後戻りを恐れるな！〜情シス目線のプロジェクトマネージメントTips#07

世の中にプロジェクトマネジメントに関するコンテンツは非常にたくさんあるのですが、よく見てみるとどうしてもSIer目線のものが多いように思えます。SIer目線の場合だと、どうしても利害が一致しないせいか事業会社というか情報システム部門目線から見るとピンとこないものも多く、ちょっと腹落ちしないことが多くあります。
というわけで無いなら作ろうということで「情シス目線のプロジェクトマネジメント」なるものを書いてみようかと思い不定期だとは思いますがシリーズ的に書いていこうと思います。

システム開発における「後戻り」

よくシステム開発プロジェクトの中で合言葉のように言われるのが「後戻りしないように」という言葉です。

システム開発における後戻りとは、いわゆる前提条件が変わって「やり直し」になることです。具体的に言えば要件が大きく変わって設計がやりなおしになったり、設計が変わってしまったので、プログラム開発やテストがやりなおしになることです。

当然、その分のコストや時間は無駄になりますし、無駄な仕事や、リカバリをする余計な作業をさせられるメンバーのモチベーションも低下するでしょう。プロジェクトを進める上では「後戻りは」できるだけ避けたい事態であります。

だからプロジェクトの中で偉い人もそうでない人も「後戻りが発生しないように」という言葉が飛び交うことになるのです。

・・・・でも後戻りしないように・・・・って具体的にどうやったら出来るのでしょうか？

プログラム設計や製造であれば、しっかりとレビューしたりテストを行ったりして、あとで欠陥が出ないようにする・・・といった感じになるのですが、要件定義、仕様決定においては少し違った意味になります。

要件定義で「後戻りがないよう」にするためには

要件定義で「後戻りしないようにする」にはどうしたら良いのでしょうか？しっかりとヒアリングや調査をする。議事録を取ったり、途中で承認をもらって、あとで違うことを言われないようにする・・・・なんかが考えられます。・・・・・まぁそれは問題ないでしょう。後戻りがないように頑張ってください。

しかし要件定義フェーズにおいては「要件がまとまらない」場合があります。

わかりやすいように夕食の献立の例にしてみます。
みんなわがままで献立が気に入らなければ作り直しになる前提です。

今夜の夕食のおかずを何にしたほうが良いかヒアリングしてみましょう。

ある人はステーキが良いと言います。

ある人は焼き魚が良いと言います。

ある人は煮物が食べたいと言います。

ある人は野菜しか食べないと言います。

・・・・以下続く・・・・

今日の献立は何にしましょう？

後戻りは許されません。

そうなってしまうと献立はステーキも焼き魚も煮物も野菜も入った温泉旅館の夕食みたいなものになってしまいます。

全部揃っているので、作り直しはありません
「後戻り」は無事避けられました。

しかし・・・

ステーキを食べたい人はステーキを食べ、その他は残し・・・

焼き魚を食べたい人は焼き魚を食べて、その他は残し・・・

煮物を食べたい人は、煮物以外はチョット手を付けただけで残し・・・

野菜を食べたい人は・・・・・

・・・・・ものすごい食品ロスが発生します。

そして、夕食のコストはものすごい膨れ上がります。明日からご飯を作るお金はもう残っていません・・・・

「後戻り」を避けすぎることの弊害

システムの要件を決めるときはついついコストとか投資対効果のことを忘れがちになります。要求事項がはっきりしない場合や、要求に対立が発生している場合に後戻りを発生しないようにするためには、できるだけ多くの要求を含めた仕様を作りがちです。
考えられる一番高コストな案を採用してしまったり、どんな要求にも答えられるようにたくさんの機能を盛り込んだり・・・・みたいな事になりがちです。

結果、仕様はてんこ盛りの贅沢なものになり、プロジェクトの難易度もコストも爆上りになってしまいます。
この状態に対し顧客である事業会社としては（よくわからないから）「仕方がない」という判断になってしまったりします。

この状態は見えにくいのですが事業会社にとっては「後戻り」よりも事態は遥かに深刻です。なぜなら投資に対するビジネス効果が著しく下がってしまう、もしくは効果以上のコストが掛かってしまう事になるからです。

しかし、この状態はシステム開発会社にとっては問題ありません。要件定義の結果で開発規模が出るので、赤字にならないどころか利益は上がります。だからSIer向けのプロジェクトの教科書にはあまりこの部分は書かれません。

最近、様々なところで問題にされているのは「使われないシステム機能」です。事例によるとリリースされる機能の６０％以上が「全く使われない」もしくは「殆ど使われない」機能だそうです。
以前、自分がある検索機能を調査したときにたくさんある検索絞り込み項目のなかで実際に使われている項目の９８％がたったの２項目だったという結果が出たことがあります。超シンプルな機能にすると、設計や開発も簡単になり、テストも少ない上、検索スピードも早くなります。
残りの項目に費やした開発コストも、そのために作ったインデックスに費やされるディスク容量も、データ能力のたびに消費されるCPUやメモリも無駄になっています。

非常にもったいない

「後戻り」だけが悪ではない

これまでの話で言えるのはプロジェクトにおいて「後戻り」だけが悪ではないということです。無駄な機能を作るのはもっと悪なのです。

無駄な機能というのは、リリースするまでは問題がはっきりと現れないものです。なんとなく開発ボリュームが増え、なんとなくテストボリュームが増え、なんとなくシステム性能がでないだけで、「後戻り」ほどショックが起きません。

無駄な機能は事業会社・・・つまりシステムを維持運用する立場から見たら非常に深刻です。

最近はアジャイル開発がだんだん浸透してきてＭＶＰ（Minimum Viable Product）という考え方も広がりづつあります。まずはビジネス的な効果と比較・評価して最低限の機能でとりあえずはリリースして、ほんとうに使うようなら改めて強化する（後戻る）・・・・というようなやり方を考えるのも必要だと思います。