プロジェクトテンプレートを考える

プロジェクトテンプレートを考える プロジェクトを始める前に・始めたい時に、まず考えることとやるこ と Yuki Izumoto

前提のおはなし。 • 現状 • プロジェクトを始める時に、なーなーでなんとなくはじめてしまう。 • 期日納期スケジュール感がゆるふわすぎる。 • 始めたプロジェクトが進んでるのか止まってるのか、どこまで進んでるのか がわかんない。

前提のおはなし。 • 進捗どうですか？ • 進捗OKです。 • 進捗どうですか？ • 進捗大丈夫です。 • 進捗どうですか？ • 進捗たぶん大丈夫です。 • 進捗どうですか？ • 進捗たぶんなんとかなります。

前提のおはなし。 この時点でもうどうしようもない

前提のおはなし。 じゃあ納期のばしましょう。 ↓ プロジェクトおわった！

そもそもプロジェクトは破綻する • 横槍プロジェクト • まとまった時間を１つのプロジェクトに集中できない • 見積もりが甘い • 思ってたよりコストがかかる • スケジュールが甘い • 思ってたより作業量が多い、非効率的な手法しか知らない • 身の丈に合わないプロジェクトを受ける • 要件が実現できない、メンバーが足りない • コミュニケーションコストが高い • 情報共有が足りない、意思疎通ができない、報告がない • そもそも要件がはっきりしてない • 成果物がきまってない、途中で成果物がかわってしまう

プロジェクト管理しよう

プロジェクト管理しよう ↓ マイクロマネジメントだ！ 電話おおいぞ、マウス動いてないから仕事してないんじゃない、メールの書き方おかしくない、逐一議事録かいて報告しろ etc..

プロジェクト管理しよう ↓ 可視化・細分化 定量化・定例化

要求「チームメンバーのパソコン揃えて、予算200万な」

要求「チームメンバーのパソコン揃えて、予算200万な」 • なにする？ •

要求「チームメンバーのパソコン揃えて、予算200万な」 • チームメンバー何人いるの？ • PCは何台いるの？１人デスクトップ１つ？ノートは？ノートだけでもいい？ • スペックは？Of ceしかやらん人と開発やる人じゃ違うよね。 • 周辺機器いらんのやっけ。 • もうちょっと予算上げていいPCにして、チームの執務環境公開して、 採用にもつなげようよ fi • えっ、納期は？

要求「来週中な」

PM「いや無理やん、量販店で吊るし買ってこよ！」

要求「チームメンバーのパソコン揃えて、予算200万な」 • チームメンバー何人いるの？ -> ７人かな • PCは何台いるの？１人デスクトップ１つ？ノートは？ノートだけでもいい？ • ノートだけでいいでしょ。 • スペックは？Of ceしかやらん人と開発やる人じゃ違うよね。 • １人3０万弱として、of ce3人、開発4人として、重み付けする？ • 周辺機器いらんのやっけ。 • いやモニターは買わなくていいっぽい。 • もうちょっと予算上げていいPCにして、チームの執務環境公開して、採用にもつなげようよ fi fi • だったら予算付だけして、みんな好きなマシン買えるようにしよう。 要 件 定 義

要求「チームメンバーのパソコン揃えて、予算200万な」 • 購入店舗は絞らないとだめっぽい • 店舗決めて • みんなのほしいマシン聞いてきて • 購入可否しらべて • だめだったらつきかえして • なんでもいいって人はどれにするか決めて • いつごろものが揃うか調べて • 初期セットアップって必要なんだっけ タ ス ク 化 で、それ誰がいつまでに？できる？

PM「じゃあ出てきたタスク、Excelで管理しよ。」 〜なんだかんだあって幾年月〜 PM「できた！」 ステークホルダー「これってなんでこうなったん？」 PM「え、、、、なんでやっけ、、、」 ステークホルダー「議事録探せー」

やったこと • 要件定義した -> えらい • タスク化した -> えらい • タスクを可視化した -> えらい • 要件定義を議事録にした -> えらい • なんとかプロジェクトを終わらせた -> めっちゃえらい

おしいこと • どのタスクがどの要件定義からでてきたのかを可視化したほうがよかった • 成果物に意図の説明責任を満足に果たせなかった • 情報共有と意識のズレ修正のために定期報告をしたほうがよかった

じゃあ プロジェクト管理ツール いれよ！

プロジェクトテンプレートを考える プロジェクトを始める前に・始めたい時に、まず考えることとやるこ と

プロジェクト管理 • 可視化 -> ツールの仕事 • スケジュール、要件、タスク、ログ、レポートを集めて、必要に応じたビジュアルで 見れるようにする。 • 細分化 -> 人の仕事 • 要件から作業に分解して、期日と担当者を決める。 • 定量化 -> 人とツールの仕事 • 定期的に期間を区切って、その期間にやることを決めて遂行する。を繰り返す。 • 定例化 -> 人の仕事 • 定量化した作業の報告、朝回、トラブル共有のタイミングを決めておく。

はい、じゃあ決めて。

はい、じゃあ決めて。 って、いきなり言われても難しい。

そこでScrum

