みなさんこんにちは。unerry CTO　伊藤です。

この記事では、2024年7月24日に開催された翔泳社さん主催の「Developers Summit 2024 Summer」での登壇セッションの発表内容を改めてご紹介できればと思います。ご来場いただいた方、その節はありがとうございました。

また、SNSでも想定以上にたくさんの方に共感いただいたようで、驚きました。

ご紹介いただいたスライドは以前の組織で見てきた怖い「あるある」について、涙を拭いながらまとめたものです。

繰り返す過ちのそのたび　ひとは　ただ青い空の青さを知る（独唱 伊藤）

そう、ひとは何度でも過ちを繰り返してしまう愚かな生き物ですが、崖っぷちに立たされたときにチームはどう立ち向かってきたのか…今回はそんなところがテーマのセッションでした。

特に組織を考える立場にあるエンジニアリーダーやマネージャーの方々とはぜひ語り合いたい内容です。

登壇セッションの概要

unerryとは？unerryエンジニアチームの特徴は？

ところで、unerryとは？という方も大半だと思いますので、最初に少しだけご紹介します。

unerry（ウネリー）は「心地よい未来を、データとつくる。」をミッションに掲げる2015年創業のデータエコシステムカンパニーであり、位置情報ビッグデータを活用した人流解析を行っている会社です。（自社調べではありますが）2022年、位置情報を主な生業とする企業としては世界初の上場を果たしました。

データ取得から自社開発のアルゴリズムによるAI解析、さらにダッシュボードでの可視化やサービス構築までを、ひと繋がりで提供しています。

つまるところ、エンジニア組織には幅広い技術スタックが求められます。Webエンジニア、iOS・アンドロイドエンジニア、データエンジニア、データサイエンティストなどなど、少数精鋭ながら様々な分野をカバーするメンバー構成となっています。

序章：エースの卒業

さて、本題です。

2023年、unerryのエースエンジニアが卒業しました。

彼はunerryにおける立ち上げ期のサービスリリースから関わり、多くのプロジェクトで新しい技術に取り組んできた人物です。私とは5年以上も二人三脚で仕事をしてきたので、卒業の話はショックでしたが、ご自身が「やりたいことをやるための独立」という前向きな一歩を、心から応援しています。

半年前ほど前から相談はあり、卒業までに時間的な猶予を設けてくれました。しかし、当然のことながら、彼の卒業が決まった時にはチーム全体に不安と焦りが広がりました。

フロントエンド、バックエンド、インフラ、バッチ、IoTなど、膨大な範囲のタスクの引き継ぎが必要だったからです。

第一章：危機の始まり 50を超える引き継ぎ項目

引き継ぎ項目は50以上。タスクは大小様々で、ソースコードを読んですぐわかるものと、商用化前のIoTサービスなど、仕様を把握するのに非常に時間がかかる、ブラックボックスになっているものが混在していました。

引き継ぐ側は入社1年未満のメンバーもおり、unerryではリモートワークがメインのため、全員ほぼ顔を合わせる機会がないままに高負荷作業に取り組むことになってしまいました。

引き継ぎ自体は2ヶ月ほどで完了したものの、気づけばチームの雰囲気が悪くなっていました。定例MTGでもメンバーの発言数は目に見えて減っていました。

「これは..やばい」

第二章：緊急対策『オフラインで話す会』&スウォーミングの実施

本格的な緊急対策が始まりました。こちらはテックリードとプロダクトマネージャーが中心になって進めてくれました。

まず開催したのはざっくばらんに『オフラインで話す会』です。ネーミングの通りですが、メンバー全員がオフィスに集合して課題・愚痴・改善案を出しあいました。

見ての通りホワイトボードに書ききれないほどの意見が出てきた

さて、せっかくレポート記事で登壇内容を振り返っているので、この施策をリードしてくれた元航空自衛官のプロダクトマネージャーにも過去の辛かったあの日あの時を一緒に振り返ってもらうことにしました。

株式会社unerry プロダクトマネージャー 浦野崇朗（うらのたかあき）

