BA BLOG

要件定義力を徹底的に再構築する:⑥もっと要件定義を簡単にしていく。すなわち、大きさを小さくし簡単にする

もっと要件定義を簡単にしていく。すなわち、大きさを小さくし簡単にする

要件定義を簡単にしていくことは、これだけでは終わらない。それでも、まだ失敗する時は失敗する。それは、どんなに仕事の進め方を簡単にしても、そもそもの検討対象が非常に難しければ、やっぱり失敗してしまうのだ。1億円のシステムと1000億円のシステムでは、その難易度は全く異なる。複雑さが全く異なるからだ。ならば、なるべく複雑さを減らす方向で考えていきたい。考え方とすれば、1億円を1000個やる方が確実に成功することができる。こうしたことを考えていかなければならない。
また、新規や全面刷新をする場合は、大規模になる。そうすると、失敗の懸念はどうしてもあがる。一方、追加開発はどうだろうか。例えば、10人月の開発。こうしたものは、ほとんど失敗することはないのではないか?確かに、ゼロではなくて、DBの設定を誤った、やるべきテストケースを端折ってしまった。。。こうしたことで、導入後に障害が発生するようなことはあるが、導入までの道のりで頓挫することはほとんどない。
なぜか?それは、追加開発は規模も小さく、複雑さが非常に小さいから、大抵の人間がやり上げることができる。
人間、規模が小さく、複雑さが少ないものはやっぱりできる。幼児用のジグソーパズルは、ものの数分でできるが、何百ピースもあるパズルは何日もかかる。システムを作るということも、似たようなもので、機能数が少なく、それぞれの機能の特徴がはっきりしており、つなぎ目が似たようなものが沢山あるのではなければ、それは作りやすい。いかに複雑ではないようにしていくか。ここを突き詰めていくことが必要だ。

いかにして開発規模を小さくしていくかは、要件定義の生命線である。開発規模を小さくしていくというも、いくつかやり方がある。以降で順をおってみていこう。

まず初めに考えたいのは、パッケージの利用だ。
おわかりのように、今時一から作るなんて考えられない。既に動くという安心感は、相当効いてくる。多くの工数を浮かせることとなる。工数がかからないということは、それだけ複雑性が減っているということだ。パッケージとうのは、そもそも動く。少なくとも、動くことを前提に作られている。そういう意味で、適切な製品が選定されていると、動く部分をそのまま使い、必要な部分だけ作るようにすることで、開発の負担は大きく減らせる。
本項の主題である要件定義も、もともとのパッケージの機能をFit&Gapを明確にすることでほぼ決まってくる。ユーザーの物分かりがいい場合には、「じゃそれでいこう」という割り切りをもってくれることもある。
しかしながら、パッケージの利用がプロジェクトと簡単にして成功の確率を高めているかと言われれば、決してそういうことはないのが面白いところである。折角簡単にしたはずのパッケージ利用を、結局難しくしているのだ。多くの場合、経営、ユーザーとIT部門全員で違った複雑さを作り上げる。

良くいうことだが、カスタムで作り上げるものはオートクチュールであり、パッケージはプレタポルテである。パッケージを選んだ時点で、そのまま着るものだ。せいぜいやったとして、丈や袖を詰めるくらいだ。襟の形を変えたり、ボタンをファスナーにしたり、はては半袖を長袖にしたりする人はいないだろう。
経営はグローバルスタンダードなんだから、そのままやれという。あるいは、他社も入れているのだから、自分達もそれでいいじゃないかという。しかし、業務の外部要因、例えば商慣習や取引慣行、個別化を求める競争環境、社内の組織形態、管理者の役割などが異なっているのに、そのままやれるわけはない。
ユーザーは、「システムは道具である。道具は、やりたいことを実現するためにある。」ということを言う。しかし、プレタポルテを買った時点で、自由にファッションを考えることは無理である。着こなしやアクセサリでやりたいことは実現しなければならない。本来ならば、非常に制約をされているのではあるが、どうもそのあたりの感覚が掴めない。
IT部門は、なんとなくわかっているのではあるが、「システムは金をかければ何でもできる」と考えてしまうことで、結局はユーザーの言うことを聞いてしまうことにある。ここは、実は我慢しなければならないところを、突破されてしまうことがままある。

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

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

複雑さというものが、どこにあるか。それは、1000人月、すなわちざっくりと言えば、10億円の開発規模に一つの目安があるように感じる。あるデータでは、10億円を超えるプロジェクトの80%は失敗するそうだ。なんらかの形で、予算の超過、スケジュールの遅延や障害率の悪化が起きていくらしい。
10億円規模となると、100人規模のプロジェクトでほぼ1年開発することになる。100人も人がいれば、働かない、有能ではない人も沢山出てくる。有能なプロジェクトマネジャーが良くいうことだが、100人いれば、10人ほど有能な人がいればいい方だ。有能ではない人は何もしないだけならまだいいのだが、有能な人にしりぬぐいをさせるなど、マイナスの影響を与える人だっている。こう考えると、プロジェクトが上手くいくほうがおかしいのではないかと思えてくる。
しかも、最近、特に日本においてはIT業界に入ってくる人は、Best & Brightestではない。少なくとも、そういう傾向が顕著になってきている。それは、プロジェクトマネジャーにしてもそうだし、その配下のエンジニアも同様だ。こういう状態なので、本来は失敗を潰すリスク管理の方が重要となる。成功を出すことよりも、失敗の回避の方こそ考えなければならない状態だ。

