Webエンジニアの君のケツがなぜ締切でぶっ叩かれるかについて語ろう。
最初に
タイトルは「Web企業の皆様が愛する締切駆動開発について語ろう。」とかなり迷ってこうなりました。
Web企業でなぜこれほどまでに締切駆動開発が流行っているかについて書いていこうと思います。
前振り
大きいWeb企業はどういう開発手法をしているのでしょうか？
今流行りのスクラム？
最近は増えましたが、スクラムは未だ最多数派ではありません。
明確な名前がついていない開発形式が主流です。
この記事では「名前がついていない開発」がどういうものか。
なぜ締切ドリブンになってしまうのか？という話を今回しようと思います。
ここで論じる「Web企業」について
- Webサービスを運営している企業
- SaaS含む。C2CかB2Bか、とかそういうのは今回はスコープ外
- 受託は今回スコープ外
- 従業員数120名以上（外注含む）
- いわゆる「トライブ」 が社内に複数存在する
- 開発チームが複数ある。
- 開発チームが１つではなくなるからこそ統制できる開発手法が必要になる
あなたのチームの開発スタイルは……
スクラム開発を導入しない場合、Web企業はどう言う開発をするのでしょうか？
大まかに言うとこんな感じです。
- 大事なことは社長とか偉い人が決める。
- プロダクトマネージャーに相当する人がいる
- 実装する機能リストはスプレッドシートなどに書き出してある。
- バックログに相当するなにかしらはある
- 御大層なドキュメントや計画は作らない
- アーキテクト的なところは、誰かがホワイトボードに書いた写真をスマホで撮ってSlackに貼ってこれが使いまわされる
- 計画に関しても、必要なものは都度作られる。ないわけではないが非常に薄い。また頻繁に変更される。
- 議事録もざっくりしたホワイトベースの板書ベースであり、不足分は参加者の記憶ベースで補われる。
そして締切駆動開発へ
最初はどの会社も締切をあまり重視しません。
ところが会社が大きくなるといつの間にか締切を使って開発チームの尻をブッ叩くようになります。
事実上Web開発の開発スタイルのトップシェアは締切駆動開発と言っても過言ではありません。
ではなぜ締切駆動開発はWebエンジニアの皆さんに愛されるのでしょうか？
締切駆動開発のメリット
- 計画が立てやすい。
- ガントチャート上でこれからリリースされる機能とリリース予定時期が説明しやすい。
- 我々の戦略はこれで、実際の戦術行動はこれです。とパッと分かる形で説明しやすい。
- 人事評価が超簡単。評価なんてしたことない人間でもできる。
- 締切より早く完成＝高評価。締切をオーバーした＝低評価。評価基準は納得しやすく単純にできる。
- チーム単位、個人単位の人事評価をこの考えでできる。評価者にとってイージーになる。
- デメリット：汚いコードを量産して、保守運用の後始末は他人任せの人間が出世しやすい。トータルではプロダクト開発を低速化させるやり方が、個人にとって評価されやすい最適解になる。
- 「次にどの作業をすればいいのか？」が明確
- 締め切りが近い OR 締め切りが厳しいタスクを取ればいい。
- スクラムのような「価値」 ベースの判断を作業員がする必要がない。迷う余地がほぼない。
- 優先度＝締切の近さで単純化できるのでマネジメントしやすい。
- 締切に間に合うようメンバーが考えて振る舞うので、自然にアウトプット最大化に向けてチームの開発体制が最適化されていく。
- なるはやでコードが生み出されるようになる
要約するとこうなります。
- 計画と人事評価のしやすさ。
- マネジメントのしやすさ。
- スピード感重視に感じられる。
経営陣からの指令を伝えるインターフェースとして「締切」は強い
ほかにも締切駆動開発にはメリットがあります。
全容を把握している経営陣が会議室で戦略を考えます。
頭を動かすべき経営陣が戦略を考えた後、手を動かすべき現場に何をどう伝えればいいでしょう？
部門やチームに対して開発チームに対して「やることと締切（What + When）」だけ伝えます。
あとはリリースを待てば戦略が達成されるはずです。もっとも全てのチームが締切を守れればの話ですが。
実は締切駆動開発はチーム間連携や大規模開発に強い
ここでいう大規模開発とは、複数の開発チームが連携してプロダクトを開発する体制を指します。
たとえば複数の時給ベースを１人のアルバイト従業員に適用できる機能を人事労務系SaaSで開発したいとしましょう。
普段は時給1,000円のAさんが、朝6時〜9時の間だけは時給1,200円として扱われる、みたいな機能です。
朝ラッシュ需要を取り込みたい小売店がターゲットです。
今までは
「ベース時給 x 勤務時間 + 残業や深夜などの諸々手当」
だった給与計算式が複雑になるわけですね。
ここで勤怠打刻、人事労務、給与の３チームがそれぞれのプロダクトでの対応範囲を改修するとします。
３つのチームで、すべての機能が揃ってリリースされないと意味がありません。
なのでこう言う際に「締切」で「チーム間の行動を同期させる」ことが重要になるわけです。
締切駆動開発は営業との連携にも強い
「締切」で「チーム間の行動を同期させる」ことが重要 と書きました。
実はチーム間の行動の同期は単一チームでの開発でも重要になるケースがあります。
営業という他チームが絡むからです。
2BのSaaSに多いケースです。
星取表 でバツがついた機能を開発することを目的とする開発プロジェクトはよく見ます。
星取表の該当機能にバツがあったことでコンペで何度も負けるプロダクトが、そのバツをマルに変えればコンペに勝てることを狙うわけですね。
営業は架電攻撃でリードをとり、アポをとり商談に持ち込んで契約獲得します。
契約獲得時に「この機能はXX月にはリリースされるんで！」と約束して、その約束された時期が開発チームの締切となるわけです。
リード取るところから考えると数ヶ月かかる一方で、大口の契約を取る攻勢作戦として企画されることが多いです。
もし開発チームがその締切を守れないとせっかく手間をかけて獲得した顧客がChurnしてしまったり、クレームに繋がったり、あるいはリリースされるまで料金割引を要求されます。
リソースがクレーム対応などに食われるので営業としても望ましくない自体です。
まとめると
締切駆動開発の長所は
前述の３点に加えて
- 計画と人事評価のしやすさ。
- マネジメントのしやすさ。
- スピード感重視に感じられる。
以下の長所があります。
- 経営陣が複数チームに指示を出すインターフェースとして強い
- 複数の開発チームの連携に強い
- 営業＋開発チームの連携に強い
これだけ長所が多い割に、比較的低いスキルでも回すことができるのが締切駆動開発の優れた点と言えます。
大口株主や出資者に見せる「次年度の事業計画」のガントチャートをバラすと開発チームに渡す開発予定のガントチャートになるのがポイント高いですね。
ガントチャートって何より分かりやすいですし。
欠点はないのか？
締切駆動開発は計画と現実のうち、計画を重視するタイプの開発手法です。
会議室に実際に手を動かすよりはるかに少ない人数を集め、最初に作るものを事前に決めてガントチャートを引いてスケジュールを決める事前計画型のプロジェクトマネジメントスタイルです。
そのためウォーターフォール同様の欠点を抱えています。
- 開発規模が大きくなれば大きくなるほど、問題が起きやすくなる
- 開発計画が硬直化してしまい、後から間違いに気づいても対応が困難
後記
締切駆動開発からスクラムの切り替えの記事を書こうとしたんですが話が長くなったので独立させました。
Discussion