＜実施の背景は？＞
エースエンジニアからの引き継ぎが始まったのは、僕が入社して1ヶ月くらいの時でした。リモート勤務のため他のエンジニアと顔を合わせたことがなかった上に、IoTという難しい領域でしたので想像以上に負荷が高く、大変な状況でした。最初は「ベンチャーっぽいなぁ」くらいにしか思っていなかったのですが、徐々にことの深刻さに気づきました。

この状況を打破するには、困った時に聞きやすく相談しやすい環境を整えて「コミュニケーションの精神障壁をなくす」ことが必要。まずは顔を突き合わせてざっくばらんに話す機会を作ろうということで、「オフラインで話す会」の開催が急ピッチで進められました。

＜「オフラインで話す会」の雰囲気は？＞
思っていた以上にみんな本音で話していた印象です。和気藹々とした雰囲気でしたが、出てくる意見はどれもエンジニアの環境を良くする上で大事なことばかりでした。

（「ビールサーバーあったら嬉しい」って冗談のような話もありましたが、WeWorkに移転したことで実現されてしまったので、驚いています。）

＜工夫したことは？＞
私が工夫したのは、とにかく明るく、砕けて話すこと。話の第一声って集団の中だと難しいので、会議室に入る前からおしゃべりしながら入ったりして話しやすい空気作りは意識していました。

＜やってみて、どうでした？＞
メンバー同士がお互いを知る良い機会になったと思います。Slackでも気軽に相談できるようになりました。オンライン/オフラインともにMTGなどではコミュニケーション時の精神障壁は以前に比べると低くなったかなと思います。

コミュニケーションが取りやすい＝長期的に働ける環境の基礎だと思っています。長期的な目線でも「団結して乗り越えるチームを作る」ための第一歩ですね。

＜今だから言えること..！＞
当時は本当に皆さん（自分も含め）いろんな感情があったと思います…。

でもあの引き継ぎをみんなで完遂したことで、他のメンバーのことをよく知ることができ、コミュニケーションも取りやすくなりました。振り返ってみると、これはチームとして、いつかは乗り越えるべき壁だったのだと思います。結果的にはチームが成長するための良い経験（負荷）でした….繰り返したくはないけれど。

彼らのおかげでチームの雰囲気は改善しましたが、さらなる問題がありました。

新たなアップデートとなるリリースをする直前、引き継ぎ間もなくということもあり、メンバーが不安を感じているプロジェクトがあったのです。

これを解決するために実施したのがスウォーミングです。

スウォーミングとは、一つのタスクや開発トピックにチームの全員で取り組むことを指します。

「3人寄れば文殊の知恵」とも言いますが、ここでは5人のエンジニアと1人のPMが集まって、モブプロみたいな雰囲気でリリース作業や実装を行いました。

話し合いながら進めてみたら複雑なプロジェクトだと思っていたものも難なく解決していました。

イメージ：
Aさん「僕リリースします！」
　と言ったときに
Bさん「あ、何か変です…」
　と他のメンバーが異変に気づいてくれて
Cさん「これ、こうなってます」
　とさらに別のメンバーがソースコード調べて原因を特定してくれたり..

一人では気づけなかったバグや仕様に気づき、心理的安全性を担保しながら作業を行うことができたということですね。「仲間がいればなんとかなる」という「万能感」のようなものをリアルに体験できた機会となったようです。

またこのことにより、立ち上げ期からの積み重ねで俗人的となっていた部分も、チーム全体で改めて共有知になったことから、その後の追加開発なども組織的に対応しやすくなったりと、堅牢性や対応力の向上に繋がり、今思えば大きな転機であったと感じます。

並行してエンジニアメンタリングチームも発足しました。

経験豊富なメンターが若手をサポートし、日々の相談や入社時のオンボーディング時のトラブルを軽減するように努めました。またメンター同士でも情報共有を行い、横のつながりを強化。先ほどの『オフラインで話す会』で出た課題も、知恵を出し合い対応策を練りました。

第三章：新たなチームの誕生

緊急対策のおかげでタスクが落ち着き、雰囲気も以前のように明るくなってきましたが、さらにチーム一丸となるための施策を行いました。

