開発生産性のために効率が必要なら、ヒトよりもシステムやプロセスを観察したい

この記事は前作 開発生産性を標榜して効率に拘泥するチームはゆるやかに衰退する に続き、とはいえ効率を含む開発生産性的なものと向き合わねばならないチームや組織に向けた3作目です。そろそろ開発生産性がゲシュタルト崩壊してきた。

前提、わりと普通な話を述べているつもりだが、円滑になりきれないチームでは普通ないし妥当に至るハードルが思いのほか高いと感じる今日この頃。

人的効率主義に対するアンチテーゼの補足編

安直に (特に人間に起因する) 効率だけを求めて、効果や成果そのものから目を逸らすのはやめよう。 本来的な存在価値にそぐわない改善活動に腐心することは衰退の兆候である。 開発生産性を標榜して効率に拘泥するチームはゆるやかに衰退する

開発成果を念頭に起きつつも、どこかで一定の効率が必要なことを疑う余地はない。チームや組織の中長期を俯瞰すると正面から成果に向き合えるタイミングばかりではないので、そうでないときに効率だけでも良くしたいときだってある。

小手先の開発アクティビティ指標（人的行動量）をこねくり回しても意味がないという立場には些かの変化もないが、今回は「成果のためには効率も良くしたい、とはいえ数字だけ眺めても"頑張る"以外にどうしてよいか分からん」という気持ちを踏まえた記事としている。

※ 以下で可視化サービスと呼称するが少なくとも国内サービスは成果までトレースできる段階にない為、あくまで開発アクティビティ指標を可視化しているものという前提で記述する。

システムよりも個人に目がいくバイアスを自覚する

引き続き人的効率主義に警鐘を鳴らす話ではあるが、多くの可視化サービスが GitHub 由来の行動量や時間を中心に計測しているため、特にチームメンバー同士で画面を眺めていると「個人がどのように行動すれば短縮できるのか」という思考に引っ張られやすい。

• 開発アクティビティ指標の多くは人に起因する
• しかし、人のアクティビティには事情も余念も言い訳もある
• 個別の工程を雑に短縮することは無意味どころか有害たりえる
• 末端の数字だけ追っても有効打に繋がらず、可視化と行動の想起が噛み合わない

人の効率化は容易でない(※)が、システムやプロセスは効率化できる ので、個人の努力に閉じずチームや組織として効率的なシステムやフローを整備することによる効率向上は期待できる。もちろん個人・チームの単位でパッチサイズを小さくして影響範囲を限定し、早くレビューを回していこうといった基本的なプラクティスは当然に押さえているものとする。

※ 作業単位に分解されてシステムに組み込まれた業務体制であれば話は異なり作業や工程の標準化による恩恵が順当に考えられる。しかし今「開発生産性」に関心を持つソフトウェアエンジニア諸氏に係る本来の期待はそういう仕事ぶりではないと仮定している。科学的管理法が適用可能ならば、ソフトウェア文脈の開発生産性以前に「時間と金」で説明できる。

システムやプロセスを軸とした効率改善の選択肢4つ

「正面から成果に向き合えるタイミングばかりではないので、そうでないときに効率だけでも良くしたいことはある」を念頭に、チームや組織の立場で講じうる効率化の打ち手の類型を試みる。これらは必ずしも既製の可視化サービスが観測可能な情報とは限らない。

1. 段取りプロセスの改善

典型的に開発工程への影響が大きい段取りの関心としては、所謂「手戻り」を減らすためのプロセス改善が効果的と考えられる。意思決定や開発仕様の過度な曖昧さが忌避されがちだが、ユーザーや事業背景の理解が乏しいまま着手してしまう悪い意味でのフットワークの軽さも忌避されるべきだろう。

2. 習慣プロセスの改善

人起因の開発効率に近しいが「開発イシューの細分化 → パッチサイズ、プルリクエストの小型化 → レビュー負荷の低減、デリバリーサイクルの向上、影響範囲の限定・明瞭化」のようなプロセスと機序は期待しても良いと考えている。経験則もあるが、比較的副作用が出づらく汎用的なプラクティスと言える。個別具体においては他にも良い習慣はあるのだろう。
個人の努力ではなく習慣、プロセスに落とし込んでこそということは留意したい。

3. 足回りシステムの改善

ビルド、テスト、デプロイ等のフローをシステム的に改善、効率化することはソフトウェアエンジニアリングとしては優先的にアプローチしたい関心事であり、実際そのようにしているチームや組織は多いだろう。CI/CD をただ座して待つ開発者はいないにせよ、テンポの良さは確実に開発効率に影響を及ぼす。

いたずらに工程の処理時間が長いのは論外だが、例えばパッと出してパッと直すが許容されているフェーズにも関わらずリリースに1時間かかってしまうとすれば改善を講じるべきだ。一過性の開発者体験を言い訳にアジリティを犠牲にすることの正当性は (ほぼ) 無い。速い方が正義だ。

4. 作業システムの改善

日常的な割り込みや、定常的に発生する手作業（トイル）の自動化、システム化も優先的に取り組みたい。下手に都度の手間、時間が許容できてしまうと後回しになりやすいが、その積み重ねが奪っている時間は大きい。不具合調査や問い合わせ対応が頻発するのであれば、その原因をプロセスから摘み取る改善も視野にいれることになる。

総じて、段取り・習慣の改善はおおよそチームに託されやすいが、足回り・作業の改善は組織横軸でもアプローチできる。組織の規模が許すならば、頼れるはずの横軸を上手に使う発想も必要だ。目の前にある数字だけでなく、バリューチェーン全体をフラットに見渡す姿勢が重要だろう。

可視化サービスには行動変容の仕掛けを期待したい

システムやプロセスを作るソフトウェアエンジニアであればこそ、自分たちの開発活動も同様に改善できるはずである。指標の上下は今そこにあるシステムやプロセスの結果でしかない。数字を見て小手先の操作をするのではなく、大元の開発活動のシステムやプロセスに対して行動変容を起こさなければならない。

可視化サービスの立場としても、変動を眺めているだけでは開発生産性が改善しないのは百も承知であり「録れるログを全て録って、出せるログを全て出す」が取っかかりに必要だとしても本命は行動変容につながるインサイトの示唆ではないか。

現状の生産性可視化サービスに直接的な事業インパクトを求めるのは酷かもしれないが、もしインサイトの示唆によって導入チームの行動変容を正しく加速できるならば、それは事業インパクトへの先行指標として十分に有意義と思われる。

追記

本稿では（タイトルの割に）既存のシステムやプロセスをどう観察して現実的にアプローチするかまで掘り下げていない。少し思い返すと技術・プラクティスを起点にすると本来的なマトを見失うという話があり、考え方の取っ掛かりとして過去の同僚氏の資料を思い出すに至った。

自分は事情・背景をよく知っているという補正もあるが、今も通用する示唆があると思ったので参考までにご紹介させていただく次第。

---