NEW
誰も全体を知らない ～ ロールの垣根を超えて引き上げる開発生産性
2024年11月15日、ファインディ株式会社が主催するイベント「開発生産性Kaigi スタートアップが目指す、開発と事業成長の接続〜価値創造への挑戦〜」が開催されました。
本記事では、株式会社カケハシで開発ディレクターを務める笹尾 納勇仁さんによるセッション「誰も全体を知らない ～ ロールの垣根を超えて引き上げる開発生産性」の内容をお届けします。
■登壇者プロフィール
笹尾 納勇仁 株式会社カケハシ 開発ディレクター
「沢山の埋もれた力を最大限に発揮できるようになれば、多くの人がもっと楽に成果を上げられる。」「チームが自律的に行動し無意識に成長できれば、最高のプロダクトやサービスを生み出せる。」の実現を常に目指すエンジニアリングマネージャー。 スタートアップのVPoEとして組織システム構築の再現性を上げたのちに、これまでの経験を大きな社会貢献に繋げるためにカケハシに参画。 エンジニア兼マネージャーとして大手自動車会社のテレマティクス分野におけるWebアプリケーション開発や、開発・運用フレームワークの開発、アプリケーション配信プラットフォームの開発などに携わっていた。その後、カケハシでエンジニアリングマネージャーを担当し現在は開発ディレクターを務めている。
目次
エンジニアの日々の活動を事業側に理解してもらう
笹尾：こんにちは、笹尾です。「誰も全体を知らない ～ ロールの垣根を超えて引き上げる開発生産性」というタイトルで発表させていただきます。僕は多くの人がもっと楽に成果を上げられる方法を探しながら、たくさんの埋もれた才能が最大限に発揮され、最高のプロダクトやサービスを生み出せる環境を目指して組織づくりをしています。
僕が所属しているカケハシは、「日本の医療体験を、しなやかに」をミッションとして事業を進めています。バリューには、高潔、価値貢献、カタチにする、無知の知、変幻自在、情報対称性の6つを掲げ、メンバー自らが体現できるチームを目指しています。そんなカケハシのなかで、僕たちのチームは「Musubi AI在庫管理」という調剤薬局で取り扱う医薬品の在庫を管理するプロダクトを開発しています。
笹尾：さて、皆さんに質問です。エンジニアの日々の活動を、事業側に広く理解してもらいたいと感じていませんか？ 他のロールの方に、自分の業務のことをもっと理解してほしいと感じていませんか？
これは2023年9月、僕たち「Musubi AI在庫管理」開発チームが、エンタープライズセグメントへの導入を必死に模索するなか、プロダクトもチームも拡大していたころのことです。
大量の機能要望がリストアップされ続けているのに、一つひとつの規模が大きく見積もりすらできない。既存の仕組みでは実現できそうになく、実現方法の検討を進めなければならない。スケジュールの見通しは立たなくなっていて、エンジニアを増員するものの、目に見えて開発スピードが上がるわけではなく、現状維持でいっぱいいっぱい。一方で、一部のエンジニアは大規模なリファクタリングにチャレンジしているという状況でした。
そうしたなか、ある会議でカスタマーサポート(以下、CS)のメンバーが勇気を持って発言してくれたんです。「開発メンバーが、お客様のことをどこまで考えているのかわからなくなりました」と。僕はハッとしました。はたして僕たちは、事業やサービス、プロダクト、そして開発を理解しているのだろうか。そう思って、すぐにエンジニアを集めて、CSメンバーと会話する機会をつくりました。その名も、CSとエンジニアの温度感を合わせる会です。
笹尾：このとき、エンジニアから伝えたのは、僕たちがお客様のことを知りたがっているということ。それ以外は、CSの方が抱えている課題や不安、そして開発がどう見えているのかを丁寧に説明してもらう時間となりました。少なくとも、お客様第一であることの認識はできたと思いますが、そもそもの不安を生んだのは、開発プロセスだけに偏った関係性、コミュニケーションの歪みだったんです。
それまでエンジニアの多くは、PdM(プロダクトマネージャー)とだけ会話して開発を進めていました。だから、その後もお互いの「わかってもらえない」が起こらないように、しっかり目的を明示したうえで、CSとエンジニアの温度感を合わせる会を継続することにしました。
笹尾：この会で意識したのは、とにかく相手を知り、相手の仕事に興味を持つこと。困りごとやその背景を知ること。ただし、その場で要望を伝えて解決方法を即決しないこと。悩みを吐き出して、自分たちから小さな振る舞いを変えることで、少しずつ問題を解消すること。これらをこの会における目的として、最初に毎回確認したうえで進めていました。
この会は、スプリントレビューの場でCSメンバーとの連携が深まるまで、ずっと継続していました。結果として、スプリントレビューで前向きな意見や提案、感想をもらえることにつながったと感じています。さらにこの会を通して、エンジニアの活動をしっかりと伝える必要性に気づき、次の活動にもつながりました。
非エンジニアメンバーにわかりやすく継続的に伝えていく
笹尾：今からお伝えするのは、その活動の初回にエンジニアのメンバーが実際に行った、システム拡大に伴うリアーキテクチャの説明についてです。エンジニア以外のメンバーに理解してもらいやすいように、専門用語を使わず、日常で想像しやすいものに置き換えた説明が行われました。
システム自体を本棚に見立て、内部の状態はその中に収める本に見立てて説明しています。システムの立ち上げフェーズは、とにかく仮説検証することが大切で、堅牢なシステムは必要なく、機能も多くないんですね。軽くて安くて気軽に使える本棚があれば、本は綺麗に整理することができます。
笹尾：仮説検証が上手くいって、スモールビジネス市場への導入が始まっていくと、高い事業目標を見据えて、機能開発がどんどん盛んになります。本は本棚に収まらないこともありますが、システムの堅牢性はまだ要求されていないので、急いで今までと同じ本棚を用意して、ちょっと不便なことがあってもこれで十分かなという形で進めます。
ところが、エンタープライズへの導入となると話は変わります。お客様と約束したスケジュールに合わせて機能開発を進めますが、今までとは異なる要求が多々あります。これまでに見たことがない、サイズも形も大きく異なる本が一気に増え始めます。
笹尾：同時に、システムの堅牢性も求められます。今までの安くて軽い本棚の組み合わせでは、重みに耐えられないかもしれない。今のまま進んでしまったら、自分が本棚を壊してしまうかもしれないと、怖くて誰も触りたくない状態になります。本が収まらなくても、本棚が歪んでも、ただ崩れないようにするだけになってしまったら、そんなシステムは健全とは言えませんよね。
笹尾：それを防ぐためにはシステムを維持したまま、新たなシステム要件に合わせた形にする必要がある。今ある本棚とは別に、この先の事業成長に必要な、堅牢で拡張性に富んだ本棚を用意して、本を移動しなければならない。自分たちのシステムが市場に受け入れられたからこそ発生する、作業や課題があることを説明したんです。
笹尾：エンジニア用語を使わない比喩やメタファーの説明では、どれくらい伝わるか未知数ですが、この説明をした際、サポートデスクの方からは「理解しやすくて、エンジニアの大変さがわかった」と感想をいただきました。
ただ、このような説明をする際に気をつける点があります。それは、当たり前にならない伝え方をすること。例えば、日常のコーディングでリファクタリングをするのは当然ですね。コードを書いたら見直し、新たな機能を入れる前にリファクタリングから始める。この日常のリファクタリングを、業務終了時の机の片付けと一緒だと伝えることもできるでしょう。
ですが、そのとき置かれたフェーズによる問題を説明したいのであれば、この伝え方は適切ではありません。机の片付けでは、「当たり前のことができていないなら、エンジニアだけでやれば」と思われかねないからです。伝える内容はそのときに合わせて選び、今なぜこの内容を伝えるのかを工夫することが大切です。
そして、説明は継続する必要があります。人は受け取れるときに、受け取れる方法で、段階を経て情報を受け取ります。つまり、継続していくなかで、一方向の説明にならないように方法を変えながら、それぞれのタイミングで受け取ってもらいつつ、何回かの説明で徐々に理解を深めてもらう必要がある。組織としては、人の入れ替わりに配慮する必要もあります。
開発チームの内部でも起こるコミュニケーションの課題
笹尾：ここまで、開発チーム以外とのコミュニケーションの話をしてきましたが、似たような問題は開発チームの内部でも起こります。「Musubi AI在庫管理」の開発チームが、以前の分業化した体制で活動していたころ、見つけた課題に対して僕がいろいろな方と会話していたなかで、面白いことに気づきました。
フロントエンドのメンバーは「UIの状態管理が複雑で改修が難しい」と言っていて、バックエンドのメンバーは「APIの仕様が複雑で改修が難しい」と言っていて、デザイナーは「UIがわかりづらいから直したい」と言っていたんですね。僕は最初、それぞれ別の課題だと思って聞いていたのですが、実は全部同じ機能の同じ課題を指していたんです。
これは“群盲象を評す”状態で、視点が偏ると一部に固執してしまって、全体で見れば同じものだということに気づけない。こんな状態でプロダクトを良くすることは難しいですよね。
笹尾：そんなときは、やはり「集合！」です。そうして、フロントエンド、バックエンド、デザイナーの苦しみを共有する会が始まりました。この会でも、目的をしっかりと定義しています。苦しくても隠してきたこと、みんな知っていると思って放置してきたことを共有して、手助けしながら嫌なことを高速でなくすために協力する場です。
自分と同じ悩みを他の人も持っているかもしれないから、話してみる。ここではとにかく一緒にやれば解決できるかも、という感覚を大切にするために、ルールを設定しました。正論での争いを避けて、自分たちの成長と達成感のために、一旦ロールも無視してスキルや知識を投入する。この短い時間だけですべてを進めることはできないけれど、支援のきっかけをつくっていく。
ここで共有した課題のうち、その場で解決に向かえたのはほんの一部です。ただ、この流れによって、ロールごとのチームから、クロスファンクショナルなストリームアラインドチームに変化するなかで、メンバーの協力を得やすくなったと思います。
ロールの垣根を越えて、より高い価値を出し続けるために
笹尾：コミュニケーションが得意な人は、さっさと相手に合わせてコミュニケーションすれば済むと思うかもしれません。でも、僕みたいに人間関係やコミュニケーションが苦手な人は、そうもいかないんですね。
特にズレが大きくなると、会話自体が成り立たないことも多々あります。特にロールをまたいだ状態でズレると、成果にはつながりにくい。人は自分が想像できる成果には、より情熱やコストをかけることができますが、認識の差がある状態で成果を出すのは、他のコストがかかってしまうのでつらくなるんですね。
だから、ズレがあるときは焦らない。決め事がなくても、成果がなくてもいいところから始めて、相手が大切にしているもの、守ろうとしているものを感じてみたり、苦しみも知ったりしながら、前進したい意思を感じられるようにする。そうやって会話していると、共通の認識やメタファーが生まれるようになり、そこで初めて今まで想像できなかった成果を想像できるようになります。
笹尾：だからこそ、時として求められないコミュニケーションにもチャレンジする必要があります。例えば、機能開発が山積みの状態でも、技術負債の解消やリアーキテクチャの会話を積極的にPdMとして、優先順位に組み込めないか確認していく。それがもし20％ルールでエンジニアの工数が確保されていたり、別に保守チームをつくればできたりすることだとしても、必要なことは伝えていくんですね。
技術負債が溜まって内部品質が低下して、徐々に希望のデリバリーを守ることが難しくなるとか、重大なインシデントが増えてしまうとか、PdMの成果に影響することに関しては積極的に伝えていく。
もちろん上手く説明するのが難しいことも多々あります。それでも、サービス全体の価値向上に全員で取り組むためには、エンジニアもPdMの抱えるプレッシャーなど、背景にある情報を知る必要があります。そのきっかけとしても、必要なことを伝えるというのが大事なんですね。
エンジニアの日々の活動を事業側に広く理解してもらいたいということよりも、今見えているものは氷山の一角だと捉えて、エンジニアだけでは見えないものを見えるようにする。その結果、ロールの垣根を越えた成果を生み出せるようになります。
笹尾：カケハシが掲げるバリューの1つに、「無知の知」があります。自分が知らないという事実を知るのは、とても難しいことなんですね。だから、自分たちの知らないこと、見えないことが、勝手に知れるようになったり、見えるようになったりしないと僕は考えています。
今まで知れなかったことを知るために、自ら会話して、相手に興味を持って、疑問を持って、知る機会を得る。自ら説明して、相手の理解を図り、理解可能な条件を探していく。そうやって何度も何度も試しながら知らないことを知り続けて、見えなかったものを見続けると、全体が浮かび上がって、解像度も徐々に上がっていきます。
何かを改善したいなら、課題を分解して捉える必要があるんですね。そして、課題を分解するには、その課題の全体像を捉える必要がある。改善の施策を実行するためには、解像度を上げる必要もあります。だから、知らないことを知れば知るほど、課題の解決がしやすくなります。
いろいろなコミュニケーションを通して、部分をつなぎ合わせ、全体を浮かび上がらせる。そうすると、ステークホルダーとのコミュニケーションでも、ロールに関係なくチームの課題感をそろえて会話できたり、事業を通した優先順位をつけながら、事業の拡大とプロダクトの持続性の両方を進めることができます。
ロールの違いが妥協を生むのではなく、ロールの違いを礎にして、新しい価値が生まれるようにする。そんなチームになるために、もし全体が見えないのなら、自分たちで垣根を越えていけばいい。何回もあがいて進めばいい。
笹尾：これからも僕たち「Musubi AI在庫管理」開発チームは、メンバーで一丸となって、プロダクト、サービス、事業やロールの垣根を越えて、より高い価値を出し続けていきたいと考えています。
