コンサルティング現場のカラクリ

要件定義力の再構築(5):大きさを小さく、もっと要件定義を簡単に

宮本認(ビズオース ) 2019年03月09日 07時00分

  • このエントリーをはてなブックマークに追加
  • 印刷

(本記事はBizauthが提供する「BA BLOG」から転載、編集しています)

 要件定義を簡単にしていく取り組みは終わらない。ここまでやっても、失敗するときは失敗する。どんなに仕事の進め方を簡単にしても、そもそもの検討対象が非常に難しければ、やはり失敗してしまうのだ。1億円のシステムと1000億円のシステムでは、難易度が全く異なる。複雑さが大きく違うからだ。ならば、なるべく複雑さを減らす方向で考えていきたい。考え方とすれば、1億円を1000個やる方が確実に成功することができる。こうしたことを考えていかなければならない。

 また、新規導入や全面刷新をする場合は、規模が大きくなる。そうすると、失敗の懸念が高まる。一方、追加開発はどうだろうか。例えば、10人月の開発であれば、ほとんど失敗することはないのではないか。確かに、確率はゼロではない。「データベースの設定を誤った」「やるべきテストケースを端折ってしまった」――、こうしたことで導入後に障害が発生するようなことはあるが、導入までの道のりでとん挫することはほとんどない。

 なぜか。追加開発は規模も小さく、複雑さが非常に小さいから、たいていの人がやり遂げられるためだ。幼児用のジグソーパズルは、ものの数分でできるが、何百ピースもあるパズルは何日もかかる。システム開発も似たようなもので、機能の数が少なく、それぞれの特徴がはっきりしており、つなぎ目がシンプルであれば作りやすい。いかに複雑さを排除するか、ここを突き詰めていく必要がある。

 いかに開発規模を小さくできるかは、要件定義の生命線である。それにも幾つかのやり方がある。以降で順を追って見ていこう。

 最初に考えたいのはパッケージの利用だ。いまどき、一から作るなど考えられない。既に動くという安心感は相当に効いてくる。多くの工数を浮かせることとなる。工数がかからないということは、それだけ複雑さが減っているということだ。パッケージというのは、少なくとも動くことを前提に作られている。そういう意味で、適切な製品が選定されていると、動く部分をそのまま使い、必要な部分だけ作るようにすることで、開発の負担を大きく減らせる。

 本項の主題である要件定義も、パッケージの機能をもとにフィット&ギャップ分析をすることでほぼ決まってくる。物分かりのいいユーザーであれば、「じゃあ、それでいこう」という割り切りを持ってくれることもある。

 しかしながら、パッケージを利用すれば、プロジェクトが簡単になって成功の確率が高まるかと言われれば、決してそういうわけでない。そこが面白いところである。せっかく簡単にしたはずのパッケージ利用を、結局難しくしているのだ。多くの場合、経営者、ユーザー、IT部門の全員で違った複雑さを作り上げている。

 カスタムで作り上げるものはオートクチュール(注文服)であり、パッケージはプレタポルテ(既製服)である。パッケージを選んだ時点で、そのまま着るものだ。せいぜいやったとして、丈や袖を詰めるくらいだ。襟の形を変えたり、ボタンをファスナーにしたり、はては半袖を長袖にしたりする人はいないだろう。

 経営者は、グローバルスタンダードなんだからそのままやれと言う。あるいは、他社も入れているのだから、自分たちもそれでいいじゃないかと言う。しかし、業務の外部要因、例えば商慣習や取引慣行、個別化を求める競争環境、社内の組織形態、管理者の役割などが異なっているのに、そのままやれるわけはない。

 ユーザーは、「システムは道具である。道具はやりたいことを実現するためにある」ということを言う。しかし、プレタポルテを買った時点で、自由にファッションを考えることは無理である。着こなしやアクセサリで実現するほかない。本来ならば、非常に制約された状態であるのに、どうもその辺りの感覚がつかめない。

 IT部門は、その辺の事情を何となく分かっているのだが、「システムは金をかければ何でもできる」と考えてしまうことで、結局はユーザーの言うことを聞いてしまう。ここは死守しなければならないところを、突破されてしまうことがままある。

 パッケージを選ぶというのは、ベストプラクティスを取り入れることでも、ユーザーのやりたいことを実現することでもない。システム開発を簡単にするためということを間違ってはならない。

 もう一つの方法は、分けて作ることだ。最近でこそ、あまり見られなくなったが、昔は家を増築した。そういう我が家もそうだった。最初は平屋で3DKの家を建てた。その後、姉と私が大きくなり、二人の部屋を中心に二階建てに増築した。分けて作ることができれば、資金的にも、大工を抱える難しさも、資材の調達しやすさも変わり、棟梁に求められる工期と品質の管理力も格段に下がる。要は、複雑さを分散できるのだ。

 複雑さというものがどこにあるか。それは、1000人月、すなわちざっくりと言えば、10億円の開発規模に一つの目安があるように感じる。あるデータでは、10億円を超えるプロジェクトの80%は失敗するそうだ。何らかの形で予算の超過やスケジュールの遅延、障害率の悪化が起きていくらしい。

 10億円規模となると、100人規模のプロジェクトでほぼ1年開発することになる。100人も人がいれば、働かない人や有能でない人も出てくる。有能なプロジェクトマネージャーが良く言うことだが、100人の中に10人も有能な人材がいれば良い方だ。有能でない人は何もしないだけならまだいいのだが、有能な人に尻拭いをさせるなど、マイナスの影響を与える人だっている。こう考えると、プロジェクトがうまくいく方がおかしいのではないかと思えてくる。

 しかも最近、特に日本において、IT業界に入ってくる人は、best and brightest(最も優秀な人材)ではない。少なくとも、そういう傾向が顕著になってきている。それは、プロジェクトマネージャーにしてもそうだし、その配下のエンジニアも同様だ。こういう状態なので、実は失敗を潰すリスク管理の方が重要となる。成功を出すことよりも、失敗の回避の方こそ考えなければならない状態だ。

 だから、10億円未満で作る方法を考えたい。全体として、50億円になりそうならば、5つに分割して作るようにする。ちょっと前に流行った方法だが、まずはインターフェース部分を整備して全てそこを通すようにする。そして、ダッシュボードなどの情報系を整備する。この段階では歯抜け状態だが、やむを得ない。その後、受注部分を作り、最後の発注部分とその周辺機能を作りこんでいく。

 こう書いてしまうと簡単なのだが、なかなかに難しい。

 まずは予算の壁だ。システムは高額になる。何本も分けて申請が上がると、経営者から「またか?」と言われてしまい、とてもやりにくい。こうした問題に対処するため、「プログラム管理」というやり方を使って複数プロジェクトで統合的に費用対効果(ROI)を管理するという考え方がないわけではないが、そうした管理体制が整っているとも限らない。

 次に時間の壁。段階的に作ると良い面がたくさんある。習熟した開発陣が次から次へとシステム構築に当たることができ、後稼働のシステムほど生産性が高くなる。ケースが乗数的に少なくなり、システムテストが楽になる。その分、プロジェクト管理や1つ当たりのスケジュールが早くなる。だから成功の可能性も上がるのだが、いかんせん、開始から終了までの期間が長い。期間が都合5年かかるということなどざらで、3年間以上かかることも覚悟しなければならない。

 そうなると、途中で経営陣が変わる、中核を担う幹部層が人事異動になることなども良くあり、プロジェクトへの波風を乗り切ることが難しくなる上、近年の速度重視の経営とは少々折り合いが付きにくい。

 では、どうするのか。ここには発想の転換が必要だと考えている。答えは「作り続ける」ことにある。大規模なシステム開発だと、「次世代」や「次期」という呼び方をしていくことが多い。すなわち、自然と投資をする局面としない局面を分けて考えていることが多い。ある局面で大規模投資をして、ある局面では休む。システムの利用年数は、ある調査によれば平均17年という結果もあるが、数年にわたって大規模投資を行って、その後の十数年は運用保守でしのぐというやり方だ。

 この業務的慣習は、歴史的な経緯によると筆者は考えている。最初に作ってから、ハードウェアなどが老朽化してきて作り直す、新たなソリューションが出てきて作り直すということが行われてきているが、そうしたサイクルをそのまま今も継続しているのだろう。どのシステムも数世代を経て大規模化や複雑化が進み、作り直すと予算が大きく、期間も長くなることは当然であり、失敗の可能性は極めて高い状態である。だから、一定の投資を継続し、作り続けることを考え、どんどん生産性を上げるような形にしていくべきだ。

 これは、経営者からしてみると、財務的な影響が少ない上、毎年、効率化の効果を期待できるモデルでもある。理解さえしてもらえれば、経営者は数年サイクルでやってくる大規模投資を考える必要性がなくなる。財務的には固定化が進んでいくからだ。欧米の大企業ではこの考え方を取り入れるところも多くある。インドやイスラエル、東欧、南米などに大規模開発センターを作るところがそうだ。欧米の技術者よりも、これらの国の「オフショアセンター」の開発者は安い。こうした技術者を大量に抱え、これらの技術者が作れる分だけシステムを作り替えていくのだ。

 これらは要件定義力の問題ではなく、戦略の問題である。戦略を立てることで、要件定義を簡単にしていく。そうしたIT部門の業務の再構築が、失敗を減らすキモとなっていくのだ。

 しかしながら、こうした戦略施策を用いるのは次の段階だろう。ここはやはり、オーソドックスな施策を考えておきたい。月並みな言い方だが、経営者とユーザーにあきらめてもらう努力をすることだ。経営者とは、「やれ、急げ、安くやれ、障害は出すな」としか言わない。そこに、優先順位を付けてもらうことだけはやっておこう。最近は、経営者もずいぶんと物分かりが良くなってきていると感じる。要件定義をきちんとやらないとシステム開発は失敗するということを理解しているはずだ。