①出社日 + ボードゲームをやる会を実施

定期的に顔を合わせるため、出社日を設けました。そこで

「ただ集まるだけではつまらない。出社日の夕方に、ボードゲーム会をやったらどうか？」

と提案ありボードゲーム会が始まりました。みんなでやりたいボードゲームを持ち寄って盛り上がっています。

この提案がボトムアップで、自然発生的に生まれるチームになったというのは「変わったな…」としみじみすることです。

②スキルシートでスキルを可視化

冒頭の会社紹介のところでチラリと触れましたが、unerryではビジネスモデル上求められる技術スタックの幅が広く、またエンジニアの人数が増えたこともあり把握が難しくなっていました。

そこで管理し、成長させていくために、個人のスキルスタックをスキルシートで可視化することにしました。

作り方としては、非常に単純です。1on1でヒヤリングしながらレベルをマッピングしていき、最後にコンセンサスをとっていきます。

作成したスキルシートを元に、メンタリングチームがメンバーの成長をサポートする体制が整いました。一定期間ごとにメンバーが目標をたて、メンターと共にチェックしています。

しかし、このような施策においてはエンジニア組織の規模によっては、

メンターのバックグラウンドがメンティーに一致しない。メンター候補がいない…

という悩みもあるのではないかと思います。弊社もそこで同じく悩みました。

しかし結論としてはバックグラウンドは必ずしも合致しなくてよい。たとえばアプリエンジニアでも新人WEBエンジニアのメンターにつける、と考えています。

そこでのポイントは、メンティーの目標の解像度上げは自分自身でやってもらうということ。

メンティー自身が「どうなりたいか」の成長イメージを組み立て解像度をあげていき、それをメンターと擦り合わせる事で、目標を定めています。

メンターは具体的な成長の定義や可能性を示しながらも、メンティー自身が自発的に掴み取ってもらうように意識しているのです。そうすれば、バックグラウンドの細かい点はそこまで重要でなくなると考えています。

エンジニア組織論：過ちの輪廻から人はどう抜け出すのか？

ここからは雰囲気を変えて「エンジニア組織論」について語らせてください。

下記の書籍は以前の会社で、大変な思いをしてきた中で助けになった「先人の教え」です。何かあった際に、立ち戻れる理論として、組織を考える立場にあるエンジニアリーダーやマネージャーの皆さまにご共有します。

なぜおいしいアイスクリームが売れないの? ダメな会社をよみがえらせる3つのレッスン (講談社BIZ)

ピープルウエア

Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス

ティール組織 ― マネジメントの常識を覆す次世代型組織の出現

アジャイルサムライ――達人開発者への道

なぜこんなにたくさんの本に頼っていたかといえば、過去いろんな怖い組織にいたからです。

たとえば事業部と技術部が分離され「社内で受発注」が起きるような会社にいたこともあります。エンジニアはコスト扱いのため、謎の理由でエンドレスなサービス残業が行われていました。ひどいですね。イノベーションなんて生まれるはずもなく、当然デスマが発生。許されることではないと思います。

そして、「エンジニアの横の繋がりが無い」ことも悲しいことです。元気に車輪の再発明。情報共有が後回しにされているために何度も同じような不具合が繰り返し起きていました。

繰り返す過ちのそのたび　ひとは　ただ青い空の青さを知る

ここで冒頭の伏線を回収します。そう、これです。言いたかったのはこれです。

ナレッジベースで身につかないから、何度でも同じ障害が起きるんですね。

そんな、一番心細かった時に繰り返し読んでいたのは「WEB＋DB PRESS vol.84」の「CTOノウハウ大公開」の記事です。

ここには「よいチームってこんな感じ」というお手本とそのためのノウハウが書かれています。

たとえば、下記のような内容ですね。

・エンジニアのゴールはエンジニアリングだけでなく顧客に価値を届けるという事業的なゴールも含まれている
・職能と事業のハイブリッド組織構造が良い
・会議は朝会15分+週1〜2回の定例に絞る
・手段を目的化しない

