Backlog Worldにブログレポーター枠で参加しました
2018/02/18に開催された Backlog World にブログレポーター枠として参加してきました。
■ Backlog Worldとは？
Backlog Worldは、プロジェクト管理に関わる全ての方のための祭典です。一言でプロジェクト管理と言っても、業種や職種、チームの規模、プロジェクトの期間などは様々。それでも、どんなプロジェクトでも、「仲間とコラボレーションしてプロジェクトを進める」ということは必須です。
Backlog Worldでは、どのようにプロジェクト管理を行なっているのか、様々な立場の方による知見のシェアが行われます。実例に基づいたセッションの中に、あなたのチームで取り入れられるヒントがきっとあるはず。
この記事では自分の参加したセッションに触れ、その中でも特に印象に残った「アジャイル開発とプロジェクト管理ツールの相性」のセッションについて詳しく感想を書きます。
参加の動機
私は 資産運用をバリアフリーに。 をミッションとして掲げるオンライン証券会社 株式会社FOLIO にバックエンドエンジニアとして入社し、現在はFOLIOのWebサービスを開発するチームのプロジェクトマネジメントに責任を持っています。
FOLIO はまだまだ発展途上のサービスなので、新機能開発やUXの向上に取り組む必要があるだけでなく、証券会社としてのコンプライアンスを尊守するためのタイトな締切の開発案件も多く抱えています。
入社時には両手で足りるほどであったエンジニア・デザイナーの人数も、今ではWebサービスの開発運用に関わるメンバーだけで20人を超えてきました。
多数の開発案件・急速に増加する開発チームをハンドリングするためには、 プロジェクトマネジメント と チームビルディング の両面からのアプローチが重要と考え、社内のメンバーとも活発に議論しています。
それに加え、他社のうまくいっている事例が聞けるとクイックな改善のヒントになるかと思い、Backlog Worldに参加することにしました。
当日タイムスケジュールと参加したセッション一覧
2トラックで進行し、基調講演など一部のセッションは裏番組なしの構成でした。
いずれのセッションも興味深かったですが、自分の興味に合わせ、以下のセッションを聴講しました。
- 基調講演 「働く」を楽しくするために
- I BELIEVE THE POWER OF TEAMWORK!!
- レガシーな新聞社が本気でテクノロジーメディアを目指す開発プロジェクト
- アジャイル開発とプロジェクト管理ツールの相性
- “プロジェクト管理”の前に考えること
- Web制作のプロジェクト管理についてぶっちゃけ話をしてみよう
- ヤッホーブルーイングのチームづくりと熱狂的ファンづくり
このうち、特に印象的だった アジャイル開発とプロジェクト管理ツールの相性 についてまとめます。
「アジャイル開発とプロジェクト管理ツールの相性」のまとめ
ギルドワークスの 中村洋 様の発表です。
ギルドワークスは「正しいものを正しく作る」をミッションとし、新規事業や新規サービスの立ち上げを組織づくりからサポートする事業を展開してらっしゃるそうです。
このセッションではデジタルなITS (Issue Tracking Tool) ツールの話に焦点を当て、アナログなプロジェクト管理ツールについてはスコープ外となっていました。
また、タイトルとは異なり、必ずしもプロジェクト管理ツールに焦点を絞った発表ではなく、チームビルディングのお話も含んでおりました。
アジャイル開発が活きる、
- グループではなくチームで挑む領域
- 不確実性の高い領域
- 例: 北京ダックを作るのは 該当しない。 複雑ではあるが、レシピが存在するので不確実性は小さい。
- 例: モックを作りながら最終的なUXを決定するソフトウェア開発は該当する。
のプロジェクトがスコープ対象内です。
アジャイルソフトウェア開発の12の原則 に触れ、そのうちの
- 変化に対応
- 全員同席
- 顔を合わせての対話
- 動くソフトウェアが重要
- 振り返りと改善
の5つの原則について深掘りされていました。
変化に対応
不確実性の高い領域では、ともするとMoving Targetを追いかけてしまい、プロジェクトの進行が不安定になってしまいます。
これを避けるために、 『アジャイルサムライ』 でも紹介されている インセプションデッキ を策定することを推奨していました。
インセプションデッキの参考: インセプションデッキ | ネスケラボ
インセプションデッキもプロジェクト開始時点で策定してずっと固定しておくわけではなく、定期的にチームで改定することが重要だとのことです。
全員同席
全員同席とは、同じプロジェクトに関わっているチームのメンバーの物理距離を近づけ、プロジェクトを把握するための情報の透明性を担保することと言えるかと思います。
『エクストリームプログラミング』 には、
プロジェクトに関心のある人がチームのスペースを見たときに、15病で状況を把握できるようにするべきである。
と記載があります。
全員同席を達成するためのアンチパターンとして、プロジェクトや業務の「掛け持ち」を挙げておりました。
掛け持ちがあると、他業務に時間を割いているときにはプロジェクトメンバーの近くにいられないことがあります。たとえ近くにいても、そのプロジェクトの相談を受けられる余裕がない場合もあるでしょう。
これは弊社で私どもが抱えている問題だと考えております。
弊社も創業から2年ほどの会社であり、数多くの業務内容に比べて人手が慢性的に不足しています。
バックエンドエンジニア・社内SE・セキュリティの業務を兼務しているメンバーもいれば、自分自身エンジニアとして開発をしながらクリエーター（デザイナーとエンジニアを合わせた弊社内の呼称）の活動を発信する業務をしているメンバーもいます。
やはり開発プロジェクトメンバー間のコミュニケーションの機会が少ないことが問題になることがあり、
「コードレビューするよりもペアプロしたほうがマージまでの時間も短縮できるし品質上がるよね」
「でもペアプロする時間取れないからレビュー投げといてください」
というやりとりも過去にありました。
この問題に対処するため、オフィスが増床した機会にプロジェクトメンバーを固めるような席順を導入しました。
まだ兼務の問題には切り込めていませんが、兼務のメンバーには複数席を設けてプロジェクトメンバーと近くに座る時間も取れるよう工夫しています。
効果が出るのはまだこれからですが、小さな改善を高速に積み重ねていくよう心がけています。
全員同席のセクションで タックマンモデル にも触れていました。
機能期に至ったようなチームはそれ自体が財産であり、すぐにチームを分解するとこの財産を失ってしまうというお話が印象的でした。
一方で自分は、あまりにも人の流動性が失われてしまうとメンバーのスキルの幅を広げたり、良い交流を産む機会を逸してしまう側面もあるかと考えており、今後実験を重ねて落とし所を探っていきたいと思います。
顔を合わせての対話
自分もよくやってしまいがちなのですが、「チケット/ドキュメントに詳細書いておいたから見ておいてね」は、一見時間が節約できるように見えて実は無駄が多いとのことです。
Face-to-faceの対話と比べ、
- 双方向のコミュニケーションじゃなければ、理解が不足している部分の補足ができず、記載された事項を100%インプットすることは難しい
- そもそも「見ておいてね」と言われても見ないこともある
などの問題が考えられます。
前者の問題は相当時間が経過してから発覚することもあり、その際はチケット/ドキュメントを記載した人が結局改めて説明を補足する手間が発生します。
それならまだ良い方で、下手をすると理解が不足したまま品質の低い製品・アウトプットを出してしまうこともあるでしょう。
顔を合わせての対話を促進するためには、前のセクションの全員同席が前提条件となるでしょう。
動くソフトウェアが重要
アジャイル開発では、受け入れ基準を定められる粒度にタスク（ユーザストーリー）を分解し、受け入れ可否を判断するときはちゃんと動くソフトウェアを通して行うことが重要視されます。
タスクの完成を待たずとも動く状態にしておけば、タスクの進捗率をタスク担当者の頭の中だけでなくプロジェクトのメンバーに可視化することができる、というお話もありました。
振り返りと改善
アジャイルは変化に対応するためのフレームワークであり、振り返りを通した改善を重視します。
自分にも覚えのある話ですが、プロジェクトの振り返りで改善案が出たときに「でもそれは{JIRAで, Backlogで}実現するのは難しいなぁ…」で終わってしまうのはもったいないことです。
プロジェクト管理ツールに振り回されるのではなく、改善のためにはプロジェクト管理ツールの枠を脱することも検討するべきだとお話がありました。
この点は深掘りするととても興味深いと思います。
少なからぬ会社のプロジェクトマネジメントが、
- 何もない混乱期
- プロジェクト管理ツールの導入
- プロジェクト管理ツールの利用方法（ワークフロー）の洗練
- プロジェクトの規模が拡大するにつれ、ワークフローに従ったマネジメントが重たくなり、マネジメント担当の負荷が増大する
- マネジメント担当が改善に着手する時間がなくなる
という悪循環に陥っている、または経験したことがあるのではないでしょうか。
私自身も段々とこの傾向が見えており、 デジタルツールによる、プロジェクト管理の定型化・用途に合わせた多様なビュー と カンバンなどのアナログツールによる、高速な実験と改善 の間の落とし所を追求していきたいと最近は考えています。
以上、「アジャイル開発とプロジェクト管理ツールの相性」を自分の考察を踏まえてまとめました。
おまけ: プロジェクト管理ボードゲーム
基調講演で紹介のあったプロジェクト管理ボードゲームの試遊に参加しました！
詳しくは実際に販売される(!!)予定のものを見ていただくとして、概ね下記のようなゲームでした。
- ゲームの目的: 与えられたスプリント回数で、遊園地のアトラクションを15個中12個以上完成させる
- プレイヤーの役割: 「やる気」 + サイコロの目 をそのスプリントの生産性として消費し、アトラクションを建設する
- スプリント計画: プレイヤー間で相談し、そのスプリントで消化すべき建設物を決定する
- 途中失敗終了条件: スプリント計画で決めた建設物をすべてそのスプリント内で完成させられなかった場合、クライアントの「信頼」を失い、すべての「信頼」を失うとゲームオーバー
その他にも、やる気は他のプレイヤーに開示できない・スプリントごとにランダムでイベントが発生する・サイコロにも複数種類がある、などのゲーム要素があり、試遊では遊びきれませんでしたが面白そうなゲームでした！
最後になりますが、主催者のヌーラボ様・発表者の方・スタッフの皆様、素敵な会をありがとうございました。