見出し画像

#QiitaNight LT登壇『類推化と定量化でつなぐ、エンジニアと非エンジニアによる開発指標を用いたコミュニケーション』 の内容まとめ

ゆーだい

この記事は、2023.11.17(金)に開催された『Qiita Night～エンジニア×非エンジニアのコミュニケーション』で発表したLTの内容をまとめた記事になります。


自己紹介

2022年1月にFindyに入社。エンジニア組織の開発生産性可視化・向上SaaS『Findy Team+』のセールス担当後、現在は事業イネーブルメント室で複数事業横断で成長させるために何でもやるマン。今回は、エンジニア組織の生産性可視化サービスを通してエンジニアに向き合う中で考えていることベースに発表しました（整理が粗い部分があると思いますが、ご了承くださいmm）。

なぜ、エンジニアと非エンジニアのコミュニケーションが”むずかしい”のか？

前提として、エンジニアと非エンジニアが担う事業活動における業務範囲がちがう

IT・通信業の基本的な事業活動は、簡素化すると、創る→つくる→売るのなかで、各ファンクションが価値を生み出し、最終顧客に価値提供するバリューチェーンに沿った活動になります。
プロダクト企画がマーケットニーズをアイデアとして落とし込み→エンジニアが動くソフトウェアを開発・実装し→マーケ・セールス・CSなどがサービスを市場・顧客へ投入するプロセスを辿ります。

このプロセスはIT通信業だけでなく、製造業も同様です。

製品企画が構想を練り、製造が実態としてのモノをつくり、その後市場に売り出されていきます。

そのなかで製造業の例で、両端の「創る」・「売る」のプロセスももちろん複雑ですが、真ん中の実態としてのモノを「作る」をはかなり複雑です。
右はトヨタの製造工場の写真です。自動車をつくっているのはわかりますが、どんな部品がどう結びついて自動車になっているのか、製造プロセスがどうなっているのか、外部からみてもなかなかわかりません。
ただぱっとみただけでも自動車内部の構造やそのプロセスはかなり複雑で、細かい修正に多くの思考と時間を使いそう、というのがわかります。

これはソフトウェア開発でも同様のことがあると思っています。
非エンジニアがエンジニアがどういう技術用語でどういう開発ツールでどういうプロセスで開発しているのか、またソフトウェア内部の複雑性を把握しているケースはなかなか少なそうです。

では、エンジニアと非エンジニアでは何がちがうのか？

ここでは事業活動における業務範囲がちがうことで、エンジニアと非エンジニアのコミュニケーション上のむずかしさを引き起こす要素を2つ紹介します（他にもあると思いますが、今回は2つ）
「扱っている言語（言葉）がちがう」「感覚がちがう」の2つです。

扱っている言語（言葉）がちがう

引用：『完全文系の非エンジニアが 開発のことを知るために辿った葛藤と解決策をシェアしてみる。 』

PCとサーバー、背景にOSやデータベースがあり、GitHubで開発、そして中身の細かい技術などについて、非エンジニアは通常業務で扱うシーンはないので、ほとんどのケースで「なんもわからん」が発生します。

感覚がちがう

引用『２つのDXと技術的負債-YAPC Tokyo 2019』

感覚の違いは、非エンジニアは外部の見え方（表面的なシステムの振る舞い）しか知り得ないのに対して、エンジニアは外部の見え方に加えて、内部品質（内部の複雑性）まで見通しますを考慮する。
（製造業の例で自動車内部の構造やそのプロセスはかなり複雑だが、外部からはなかなかその複雑性の詳細を計り知れないのと同様のことがあると思いいます）
そのためよくあるケースが、非エンジニア視点で簡単そうな変更でも、エンジニアは内部を考慮する時間がかかるので、「簡単な変更にどうしてそんなに時間がかかるんだ！」というコミュニケーションが発生したりします。

ここでもう一つ、エンジニアと非エンジニアのコミュニケーションで発生する問題を取り上げます。「技術的負債の解消問題」です。

コミュニケーションのむずかしさ：技術的負債の解消

技術的負債の解消問題
顧客要望に直接関係のない技術的負債の解消って「今やる必要ある？」と非エンジニアに伝わらづらい

非エンジニアは売上（PL）に直接的に結びつく機能を早く正確にでてくることを求めています。一方で、非エンジニアはソフトウェア資産（BS）をつくり、それを通して売上（PL）に間接的に貢献しようと考えています。
非エンジニアは顧客要望に直接的に結びつく取り組みにフォーカスする、かつソフトウェア内部の品質のことは計り知れないため、「技術的負債の解消」というエンジニアの取り組みがよくわからない、といったケースはおおいのではないでしょうか？

ただし、前提として、エンジニアも非エンジニアも、「顧客価値提供を通して事業貢献したい！」と目指しているゴールや理想は同じだと思います（以降、非エンジニアを営業職種を例に話します）。

例えば、具体的には営業もエンジニアも以下のように考えている思いは同じなはずです。営業が受注リードタイムを短縮して事業へ貢献するのと同様に、エンジニアも開発リードタイムを短縮して素早く顧客要望に応え事業に貢献したいのは変わらないかと思ってます。

しかしながら、以下の要因で、結局のところ顧客要望に直接関係のない技術的負債の解消って「今やる必要ある？」と非エンジニアに伝わらづらくなっていると考えています。

技術的負債の解消問題の要因
開発リードタイムを測ってない and 開発プロセスで出てくる言葉を営業がわからない とコミュニケーションが取れない

”むずかしさ”と向き合うためにはどうすればよいか？

