そのような状況に、一部の優秀な開発者は我慢ならない。憂いている。「このままではまずい、積み上がった問題に取り組むために時間が欲しい」「まとまった時間でなくても、継続的に取り組むための少しの割り当てでも構わない」と。そんな願いも虚しく、使える時間はすべて、担当する開発を進捗させることにのみ費やすことを強いられる。
私たちエンジニアリングマネージャーやテックリードは、このような状況を見て見ぬふりをしていないだろうか。開発の進捗やシステムトラブル以外にも注意を向けるべき対象がある。それを関係者らに伝えられているだろうか。説明責任を果たし、ソフトウェアの内部品質や開発プロセス上の課題を組織の課題としてプロジェクトで認識を共有することができているだろうか。
本記事では、ソフトウェア開発における関心事を組織の関心事にまで押し上げ、その問題や課題に取り組むための方法について考えていく。
- 情報の分断が組織を分断する
- 問題や課題の存在に同意を得る
- メトリクス化により関心事を評価する尺度を揃える
- 良し悪しの判断基準を統一する
- 時系列変化の可視化で一体感を醸成する
- コントロールからチームを守る
- 目標設定で期待値を合わせる
- メトリクスの自己目的化を回避する
- 最後に
情報の分断が組織を分断する
スクラムに代表されるモダンなソフトウェア開発手法では、誰が、何を、いつ、どのように行うかを決める主体はチーム自身だ。そのような自己管理型、自己組織化がチームのあり方とされる。
しかし、それを実践できる組織がどれだけあるのだろうか。現実の現場で「チーム」と呼ばれるものは、ソフトウェアエンジニアだけで構成され、その活動は、内部設計や実装からリリースまで、そして本番運用に限定されていることも多い。何を作るか、それをいつリリースするかは、企画を含むビジネス担当者らが中心となって決める。経営者が関与することもあるだろう。そして、その強い意向によって、チームがその意思決定に関与する余地は、見積りを提示してリリース日やスコープをわずかに調整する程度となるのだ。
このように、ビジネスと開発が分断した組織構造は、それぞれが有する情報や関心事の共通範囲が狭く、相互理解が乏しい。その状況でビジネスリーダーが意思決定を行うとしたら、ソフトウェア開発上の関心事が意思決定に及ぼす影響は必然的に小さくなる。
しかしもし情報の分断がなく、ビジネスの課題もソフトウェア開発の課題も互いに理解し合えていたとしたら、そもそも組織も分断していないのかもしれない。ビジネス上の関心事とソフトウェア開発上の関心事の両方を総合して下す意思決定が、組織を一体化するのだ。その先にあるのが、機能横断型で自己管理型のチームというわけだ。
そう考えてみると、問題の根底にあるのは、情報の流通にあるとは言えないだろうか。ソフトウェア開発上の関心事は専門性が高く、その理解に知識や経験を要するため、ソフトウェアエンジニア以外がそれを理解することが難しい。このことが障壁となって、開発からビジネスへ情報が流通しにくくなっているのだ。また、ビジネス上の関心事は比較的理解しやすいのであるが、そこに興味を持つエンジニアが少ない。これらの事情ゆえにビジネスと開発はそれぞれが自分たちの領域にとどまって活動する。これが、組織の分断の実体ではないだろうか。
このような分断を解消することは、テックリードやエンジニアリングマネージャーの責務だと考えている。互いの情報を流通させ、組織を一体化させていくのだ。少なくとも、自社ソフトウェアプロダクトの内製組織では、ビジネスも開発も利害は一致する。プロダクトのユーザー価値およびビジネス価値を高め続けることがミッションであるからだ。遂行するミッションが同じならば、情報や組織の分断を解決することも可能なはずだ。対立しているのはミッション遂行の手段の優先順位付けであり、その対立は低い相互理解によって生じているだけである。
この対立解消に向け、ソフトウェア開発上の関心事を伝える方法を以降で考えていく。ビジネス上の関心事を開発者らに伝える方法についての検討は、本記事では対象外とする。
問題や課題の存在に同意を得る
取り組むべき問題や課題の存在を意思決定者が認識していなければ、そこに時間をかける意思決定がなされるはずもない。意思決定者がビジネスリーダーであってもチーム自身であってもそれは同じだ。まずやるべきことは、ソフトウェア開発上の関心事の認知をチーム内外に浸透させることだろう。
「ソフトウェア開発上の関心事」と言ってしまうと、その影響が開発者らだけに閉じているように聞こえてしまうが、もちろん実際はそうではない。組織全体のミッション遂行に必ず影響する。それを切り口としてソフトウェア開発上の関心事を伝えなければ、開発者の話がビジネス担当者らに響くことはないだろう。つまり、ソフトウェア開発における関心事は、ビジネスにおける関心事でもあるということに同意を得るのだ。
組織全体のミッションは、ビジネス目標として表現される。それは、ビジネス価値やユーザー価値で計測される。そのいずれであっても、価値の総量の変化は、ソフトウェア開発によって駆動されることを前提としている。マーケティングや営業努力だけでは継続可能性が低い。ソフトウェア開発なしには、中長期での目標の達成はありえず、ミッションは失敗に終わる。だから、ソフトウェア開発における関心事は、ビジネスにおける関心事と言えるのだ。
このことは、組織がミッションとして扱う領域を「価値」と「価値を提供する組織の能力」に分けるとより理解が深まる。私は以前の記事でこれらの探求を「プロダクトの差異化」と「組織としてのプロダクト開発能力の差異化」と呼んだ。また、Scrum.orgのエビデンスマネジメントガイド（Evidence-Based Management Guide）ではこれらをそれぞれ「市場価値（market value）」「組織的な能力（organizationl capability）」という言葉で表現している。この表現がしっくりくる。市場価値とは、例えば市場占有率や顧客満足度、アクティブユーザー数などが挙げられる。組織的な能力は、DORAのFour Key Metrics（変更のリードタイム、デプロイの頻度、サービス復旧時間、変更失敗率）や、ソフトウェアの内部品質などだ。
ビジネス目標は「市場価値」を問うものだ。開発者は、同じミッションを遂行する組織の一員として「市場価値」を探求することはもちろんであるが、ソフトウェア開発においては「組織的な能力」を探求することになる。そして、ソフトウェア開発上の関心事に問題や課題があるなら、組織的な能力が不足した状態になる。市場価値を高める可能性が下がり、価値を届けるまでの時間が長くなり、価値の継続的な提供を困難にする。それゆえ、ソフトウェア開発における関心事は、ビジネスにおける関心事と言えるのだ。
リーンと同様、トヨタ生産方式に起源を持つTOCでも、思考プロセスにおいてまず最初にやるべきは、問題や課題の存在について同意を得ることだ。認識しない問題や課題に取り組む判断などあり得ない。ソフトウェア開発上の関心事に対し、ビジネス担当者らからの同意を得る必要性はそこにあるのだ。
メトリクス化により関心事を評価する尺度を揃える
ソフトウェア開発上の関心事は質的な情報を多く扱う。それらを説明するのはとても難しい。説明する側とされる側、互いの語彙や知識、経験が揃っていなければ、それがさらに障壁となって伝わらない。エンジニアとビジネス担当者とのコミュニケーションがまさにその典型だ。それは、ソフトウェアの内部品質を話題にするシーンを思い浮かべると明らかであり、エンジニアの多くが経験するところだろう。
しかし、概念は伝えられる。伝えるための工夫や努力は必要であるし、相手も理解しようとする姿勢が必要であるが、それらが揃えば、内部品質が何であるか、それがどう問題なのか、理解を得られるだろう。
問題となるのは、概念の理解ではなく、ビジネスリーダーがその「程度」を推し量ることができないことだ。概念を理解できても、ビジネスリーダーは、対象そのものを見て、それを評価する術を持ち合わせていない。評価ができなければ、判断ができない。問題があるのかどうか。問題があるなら、それは大きいのか小さいのか。
そのもので推し量れないなら、推し量れる別のものを見て判断するものだ。「いま現時点でプロジェクトは順調に進んでいる」と、少なくともビジネスリーダーにはそう見える。だから、「おそらく問題はない、あるいは小さいのだろう」という評価にいたってしまう。技術的な問題への対処に時間を割かないという判断になる。この結論が、エンジニアの判断と合わないのだ。プロジェクトが順調に進んでいるように見えるのは、「自分たちが苦労して何とかカバーしているに過ぎない、いずれ破綻する」と認識しているからだ。
ここで、量的な情報が必要になる。「コードの保守性が低すぎて開発時間がかかるから、早急にリファクタリングが必要だ」と言ったところで判断できない。保守性がどのくらい低いのか。開発時間がどのくらい余分にかかるのか。それらを評価するために、客観的に定量化した数字が必要なのだ。
とは言え、それらを正確に定量化することは難しい。完璧なメトリクスを作ることは諦め、代替メトリクスを使った方が早い。保守性に関係するメトリクスであれば、静的コード解析ツールから得るのが簡単だろう。ツールが提供するメトリクスは、状態を正確に表したものにはならないが、まったくの的外れな数値でもない。例えば静的コード解析ツールのSonarQubeであれば、テストカバレッジやコードの重複、複雑性、保守性などを計測して数値やランク（rating）で表現する。一部ではあるが、問題の改修にかかる時間の見積りも提供される。こういったものを活用すると良いだろう。
チーム内の開発者らへのアンケートなどを通してスコアリングしても良い。客観性は失われるが、これを見ることで、ビジネスリーダーも課題の大きさを実感することができる。
メトリクスの検討は、書籍『アジャイルメトリクス』が参考になるだろう。
なお、メトリクス化すると言っても、ソフトウェア開発の関心事を、ビジネス上のKGIに連なるKPIツリーに変換する必要性を説いているわけではない。先に述べた通り、ビジネスとソフトウェア開発では、責務とする領域が異なる。市場価値を扱うビジネス系のメトリクスに対し、組織の能力を扱うソフトウェア開発系のメトリクスが及ぼす影響は間接的だ。無理に関連付けようとすると、その効果の判断で悩むことになるだろう。
良し悪しの判断基準を統一する
メトリクス化しただけでは、それが良い状態を表しているのか悪い状態を表しているのかの基準が組織内で揃わない。計測されたメトリクスを見て、ビジネスリーダーは「問題なさそうだから機能開発に専念すべきだ」と言うかもしれない。一方で開発者は「悪い状態だから今すぐ問題に取り組むべきだ」と言うかもしれない。これは、ビジネスと開発の間で評価が分かれるだけでなく、開発者間でも評価が分かれる可能性もある。そもそも、メトリクスの良し悪しが判断できない場合だってある。
良し悪しの境界となる何らかの基準が欲しいところだ。そうすれば、その基準を上まわっているなら良く、下回っているなら悪いという判断が統一できる。
システムパフォーマンスをはじめとする外部品質と呼ばれるソフトウェア品質は、その基準策定に合意を取りやすい。ユーザーが見て、触れて、感じられる品質は、ユーザー体験に影響するため、ビジネス上の関心事として扱われることも多い対象だからだ。そもそも、外部品質の良し悪しは、ビジネス担当者自身も体感できる。このようなメトリクスは、ビジネス上の関心事として扱われることも多い対象であり、非機能要件として従来どおりに定義すれば良いだけだ。
一方で、内部品質やチームパフォーマンスについては合意が難しい。内部品質はどれぐらいが妥当であるか誰にも判断がつかない。チームパフォーマンスは、妥当なラインについて、開発者とビジネス担当者との間で意見が対立したりする。
このような合意が難しいケースでは、組織の内外から比較対象を見つけると良いだろう。内部品質であれば、社内の他のソフトウェアの測定値と比較してみることもできる。比較対象とできるソフトウェアが無いのであれば、OSSの内部品質を計測してみて比較する手も使えるかもしれない。チームパフォーマンスであれば、DORAやpuppetのState of DevOps Reportで公開されているクラスタ毎のパフォーマンス値を参照しても良いだろう。
もしそういった比較対象を見つけられないなら、自己参照してみるのも良い。チーム内の意見を聞き、過去の経験を踏まえて良かった時期、悪かった時期がどうだったのかで基準を決めるのだ。ベロシティのように、他チームと比較することに意味がないメトリクスはこの方法で定義することもできる。
ただし、ベロシティがそうであるように、メトリクスによっては、基準ラインを決めることが「メトリクスの自己目的化」という別の問題を生じさせることもある。これについては後述するが、そういう場合は良し悪しの判断基準を決めず、「時系列の変化」を追うだけでも良いだろう。
時系列変化の可視化で一体感を醸成する
ソフトウェア開発上の関心事に対するこういった取り組みは、ビジネスリーダーらから理解を得られても、組織内では他人事になりがちだ。賢明に取り組んでいるのは開発者だけで、その外側にいる人たちは関心を持たないばかりか、取り組みの存在自体を知らないことも多い。「自分たちにできることは何もない」という意識もあるからだろう。これはちょうど、ビジネスに関心を持たない開発者と同じ構図だ。その上、取り組みへの同意を得たはずのビジネスリーダーらの関心も長続きはしない。
メトリクスの時系列での変化を組織全体に可視化すれば、この残念な状況を多少改善できるだろう。ここで言う可視化とは、変化を定期的に報告するということだ。組織やプロジェクトの週次報告に記載しても良いし、組織全体への月例会で報告しても良い。とにかく、メトリクスが取り組み開始時や前回報告時と比較して改善しているのか悪化しているのか、時系列での変化を能動的に発信するのだ。
時系列での変化を報告すると言っても、ただ「上がった」「下がった」だけを伝えても意味がない。なぜ上がったのか、なぜ下がったのかを分析し、それを踏まえて次にどのようなアクションを取るべきかも伝える。時系列の変化を見ることで、現在と過去の比較だけでなく、そこから未来を予測することもできる。過去から現在までが悪化傾向ならば、現在から未来も悪化傾向である可能性が高い。この観点も踏まえた上でアクションを立案し、報告に含めると良いだろう。また、これらの変化がビジネスにどう影響し得るかについて、定性的にでも伝えたいところだ。
これを続けることで、ソフトウェア開発上の関心事への取り組みに対し組織内での認知が進み、一体感がわずかでも醸成される。それは、組織内の誰かとのちょっとした会話の時にあらわれる。開発者以外から、取り組みに対する感想が聞けたりするようになるからだ。こういった声が、チームのモチベーションにつながるだろう。
コントロールからチームを守る
定期報告の存在は、「管理されている」という感覚を開発者に植え付けかねない。特に、報告を受けたビジネスリーダーが報告内容に対して否定的な意見を述べ、アクションを指示したりといったことが繰り返されたときだ。これは、報告相手となるビジネスリーダーが報告者より立場が上の場合に起こりやすい。「管理されている」という感覚は、開発者らの主体性を奪う要因になり得る。自己管理型チームから遠のいてしまう。
報告相手のこのような振る舞いは、性格によるところもあるが、開発者らに対する不信感から発せられることも多い。開発者との信頼関係が構築できていない状況は、分断された組織であるならなおさらだろう。この報告相手にとっては、開発者らが適切に問題や課題をとらえ、それに対する正しいアクションを取れるとは信じられないのだ。だから自ら指示を出し、開発者らをコントロールしようとする。
この問題への対策としては、まず、ソフトウェア開発上の問題や課題を開発者らが正しく認識しており、正しい対策を取ろうとしていることを報告相手にはっきり示すことだ。その上で報告相手が意見を述べ、それが妥当でないと思うなら、その場で議論すべきだろう。報告を受ける側と報告を行う側には、前者が上の立場、後者が下の立場といった上下関係が、自然と意識下に形成されやすいように思うが、「両者は対等である」というスタンスで議論したいところだ。そういう意味で、こういった役割はテックリードやエンジニアリングマネージャーが良いだろう。
他に考えられる対策としては、例えば組織やプロジェクトに関わる全員が参加するような、できる限り多くの人が集まるオープンな場で報告を行うことだ。人目が多ければ、報告者に対してコントロール的な発言をしがちなビジネスリーダーも、そういった発言を控えるだろう。
逆に、できる限りクローズドな場で報告する方法もある。テックリードやエンジニアリングマネージャーだけがそこに参加する。議論結果は、場に参加したテックリードやエンジニアリングマネージャーが翻訳し、フィルタを通して、第三者の建設的な意見として開発者らにフィードバックする。そうすることで、報告相手のコントロールからチームを引き離す。取り組みの主体はあくまでもチームにあるという意識を守るのだ。
このようなクローズドな報告による解決手法は、組織の分断を解消する時間を長引かせるため、おすすめできない。しかし、どうにもアンコントローラブルなプロジェクト関係者が存在する組織では有効な手段となり得る。とにかく、このクローズドな議論の中で、1日でも早く信頼関係を築くよう努力を続けるしかない。
ここで注意したいのは、あいだに入ったテックリードやエンジニアリングマネージャーに蓄積されるストレスだ。本音を話せる同僚がいれば、そのストレスもいくぶん軽減できる。特に、その同僚が、同じような立場、同じような経験を持つ人ならなお良い。社内に見つからないなら社外でも構わない。社外秘情報は話せないが、利害関係がない分、正直な話ができる。画期的な解決法でもなんでもないが、そういった仲間を作っておくことも、思ったより助けになるものだ。
目標設定で期待値を合わせる
いつまでに、どのレベルまでメトリクスを高められるか。例えば、現時点では基準ラインを下回っているメトリクスが、3か月後に基準ラインに到達できると開発者らは考えているとしよう。3か月後というのは早いのだろうか、遅いのだろうか。開発者とビジネス担当者で意見が分かれる可能性がある。そしてそれは、開発者よりビジネス担当者の方が楽観的な期待を持っていることが多いだろう。その認識のズレに気付くのが遅ければ遅いほど、現実を知った時のビジネス担当者の落胆は大きくなる。それがしこりとなって、互いの信頼関係を壊す結果を招くことになるかもしれない。
取り組みを始める前に、目標を定めてビジネス担当者らと合意しておくことは、彼らの期待値をコントロールする手段となる。いつまでに、どのレベルまでメトリクスを高められるかの認識のズレに、早期に気付いてそのギャップを調整できるからだ。
さらに、目標を時系列方向に細分化して、月次やイテレーション（スプリント）単位の計画に分解しておく。そうすれば、計画と実績の予実差異を知ることができる。前節で述べた定期報告には、計画と実績、そしてその予実差異を含める。これらの情報を定期報告に記載することで、ビジネス担当者らは現実を正しくとらえることができるようになる。
予実差異は、未来を予測するセンサーのようなものだ。実績が計画を下回っているなら、それは期日までに目標を達成できない可能性を知らせている。こうして事前に遅れを検知できるので、開発者は、早期に適切なリカバリアクションを取れるようになる。期日ギリギリになって慌てふためくようなことを予防できるということだ。予実差異によるこのようなメカニズムは、適応度関数として捉えることもできるということだ。
ただし、計画はあくまで計画。固執しすぎることは良くない。計画どおりに進めることが、必ずしも目的を果たすことにつながるとは限らない。目標や計画が間違っていると気づいたなら、見直せば良い。ここを間違うと、チームの中でメトリクスが自己目的化してしまう。
メトリクスの自己目的化を回避する
ソフトウェア開発上の関心事をメトリクス化し、目標や基準を定めることにはリスクを伴う。メトリクスが自己目的化しやすいからだ。開発者らが本来の目的を見失い、目標や基準ばかりを追い求める状況に陥ると、目的に対して意味のない手段でメトリクスを向上させる行動が目につくようになる。
こうならないためにも、あるいはこうなってしまった時も、開発者らが目的と照らし合わせて手段を選択するよう、テックリードやエンジニアリングマネージャーが常に彼らをサポートしたい。メトリクスとは、目的を果たせた時に目標や基準に達しているものだ。逆に、メトリクスが目標や基準に達したからといって、目的が果たせたとは限らない。ここを間違えないよう、チームが常に自らの行動を律する状態を作り出したいところだ。
興味深いことに、ビジネス担当者もソフトウェア開発のメトリクスを自己目的化する罠にかかりやすい。むしろ彼らの方が、開発者よりその傾向が強いようにも思える。その背景は、ビジネス担当者らが、自らの目標に対し特に強くコミットする職種であることに起因するのだろう。ソフトウェア開発が扱う目標と比べるとビジネス目標は、目的に、より近いものだからだ。ユーザー価値は別としても、ビジネス価値を高めるという目的とビジネスメトリクスを高めることはほぼ同義だ。目標を達すれば、目的を果たせる。その思考が染み付いているからこそ、ソフトウェア開発が扱う目標や基準においても、開発者に同レベルのコミットを求め過ぎてしまう。
もしビジネスリーダーらがそのような習性に基づいて、目標に達するためだけの不合理なアクションを求めてきたら "NO" と言おう。それを実行することが目的にとって意味がないなら、ビジネスリーダーらにそれを説明することは、我々の責務である。そうしなければ、チームが無駄なアクションに貴重な時間を浪費することになる。
自己目的化による問題は、目的に対してメトリクスが間接的であるほど起こりやすいのではないか。上述の通り、ビジネス目標で扱う売上や顧客単価といったビジネスメトリクスは、ビジネス価値を上げるという目的とほぼ一致するものだ。だから自己目的化による問題が起こりにくい。一方で、ソフトウェア開発のメトリクスは、目的を完全に説明することができないことが多い。不明瞭なのだ。だからこそ、目的を見失ってメトリクスを上げていくことが、必ずしも目的を果たす結果につながるとは限らない。目的を見据えてメトリクスを改善する手段を選択し、実行する。そしてその効果を検証し、次の手を導き出す。このフィードバックサイクルが必要なのだ。
実は、ビジネス系メトリクスでも自己目的化は起こり得る。ビジネス目標の達成はたしかにビジネス価値を高めるのだが、手段を間違えるとユーザー価値を損なうからだ。ビジネス価値ばかりを追い求め、ユーザー価値を犠牲にするなら、それはビジネス、ひいては企業として問題だ。企業やビジネスが掲げるミッションやビジョンに背いた行為だと言える。だからこそビジネス価値とともにユーザー価値も問わなければならない。ビジネス価値を計測するメトリクスばかりでなく、ユーザー価値を計測するメトリクスもサブメトリクスとしてモニタするのだ。
同様にソフトウェア開発におけるメトリクスも、サブメトリクスで補強することで、それが自己目的化のセンサーとなる。例えば、「変更のリードタイム」の短縮に力を注いでスピードを追い求めたばかりに、本番でのシステムトラブルが増えるのは問題だ。それを検知するために、「変更失敗率」をサブメトリクスとするのも良いだろう。
それでも自己目的化のリスクが高い場合は、それを回避するために、目標や基準を作らないことも1つの選択肢となる。自己目的化とは、メトリクスを向上させようとする意識が強くなり過ぎた状態だ。チームの思考を「どうやってメトリクスを向上するか」ではなく、「何がメトリクスを悪化させているか」に置き、その障害を取り除くことに注力すべきだろう。
最後に
私が知る限り、ビジネスリーダーたちにのし掛かるプレッシャーはいつだって大きい。短期、あるいは中長期で達成しなければならないKGIに全力を注いでいる。ビジネスやユーザーの価値を計測するそれらのメトリクスは、思い通りに動いてはくれないから、限られた経営資源を使い、考えつく限りの施策を打つ。そうやって、小さな成果を一つひとつ積み重ねながら、実績値を目標に近づけていく。
それゆえに、彼らには余裕がない。ソフトウェア開発上の関心事の話など、開発者らの子供じみた言い分にしか聞こえない。そんなことに、貴重な経営資源を費やすわけにはいかない。
そこに割って入るためには、私たちも彼ら同様に真剣であることを示すしかない。ともに担うミッションの遂行と目標の達成のために、ソフトウェア開発上の関心事に取り組む重要性を説くのだ。その継続が、互いの信頼関係を築き上げていき、分断した組織は、やがて1つに統合されるのだろう。