だから、10億円未満で作る方法を考えたい。
全体として、50億円になりそうならば、5つに分割して作ることを考えたい。ちょっと前に流行った方法だが、まずはI/F基盤を整備してI/Fをすべて当基盤に通すようにし、情報の最終利用系である情報系、すなわちダッシュボードをまず先に整備する。この段階では歯抜け状態だが、やむを得ない。そして、受注部分を作り、最後の発注部分とその周辺機能を作るなど。
こう書いてしまうと簡単なのだが、なかなかに難しい。
まずは、予算の壁だ。システムは高額だ。高額の申請は現代では特に申請しにくい。何本にも分けて申請が上がるのは、経営からまたか?と言われてしまい、とてもやりにくい。こうした問題に対処するために、「プログラム管理」という名称でかつ複数プロジェクトで統合的にROIを管理するという考え方がないわけではないが、そうした管理体制が整っているなんて全く期待できない。
次に時間の壁。段階的に作るのはいい面が沢山ある。習熟した開発陣が次から次へのシステム構築にあたることができ、生産性が後稼働のシステムほど高くなる。ケースが乗数的に少なくなり、システムテストが楽になる。その分、プロジェクト管理や一つ当たりのスケジュールが速くなる。だから成功の可能性もあがるのだが、如何せん、開始から終了までの期間が長い。期間が都合5年かかるということなどざらで、3年間以上かかることも覚悟しなければならない。そうなると、途中で経営陣が変わる、コアとなる幹部層が人事異動することなどもざらで、プロジェクトへの波風を乗り切ることが難しくなるうえ、現代の速度重視の経営とは少々折り合いが付きにくい。

では、どうするのか。
ここには、発想の転換が必要だと考えている。答えは、「作り続ける」ことにある。大規模なシステム開発の場合、「次世代」とか「次期」とか、そういう呼び方をしていくことが多い。すなわち、自然と投資をする局面としない局面をわけて考えていることが多い。ある局面で大規模投資をして、ある局面では休む。システムの利用年数は、ある調査によれば平均17年という結果もあるが、数年大規模投資を行って10数年は保守・運用費用でしのぐというやり方だろう。
この業務的慣習は、歴史的な経緯によると筆者は考えている。最初に作ってから、HW等が老朽化してきて作り直す、新たなソリューションが現れて作り直すということが行われてきているが、そうしたサイクルをそのまま今も継続しているのであろう。どのシステムも数世代を経ており、大規模化、複雑化しており、これらを作り直すことは大予算化、長期化することは当然であり、失敗の可能性は極めて高い状態である。だから、一定の投資をし続け、作り続けることを考え、どんどん生産性を上げるような形にしていくべきだ。
これは、経営からしてみると、財務的なインパクトがないうえ、毎年効率化効果を期待できるモデルでもある。理解さえしてもらえれば、経営は数年サイクルでやってくる大規模投資を考える必要性はなくなってくる。財務的には固定化が進んでいくからだ。欧米の大企業ではこの考え方を取り入れるとこも沢山ある。インドやイスラエル、東欧、南米などに大規模開発センターを作るところがそうだ。欧米の技術者よりも、これらの国の「オフショアセンター」の開発者は安い。こうした技術者を大量に抱え、これらの技術者が作れる分だけ、システムを作り替えていくのだ。

後述で語っていくこととなるが、これらは要件定義力の問題ではなく、戦略の問題である。戦略を立てることで、要件定義を簡単にしていく。そうしたIT部門の業務の再構築が、失敗を減らす肝となっていくのだ。
しかしながら、こうした戦略施策を用いることは、次の段階だろう。ここはやはり、オーソドックスな施策を考えておきたい。それは、月並みな言い方なのであるが、経営とユーザーに諦めてもらう努力をすることだ。経営とは、「やれ、急げ、安くやれ、障害は出すな」としか言わない。そこに、優先順位をつけてもらうことだけは、やっておこう。最近は、経営も随分とものわかりが良くなってきていると感じる。要件定義をきちんとやらないとシステム開発は失敗するということは理解している。十分だ。


プロフィール

宮本 認 Mitomu Miyamoto
BA参画前は、某外資系ファームで統括を務める。17業種のNo1/No2企業を経験した異色のIT戦略コンサルタント。

年別アーカイブ