宮本認(みやもと・みとむ)
ビズオース マネージング ディレクター
大手外資系コンサルティングファーム、大手SIer、大手外資系リサーチファームを経て現職。17業種のNo.1/No.2企業に対するコンサルティング実績を持つ。金融業、流通業、サービス業を中心に、IT戦略の立案、デジタル戦略の立案、情報システム部門改革、デジタル事業の立ち上げ支援を行う。

ZDNet Japan 記事を毎朝メールでまとめ読み(登録無料)

  • このエントリーをはてなブックマークに追加

関連ホワイトペーパー

連載

CIO
月刊 Windows 10移行の心・技・体
ITアナリストが知る日本企業の「ITの盲点」
シェアリングエコノミーの衝撃
デジタル“失敗学”
コンサルティング現場のカラクリ
Rethink Internet:インターネット再考
インシデントをもたらすヒューマンエラー
トランザクションの今昔物語
エリック松永のデジタルIQ道場
研究現場から見たAI
Fintechの正体
米ZDNet編集長Larryの独り言
大木豊成「仕事で使うアップルのトリセツ」
山本雅史「ハードから読み解くITトレンド放談」
田中克己「展望2020年のIT企業」
松岡功「一言もの申す」
松岡功「今週の明言」
内山悟志「IT部門はどこに向かうのか」
林 雅之「デジタル未来からの手紙」
谷川耕一「エンプラITならこれは知っとけ」
大河原克行「エンプラ徒然」
内製化とユーザー体験の関係
「プロジェクトマネジメント」の解き方
ITは「ひみつ道具」の夢を見る
セキュリティ
セキュリティインシデント対応の現場
エンドポイントセキュリティの4つの「基礎」
企業セキュリティの歩き方
サイバーセキュリティ未来考
ネットワークセキュリティの要諦
セキュリティの論点
スペシャル
エンタープライズAIの隆盛
インシュアテックで変わる保険業界
顧客は勝手に育たない--MAツール導入の心得
「ひとり情シス」の本当のところ
ざっくり解決!SNS担当者お悩み相談室
生産性向上に効くビジネスITツール最前線
ざっくりわかるSNSマーケティング入門
課題解決のためのUI/UX
誰もが開発者になる時代 ~業務システム開発の現場を行く~
「Windows 10」法人導入の手引き
ソフトウェア開発パラダイムの進化
エンタープライズトレンド
10の事情
座談会@ZDNet
Dr.津田のクラウドトップガン対談
Gartner Symposium
IBM World of Watson
de:code
Sapphire Now
VMworld
Microsoft WPC
Microsoft Connect()
HPE Discover
Oracle OpenWorld
Dell Technologies World
AWS re:Invent
AWS Summit
PTC LiveWorx
吉田行男「より賢く活用するためのOSS最新動向」
古賀政純「Dockerがもたらすビジネス変革」
中国ビジネス四方山話
ベトナムでビジネス
日本株展望
企業決算
このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]