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

要件定義力の再構築(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 記事を毎朝メールでまとめ読み(登録無料)

ZDNET Japan クイックポール

自社にとって最大のセキュリティ脅威は何ですか

NEWSLETTERS

エンタープライズ・コンピューティングの最前線を配信

ZDNET Japanは、CIOとITマネージャーを対象に、ビジネス課題の解決とITを活用した新たな価値創造を支援します。
ITビジネス全般については、CNET Japanをご覧ください。

このサイトでは、利用状況の把握や広告配信などのために、Cookieなどを使用してアクセスデータを取得・利用しています。 これ以降ページを遷移した場合、Cookieなどの設定や使用に同意したことになります。
Cookieなどの設定や使用の詳細、オプトアウトについては詳細をご覧ください。
[ 閉じる ]