要件定義力を徹底的に再構築する:6もっと要件定義を簡単にしていく。BLOG2017.12.15要件定義力を徹底的に再構築する:6もっと要件定義を簡単にしていく。大きさを小さくし簡単にするもっと要件定義を簡単にしていく。大きさを小さくし簡単にする要件定義を簡単にしていくことは、これだけでは終わらない。それでも、まだ失敗する時は失敗する。それは、どんなに仕事の進め方を簡単にしても、そもそもの検討対象が非常に難しければ、やっぱり失敗してしまうのだ。1億円のシステムと1000億円のシステムでは、その難易度は全く異なる。複雑さが全く異なるからだ。複雑さを減らす方向で考えていきたい。考え方とすれば、1億円を1000個やる方が確実に成功することができる。したことを考えていかなければならない。新規や全面刷新をする場合は、大規模になる。すると、失敗の懸念はどうしてもあがる。追加開発はどうだろうか。したものは、ほとんど失敗することはないのではないか?確かに、ゼロではなくて、DBの設定を誤った、やるべきテストケースを端折ってしまった。したことで、導入後に障害が発生するようなことはあるが、導入までの道のりで頓挫することはほとんどない。?それは、追加開発は規模も小さく、複雑さが非常に小さいから、大抵の人間がやり上げることができる。人間、規模が小さく、複雑さが少ないものはやっぱりできる。幼児用のジグソーパズルは、ものの数分でできるが、何百ピースもあるパズルは何日もかかる。システムを作るということも、似たようなもので、機能数が少なく、それぞれの機能の特徴がはっきりしており、つなぎ目が似たようなものが沢山あるのではなければ、それは作りやすい。複雑ではないようにしていくか。ここを突き詰めていくことが必要だ。して開発規模を小さくしていくかは、要件定義の生命線である。開発規模を小さくしていくというも、いくつかやり方がある。以降で順をおってみていこう。初めに考えたいのは、パッケージの利用だ。おわかりのように、今時一から作るなんて考えられない。動くという安心感は、相当効いてくる。多くの工数を浮かせることとなる。工数がかからないということは、それだけ複雑性が減っているということだ。パッケージとうのは、そもそも動く。少なくとも、動くことを前提に作られている。いう意味で、適切な製品が選定されていると、動く部分をそのまま使い、必要な部分だけ作るようにすることで、開発の負担は大きく減らせる。本項の主題である要件定義も、もともとのパッケージの機能をFit&Gapを明確にすることでほぼ決まってくる。ユーザーの物分かりがいい場合には、「じゃそれでいこう」という割り切りをもってくれることもある。パッケージの利用がプロジェクトと簡単にして成功の確率を高めているかと言われれば、決してそういうことはないのが面白いところである。簡単にしたはずのパッケージ利用を、結局難しくしているのだ。多くの場合、経営、ユーザーとIT部門全員で違った複雑さを作り上げる。いうことだが、カスタムで作り上げるものはオートクチュールであり、パッケージはプレタポルテである。パッケージを選んだ時点で、そのまま着るものだ。やったとして、丈や袖を詰めるくらいだ。襟の形を変えたり、ボタンをファスナーにしたり、はては半袖を長袖にしたりする人はいないだろう。経営はグローバルスタンダードなんだから、そのままやれという。他社も入れているのだから、自分達もそれでいいじゃないかという。業務の外部要因、例えば商慣習や取引慣行、個別化を求める競争環境、社内の組織形態、管理者の役割などが異なっているのに、そのままやれるわけはない。ユーザーは、「システムは道具である。道具は、やりたいことを実現するためにある。プレタポルテを買った時点で、自由にファッションを考えることは無理である。着こなしやアクセサリでやりたいことは実現しなければならない。本来ならば、非常に制約をされているのではあるが、どうもそのあたりの感覚が掴めない。IT部門は、なんとなくわかっているのではあるが、「システムは金をかければ何でもできる」と考えてしまうことで、結局はユーザーの言うことを聞いてしまうことにある。ここは、実は我慢しなければならないところを、突破されてしまうことがままある。パッケージを選ぶということは、ベストプラクティスを買うことではない。ユーザーのやりたいことを実現することでもない。システム開発を簡単にするために選ぶ。そこを間違ってはならない。一つ、簡単にしていく方法がある。最近でこそ見られなくなってきているが、昔は家を増築した。いう我が家もそうであった。初めに平屋で3DKの家を建てる。その後、姉と私が大きくなり、二人の部屋を中心に二階建てに増築する。分けて作ることができれば、資金的にも、大工さんを抱える難易度も、資材の調達しやすさも変わり、棟梁に求められる工期と品質の管理力も格段に下がることとなる。要は、複雑さを分散することができるのだ。複雑さというものが、どこにあるか。それは、1000人月、すなわちざっくりと言えば、10億円の開発規模に一つの目安があるように感じる。あるデータでは、10億円を超えるプロジェクトの80%は失敗するそうだ。なんらかの形で、予算の超過、スケジュールの遅延や障害率の悪化が起きていくらしい。10億円規模となると、100人規模のプロジェクトでほぼ1年開発することになる。100人も人がいれば、働かない、有能ではない人も沢山出てくる。有能なプロジェクトマネジャーが良くいうことだが、100人いれば、10人ほど有能な人がいればいい方だ。有能ではない人は何もしないだけならまだいいのだが、有能な人にしりぬぐいをさせるなど、マイナスの影響を与える人だっている。考えると、プロジェクトが上手くいくほうがおかしいのではないかと思えてくる。Brightestではない。少なくとも、そういう傾向が顕著になってきている。それは、プロジェクトマネジャーにしてもそうだし、その配下のエンジニアも同様だ。いう状態なので、本来は失敗を潰すリスク管理の方が重要となる。成功を出すことよりも、失敗の回避の方こそ考えなければならない状態だ。10億円未満で作る方法を考えたい。全体として、50億円になりそうならば、5つに分割して作ることを考えたい。前に流行った方法だが、まずはI/F基盤を整備してI/Fをすべて当基盤に通すようにし、情報の最終利用系である情報系、すなわちダッシュボードをまず先に整備する。この段階では歯抜け状態だが、やむを得ない。受注部分を作り、最後の発注部分とその周辺機能を作るなど。書いてしまうと簡単なのだが、なかなかに難しい。