リモート読書会の方式の見直し

こんにちは、AWS認定ソリューションアーキテクトプロフェッショナル試験になんとか合格し、ホッとしている土居です。
今回は、以前より定期的に開かれている社内のリモート読書会の方式が今回の「アジャイルな見積りと計画づくり」から変更されたためご紹介したいと思います。

これまでの方式

以前は、

• 対象の技術書を章ごとに区切ってそれぞれローテーションで担当者を決定する。
• esaに自由に図なども用いてまとめる。
• 当日、esaのSlide show機能を用いてチームメンバーに説明する。
• 説明が終わったら、チームで議論する。

という方式を取っていました。

この方式のメリットは、

• 担当者は皆に説明しなければならないため、より深く理解する必要がある。
• わかりやすく人に伝えることの練習になる。

が大きいです。
特に２つ目は、普段の開発作業においては資料を準備してプレゼン、といったことは基本はありませんので、非常によい機会であったと思います。

逆に、若干のデメリットとしては、

• 担当者以外は、特に忙しい時など読み方がついサラッとになってしまうこともある。
• 資料を作りは思ったよりコストがかかる。

があります。

このあたりの意見を鑑みて、方式を変えてみることになりました。

新しい方式

今回からは、特に各回の担当者を決めることはせず、

• 毎回、対象の章についてesaに意見、感想、チームで議論したい点等々について軽くまとめる。
• 当日、順にまとめられた意見について議論。

のようにしました。

こちらですと、全員が若干時間は取られるものの、資料作成ほどは負荷が無いですし、これまでの方式に比べて議論の時間が多く取れるようになって良いと感じています。

また、今回の対象である「アジャイルな見積りと計画づくり」では、各章末に内容の議論のためのテーマがいくつか挙げられており、今回の方式の良い助け・ヒントにもなっています。

実際に活かされたこと

書中で述べられていたことに対しては、内容そのものについてはもちろん、MMMのプロジェクトにどう活かせるかといった観点でも議論されます。
直近で実践に移し、好感触だったものでは「イテレーションプランニング」でしょうか。こちらは、次回のイテレーション（顧客への報告が可能なレベルの機能開発を完遂する開発期間の単位）について必要な作業を計画することです。
これまでMMMでは必要な機能をプロジェクト開始時に洗い出し、完了次第、順次進めていくといった形を取っていました。
「イテレーションプランニング」はぜひ試してみようという運びとなり、まずは

• 1イテレーションの日数はこれまでの振り返りの単位としていた1スプリントと同じく、「1週間」とする。
• 毎週金曜日の「振り返り会」と合わせて実施する。
• 各機能に必要なタスクもこの時点で作成する。
• 書中で述べられているほど厳然とはしないが、イテレーションの目標を設定し、タスクを割り振る。
• 開発後に作成していたテスト項目を開始時に作成する。

を意識して取り組んでみることになりました。
まだ導入から日が浅いものの、以下のような意見が出ています。

• 次週の作業目標が明確に決まっているので、ちょうどよいプレッシャーになる。
• 機能以下のタスクまではじめに洗い出すので、分量が見えやすい。
• チームで揃って決めるため、バックエンド/フロントエンドなど自分と別チームの状況をよく把握できる。

また、個人的に導入前は金曜日の振り返り会にかなりの時間が取られてしまうのでは、との懸念がありましたが、思いの外さっくり終わっている気がしています。

まとめ

今回は読書会についてのお話でしたが、仕事の進め方においても、対象のプロジェクトの性質であったり、またチームの人数等の会社の状況変化によってもベストな方式は変わってくると思います。
これからも積極的にチームで議論し、変えるべきものは変えて、よりよくしていければと思います。

どいけん