お客様より、もっと安くならないか、開発生産性向上できるでしょう、と半ば当然のように頼まれることがある。
早く安く高品質でという依頼は、牛丼じゃないんだからと思っても、他ならないお客様の依頼だからと、頑張って安くしよう効率化しようと考えるのは、もちろん正しいのだけど、やり方によってはリスクが高く大変になるということを今回は書いてみます。
僕は正直、何度か失敗しています。
プロジェクトこれをやると失敗する【開発生産性向上はリスクあり】
ポイントは、システム開発は、やるべきことを簡略化すると後の工程でツケが回ってきて、結局は品質低下、納期遅延、コスト増加につながる、ということです。
生産性向上への対策あるある
「もう少し安くならないかね、２、３割くらいなら生産性あがってもいいのだが」
お客さんからこんなことを依頼されると、プロジェクトを受注するためについついやってしまうこと。
１．ドキュメントの削減。
「わかりました、では納品するドキュメント-仕様書を減らし、画面は実画面で確認ということでいかがですか」
２．テスト工数の削減。
「単体テストは画面単位にして、共通モジュールとかのテストはそこで実施することで、テスト減らします」
３．共通化への期待
「画面の類似性を調査しましたが、３０％は同じで共通化しますので画面の開発費用は低減させてもらいます」
４．新規ツール/新技術の適用
「新しい開発ツールと新しい技術を適用すれば、工数削減されそうなので使わせてもらいます」
５．根性論/ブラック企業/下請け叩き
「わかりました費用低減がんばります」
「おまえら、頑張れ！」
「お客さんから３割削減を頼まれたので、安く頼みます」
よくある話を書いてみましたが、感覚で工数を削減するとリスクが高いです。
【ドキュメント削減】
ドキュメントを削減してはならない理由は、仕様書や設計書を書くというのは、書くことだけをやっているわけではなくて、その時間の中で実際には、仕様の詳細を確かめ実現できるかを確認したり、プログラムの構造を考えたりしているからです。
単純に手を動かしてものを書いているだけではないからです。
実際に仕様書・設計書を記述している時間は、設計なら設計工程の２割とかにも満たないのではないでしょうか。
それなのに、ドキュメントを記述しないからと費用・工数を半分にしたら、設計不十分で後の工程で不具合が頻発したり、作り方がわからないということで予定よりも時間ががかってしまったりします。
また、設計工程で検討すればわかったことが、検討していないため後工程でわかって、全体に影響のある課題の場合には、手戻りの工数・費用が発生してしまいます。
設計ドキュメントを削減していいのは、わざわざ紙に設計書を落とさなくとも、頭で設計して手元にすこしメモする程度でプログラムを書けてしまう人だけです-全体の１割にもみたないと思います。
また、仕様書を削るのは、同じ会社のシステムでアジャイルなどの確認しながら進めるのであれば可能ですが、お互いに契約でなりたっている場合、言った言わないでもめる可能性もあり、おすすめできません。
唯一不要なものがあると思うのは、日本語でプログラムレベルの記述をしており、それをコーダー（プログラムに翻訳だけする人）に渡してコーディングしてもらっている場合です。その日本語プログラム（詳細の設計書）は不要です。
プログラミング言語ってその名前の通り言語なので、日本語で書くのは無駄だからです。
もちろん、大規模プロジェクトの場合やお客様への納品として必要な場合など、プロジェクトマネージャの判断で実施することですが。
【テスト工数削減】
テスト工程を削減するのは、論外です。どこかでエラーがでるし、いくら品質低下の話をお客様と調整していても、バグがでたら結局、開発側が悪いと責任問題になってしまいます。
【共通化への期待】
画面が３０％類似でも、見た目だけの話で、処理が異なれば共通化は難易度が高いです。
そもそも通常は、共通部品をつくったといっても通常は、エラー表示部分とかログの出力とか、完全同一の業務処理とかで、全体の数％というのが一般的なプロジェクトです。
実際には共通化というよりは、コピーして製作するから早くできあがるというパターンで、テスト工数は必要になるため、工数が削減になっても、類似している割合ほどは削減しないので注意が必要です。
【新規のツールや技術の適用】
事前に適用検証をやってから適用するべきです。
以前、海外でつくったコンパイラ（Ｃ＋＋）を日本ではじめて使用したときに、そのバグで大変でした。
昼間日本でバグだしして、夜海外で修正するというのを数カ月続けたプロジェクトは、その半数が体を壊して入院しています。
技術的にあたらしいものではなくても、はじめてつかうものには習得期間と工数がかかります。十分な検証をしてから適用すべきです。
【根性論/ブラック企業/下請け叩き】
やめましょう。
メンバーや協力していただける会社を守るのも、プロジェクトマネージャの大切な仕事です。
生産性向上はこれをやれ
実は生産性があがる方法
本気で生産性向上を狙うのであれば、生産性の高い優秀なメンバを雇うか、抜け漏れのないドキュメントで手戻りをなくす、日々しっかりした進捗・課題管理を行うというところになります。
ドキュメント、管理については、簡略化とは逆のことをすると、実は生産性があがるのだと数十のプロジェクトの経験から確信しています。
１．生産性の高い優秀なメンバーを雇う
プログラミングの生産性ほど個人差のでるものはありません、プロジェクトを成功させるためにも技術力の高いメンバは確保すべきです。
小規模（数十人月程度）までであれば、優秀さの度合いにはよりますが一人優秀なプログラマがいれば、開発に関してはそれだけで円滑にすすめられると思います。
プロジェクトマネージャとして注力すべきは、優秀な人材確保がお勧めです。
大規模・中規模でも同じですが、単純にその人にプログラムを頼むのではなくて、１本目の開発を優秀な人材にやってもらい、できた結果を展開するという策でプロジェクト全体の生産性向上が狙えます。
展開する場合には、十分テストして品質は保証しておいてください。またそのプログラムの説明書（変更方法のガイド）があると、さらに効率があがります。
２．ドキュメントをしっかり記述する
お客様のつくりたいものは、お客様が知っているもので開発する側はそれを請け負っているというのが、日本では一般的です。
また設計書を記述した人間とプログラミングをする人が異なる場合もあります。
情報伝達のベースが仕様書・設計書である場合、納期や品質が厳しいプロジェクトであればあるほど、手戻りを防ぐためにもドキュメントはしっかりと作成するのが基本になります。
３．日々メンバの進捗状況を管理する
人は納期が設定されると、その期間の中で与えられた成果を出すように行動します。
厳しいプロジェクトであればあるほど、各自がその日何をするかとその日のゴールがわかるようにして、毎日そのゴールが達成できたかをしっかり管理することが、管理工数は多少増えても結果としてプロジェクトは円滑に進むことになります。
日々の進捗といっても、連日１時間とか進捗ミーティングをやるとかいうのではなく、ＷＢＳ上で予定が完了したか遅れが発生したかを日々わかるようにしておき、遅延拡大の傾向がみえたら対策をうてば、プロジェクトの遅延は回避できます。
プロジェクトで困った時
これまでの自分の経験やノウハウをもとに、プロジェクトのコンサル、ご支援/ＰＭＯ、プロジェクトマネージャの育成などを実施しております。
もしプロジェクトでお困りの時はご相談ください。下記にリンクも貼っておきます。