Scrum • チームで効率的にプロジェクトを進めることができるフレームワーク • 長い期間を短い期間に区切って、都度、計画と振り返り、ズレを修正する • 短い期間で都度ズレを修正することで、見積もり制度を上げていく -> セルフマネジメント • 短い期間の中で新しい手法を試す。 -> 業務Hack • 成果があれば継続する。失敗すれば期間内でやめる。 早い失敗は早い学びになる。 -> チーム内学習 • Fail fast, Learn fast.

Sprint Planning • 1Sprintを何日に設定するか、を決める。 • 1Sprintにどれだけのタスクをこなせるか、を決める。 • MTGのタイミング、を決める。 • まずはこの３つだけ。ただし厳守する。

Sprint Planning • 1Sprintを何日に設定するか、を決める。 • 基本的には短期では変えない。 • 最初は短い期間を設定するとよい。 • チームの成熟度に合わせて長くしてもよい。

Sprint Planning • 1Sprintにどれだけのタスクをこなせるか、を決める。 • ストーリーポイントと呼ぶ。 • 短期的に実現したいタスクの難易度（時間ではなく）に、チーム全員でせーのでポイントをつけ る。（フィボナッチ数列で）（プランニングポーカー） • Aさんにとってこのタスクは難易度５かもしれないし、Bさんにとっては難易度13かもしれな い。その意識の差分と問題点をあらわにしていく。 • 大きすぎる難易度はタスクとしての分解が甘い証拠。（何をすればいいか明示できてない） • そのストーリーポイントを消化できるように、また溢れないように、Sprint内でやるタスクを決 めていく。 • チーム内で消化できるストーリーポイントは精度を目指して変えてよい。

Sprint Planning • MTGのタイミング、を決める。 • 朝回（’朝でなくても昼でも） • 昨日できたこと、今日やること、その障害を短く、その他共有、１人３分程度を毎日 • スプリントレビュー • ステークホルダーにSprintの成果を報告してフィードバックをもらう、１回 • スプリントレトロスペクティブ • チーム内でのSprintの振り返り、Kept、１回 • スプリントアラインメント • 次のSprintでやることを決める会、長い時間を確保してしっかり決める、１回

Sprint Planning • 1Sprintを何日に設定するか、を決める。 • 1Sprintにどれだけのタスクをこなせるか、を決める。 • MTGのタイミング、を決める。 • まずは決めてみよう。 • スクラムマスター・PMは、Sprintでの決め事の厳守と軌道のズレの気付きを 与える役をしよう。

プロジェクト管理 • 可視化 -> ツールの仕事 • スケジュール、要件、タスク、ログ、レポートを集めて、必要に応じたビジュアルで 見れるようにする。 • 細分化 -> 人の仕事 -> タスクの分割と振り分け • 要件から作業に分解して、期日と担当者を決める。 • 定量化 -> 人とツールの仕事 -> ストーリーポイント • 定期的に期間を区切って、その期間にやることを決めて遂行する。を繰り返す。 • 定例化 -> 人の仕事 -> Sprint MTG • 定量化した作業の報告、朝回、トラブル共有のタイミングを決めておく。

ここまでの決め事を決めて、 初めてツールが導入できる。 ツールは所詮ツール。 ツールは決め事を厳守・サポートするために 存在する。

Scrumをサポートするツール・サービス • Azure DevOps、Asana、youtrack、Jira、GitHub Issues、Trello、Notion etc… • 正直、はじめのツールはなんでもいい（費用の差とかはあるけど） というか、ツールを比較できるほどScrumへの理解がないはず。

Scrumをサポートするツール・サービス • 今のSprintでなにをやるのか。 • 今のSprintでだれがなにをやるのか。 • 今のSprintでなにが進んでて、なにが終わっているのか。 • それさえ分かれば基本的になんでもいい。（たとえExcelだろうと） • ただ、チームが求める必要な見え方を探るべき。 （カレンダーで見たい、カンバンでみたいとか。） • その見え方の実現するのにコストを割くべきではない（だからExcelでは無理）

あとは決め事を守って、やるだけ。 チームを育てられない人は、いつまでも自分が辛いだけ。 学びのない現状維持はゆるやかな死。

まとめ • プロジェクト名を決める（これがないと何も始まらない） • プロジェクトを進行するために必要なサービス環境を構築する。 • 例えばTeams、例えばJira。 • 構築したサービスのプロジェクト内での使い方を決める。 • こういう内容はここに書く。この項目は必須だ、とか。 • 1Sprintの期間を決める。 • 1Sprint内のMTGタイミングを決める。 • 決め事は厳守する、かつ寛容に変えて、早く挑戦して早く学ぶ。

入門レベルの参考文献 • SCRUM BOOT CAMP THE BOOK • スクラムマスター・PMだけじゃなくチーム全員の義務教育レベル • アジャイルとスクラムとは 価値・原則・プラクティス • https://www.docswell.com/s/yattom/KRY9J5-agile-and-scrum • 認定スクラムマスターがすごく丁寧に、かつ色濃く説明してくれた資料 • おやつ神社パターン • https://kcf-developers.hatenablog.jp/entry/2018/05/25/100720 ～ • https://note.com/keitafukui/n/n2626396adfd4

• https://www.docswell.com/s/yattom/KRY9J5-agile-and-scrum
• https://kcf-developers.hatenablog.jp/entry/2018/05/25/100720
• https://note.com/keitafukui/n/n2626396adfd4