【EC開発体験記-開発-】命題を共有し開発者から提案する

「作っては壊す」過程があってこそ良いものが作れる

ゲーム開発者の話を聞くと作り直しはあたりまえだという。そもそも、多くの人に面白いと感じてもらうことが要件だったりするので納得のいくまで何回でも作り直す。いわゆるアジャイル開発なのだがこれが一般企業のシステム開発に採用されるにはいくつかの障壁がある。まず、一度作ったものを壊すことは心理的になかなかできないという点。開発者の立場からすれば過去に費やした時間と労力をすべて捨てさるような気分になるだろうし、発注者の立場からすれば、そんな無駄なことにお金を払いたくないと思うかもしれない。また納期が短くサービスインの日から逆算してスケジュールが組まれることが多いのも「作り直し」ができない理由の一つだろう。そこでよく陥るのは、要件定義や設計にしっかり時間をかけてやればいいとか、テストを十分にやればいいとか、一見正しそうで間違った意見に流されることだ。作りなおしてもいいがイテレーションの回数を先に決めようとか変な話になったりもする。たしかに、開発効率が悪いのは要件定義や設計をちゃんとやってないからだし、不具合が多いのはテストを十分にやってないからなのだが、そもそもこの「ちゃんとやる」ことが非常に難しいから困るのだ。ウォーターフォール型の開発の問題点はまさにここにある。次にこの記事を読んでもらいたい。

デスマーチがなくなる？
下請けは労働生産性が低い

　私は工事進行基準で解決できる話とは思わない。「ユーザーの要件定義があいまいで・・・・」とあるように、デスマーチはよく客のせいにされる。要件が決まらないとか、仕様がコロコロ変更になるのが諸悪の原因であるかのようにいう。たしかに客は何かお願いしたいことがあるから開発を依頼するのだが、要件定義や仕様をしっかり決められる客はまずいない。できるのであれば要件定義にお金を払うことはしない。一方の開発者は、客の意図・目的を積極的に理解しようとしない。彼らは意図に関係なく指示されたことだけを淡々とこなす。リスクを背負いたくないとか、いろいろ面倒なことを考えたくないので、客にそういった部分を引き受けてもらうか、元受けにマネージメントを要求する。多少単価が高くても元受けにはならず、すすんで孫受けになりたがる人さえいる。客は曖昧な命題だけをいい、開発者は具体的な指示がないと引き受けない。こうしてデスマーチの土壌が生まれる。間に入るPMが、安請け合いする場合や、マネージメント能力がない場合にデスマーチとなる。
　マネージメントは、まず要件定義をしっかりやることから始まる。私が考える要件定義とは、客のかかえている問題、悩みを解決するソリューションとして、まず開発者が提案し、それを客が受けいれて定義していく作業である。（ここでの開発者はPMを含むプロジェクト全員を指す）要件を決めるのは客だけだと思っている人は第一段階でつまずくことになるので要注意だ。要件定義も開発の１工程なので開発者が責任もってやらないといけない。それには提案型であることが重要である。積極的に提案すれば開発の範囲を明確にしながら前に進めることができる。
　これは客によるかもしれないが、開発者は提案に自分のやりたいこと、例えば、新しい技術習得であったり、フレームワークであったり、何か自分の目的を含めてしまって構わないと私は思う。それで開発者はモチベーションが上がって提案しやすくなるだろうし、客はそういうやる気のある開発者に任せてみたいと思うものである。
　作っては壊すアジャイル開発手法は品質のいいものを生み出すが、どうしたらそれを一般企業のシステム開発に採用できるのだろうか。命題を客と開発者が共有し、開発者から提案できるような文化をつくること・・・これがとりあえずの私の結論だ。