しかし、毎回と言って良いほど、プロジェクトの最終段階で炎上している。
原因を分析すると、プロジェクトの開始時にクライアントと決めておかないといけないことを、やってないための場合が多い。
そのため、クライアントの要望が増大し、無理に要望を組み込む事で、品質が大きく低下する状況になる。また、プロジェクトが炎上し、そこに携わるエンジニアに多大な負担をかけることになる。
エンジニアは、ロボットではないし、資源でもない。使えなくなれば、変えれば良いということにはならないし、エンジニアを多く抱え込めばうまくいくわけでもない。
プロジェクト開始前に決めておくこと
少なくとも以下のことについては、プロジェクトを始める前に決めておく必要がある。これを怠ると、プロジェクトの最終段階で、炎上する可能性が高い。
開発理由の確認
まずは、クライアントがシステム開発を必要と考えた理由について、共有する必要がある。詳細を聞き、システム開発が本当に必要なのかを確認する。もしかすると、マクロを作ることで解決できるかもしれない。
ビジネスとしては、システム開発を行う方が利益を得れるので、プロジェクト化したい気持ちは分かる。しかし、使用されないシステムを開発するよりも、必要とされているものを作ることの方が、クライアントにとっては良いし、空いた時間で、別の開発をすることで、結果的に、利益を最大化できる可能性がある。
機能確認
開発理由を充分に共有できた上で、必要となる機能について決めて行くことになる。ここで、決めるのは、開発理由で上がった問題を解決するために必要となる最低限の機能である。
間違えてはいけないのは、外部設計でないことだ。UIは、設計段階で行えば良いし、細かい機能を言い出すと時間がいくらあっても足りなくなる。
ここで決めた機能については、納品する時に実装されていないといけない機能となる。
マイルストーン確認
次に必要となるのは、どの機能をいつまでに確認できる環境に上げるかということだ。開発方法によっても違ってくるかもしれないが、マイルストーンを決めておくことで、どんな仕様をいつまで用意してもらうのかを決めて行くことができるようになる。
また、クライアントからの要望を、どこまで取り入れるかの基準となる。
たまに、開発スケジュールを立てた上でマイルストーンを決めるプロジェクトがあるが、これは、エンジニアの負担をかけることになるし、クライアントからの要望を追加できない。
ウォーターフォールで開発するのであれば、各段階ごとに受けるクライアントのレビューでマイルストーンを決めることができる。
アジャイルで開発するのであれば、どの機能から作って行くか、どの段階でクライアントの確認が必要となるのかでマイルストーンを決めることができる。
ステークホルダ
ここで決めないといけないことは、お互いの窓口だ。クライアントにとって、開発側の窓口は、１つであった方が連絡が取りやすい。開発する側も、クライアントの窓口は１つ良い。それに加え、利害関係にある相手には、状況を共有しておく必要がある。
炎上するプロジェクトの特徴として、開発が進むにつれて、ステークホルダが増えて行く。ステークホルダが増えると、情報の共有に時間が必要となるし、突然、仕様が変更され、後戻りが大きくなる可能性が増える。
複数の企業が参画するプロジェクトの場合は、それぞれの窓口を確認する。
Q&A管理
クライアントと開発者との質問を管理する方法を決める。エンジニアであれば、お馴染みのことであるが、クライアントにとっては、使い方を知らない場合が多い。どのように記載するのか、どのように対応するのか、そして、どのように管理するのかを共有する。
この管理方法を共有できないと、複数の方法で質問がきたりする。ファイル、メール、チャット、電話…。
Q&Aの管理ができないと、プロジェクト後半で、言った、言わないの問題となり、プロジェクトは炎上して行く。
要望管理
多くのプロジェクトでは、要望の管理をしていない。なので、クライアントは、Q&Aに要望を記載する。しかし、Q&Aと要望は別であり、それぞれ管理しないといけない。
これまで、Q&Aに記載された要望は、エンジニアが抜き出して別管理していたところが多いのではないだろうか。
しかし、それでは、エンジニアの時間が開発以外の作業に費やされてしまう。それに、クライアントが要望と感じていないため、不具合となってしまう場合が多い。
リスク管理
これも、多くのプロジェクトで管理されていないのではないだろうか。
リスク管理で必要となるのは、どのような要因がプロジェクトの失敗に繋がるかをクライアントと共有することである。それぞれの要因について閾値を作り、定量的に管理していく必要がある。
そして、リスクが発生した場合の対応方法と共有しないといけない。ここでやっていけないのが、残業や休出で対応するということ。対応方法が、エンジニアに負担をかけて対応するのは、プロジェクト内で行うことであり、クライアントと共有することではない。
そもそもの要因が、クライアントによるものである場合は、エンジニアへの負担を最小限にできるよう対応方法を共有しておかなければいけない。
進捗管理
これは、多くのプロジェクトでやってるよ、と言われるが、それはクライアントと共有できているのでしょうか。月１や週１の進捗会議などで状況報告して終わりではないだろうか。それに、進捗の使い方をクライアントが理解していない可能性もある。
クライアントとしては、開発がどれほど進んでいるか以外に、確認がいつ必要になるかを知りたいのではないだろうか。クライアントは、実作業があるのだから、確認のために予定を早めに立てる必要がある。早めに確認できるのであれば、早く確認したい場合もあるだろう。
プロジェクトとしては、予定と実績を記録しておくことで、分析や今後のプロジェクトの参考にすることができる。
不具合管理
これも、多くのプロジェクトでやってるよ、と言われるのではないだろうか。
しかし、不具合管理で必要なので、出来上がった機能やシステムの品質を上げることである。そのために、必要となる不具合の量など、定量的に閾値を決めて、クライアントの要望する品質を担保する必要がある。
上記の「Q&A管理」「要望管理」「リスク管理」「進捗管理」「不具合管理」については、できれば、リアルタイムでクライアントと共有できるようにしたい。表計算ソフトで共有している場合がよくあるが、これは、内容が入れ子になって、漏れる可能性がある。それに、バージョンによりレイアウトが変わったりするため、共有するためのコストがかかってくる。
環境
これは、プロジェクトごとに作成するタイミングが違うのかもしれない。しかし、どれだけの環境が必要になるのかを、クライアントと共有しておく必要がある。
最低、以下の環境は必要になるのではないだろうか。
・本番環境
・ステージング環境
・開発環境
特に、本番環境をどう運用していくのかを決めておかないといけない。それによっては、本番環境をどこが構築するのか、ステージング環境を開発完了後どうするのかを決めないといけなくなる。
セキュリティの問題もここで決めておいた方がいいのかもしれない。既知のセキュリティ問題と、今後のセキュリティ問題に対する対応についても決めておくと、意識のズレが少なくてすむのかもしれない。
納品物
最終的に納品物について決めておく必要がある。よくあるのが、プロジェクト完了後に設計書が欲しいなどが出てくる場合がある。しかし、納品ようにドキュメントを作成するとなると、コストがかかるということをクライアントと共有しておかなければならない。
ドキュメントやソースコードには、著作権が発生することも、共有しておかないと、後々問題になることが多い。
今回は、私が、プロジェクト開始前にクライアントと決めておかないといけないと考える内容を記載した。と言うよりも、炎上した場合に後悔した内容をまとめた。
