開発者の答える開発期間が、依頼者が期待するよりも長い理由

deathmarch

開発の依頼者は、大体のケースでなるべく早めにサービスを出したいと思うものだ。もしくは、予めリリース日が決まっているならば、なるべく多くの機能を入れたいと思うだろう。

つまり、依頼者が開発期間を考える時は楽観的になりやすい。「あと一ヶ月あるじゃないか」「他社は2ヶ月でやってるぞ」など、こういう言葉が、より楽観的観測を助長することもある。論外に短い期間については、ここでは話をしない。なぜなら、最近は依頼者にも知識と経験を持ち合わせた人が増え、絶対に無理な期間は言ってこない場合がほとんどだからだ(少なくとも僕の周りでは)。これは、技術用語で楽観値と呼ばれる。

 

それに対して、開発期間に対する開発者の最初の回答は、極めて悲観的だ。

多くの場合、開発期間の見積をする開発者は、ある程度実績と経験がある人になるだろう。そういう人は、大小の差はあるにせよ、必ずデスマーチを経験したことがある。依頼主が仕様を途中で変えたり追加してくることも知っている。そして、答えた期間に合わせて、開発以外の準備(例えばプレスリリースやクライアントに対する商品説明など)が進んでいく事も知っている。つまり、失敗できない期間を答えたがる。これを技術用語では悲観値という。

 

依頼者にしてみれば、悲観値を聞いてるのでは無く、可能な範囲で最短の期間が聞きたいのだと思うが、開発者からそれが最初に出てくる事は無い。それは、最初の段階で依頼者が開発者に、仕様変更が必要ない完璧な仕様を伝える事が出来ないのと同じだ。

絵にするとこんな感じだろうか。

development

実際、開発工数の見積り方法は複数ある。勉強をすれば、結果に近い形で開発者が見積りを出すことは可能だろう。しかし、SI業界ならともかく、僕が生きてるWeb業界で正確な見積りを出すことに、どれだけの価値があるだろうか。

 

Web業界では、そもそも許される開発期間が短く、それとは反比例して不安定要素が多い。技術も新しい物がどんどん出てくるし、新しい技術を使わなければ、いいエンジニアは他に行ってしまう。不安定要素が多ければ、どんな方法を用いて見積もっても、開発期間は長めに出てしまう。

 

僕らに本当に必要なのは、新しい技術を取り入れながら、不安定要素を消化しながら、実際の開発期間を短くする事だ。それには、開発者だけではなく、依頼者も真剣にそのプロジェクトを考え、お互いの共通理解を「文化」として浸透させて行かなくてはいけない。アジャイル的な手法は、単発で実施したところで効果は薄い。単発では、アジャイルの良さが出るまで、チームが成熟しないからだ。「文化」を作ることは地道な作業だ。しかし、それを避けていたら、いつまでも開発期間が短くなることはない。

 

多くの場合「文化」が成熟しても、不安定要素が減るわけではない。しかし、不安定要素に対する振れ幅が小さくなる。この事が意味するものは、一度でも「良いチーム」で働いた経験のある人は分かるだろう。そして、その重要性を痛感しているはずだ。

 

幸運にも、Web業界はプロジェクト期間が短いため、2~3年経てば、組織としては多くのプロジェクトを経験する事が可能だ。その一つひとつを、単に作るだけれはなく、今書いたようなマインドを持って進めていけば、その組織は変わっていく。

 

そういうマインドを持っていない会社は、残念ながら、あまり優秀でない開発者しか残らず、やってることは外注のコントロール。しかも、外注に高いお金を払い、最終的なスケジュールを彼らに握られるてしまうだろう。

 

もし、あなたの会社が次のような方法で開発期間を短くしようとしていたら、注意すべきだと思う。

  • 開発者に圧力をかける → 良い開発者が逃げる 品質が落ちる リリース後運用ができない
  • 安易な機能削減 → サービス中の追加開発は新規開発よりも工数がかかる
  • 開発者を増やす → 新しい人が慣れるのに2週間〜1ヶ月が必要で、更に、優秀な開発者が面倒をみることになる
  • 一部を外注する → ピザを焼くのに、チーズを乗せるところだけ他のお店にお願いしてるようなもの
  • 全部を外注する → 将来的に開発期間が短くなることはない
  • 残業時間を増やす → 短い期間なら有効に働くこともあるが、中長期の解決方法では無い

 

開発の短期的な目標は「何かをつくり上げる事」だが、もし作られた物以外得るものが無いなら、いずれその組織は瓦解するだろう。

 

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です