見出し画像

Findy主催イベント「コード品質が及ぼすビジネスへの影響」に登壇しました&質問回答

Yoshiki Iida

4/4に以下のイベントで登壇させていただきました。

資料はこちらです。

ログラス内では、創業時から設計やテストについて意識的に取り組んできており、今回のテーマもまさにお話しできるポイントが多いテーマだと感じておりました。

これまでの発信では実際の取り組みについての発信が多かったため、今回は実際にその取り組みが根底にある開発チームのアウトプットがビジネスサイドからどう見えているのか？という点にフォーカスしました。

コード品質や開発生産性が高いと言っているがビジネス価値につながっていなければその前にもっとやることがあるだろう、という意見もあると思っており、この観点は参加者の関心も高いのではないかと考えました。

事前にいいかんじにネタバレしてもらったこともあり、ここでも参加者が増えていたのでありがたい限りです。

詳しい内容については資料のほうを見ていただければと思いますが、実際にビジネスサイドからみてきちんと価値を出している開発組織になっているか？は今回の取り組みを通して定点観測していけると健全だなと感じました。

定量的にはアニバーサリーページで出しているような数値や、今後の事業成長、調達などで評価いただくことになると思いますが、事業の感度が高い開発組織であり続けたいと考えています。

アウトカムまでの接続を追いたい

質問への回答

以下は回答しきれなかった質問へ回答します。

Q.技術的負債の解消と新機能の開発だと、ビジネス的には新機能の開発が優先されがちですが、技術的負債の解消を組織的に継続するための仕組みがあれば聞きたいです

A.組織的に継続する仕組みについてはチーム横断で負債を認識し優先順位をつけていくという話は資料でも記載しているところですが、さらにいうとその活動を支えるマネジメント層の協力者はいたほうがやりやすいかと思います。また、プロダクトロードマップに技術観点の開発項目を差し込んでいくような動きも必要かと思います。（とくにフレームワークのバージョンアップのような大きな対応は関係者が認識した上で進めないと難しいかと思います）

Q.「コード品質や付随する課題を経営層やビジネスサイドにどう説明している？」まさにこれです。難しいのは、私はPMではなく一介のエンジニアであるため意志決定層にはタッチできないということ。PMは内部品質の重要さを理解しており、エンジニアとしてPMをどのように支援すべきかと考えています。実は意志決定層に対して一度は説得に成功し取り組んだのですが、リファクタリングのやり方が非常にまずく、かえって信用を損ないました。それでも前に進むべきですが、なかなか難しいと感じています。

A.内部品質の重要性を理解しているPMの存在はとても良いと思います。リファクタリングの進め方の良くなかった点についてまずは振り返りを行い、その問題が改善できるのか？を示すところから着手するとよいかと思いました。失敗したのでリファクタリングをやらないという選択になると、元々の課題は解決しないということになると思いますので、関係者が課題を認識していて解決の意思があれば、解決策をアップデートする提案をしていくのがよいかと思います。
社内にケイパビリティがなければ、リファクタリングに慣れている業務委託など社外の力を借りることも選択肢かと思います。

Q.顧客課題の解決へのコミットの部分で、顧客課題解決の責務がエンジニアだけではない場合に「howは自由に」 とはなりにくいと思うのですが、その場合はhowを任せてもらうためにはどのようなアプローチが考えらるのでしょうか・・・？

A.別の質問回答で少し触れましたが、ステークホルダーとの信頼関係の度合いによってどこまで細かく求めてくるか？が変わると思います。極論期日までに要件通りの実装ができる人だと認められるだけでも良いとは思います。
別のパターンとしては信頼はされているがステークホルダーが悪気なく細かい要件まで決めすぎてしまうケースがあると思います。こちらは「課題を教えてほしい、解決策は考えさせて欲しい」という交渉をするしかないかと思います。

Q.負債の解消にメリットがあれば許容できるということですが、ビジネスサイドが理解するまでどこまで説明すべきなのか、労力をかけないといけないのかと辛い部分がある。ビジネスサイドというより、組織の決済権を持った方が勉強するのを期待してはいけないのか？

A.内部の技術的なことを全て理解する必要はなく、ビジネスインパクトに変換し説明ができれば十分かと思います。
例えば、ある機能のコード品質が悪いことによって手戻りの発生率や不具合の発生率がどれくらいになっている、それによりリリースやユーザー満足度に影響がでている、これを低下させるためにはリファクタリングやテストを書いていくしかない、というイメージです。
ユーザーやビジネスに関する直接的な指標での説明があれば改善の必要性としては十分な根拠となるかと思います。

Q.顧客がお金を払い、契約があるわけだと思うのですが、そういう顧客からの数値的な説明のプレッシャーと、先ほどの数値的なものを曖昧にするという流れと、どう両立していっていますか？

A.登壇および質疑の中でお話しした観点としてはコード品質や開発生産性に関する指標は約束しない方がいいという話でした。上の質問回答とも重複しますが、ユーザーやビジネスに関する直接的な指標はしっかり説明責任を果たす必要があるかと思います。
契約が絡むもので言えば、受託開発においては納期や不具合に対する契約不適合責任などがあげられますし、SaaSビジネスではSLAなどが該当するかと思います。
一方で例えばテストカバレッジを100%にすれば不具合がゼロになるか？というとそうではないため、そういった内部的な指標を約束に使うことは避けた方がよいかと考えます。

さらに詳しく聞きたい人はオンラインで話しましょう！

もし、より細かい話がしたいという方がいましたらオンラインでの面談も可能ですので上記より登録いただければと思います。

ご参加いただいた方、ありがとうございました！

この記事が気に入ったらサポートをしてみませんか？