曳光弾型開発のススメ

プロジェクトは不確実性が多いことから、遅延が発生したり、失敗に終わったりしてしまうことがあります。
本スライドでは、曳光弾型開発を行うことで、プロジェクトの不確実性を減らし、安全にプロジェクトを進める方法を提案します。

Transcript

1. 曳光弾型開発のススメ プロジェクトを安全に進めよう
2. 想 定 す る プ ロ ジ ェ ク ト 数年かけてリリースするような大規模プロジェクトではなく、 2週間〜3ヶ月ほどを想定した規模のプロジェクト プロジェクト内でエンジニアが詳細の要件定義、工数見積、 開発などを行うプロジェクト
3. 現 状 の 課 題 PJ中に想定していなかった 難関にぶち当たり、想定し ていた工数を超過してしま う。 PJの遅延 PJ中のMTGやリリース後 に、ユーザーとの認識の齟 齬が発覚し、手戻りや工数 超過が発生してしまう。 認識齟齬による 手戻り 想定以上に工数を使ってし まい、リファクタリングな どに時間を使えず、技術的 負債を残してしまう。 工数見積の 精度が低い
4. プロジェクトにおける不確実性 現 状 の 課 題 主な原因は... 想定外の要件が入ってしまった いけると思ってた実装が思ったより難しく時間がかかってしまった ユーザーとの認識齟齬により手戻りが発生してしまった
5. 曳光弾を使って 開発における不確実性を排除していきましょう 現 状 の 課 題
6. 優先的に検証したい部分を、先行的に プログラミングすること。プログラマ に対して、コードの骨格を提供し、ユ ーザーに対して、どのような使い勝手 になるのかを提示する。作成した骨格 となるコードは使い捨てず、徐々に肉 付けを行っていく。 曳光弾 ソフトウェアのコンセプトや最終形態 についての「理解を検証する」ための もの。コンセプトの確認を終えたら、 作成したものは全て捨てさり、得られ た「学び」を使って一から作り直す。 1 2 曳 光 弾 型 開 発 の ス ス メの前に... 言葉の定義 プロトタイプ 参考: 「達人プログラマー(第2版): 熟達に向けたあなたの旅」 「プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則」
7. 優先的に検証したい部分を、先行的に プログラミングすること。プログラマ に対して、コードの骨格を提供し、ユ ーザーに対して、どのような使い勝手 になるのかを提示する。作成した骨格 となるコードは使い捨てず、徐々に肉 付けを行っていく。 曳光弾 ソフトウェアのコンセプトや最終形態 についての「理解を検証する」ための もの。コンセプトの確認を終えたら、 作成したものは全て捨てさり、得られ た「学び」を使って一から作り直す。 1 2 プロトタイプ 参考: 「達人プログラマー(第2版): 熟達に向けたあなたの旅」 「プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則」 今回はコッチ 曳 光 弾 型 開 発 の ス ス メの前に... 言葉の定義
8. 認識齟齬 PJ開始 目標 追加修正 データメンテ 影響範囲 曳 光 弾 で 暗 闇 を 照 ら そ う
9. 認識齟齬 PJ開始 目標 データメンテ 追加修正 影響範囲 曳 光 弾 で 暗 闇 を 照 ら そ う
10. 曳 光 弾 の メ リ ッ ト 工数見積の精度を向上させ、 遅延を発生させない ユーザーや企画チームに実装イメージ を共有することで、成果物や目標の認 識が揃っているかを確認できます。要 件が複雑であればあるほど、効果が大 きいです。 実際に画面を触りながら議論すること で、漏れていた要件を発見できること が多くありました。 ステークホルダーに 実装イメージを共有し、 認識の齟齬を発生させない 1 2 プログラムの骨格を作っておくこと で、実装イメージやTODOが明確にな り、正確に工数を見積もれるようにな ります。 さらに、PJ内では曳光弾で作成した 骨格の肉付けやリファクタリングを行 うだけになれば、遅延が発生しづら く、PJがを安全に進めやすいです。 不安な箇所の方針をしっかり定めてお くだけでも効果は大きいです。
11. 曳光弾を使って 工数見積 実際に手を動かして骨格を 作り、開発で詰まりそうな ポイントや、もっと詰める 必要がある要件がないかを 確認する。 開発 骨格の肉付けやリファ クタリングをする。 イメージの共有 複雑な要件がある場合 は、成果物のイメージ を共有して認識をあわ せる。 1 3 2 → → P J の 流 れ
12. P J の 特 性 や 自 身 の ス キ ル に よ っ て テ ク ニ ッ ク を 使 い 分 け る 複雑な要件の場合は、全体的な イメージを共有できるように、 サッと画面を作成します。画面 で指差しをしながら議論をする ことで、新しい要件やもっと詰 める必要のある要件を発見する ことができます。 要件が複雑な場合 1 エンジニア自身のスキルや経 験によって使い分けるのもア リです。 例えば、メール送信機能を作 成するPJで、他のPJで同等の 機能を作成した経験がある人 とない人では、どこまで骨格 を作成するかなどは変わって きそうです。 自身のスキルで使い分ける 2
13. 曳 光 弾 の ポ イ ン ト エラーハンドリングやデザイン などは最低限で実装し、あくま でPJ内の不確実性を排除する目 的で作るのがオススメ。 最低限で作る 内部品質は一旦気にしない 1 2 可読性やテスト可用性などは考 えすぎず、とりあえず動く成果 物を作るのがオススメ。手を動 かす中で、修正やリファクタリ ングしたい箇所があれば、コー ドやPRにコメントを残してお くといいかも
14. 参 考 文 献 上田 勲 (著),「プリンシプル オブ プログラミング3年目までに身につけたい一生役立つ101の原理原則 」秀和システム David Thomas (著), Andrew Hunt (著), 村上 雅章 (翻訳), 「達人プログラマー(第2版): 熟達に向けたあなたの旅」オーム社
15. 以上です。 PJを安全に進めていきましょう！