はじめに
皆さんアジャイルしてますか？
エンジニア 3 年目にして初めてアジャイル開発(スクラム開発)に参加した筆者が、
インセプションデッキ作成に(勿論初めて)参加してみて、
アジャイルいいじゃんと思ったので記事にしてみました。
インセプションデッキとは、という話と、それがどう良いと感じたのかという話を
していきたいと思います。
筆者はアジャイル初心者です。
この記事はあくまで初心者目線で感じたこと、今後活かせそうだと考えたことを
まとめたものになります。
アジャイルのきちんとした用語解説や考え方の説明ではありませんのでご留意ください。
間違っている部分があれば、遠慮なくコメントください。
この記事の対象者
- これからアジャイルに参加する人
- インセプションデッキってなんぞやな人
- 未来の自分
インセプションデッキってなんぞや
アジャイルあるある、カタカナ用語多すぎてよく分からない。。。
インセプションデッキも言葉から内容が全然想像できなくて眉間に皺寄りますよね。
念の為言っておくと、武藤遊戯も海馬瀬人も一切関係ありません。
インセプションデッキを一言で説明すると、
『プロジェクトの開始時に、プロジェクトに関わるあらゆる関係者同士で、プロジェクト遂行に必要な共通認識を作る質問、作る場』
のことです。
インセプションデッキは、以下の 10 の質問で構成されており、
この質問について話し合うことで、共通認識を作っていきます。
| No. | 質問 | 説明 |
|---|---|---|
| 1 | 我々はなぜここにいるのか | プロジェクトの背景・目的を明確にする |
| 2 | エレベーターピッチ | プロジェクトの概要を簡潔に表現する |
| 3 | パッケージデザイン | 成果物の魅力を簡潔に表現する |
| 4 | やらないことリスト | プロジェクトのスコープを明確にする |
| 5 | 「ご近所さん」を探せ（プロジェクトコミュニティ） | 開発チームに限らず、顧客、マネージャから法務担当などあらゆる関係者を洗い出す |
| 6 | 解決案を描く | ざっくりアーキテクチャ図を作り実現手段を共有する |
| 7 | 夜も眠れない問題 | 発生しうるリスクや対処方法を洗い出す |
| 8 | 期間を見極める | 大まかなスケジュール感を明らかにする |
| 9 | トレードオフスライダー | QCD の観点で優先順位を付け、不測の事態が発生した際の判断基準とする |
| 10 | 何がどれだけ必要か | プロジェクトに必要なリソースを明らかにする |
色々ありますね。
詳細に知りたい方はネットで検索すれば沢山出てきますので、ぜひ調べてみてください。
または、名著「アジャイルサムライ」を読みましょう。（私も最近買って読み始めました）
アジャイルサムライ − 達人開発者への道 −
なんのためにやるの
システム開発を一度経験した方なら想像がつくと思うのですが、
プロジェクトというのは本当に様々な人が関わっています。
開発チームとしてみれば PM,PL,メンバーくらいですが、より広い範囲で見ると
発注元のお客様、プロダクトのユーザ、経営層、営業、脆弱性診断サービス提供元、
デザイナー企業...etc
プロジェクトによって様々だとは思いますが、想像以上に色んな人がいるわけです。
当然、目的意識や問題意識、課題感はバラバラです。
そして、その認識のズレが表層化した時には手遅れになっていることが多々あります。
皆さんにも身に覚えがあるのでないでしょうか。
「この機能相当ユーザビリティ低いけど何のために実装しているんだろう・・・」
「既存バグが出てきたけど過去ベンダーとのコミュニケーションってどうするんだ・・・」
「RFP になかった要求がテスト工程で発覚したんだが・・・」
炎上のきっかけになり得ますね。
インセプションデッキを作成することで、こういった認識のズレ・漏れを初期に減らすことができます。
また、開発工程が進んで意思決定・判断に迷った時に、インセプションデッキに立ち返ることで、
プロジェクトの目的 = 成功の方向に進める判断ができる訳です。
なにがいいの
個人的に以下 2 点がいいなと感じました。
開発者以外の視点を知れる
開発チームの中にいて、開発作業だけ行っていると当然開発者としての視点しか身につきません。
もちろん、開発者として知識・技術を深めていくことは重要ですが、
マネジメント層の視点であったり、顧客の視点を持つことで、よりスムーズに期待値調整が行えたり、
開発作業以外での詰まりポイントにいち早く気付けるようになると考えています。
改めて質問するよりハードルがぐっと下がる
「そもそもこの機能ってなんために実装するんだっけ」のようなそもそも論的な質問は、なかなか聞きづらいものです。
人によるかもしれないですが、自分は「こいつそんなことも分からないまま作業してたのか」など思われそうだなと思わず尻込みます。
インセプションデッキの作成はワークショップのような形式で行われるので、
聞きづらいことでも、形式に則ることでちょっと聞きやすくなるのかなと個人的に感じました。
これは、インセプションデッキ以外にもスクラム開発のスクラムイベントも同じような効果がありそうだなと思っています。
決められたルールがあるからこそ、動きやすいのかなと。
でもうちはウォーターフォールでしか開発しないから・・・
インセプションデッキについてここまで説明してきましたが、
アジャイル以外でも活かせそうではないでしょうか。
ウォーターフォール開発でも当然関係者と共通認識を持つべきですし、
品質検証や受入試験などの開発以外のプロジェクトでも、作業の目的やスコープの確認などどれも大切になると思います。
勿論、インセプションデッキと全く同じ形式にこだわる必要はないですが、
やり方の一つとして参考にできると思います。