このエンジニアと非エンジニアのむずかしさに向き合うためのアプローチとして、今回は2つ紹介します。「類推化」と「定量化」です。

先程の「技術的負債の解消問題」で言うと、開発リードタイムを測る（感覚のちがいに抗う定量化） and 開発プロセスで出てくる言葉を営業がわかる （言語のちがいに抗う類推化） とコミュニケーションが取れる、の状態にしていくためのアプローチとも言えます。

類推化によるコミュニケーション

創る→作る→売るのバリューチェーンに沿った事業活動の各ファンクションにもプロセスがあります。
ソフトウェア開発では、コードコミット・PR（プルリク）→レビュー・修正→マージ・デプロイというプロセスを経て、動くソフトウェアを「作り」ます。
セールスでは、提案書作成→顧客への提案→受注というプロセスを経て、サービスを「売り」ます。

それぞれのファンクションの活動は違えど、共通項を探すと、少しは他業務を理解できるのでは？と考えるのが類推化のアプローチです。

バリューチェーンがインプットに対してアウトプットを最大化することで、価値を生み出し、チェーンのように価値が連鎖する活動だとすると、
それぞれのファンクションにおいても、そのプロセスを抽象化すると、インプット→スループット→アウトプットのサイクルが周り、後工程のプロセスにアウトプットが引き渡され、結果として最終顧客に価値のついたアウトプットとして届けられる、と考えられます。

つまり、各ファンクション（プロダクト企画/ソフトウェア開発/セールス）の業務プロセスは、抽象化すると、インプット→スループット→アウトプットとほとんど流れは変わらないと言えます。

このように抽象化したプロセスを、他業務に類推化することで、例えばエンジニアが言うところのPRを作成するプロセスとは、セールスで言うところの提案書を作成プロセスと同じなんだな！が感覚的にわかるようになります。まだまだ感覚的にわかる程度ですが、まずは構造を理解することが大事だと思ってます。構造とは業務がどういうプロセスで進むのか、またそのプロセスとプロセスの中で使われる用語を理解することです。（ソフトウェア開発プロセスでいうと「PR（プルリク）」や「マージ」などの用語がどういうことを指すのかを最低限インプットする必要があります）

では、次に感覚に対してデータ・数値を通した定量化で抗います。

定量化によるコミュニケーション

インプット→スループット→アウトプットの各プロセスにおいて、アウトプットがでるまでのリードタイムやアウトプットの量・質（アウトカム）を測るとよさそうです。
質はアウトプットが後工程にどれくらい不具合を生じさせないか、である、最終的には顧客が定性的に判断する性質をもつので、今回はリードタイムと量にフォーカスして、定量化によるアプローチを考えます。

Findy Team+の画面：コーディングプロセスの定量化・可視化

左端の平均プルリククローズ時間（リードタイム）はソフトウェア開発のコーディングプロセスの全体のリードタイムを指し示すため、営業プロセスの受注リードタイムと類推化による置き換えができます。
アウトプットの量はソフトウェア開発ではPR数であり、営業では提案書作成量（≒提案の量）と見立てることができます。

このようにソフトウェア開発のプロセスを定量化していることで、営業で言うところの顧客への提案数や受注までのリードタイムがどうなっているかが感覚ではなく、定量でわかるようになります。

ここで、改めて、技術的負債問題を考えます。

類推化と定量化でつなぐ、エンジニア・非エンジニアのコミュニケーション

技術的負債の解消問題
顧客要望に直接関係のない技術的負債の解消って「今やる必要ある？」と非エンジニアに伝わらづらい
↓
技術的負債の解消問題の要因
開発リードタイムを測ってない and 開発プロセスで出てくる言葉を営業がわからない とコミュニケーションが取れない

まずは開発プロセスを定量化し、営業に類推化してみます。以下はFindy Team+のフロントエンドチームの数値です。

2023年1月に技術的負債の解消（リファクタリング）を実施したあと、リードタイムは短縮、PR数は伸びていることから、営業でいうと、組織として受注リードタイムは短縮、提案数は増加していると言えます。

また、一人あたりでみても提案数は増加していると言えます。

開発リードタイムや量を定量化 and 開発プロセスで出てくる言葉を営業が類推化を通して理解すると、「技術的負債の解消」は間接的にクライアントの価値提供につながるものなのか！と非エンジニアが理解できるようになる

類推化と定量化による開発指標を用いたコミュニケーションで「技術的負債の解消問題」が一定解決したと言えるのではないでしょうか？

まとめ


エンジニアと非エンジニアは互いの歩み寄りが必要。
歩み寄りのアプローチの方法として類推化と定量化が大事。
具体的には、非エンジニアは類推化しエンジニアを理解し、エンジニアは定量化によって非エンジニアに伝える歩み寄りのコミュニケーションを！

以下YouTubeにアーカイブの動画もアップされておりますので、動画を観たい方はぜひこちらご覧ください！
Qiita Night～エンジニア×非エンジニアのコミュニケーション～ https://youtu.be/UiXQ5VECi9w?si=KqxHusdnmJ-_aG2S

感想もありがとうございます！

以上、いかがでしたでしょうか？
最後まで読んでいただきありがとうございました。
今回リードタイムやアウトプット量として、PR数や平均プルリククローズ時間などを取り上げましたが、そのほかどのような指標を可視化しているのか？や指標改善の取り組みを各社に語ってもらうイベントをやりますので、ご興味あればご参加ください！

11/28 開催！開発生産性の未来：世界と日本の最前線事例から培うFour Keys向上〜ハイブリッドカンファレンス〜

（参考）


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