そんな私の人生に深く関わるこの本なのですが、ちょうど登壇前日、日本CTO協会のイベントで、今はデジタル庁の最高技術責任者をされている藤本さんにお会いしましてサインを頂戴した次第です。ありがとうございます。

事業会社において、良さそうなエンジニア組織構造の例を図式化するとこうなるかなと思います。

縦がプロジェクト、横が職能でミックスされている状態ですね。そしてそれぞれが主体的な目標をもっていることが大事です。

スタートアップは人数が多くないので、ここまできれいに分担できないかとは思いますが、規模の大きな組織ならリーダーをたてることも可能かと思います。そして、この構造の中で、エンジニア本人がどうなりたいのかという解像度をあげることが重要だと考えています。

さて、私がお世話になった「先日の教え」の一つでもある「ティール組織」という本の中で紹介されている組織の段階モデルです。

「レッド（群狼 狼の群れ）」から「ティール（生命体）」へと進化していくと示していますが、個人的には「グリーン（家族）」くらいがちょうど良い組織なのかなと思っています。

ティールは個人個人が意思決定するので自由度は高いのですが、全員に成熟したプロフェッショナリズムが求められ、大きすぎる裁量を扱いきれないと逆に組織的な成長が阻害されます。グリーンは平等性や多様性を尊重し、ヒエラルキーがありボトムアップの意思決定があるので、上に突き上げていくという健全な成長が望めます。

ここでアンチパターンの復習です。組織を退化させる要素が、単純だけれどたくさんあります。

でも逆にして、リスペクトを出発点にすれば組織は成長し生産性が向上していきます。

ただ、ゴールは生産性向上ではありません。生産性をあげることにより長時間労働をなくして余裕を作り、1日に1時間でも自己研鑽に充てる時間をとることができれば、1年後には大きな差がつきます。

先期は、特許出願の社内ワーキンググループと資格取得の推奨の制度を作りました。テックベンチャーの源である次のイノベーション人材、そして「次のエース」を育てたいと思っています。

まとめです。

絶対にやってはいけないのは「慢心」です。これだけ考えてきても、何かをきっかけに一瞬で崩れ去る可能性があります。緊張感を持っていきましょう。

最後に、私が大切にしている2人の偉人の言葉をご紹介します。

まずは武田信玄の格言で「情けは味方、仇は敵也」。

「情けをかけることは味方となり、害を与えれば敵方となる」という意味ですね。チームビルディングの根幹には信頼があり、お互いにリスペクトすることにより心理的安全性が醸成されます。不具合対応や締め切り前でテンパってる場合でも、いかなる相手でも、この大前提を忘れてはならないと思います。

またビジネスは流動的です。いま一緒に仕事をしている人が、いずれ別の形で関わりを持つ事もあります。そういった時に、あえて敵になるような振る舞いは避けておいた方が良いということもあります。実際、20年前の同僚と一緒に働いてる自分ですが、業界を見渡すとさまざまなポジションに昔の同僚がいて、お話しするとスムースに繋がったりします。あの時人様に迷惑をかけず、ちゃんと仕事しておいて良かったと思います。

そしてもう一つは『ジョジョの奇妙な冒険 』第5部、ブローノ・ブチャラティの言葉です。

「任務は遂行する」
「部下も守る」
「両方」やらなくっちゃあならないってのが「幹部」のつらいところだな
覚悟はいいか?オレはできてる

会場中が「うん、うん」と頷いていました。当日、いちばんの共感を得られたのはブチャラティの言葉だったかもしれません。

ディ・モールトグラッツェ（どうもありがとう）

歴史と伝統のデブサミで登壇の機会をいただき、ありがとうございました。一生自慢します。

その後の懇親会も楽しかったです。

告知

9/13に「生成 AI ではじめる Bot 開発」というイベントでGeminiとRaspberry Piで作る物理Botの作り方の紹介をしますので是非お越しください。

会場はGoogle様の渋谷ストリームです。ML女子部というコミュニティ主催ですが、性別問わず皆様のお越しをお待ちしております。
https://women-ml.connpass.com/event/325067/

• #エンジニアイベント
• #エンジニアのひみつ
• #プロダクト開発チーム
• #仲間募集
• #技術部