会の概要
以下、イベントページから引用です。
昨今、プロダクトの品質がビジネスに与える大きなインパクトについて語られる場面が多くなっています。一方で、「コード品質」についての問題やそれに関する議論はエンジニアの中で留まってしまい、経営者やビジネスマネージャーに認識される機会は少ないという話も見受けられます。
本イベントではコード品質がビジネスに与える影響を紐解いた上で、ご登壇者の所属企業では実際どのようなコード品質向上のための取り組みを行っているのか、またそれらを経営陣やビジネスサイドとどうコミュニケーションを取れば良いのかを考えられる場を目指します。
会の様子
ビジネスとエンジニアリングの接合点、そしてコード品質がそこに及ぼす影響（v1.1）
最初に松本さんから講演がありました。
プロジェクトのスタート
プロジェクトは、ビジネス担当者からエンジニアに対して相談が行き、その内容を理解したエンジニアが見積や計画を通してビジネス担当者と調整するものだという話がありました。
こう考えると、見積や計画はビジネス担当者とエンジニアの調整結果とも言えそうだということでした。
プロジェクトの評価基準
CHAOS REPORT 2015の基準を使うと、プロジェクト成功の評価基準は、予算通り/スケジュール通りなだけではなく、顧客に価値提供ができているかも含まれているという話がありました。
予算通り/スケジュール通りにするためには、正しい計画を立てることが重要なわけではなく、途中で起こる様々な困難をモニタリング&コントロールする必要があり、価値提供するためには実験による検証(仮説→実験→検査→適応、のサイクルを回す)を素早く回してEBMで言うT2Mを短縮することが必要だということです。
コード品質がビジネスに与える影響
コード品質が低いと、見積もりが難しく欠陥が多く開発時間が長くなるため、誤ったプロジェクトプランニング、不適切なプロジェクトコントロール、長いT2Mに繋がってしまうということでした。
この結果、エンジニアは見積を長く出すようになり、欠陥があることを想定してもっと大きなバッファを取るようになりT2Mがどんどん悪化していくため、ビジネス担当者はエンジニアに対して不信感を抱くようになり、信頼関係が崩れてしまうということです。
改善が上手く進まない例
以下のようなすれ違いが起こってしまうという話がありました。
- 改善提案したつもり VS 愚痴を言っているように聞こえる
- 技術視点に特化した話をする VS 技術課題の解決には興味があまりない(ビジネス課題を解決したい)
- 情報の非対称性 VS さっぱりわからない
- 計画化していない VS 意思決定できない
- 信頼関係がない VS 本当にできるのか？
これらは、コード品質が「目的」として捉えられてしまっており、状況を「説明」するものでしかない点に対する考慮が足りていないことが原因であるということで、現状とありたい状態を示したうえで解決策を話すようにすることが重要ではないか？ということでした。
ログラスにおけるコード品質でビジネスに貢献する仕組み・カルチャー
次に飯田さんからの講演がありました。
コード品質に対する考え方
コード品質を考える際は、保守性*1をもとに考えることができ、これに加えてログラスではLTV FirstのValueを掲げることで長く走り続けることができるシステムづくりを目指しているということでした。
また、ログラスでは品質=コード品質とは捉えておらず、QAが文化を作りながら組織全体で品質とは何かを考えるにようにしているそうです
コード品質を維持・向上させるための仕組み
まず、設計標準を作っているということでした。
設計標準は「完全にこれにしたがってください」というものではなく定期的にアップデートをしているそうで、創業時のコードの考え方から進化した考え方が組織の中で生まれ続けているということです。
次に、技術的課題解決スクワッドを形成しているということでした。
特定の個人が品質をリードすることもできますが、それではスケールしないため、チーム横断で技術課題に立ち向かうチームを作っているということでした。
最後に、コードの外観をとらえているということでした。
組織全体での仕組みというよりは飯田さんの趣味に近いところもあるということですが笑、コードの総量と単一責任原則違反指数を集計し、負債の蓄積具合にまつわる状態を可視化するようにしているということでした。
アウトカムとの接続
「リファクタリングによってXX%開発速度を向上させます」といった提案をしたくなる場面がありますが、同じコードでも誰が実装するかで速度は変わるし、開発速度に寄与する変数は他にも数多くあるため、定量的な説明は難しいと考えているそうです。
そこで、お客さんの課題を解決することに対してコミットメントをし、その上で生じる不確実性に関しては開発とビジネスの相互理解によって対応をしているということでした。
ビジネスサイドの声
ここまで説明したようにログラスの開発組織ではコード品質向上のために動いているそうですが、実際にビジネスサイドのメンバーにアンケートを取ってみたということでした。アンケートでは、
- 事業目標に良い影響を与えていると感じている人が60％ほどいる
- ビジネスサイドも技術的負債に関しては意図しているものと意図していないものがあることを知っている
- 入社前から、エンジニアバックグラウンドではない代表から技術的負債にまつわる話があったので把握している
- 機能クローズにもメリットがあることを理解している
といった意見があり、
- プロダクトの貢献度が全体 > 個人となっていること
- 解像度にばらつきはあれど技術的負債やコード品質にまつわる解像度が高い方がいること
- ロジカルな説明があれば負債解消や品質向上への取り組みはポジティブに捉えられていること
が見受けられるということでした。
組織文化
エンジニアとしては、ビジネス目標を達成するために最適なコードを書くために保守性が高いコードを書き、ドメイン理解を深めているという話がありました。
また、ビジネスサイドとしては、(裏にあるテクノロジーを含め)プロダクトに対して関心を持って営業されているということです。
こういった文化は、CEOとCTOがマンションの一室でドメインモデリングを行っていた経験から脈々と受け継がれているものではないか？ということでした。
Q&A
講演の後はQ&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。
ToBe の値を求めるのは難しいと思うが、コツだったり考え方を教えてほしい
シンプルに話し合って決めたものを前に進めながら都度決めていくことが望ましい。なお、他プロジェクトや他チームと比較するのはやめたほうがいいと思う。
SRP単一責任原則のグラフはどうやって計測しているのか？ツールがあるのか？
なにかのブログ記事をもとにシェルで対応している。
ビジネスへの説得材料としてチーム内の生産指標を出すとそれをチームの評価として利用されはじめる懸念があるように思う。何を出すべきかなど具体例はあるか?
- 何を課題としているのかによるが、アクティビティ系の細かい指標を出すよりは抽象度の高い指標(バッファ率や予実)が良いと思われる
- 生産指標は基本出さない。指標を管理/評価の文脈で使われるとハックされてしまうため。不具合発生率などビジネスに影響するものは出す
今、生産性が低いと感じていて、コード品質が低いとも感じているが、この場合、どのようなアクションをすべきか？
- 具体的にどのあたりが低いと感じているのか？みたいな話をまず議論する。テスト容易性みたいな話なら責務分割などのアクションを取ることになると思うので、より具体の課題を打てるようにするために準備していくのが重要
- 文面を見る限りまだ一人が感じているように見えるので、周囲も同じ意見を持っているのか聞きながら仲間を集めていくのが次のアクションになると思う
解消されてきた技術負債はどのような種類の負債が多いなどの感覚はあるか？例えば、インターフェイス設計が使いにくい、データ構造が実態と一致しない、循環的複雑度が高いなど
観点としてこういう見方をしたことがないので回答が難しいが、普段は保守性(テスト容易性/変更容易性/理解容易性)のテスト容易性にフォーカスすることが多い
コード品質の定量的な計測方法を知りたい
- 色々ツールはあるが、ツールで見た数値をもとに細かいアクションを出すのは継続性がないと思うので、それよりも現場でコードを書いている人が課題に感じていることをバックログ化して対処していくことの方がROIが高いと思っている。外観を把握するくらいのものであれば良いと思う
- 欠陥の発生率や手戻り率、見積もり精度などを見る。リーン開発の現場にあるように定性的評価を組み合わせる
コード品質の基準は組織で一番経験ある人の基準が上限となる以外の方法はないのか？
- 社内だけで見ればそうだと思うが、品質に関する取り組みを社外でアウトプットしてフィードバックをもらうことは重要なのかな、と思う
- 世の中の標準を導入すればいいと思う。コード規約やTDD、ペアプロなど
技術的負債の返済が必要となった場合経営層にどのような情報を用いて提案するのか？
- 負債とまではいかないが、直接顧客価値に結びつかない開発(フレームワークのリプレイスなど)はした記憶がある。その際は、もし対応しないと起きること(採用が難しくなる、オンボーディングコストが高くなる...)を説明した。組織が大きくなると比例的にコストが高くなることを示すことが重要。また、どこまで細かいものを求められるのかは信頼関係によっても変わってくると思う
- 何かを話すときは、相手から問題や課題に対して共感を得ないといけない。そうすると相手の視点で話をする必要があるので、相手の関心を知ってその観点で話をするのが大切だと思う。また、上でも言っていたように信頼関係が必要。過去に失敗した場合は、なんで失敗したかをふりかえったうえでその失敗を起こさないような取り組みをセットで話すとよい
会全体を通した感想
コード品質というと具体的なメトリクスの話やその運用の話が中心になることが多いですが、ビジネス価値という視点での話がお二人共中心だったのが非常によかったです。
松本さんの話で世間一般で言われている部分で特に大切なことがまとめられ、そこから実践的な取り組みの話が飯田さんからされるという流れもお見事でした。
*1:副特性でいえばモジュール性、再利用性、解析性、修正性、試験性
