エンジニアリング＆デザインマネジメント室（EDMO・エドモ）の吉谷です。前回の記事でスタジオテックリードでの取り組みを紹介しましたが、その中の1つに技術課題マネジメントがありました。
この技術課題マネジメントとはどういったものかを簡単に説明すると、プロジェクトの技術的な課題を整理し、それに対してアクションしていくことで解決を図るというものです。この取り組みはプロジェクトが問題で溢れかえり、著しく開発効率が下がってしまったり、リリースできなくなってしまうような状態を無くすことが目的になります。また、問題だけでなく、時にはどうやったらもっと効率化を図れるかなどを議論し、技術チャレンジなどにもつなげていきます。
今回は、これまで取り組んできた、このワンプラなりの「技術課題マネジメント」のやり方をもう少し詳細に解説しつつ、自分が重要だと感じているポイントを紹介します。
課題の定義
まず最初に、今回の記事の中心トピックである「課題」とはどのようなものかを改めて考えてみましょう。そもそもですが、ビジネスの世界で「問題」と「課題」は似ているようで明確に区別されていると言われています。
- 問題: 理想となる姿が阻害されてギャップがある状態
- 課題: 阻害要因（ブロッカー）を取り除くために解決すべき事柄
あくまで「問題」は状態であり、直接解消はできません。課題として整理され、それらの具体的なポイントを解決することで問題がはじめて解消されるというワケです。今回のテーマでは「技術」課題マネジメントであるため、例を挙げると以下のような感じになります。
- 問題: 最近開発ベロシティが想定より出ていない
- ブロッカー: 同様のコードが各画面ごとに毎回実装され、さらにバグが頻発している
- 課題: 当該コードの共通化と、品質の安定化を行う必要がある
また、問題や課題というものは、不確実なものがほとんどです。プロジェクトの途中で突如発覚したり、対応方針が決まっていなかったりします。一般的な作業や機能実装であれば、実績から工数を見積もることができますが、このようなものはそうもいきません。このように、通常の作業ワークフローにのせきれないものや、初めて取り組むような事柄が課題として扱われます。
また、現状に問題が起きていないと感じていても、課題が無いということとは関係ありません。課題は目標や理想とのギャップを埋めるためのものです。そのため、何も課題が感じられないということは、そもそも目標や理想形が意識出来ていないか、もしくはその基準自体が低いのかもしれません。
改めて、技術課題の例を比較しつつ以下にリストアップしてみます。
技術課題でないもの
- バトルスキルの量産タスク
- ミッションAPIの実装
- 機能実装のレビュー
技術課題になりうるもの
- バトルスキルを量産するための設計やワークフロー
- 高負荷時のミッションAPIのパフォーマンス担保
- 相互レビューのためのレギュレーション策定
- 重要なライブラリの技術選定
- より開発効率を上げるための自動化
技術課題マネジメントの方法
次に実際に取り組んできた技術課題マネジメントの方法を紹介します。とはいっても大層なことはしておらず、 主な要素は2つで、問題や課題を見える化するための「技術課題ボード」と、それらについて議論するための「技術課題定例」です。
1. 技術課題ボード
技術課題ボードは問題や課題などをチーム共通で書き留めて置く場所です。フォーマットは何でも良いですが、基本的に関係者全員がアクセスできるWebツールを利用します。自分が担当しているプロジェクトでは、以前まではTrello、最近ではClickupを利用しています。一番手軽に初められるのはGoogleスプレッドシートかもしれません。全員が見える状態にしているのは、基本的に議論に参加するエンジニアだけでなく、課題はチーム全員のものであるという認識をもって欲しいからです。
実際運用中の課題ボードは都合により掲載出来ないのですが、Trelloで行っていたときのイメージは以下のような感じです。
この上記のイメージ図でも示す通り、技術課題ボードは、できれば以下のような機能があると良いです。
- 進行中・完了などのステータスを定義でき、完全解決の状態で非表示にできる
- 1つの課題に対してサブタスク（アクション）を追加・定義できる
- 課題・サブタスク（アクション）に対して担当者、期日を設定できる
- タグやラベルを付与することで、適切に課題をフィルターして表示できる
- 重要度や緊急度の順に応じて並び替えができる
- 上記の動作や、起票、分割などの作業を手早くスムーズにできる
これらの機能が要求される理由は、記事の後半に紹介しているポイントを実践するためということもありますが、基本的な使いやすさや見やすさに寄与するということもあります。ツール自体が使いにくいと課題の確認が億劫になったり、問題の吸い上げ自体が滞ってしまうことも考えられます。
技術課題ボードはプロジェクト毎に1つが基本で、同一の課題ボードにクライアント、サーバー、インフラなど職種を跨いで課題が起票されます。過去にクライアント課題ボード、サーバー課題ボードと別れていた時期もあるのですが、ボードが乱立してしまうことや、クライアントエンジニアとサーバーエンジニアの連携が必要なケースなどのために統一することとしました。
その代わりタグやラベル機能を活用しています。実際には課題ごとに「クライアント」や「サーバー」といったタグを付与し、フィルター機能を利用することで、会議体に関係性が高い表示を都度作成して運用しています。
2. 技術課題定例
次に技術課題定例の実施です。こちらは週次もしくは隔週で、決まった時間に技術課題ボードを開きながら、課題に対してのアクションを議論します。
技術課題定例の設定頻度や粒度はプロジェクトに応じてまちまちです。規模や状況に応じて適切に時間や参加メンバーを調整しています。以下は具体的な例です。
少人数のプロジェクトの場合
- クライアント・サーバー全エンジニア参加Mtg（30分/週）
大人数のプロジェクトの場合
- クライアントリードエンジニア参加Mtg(1時間/週)
- サーバーリードエンジニア参加Mtg(1時間/週)
技術課題定例の基本的進行は以下のような流れです。技術リーダーやリードエンジニアがファシリテートを担当し、起票されている問題や課題に対して議論を進行していくケースが多いです。
- 進行中の課題に対してのアクション確認
- 進捗の確認
- 新しい事実やブロッカーが確認されたらアクションを再設定
- 未議論の課題に対してのアクション議論
- 状況の確認（問題の課題化）
- 重要度や対応時期の決定
- アクションの決定
- アクションに対する担当者・Due Dateの設定
なお、一度の議論やアクションでは課題が解決しきらないケースがほとんどであるため、繰り返し状況を確認したりアクションを再設定していきます。そのようにして、アクションを繰り返し、関係者間でコレはすでに課題ではないと合意できたら、起票された課題の取り扱いが完了となります。
技術課題定例は、問題や課題という不確実な要素に継続的にアクションを設定することで、徐々に不確実性を下げ解決に導く働きをします。認知されていない問題は、起票することでようやく扱うことができるようになります。問題は的確に分析することで、ブロッカーや課題が明らかになります。そういった、なぜそうなっているか分からない、どうしていいか分からない、どのくらいかかるか分からないという状態から、具体的なアクションやタスクを落とし込んで行きます。＊ただし、問題や課題の起票は誰でもいつでも行っていいルールです。
技術課題マネジメントのポイント
改めてですが、今回紹介している技術課題マネジメントの方法は大した話ではないのです。もしかしたら、こんな事は当たり前のようにやられているところも多いのかもしれません。
しかし、この「当たり前のこと」を継続的に取り組んでみると、実に難しいというということがわかります。自分が今まで関わってきたプロジェクトでも「課題リスト」というスプレットシートは大半存在していましたが、どうも形骸化してしまっているケースが多かったです。数多くの問題や心配事、気になっていること、起こりうるリスクなどが、プロジェクト開始時や大きいマイルストーンの振り返り時に集まりますが、課題リストを見返したり、解決のためのアクション設定が様々な要因から継続しないのです。
そういうこともあり、継続的に課題に向きあうためのスキームとして、現在のメソッドにたどり着いてきました。それらを実践するために特に大事だと考えるポイントを紹介します。
1. 課題定例の参加メンバーを見極める
ミーティングの基本ですが、課題について話すメンバーは限定したほうが良いです。大体6人くらいまでがちょうど良いのではないかと思います。人数が多いと、特定の議論には関係無い人が多数存在しうるため、その人たちの時間を無為に消費することになってしまいます。そして技術課題という特性上、時には深い議論が必要なケースもありますが、大人数が参加している会議では、発言しにくい空気などが働き議論が浅くなってしまうこともあります。
チームの規模や状況に応じて、リーダーのみ参加することや、技術領域に応じてミーティングを分割するなど調整したほうが良いでしょう。
ただし、議論に参加しているメンバーのみでは解決出来ない課題や、課題はチーム全体のものであるというような意識を忘れないように、課題ボードを開示したり、定期的にメンバーを入れ替えるなどの工夫をするとより良いかと思います。
2. とにかくネクストアクションを決める
課題は、その性質上どのようにしたら解決できるのかが、すぐにはわからないものがほとんどです。調査や検討・計画などが必要なものもあります。技術課題定例の中で方針が念密に議論できれば一番早いのですが、多数のトピックについての議論時間が足りないこともしばしばです。
そのような時は、「有識者で集まって別途議論する」というアクションを設定することでも良いと思います。とにかく、なにかしらで良いので不確実性を減少させるアクションを設定し、課題の状態を進展させましょう。
一番よくないのは、「これどうにかしたいよね〜」というコメントや感想で終わってしまうことです。
3. 担当者・期日を決めてログを記録する
こちらもミーティングの基本ですが、議論した内容はキチンとログを取りましょう。大きめの課題は一度の議論で解決しないことがほとんどで、数回の定例で継続的にトラックしていきます。そのため、前回議論した内容が残っていないと「先週どういう話になりましたっけ？」という回想で時間を浪費してしまいます。
今回紹介した方法では、分離されている議事録というよりは、技術課題ボードの課題項目のそれぞれに状況や議論の経緯などを履歴として記載していきます。
また、議論の結果決まったネクストアクションは、別途サブタスクやチェックリストの項目に記載し、必ず担当者と期日を設定しましょう。このようなルールにすることで、ミーティングのアウトプットやアクションの実行が担保されやすくなります。担当者は、可能であれば有志で名乗りでてもらい、それが難しそうであれば、ファシリテーターの人が候補者を指名しつつ最終的にメンバーで合意を取るようにしましょう。
4. 積極的に解決に持ってく・議論スコープから除外する
この技術課題マネジメントをやってみるとわかるかもしれないですが、大・中・小ものすごい量の課題が起票されていきます。
よって効率的に議論を進めるために、もう議論が必要ないと判断されるものは、進行中状態のものから排除するようにしましょう。課題ボードが埋め尽くされると不安感も募りますし、議論時間も伸びてしまいます。
以下のようのなパターンで対応することが多いです。
不確実性が下がった課題
調査や設計が完了し、対応のためのタスク登録が完了したら一旦解決とみなすこともありです。実装途中になにか問題が起きたら再起票や状態を戻せばよいかと思います。
他のタスクが優先され進捗が明らかに遅い課題
期日を設定してもどうしても間に合わず、リスケジュールが何回もおきてしまっているものは、もしかしたら緊急度が低い課題かもしれません。PENDING状態にして、しばらく議論から除外することを検討しても良い場合があります。
議論・対応するには時期が早い課題
先行して予見すべき課題をリストアップすることは重要ですが、その他の要素が確定しないと議論出来ないものもあります。そのようなものは、開発マイルストーンごとや四半期単位の粒度でグルーピングし、その時が来るまでは一旦非表示にしておくと良いです。
緊急度が低い課題
無理して今やる必要が無いと判断できるものはBACKLOGなどのグループにし、進行中の課題が少なくなってからあらためて議論すると良いでしょう。
5. 詳細な議論の継続と切り上げを見極める
基本的には技術課題定例では課題に対するネクストアクションを決め、それらの状況を確認していくことが主題になっています。その場で、1つずつ技術的な詳細や、実装箇所のコードなどを追っていくと明らかに時間が足りません。場合によっては、議論やコードを追うのを打ち切り、別途調査タスクを設定したほうが効率的です。
しかし、議論が詳細に入りつつ核心に迫る場合もあります。せっかく貴重な時間を使い技術リーダーに集まってもらっているため、その場で合意が取れそうであれば、議論を継続することも重要な判断です。やりかけの10の課題を継続するよりも、1つでも課題をきっちり解決したほうが良いことだと思います。
6. 厳密になりすぎない・問題や課題感を吸い上げ・課題に変換していく
技術課題ボードに追加される問題や課題の粒度はまちまちでOKです。「そんな気がする」という抽象的なものから、議論の結果「課題」でないケースということもありえるでしょう。
課題を扱うためには、まず認知するということが非常に重要で、難しいポイントです。これは、長期間同じメンバーで開発を進めていたり、プロジェクトが忙しくなると、どんどん、目標や他との「ズレ」や「異常」に鈍感になっていくためです。誰でもどういったものでも、課題ボードに起票して良い「空気」のようなものは大事にすべきことだと思います。
もちろん、問題点や経緯、ブロッカー、解決方針まで記載されていれば素晴らしいですが、これらは技術課題の定例で議論していけば良いと思います。議論したのち問題のポイントが明確になったら、タイトルをより実態を表すものに変えたり、他の課題と統合したり、分割などを行います。
7. バックログの課題に向き合う・振り返る・棚下ろす
上記を踏まえ技術課題ボードで扱う課題が増えると、とてもではないですが、定例の中ですべての状況をトラック出来なくなるケースも出てきます。そのような時は以下のようにすべきです。
- 技術課題定例の主催者が事前に仕分けや整理を行っておく。完了させてしまいたいカードをピックアップし重点的に議論を促す。
- 別途定例とは別途の時間を設定して議論する（おかわりタイムや合宿など）。
- 開発フェーズごとや四半期に一度、残課題などを棚卸し、次の区間の計画を立て直す
一番良くないのは「やるのかやらないのか決めない」ことです。
8. 技術的な価値の説明をする・あきらかな無理はしない
最後は一番むずかしく重要なポイントです。技術課題の対応は通常の業務とは別に、突如発生したりします。そのため、他の作業時間を圧迫したり、時には残業でカバーするケースも出てくるかもしれません。
簡単なものやピンポイントで完結するものは、それでも良いもしれませんが、しっかりと工数管理しながら進めるべきものもあります。例えば新しい技術を導入するケースや、一定規模のリファクタリングを行うケースが挙げられます。このような場合は、プロジェクトマネージャーやディレクターにきちんと説明をしながらプロジェクトの状況に合わせつつ進めることが必要です。
もちろんリリースに必須な要素であればわかりやすいですが、反面パフォーマンスを最適化するようなものや、作業効率を上げるようなツールのような費用対効果が見えにくいものはどうでしょうか。プロジェクトの責任者は、目に見える実用可能な機能要件と、技術がもたらすであろう見えにくい要素を天秤にかける必要があります。そのためにも技術者は、それらの価値やリスクを説明する必要あります。
技術リーダーは、技術ビジョンを見据えて技術課題の解決を推進していく使命を持っていると言えますが、課題という性質上つきまとう不確実性が工数管理の問題を複雑化させます。課題の緊急度・重要度を見極めて、ビジネスサイドと連携・対話しながら、時には厳密に、時には柔軟に動きを変える必要があります。
まとめ
今回は、ワンダープラネットで取り組んでいる技術課題マネジメントの方法とポイントについて紹介しました。とても基本的なことが多いですが、技術課題ボードと技術課題定例を組み合わせることで、課題の認知の促しと、課題に対するアクション設定を継続的に行うといったシステムになっています。これにより不確実性が高い課題に対しても、確実に取り組むことができるようになります。とは言っても、課題の性質はそれぞれだったり、起票される課題数が多かったりして、何にリソースを割くべきなのかを泥臭く都度判断することは必要です。これはまさにマネジメントと言えるのでしょう。
課題マネジメントはチームやプロジェクトをより理想の姿に近づけるために重要な取り組みだと考えます。今回は「技術課題」での適用の例でしたが、これらの基本スキームは、他の組織課題やプロジェクト課題などに対しても適用可能です。身近に「どうにかしたいな〜」と感じることがあれば、ぜひ参考にしていただければと思います。