〜AYAMACHI〜　スケジュールのすすめかたのススメ

OCHITSUKI

今回はスケジュールの見積もり方法について書こうと思う。

先日、弊社が運営している自社サービス ノウキナビ の大幅リニューアルをおこなった。幾つかの新機能追加と既存機能の大幅改修が重なったこともあり、一人で右往左往していた感がある。リリース後も修正点が発覚しその都度修正していたが、ようやく落ち着いてきたところである。

こうして乗り切ることができたのは、チームメンバーの協力による所が大きい。各分野のスペシャリストが個性を発揮しながらも、それぞれが同じ目標に向かって進んでいる。改めて、なかなか良いチームだと思う。
なにやら偉そうに書いているが、私もチームの１メンバーに過ぎないんだけれども。

さて、先ほど私は、リニューアルにあたり右往左往したと書いた。その右往左往した原因はどこにあるのだろうか。三十路も中盤にある今、右往左往していては貫禄がつかない。このままでは右往左往したまま３０代を終えてしまう。それだけは避けねばなるまい。３０代の男の魅力はオーストラリアのブルーマウンテンのような、荘厳な落ち着きにあるのだ。次の写真は、絶景で有名なオーストラリアのブルーマウンテンを私が観光したときの写真である。

霧で何も見えなかった。
なお、この記事の文体が妙に固いのは、形だけでも落ち着きを醸し出すためである。

AYAMACHI

振り返ると右往左往した原因はいくつか見つかるが、まず初動から過ちを犯していたように思う。その過ちとは、スケジュールの見積もりである。スケジュールをひくとき、各作業日数を直感的に見積もっていたのである。過去に同じ過ちは幾度となく犯していたが、スケジュールに遅れが発生するのは自分にスキルや経験が足りないから、と原因はすべて自分にあるものだと思い込んでいた。この考え方は私自身のスキル向上に繋がりはしたが、ビジネスシーンではこの考え方は誤っているのだとようやく気づいた。

まず、作業が理想通りに進むことは１００％有りえないのである。どれだけ要件定義を丁寧に作成しても、実装段階になってから予定外のコーディング作業は発生するし、無関係のように思えた既存機能への影響は発覚する。

スケジュールの見積もりから不確定要素を取り除くことは不可能なのである。なのにスケジュール作成時には、そういった不確定要素を一切考慮することなく、理想の作業日数を現実の作業日数に入れる。手元にある『アジャイルな見積りと計画づくり』の第５章によると、不確定要素には以下のようなものも含まれる。

• リリース済みプロダクトのサポート
• 体調不良
• 会議
• デモンストレーション
• 私用
• 電話応対
• 緊急の割り込み作業
• トレーニング
• メール
• レビューやウォークスルー
• 候補者の面接
• タスクの切り替え時間
• リリース済みプロダクトのバグ修正
• マネージャとの面接

理想の作業日、つまり理想日を、現実の作業にかかる日数、現実日と混同してはならない。そしてこれと同じ過ちを社内でもよく見るし、私自身もよくやってしまう。上司に「この作業に何日かかる？」と聞かれたとき、上司は現実日を問うている。しかし作業者は理想日を答える。そして現実日までに作業が完了しなかった結果、上司はイライラし、作業者は気分が落ち込み、チームの雰囲気が悪くなり、メンバーの連携が鈍り、結果納期が遅れ、会社の信用がなくなり、ついには倒産し、街には失業者が溢れ、長野県の治安が悪化し、需要と供給のバランスが崩壊し、インフレが起こり、ついには新作ゲームを購入しにくくなってしまう。これでは良くない。

作業量の見積りと、期間の見積りは、分けて考えなければならない。もちろん、作業量とスケジュールは関連している。ではどうすれば良いのか？それも手元にある『アジャイルな見積りと計画づくり』に書いてある。なんという良書。

Story Point

まず作業規模を見積もる。作業の大きさを表す単位を、ストーリーポイントと呼ぶ。ストーリーポイントの数値そのものはあまり重要ではなく、他の作業との相対値にこそ意味がある。ストーリーポイントとして設定する値は、１・２・３・５・８・１３といったフィボナッチ数列を使うのが良いとされている。値が大きくなるほど、不確定要素が絡む可能性が増えていく。

今週に改修をおこなったばかりの、ノウキナビのメッセージ機能インターフェース改修で考えてみよう。

作業規模は変わる事がないので、作業状況や作業者が変わっても見積り直す必要がない。ストーリーポイントの算出は担当者一人でおこなうのではなく、作業者全員でおこなうこと。

更にひとつ注意なのだが、本来はストーリーポイントを時間や日数に換算するべきではない。しかし社会は何月何日までにできるかを非常に重要視するので、そうも言ってられない。180,000ミリ秒もの長い時間をかけて考えた結果、以下が汎用性があって良いのではないかと思う。

・１理想日を割り込みなしで集中できる８時間の作業とした場合、自分の職場環境では１理想日は現実時間での何営業日に相当するかを見積もる。※１

・各担当者が、1 SP にかかる自分の作業時間を算出する（ベロシティ）　※２

ここでは計算しやすくするために、
※１の値を３営業日、
※２の値を２時間とする。

※１　×　※２　× 担当者の総SP　とする。
デザイナー分野をデザイナー一人で担当する場合、
工数は合計 13 SP なので
３ ×　２　×　１３　＝　７８
となり、デザイナーの現実の作業時間は７８時間、つまり 約１０営業日と算出できる。
ここは専門家や、アジャイル開発を取り入れている方から見たら間違っているかもしれない。その場合はご指摘いたければ幸いです。

今後、上司から「何日までに終わる？」と問われたときはこの方法で算出した日数を答え、「どのくらいかかる？」と問われたときは「**SPです！」と答えれば良いのだ！

AGAIL MOTTO BENKYOU SHIYOU

弊社のような人数がすくない会社のうちは、こういったアジャイル開発は効果が薄い。
しかし近いうちに必ず大きくなるので、こういった手法も今のうちから習得しておかねばなるまい。

なにごとも勉強なのである。