「90対90の法則」というのを最近知りました。
これは、システム開発においてよく言われる言葉だそうで、Wikipediにもこの言葉の解説ページがあります。
Wikipedia
簡単に説明すると、システム開発で90%ぐらい終えた段階で残りの10%は、それまでの90%と同じぐらいの時間がかかるということです。
これを聞いた時に、90%の時点を50%と考えるとわかりやすいんじゃね？と思いがちなんですが、
そうではなく、システム開発は想定を100%としたら、180%ぐらいかかるものだという事を言っているんですね。
そりゃあ、開発遅延するわ〜
残りの10%が90%かかってしまう不思議
システム開発を経験したことがある人なら誰もが納得すると思いますが、
仕事で行うシステム開発は、大体においてスケジュールが設定されています。
いつまでも作り続けていいよ・・
なんていう夢のようなスケジュールなしのプロジェクトなんて、仕事においては存在しません。
趣味で作るシステムであれば、そういうのもありかもしれませんが、仕事ではほぼタイトなスケジュールが強いられているのが現状です。
この時に、システム開発で、
α版、β版、FIX版・・・という風に版管理が行われて、FIXしたあとは、デプロイするという流れになります。
（このシステム開発というのは、ソフトウェア開発と解釈してもらったほうがいいですね）
そして、多くの場合β版開発が完了した段階で、90%の開発が完了したと考えます。
そこからFIX版まで、何をするのかというと、
検証やテストという、不具合チェックを行います。
この工程がどうしても初期設計段階では、計画を立てるのが難しく、ある程度のテスト設計を行うことは可能ですが、
実際に出来上がったシステムを下に、新たに必要なテストが生まれることのほうが多いんですね。
そのテストで、不具合が見つかったら、その不具合部分の修正をするんですが、その修正範囲が大きかったり、
そもそものUI設計などを修正する必要が出てきた場合、開発工程をα版まで遡って、開発工程をやり直す場合もあります。
そう考えると、テストからの修正作業って、
開発工程と同じぐらいのボリュームが発生しがちというのもわかなくもなんですよ。
実際に、開発をしているエンジニアからすると、毎回、大体こういう流れになるというのが、このラスト90%です。
ちゃぶ台ひっくり返しの刑
テスト検証の時に発生しがちな、仕様変更って、エンジニアにとっては、これまでやってきた自分たちの作業をなかったものにする、「バルス」的な魔法の呪文でもあります。
多くの場合、システムがわからずに設計を行っている人が、
- ココの使い勝手が良くないから、別の見え方に変更しよう
なんて気軽に、コーヒー飲みに行こうよ感覚で言い出します。
もちろん、そうした方がいいという認識もあるので、無下には断れないんですが、このときのエンジニアの心の中は、
一生懸命作った晩ごはんを、
星一徹がちゃぶだいごとひっくり返してしまう、
その時の星明子のような気分になることでしょう。
技術を知らないことが悪なのか？
技術を知っていてムチを打つほうが悪なのか？
それは、開発プロジェクト内の人間関係によりますが、とにかく、テストにおける仕様変更には膨大な時間が要するということを理解して、開発工数と向き合う必要があるということですね。
中には、
仕様変更があってもスケジュール変更はされないという現場も少なくない・・・とか・・・
営業が言った一言
自分が企業内で、エンジニアをしていた頃の話です。
案件を取ってくる営業が、何気なく言った一言を今でもよ〜く覚えています。
開発工程を理解できていなかったその営業の彼は、思った本音を言ったに過ぎないんでしょうが、
90対90の法則を彼が理解しているはずもないので、システムが出来上がった！と言われた時から、完了するまでがいつも遅くて、なんか予定よりも遅延する事に大して思っただけなんでしょうが、
同じように営業でも、
見積書出してから、注文書をもらうまでと似たようなものだと説明したら、なんとなく納得していました。
モックアップがβ版？！
新しいものを作る時に、どういう触り心地かを確かめるために、システムでもモックアップというのを作ることがよくあります。
個人的にはこのモックアップ作りが得意だし、趣味的に行ってもいます。（このブログがまさにそうですね）
しかし、このモックアップを作った段階で、「これええやん！」と言って、そのままロンチしようとしたがる早漏な人は結構いっぱいいます。
- これ売れるやん！
- このままでええやん！
- 開発コスト浮いたな！
なんていうセリフをよく聞きますが、モックアップはあくまで試作品。
これをそのまま製品として出すにはあまりにも稚拙。
見た目はいいけど、未熟な幼子を、そのまま社会に放り出すようなものです。
もちろん、ある程度の整えは行いますが、そこからの開発スケジュールは、90対90の、初回の90%を終えていると思わないでもらいたい。
モックアップの時点では、最初の設計が少し短くなる程度でむしろ
0%スタートであることを認識しておかなければいけません。
あくまで方向性を確認するのが試作品ですからね。
あとがき
90対90の法則は、なかなかシステム開発現場以外では理解されにくい内容かもしれませんが、
これが伝わっていないから、開発が想定以上に毎回遅延しているという事実が理解できないんでしょう。
それを考えると、見積もり段階や設計段階でテストスケジュールを大幅に取っておくことも重要ですが、
「テスト長すぎん？」
と、マネージャーの立場の人から削り取られる可能性も高いので、
設計者は、そこの書き込みをしっかりとしておくようにスキルを身に着けましょう。
あと、web制作でも、90対90の法則が働いていると思ったのは、デザインがfixしているのに、出来上がったホームページを実際にさわってからの変更依頼が、見積もりには含まれていないので、
ここから90%の工数がかかることがこれまでほとんどの案件で発生していました。
自分の仕事にも影響する90対90の法則、改めて見直して、なんとかうまく活用できるようにしてみたいと思います。
0 件のコメント:
コメントを投稿