はじめに
どうも、レバテックでCREを進めている住村です。
レバテック開発部では社内でテックブログ執筆を促進するためのキャンペーンをやってまして、前回の記事がなんと社内のテックブログ執筆のキャンペーンで賞品をいただけました！
賞の連絡をくれた編集長が「何でもいいよ！」と言ってくれたので、遠慮なく犬用の服を選ばさせていただきましたが、それで実際買ってくれたので凄いですね。
賞品を着た愛犬。この数分後に芝生で転げ回り、早々に汚しました
今回の記事では、前々回の記事で少し触れた、業務の選択と集中について書いていきます。
想定読者
- 事業会社のエンジニア
- 規模に対して人員が不足気味で、タスクの調整や優先度の意思決定をするレイヤーが不足
- なるべくコストをかけず、出来る範囲で該当レイヤーの負荷を減らしたい
やったこと
チームの状況
現在、レバテックのCREチームではシステム化対象の領域を可視化/計測し、それを元にした改善活動を進めようとしています。
理想を言えば事業と開発の目標設定まで含めてプロセスを改善したいですが、一気にそこまで進めるには解像度も足りず、実施する際のハレーションも大きいです。
そのため、CREチーム立ち上げ後の初動の対応ではリスクが高いと判断し、まずは信頼貯金を貯めて現状の解像度を上げて今後の動きに繋げることを目的に、なるべく小さい対応から進めたいと考えました。
どういう流れで対応したか？
大枠の流れ
今回の対応は、ざっくり下記の流れで進めました。
- 現状の全体像を把握
- 仮説設定、方向性の検討
- 関係者へ方針の壁打ち、実施の意思決定
具体的な流れ
まず、現状の開発プロセスの全体像を把握するためにバリューストリームマッピングを作成しました。
今回は作業着手前の段階で関係者と話していて「開発におけるタスク調整の負荷が高い」という情報があったので、ほぼその裏付けを取るための情報整理でした。
具体的には、タスク要望が発生してから意思決定がなされて開発に入るまでのプロセスに着目し、そこに関わる関係者と会議体とその頻度などを整理し、関係者にヒアリングを進めました。
その結果として、下記の課題が分かりました。
-
優先度の意思決定コストが高い
- システム化対象の業務範囲が広く必要とされる業務知識量が多いので、意思決定に必要な情報収集のコストが高い
- 現状は意思決定コストを下げるため、依頼者の所感をベースに優先度を調整
- タスク間の関係性が薄く、知識が再利用できない
- システム対象の業務範囲が広く、対応インパクトだけをベースに順に対応していくとタスクを対応する際に都度キャッチアップが必要
これらの課題情報を元に、営業・開発双方の調整担当の人に実現可能性や妥当性など適宜壁打ちをしつつ、詳細を詰めていきました。
前述のリソース状況の中で協力してくれたことには感謝しかありません。。。
その後は事業のステークホルダーと実施可否の意思決定の場を持ち、現状の問題に対して理解を示してもらえ、特に反対もなくGOサインが出たので実施しました。
ここの意思決定がスムーズだった要因として、相談の前に非エンジニア向けの開発生産性の研修をやっていたのも大きかったです。
研修の中で開発業務における認知負荷/コミュニケーションコストが高いことを軸に研修の背景を説明していたので、ステークホルダーからも「この辺、前やった研修でも言ってた部分だよね」とすんなり理解してもらえました。
（ここは研修でやったことが次に繋がった感じがあり、個人的に嬉しかったポイントです）
何をやった？
状況としては前述の通り、人員に対してシステムの規模が広く、調整・意思決定のコストが高い状況でした。
なので、今回の対応ではいわゆる選択と集中によりシステムの対応範囲を減らして負荷を減らすことを意図しました。
具体的には、システム化対象となる業務をいくつかの領域に分割し、期間毎に対応する領域をローテーションすることにしました。
従来の対応範囲と、変更後の対応範囲
ローテーションする対象領域の順序については課題リストに起票されていたタスクの統計を取り、優先度の高い領域が多いところから進めていくことで合意しました。
また、システム化対象とする業務領域を限定することで、タスク間の関連性が生まれてタスクを進めて得た知識が再利用され、キャッチアップコストが下がることを期待しました。
どうなった？
そして実行した結果ですが、優先度の意思決定に対するシステムディレクターの負荷は想定通り下がりました。
優先度調整前に精査すべきタスクの総数が多かったので、対象とならない業務領域のタスクは精査するまでもなく対象外とできたのはシンプルに効果が出ました。
従来だと優先度調整前に精査する領域が広く、タスク数が多い
変更後だと業務領域でフィルタできるため、精査に必要なコストが下がる
次に、知識の再利用によるキャッチアップコストの軽減についてはほぼ効果がありませんでした。
これは、初手なのもあり大きめの粒度で領域を分けたので結局タスク間の業務の関連性がそこまで無かったためです。
立案段階で切る粒度が広くて効果が薄くなる可能性は想定しており、1Qの振り返りで効果検証するつもりではいたんですが、思ったより効果が無かったのでそこは残念でした。
本筋の可視化が進めばより効果的な切り方もできるかもしれないので、その際も業務領域の選択と集中が必要であれば活用してみようと思います。
所感
やってみた結果として一定の効果はありましたが、劇的な効果はありませんでした。
タスクのリストに上がった優先度の意思決定部分に関するコストが半減できたので確実に負荷は減らせたものの、タスク調整のコストはまだまだ高いのでそこは引き続きの課題です。
今回は対応に必要なのがほぼ意思決定コストだけだったので、対応にかけたコストを考えると良い結果だと思うので、やって良かったと思っています。
また、ヒアリングを通して関係者との関係性も構築でき、CRE活動で考えている方向性への所感も聞けて今後の動きの準備にも繋がったので、当初の目的は達成できました。
次回は、現在のCRE活動の本筋として進めている業務の可視化と計測について記事を書こうと思います。
レバテック開発部の公式テックブログです！ レバテック開発部 Advent Calendar 2024 実施中: qiita.com/advent-calendar/2024/levtech
Discussion