※本記事は2020年12月に公開された内容です。

■本記事の対象者(こんな人におすすめ)

• エンジニアマネジメントを現在行っている方
• エンジニア組織拡大を考えている方
• 現在、CTO・VPoEのポジションにに該当される方
• マネジメント思考を高めたい方。 *様々なマネジメント手法を取り入れたい方

2020年12月15日に開催されたCTO meetupのテーマは、強い開発組織の作り方についてです。

LIFULL、Chatwork、LINE Growth Technologyといった名だたる企業の方々に、組織がどのような変遷を遂げてきたのか、そして今後の組織の成長のためにどのようにメンバーの育成を行っているのかといったことをたっぷりディスカッションしていただきました。

今回は特にマネジメントレイヤーの方々にとって気になる話題が盛りだくさんの内容になっています。

まずは、ご登壇者から各社のエンジニア組織の歴史について語っていただきます。

登壇者

LIFULLのエンジニア組織について

事業部制と職能別を交互に繰り返し改善を重ねてきたLIFULL

株式会社LIFULL CTO 長沢 翼 氏（以下、長沢）：本日のモデレータを務めさせていただきます、株式会社LIFULLのCTO長沢と申します。LIFULLは主力サービスの「LIFULL HOME’S」という不動産ポータルサイトを作っている会社です。私たちは社会課題を、事業を通して解決することを目指し、地方創生事業や介護施設紹介事業などを展開しています。

今回は組織の話ということで、LIFULLの組織がどんなふうにこれまで歩んできたのかをご説明させていただきます。

長沢：まず2008年当時、HOME’S（現LIFULL HOME’S）には賃貸や分譲マンションなどのさまざまなマーケットを扱うサイトがありました。組織としても事業部制を採用しており、各事業部ごとにエンジニアやデザイナー、プランナーが所属していました。

このときはスピード感のあるプロダクト開発を行えていた一方で、車輪の再発明が起きたりエンジニア同士の交流が少ないといったことが課題でした。

長沢：2011年頃のことは第1次職能別時代と表現していますが、これは職能別の体制を何度か繰り返しているためです。当時はエンジニアやデザイナー、プランナー、セールスが部門として分かれていた時代です。開発チームは大体60名でした。チーム構成は7～10名ほどで、各グループにエンジニアチームが3つほどあるような構成でした。

良かったのは、きちんと技術に目が向いたことや、エンジニア同士がとても仲良くなったことです。しかし、職能別のセオリーとしてプロダクトへの愛着が薄れやすい、下請け感が出やすいといた課題を抱えました。

再び事業部制に戻ったのが2014年頃です。マーケットごとに意思決定を積極的に権限委譲することで、スピード感のある開発を行おうとしていました。実際、作る・届けるというサイクルを素早く回せたのは非常に良かったところですね。職能別組織だったときに培ったエンジニアのつながりは持続していましたし、マーケット愛を持てたのもメリットでした。しかし、だんだんと人員・ナレッジの蛸壺化が起こってしまったのが課題でした。

当時は職能としてエンジニア部を強化するために、事業部という縦のラインに対して横のラインに職能横断のエンジニアマネージャー各10名ほど付け、メンター的に能力やスキル開発をしていくという取り組みも始めました。

長沢：これが最新の組織編成で、2020年から再び職能別に戻しました。本部としてスピード感を持った意思決定をして全体を動かしていこうという狙いがあり、さらに蛸壺化によって部分最適になっていしまっていた人員やシステムのコストをきちんと全体として見直そうとしています。技術力強化や、非機能要件への着手という意味もあります。

部門間連携をうまくできる「越境力」をもった組織を構成していくことが今後の課題です。

LINE Growth Technologyのエンジニア組織について

複数拠点で異なる体制を採用しているLINE Growth Technology

LINE Growth Technology株式会社 東京開発室室長 黒木 亮太 氏（以下、黒木）：LINE Growth Technology株式会社で開発室室長を務めている黒木と申します。

みなさんLINEはご存知だと思いますが、今回は開発子会社であるLINE Growth Technologyにフォーカスしてお話しさせていただきます。

黒木：当社はLINEサービスのGrowth領域に特化した組織です。サービスの満足度と認知度向上のための改善活動や、サービスの運営に寄り添ったさまざまな運営フローの設計・改善に注力しています。

僕が入社した2年前のタイミングはまだ組織として立ち上がったばかりで、社員数も10名ほどでした。

黒木：東京のほかに福岡にも開発室を持ち、多拠点での開発を行っています。当時は基本的に、開発室の下にさまざまな職種がフラットに所属しているような状態でした。

まだチームを作るという規模感ではなかったので、LINEのチームと一緒に動くことも多かったですね。

黒木：1年ほど経過すると社員数が20～40名ほどに増え、チームを意識して開発をしていました。我々の組織も職種型とプロジェクト型があり、東京の開発室はどちらかというとプロジェクト型、福岡は職種型でチームを作るという選択をしていました。

LINE全体としてチームがどうあるべきかはあまり決まっていないので、目的に合わせてチーム編成を変えています。

黒木：現在はさらに社員数が増え、札幌にも開発室を立ち上げました。もともとは札幌というニアショアの活用という狙いがありましたが、現在は在宅ワークの流れもあり、良い意味で拠点間の差はなくなってきています。

東京・福岡・札幌でハイブリッドチームが組まれたりもしている状態です。

Chatworkのエンジニア組織について

組織拡大に伴って提供機能別から職能別に変遷してきたChatwork

Chatwork株式会社 執行役員CTO兼開発本部長（※2020年12月時点）春日 重俊 氏（以下、春日）：ChatworkでCTOを務めている春日と申します。Chatworkは日本最大級のビジネスチャットサービスで、2020年11月末日時点の導入社数は29.3万社以上。毎月約3000～4000社ほど導入企業が増えているようなサービスです。

お二方と同様にChatworkの組織編成についてご説明させていただきます。そもそもChatworkは2021年3月で10年目を迎えるプロダクトなのですが、組織はLINEさんのように大きいわけではありませんでした。

春日：上記の通り、初期段階ではCTOがプロダクト開発もマーケティングも行っており、チームも全体で10名未満でした。

春日：Chatworkが順調にビジネスとして成長し、外部から資金調達をしてグロースを図ろうとしていたのが2014年頃です。

エンジニアは20名を超え、エンジニア組織は提供機能別に分割しています。ただ、インフラエンジニアがほとんどおらずサービスが長時間停止してしまうことがあるのが課題でした。

春日：次の組織の変遷は、上場前夜と題した2016～2019年にかけてのタイミングです。僕が入社したのは2016年1月ですね。

当時はCTOに経営レイヤーの仕事が非常に増えてしまっていたため、現場を回すための開発本部という箱を作り、そこを運営するために僕がジョインしました。インフラの安定化のため、専門部署としてSREも設立しています。

また、エンジニアのスキルを深く追求するために、このタイミングで体制を提供機能別から職能別に変えました。

春日：これが2020年現在の状態です。CEOの山本がCTOを兼務していた状態を解消し、経営的・技術的なジャッジメントは僕が担保することになりました。メンバーは現段階で60名を突破。職能別の縦割り組織から一部を切り出し、サービスのグロース部分だけを提供機能別にするという体制にしています。

部署は8個ありますが、2021年1月を迎えたタイミングで10個に増える予定なので、どんどんマイクロサービス化していこうと考えています。

チームビルディング（オンボーディング含む）の方法／組織文化醸成について

部署間の交流を図る取り組みを積極的に行い定着率をアップ

株式会社LIFULL CTO 長沢 翼 氏（以下、長沢）：では早速、チームビルディングやオンボーディングについて、最近大変だったことや工夫している点について春日さんから聞いていきたいと思います。

Chatwork株式会社 執行役員CTO兼開発本部長（※2020年12月時点）春日 重俊 氏（以下、春日）：Chatworkの組織のあり方から少しご説明させていただければと思います。Chatworkは兄弟で創業した会社で、現代表の山本の兄が前代表を務めていました。前代表は大阪、山本は東京を拠点にして開発をしていたため、多拠点開発が当たり前の組織カルチャーでした。

その中でメンバーに馴染んでもらうための特徴として、メンターランチという取り組みがあります。

これはコロナ以前からある制度で、部署間の交流を図るものです。中途で入社したメンバーが所属している部署以外のメンバーをランダムに3名、所属が東京拠点であれば大阪からメンバーを1名ピックアップして、会社がお金を出して3、4回ほど豪華なランチをします。自分が所属する部署以外にもメンターがいる状況にすることで、例えば仕事で孤独感などを感じていれば相談できるようになります。その結果、Chatworkの離職率はコロナ禍においても1桁％で推移しています。

もう一つ、コロナ禍をきっかけにスタートしたのが開発本部全体会というものです。当社は以前は偶発的なコミュニケーションを生むために出社を推奨していたのですが、現在は原則的に在宅を推奨している状況です。そんな中でも事業を前進させるために幹となるメッセージをメンバーに発信しようと、開発本部全体の人事を考える「DevHRチーム」を立ち上げました。全体会はこのDevHRが開発本部全員を巻き込み、半日ほどかけて会社の重要なテーマを発表する場です。最後に懇親会でメンバー同士の交流も行いました。振り返りアンケートでも良い結果が出たので、継続していきたいと思っています。

LINEが定義する11の項目がオンボーディングと評価の軸

長沢：黒木さんはいかがでしょうか。オンボーディングでもいいですし、組織文化醸成のために意識していることやここ最近の変化などはありますか？

LINE Growth Technology株式会社 東京開発室室長　黒木 亮太 氏（以下、黒木）：LINEには「LINE STYLE」という11項目の価値基準があるので、オンボーディングや評価においてもこれらの項目を基準にする文化が浸透しています。

黒木：ここまで綺麗に落とし込むには時間がかかると思いますが、「こうあるべき」というガイドラインを定義するのは、オンボーディングにおいては重要だと思っています。

また、入社したタイミングでウェルカムミーティングというものを行っていて、取締役やマネージャー、僕なんかが全員集まって顔を合わせています。そこで入社したメンバーに対する期待値などを話していますね。

最近オンボーディングで苦労しているのは、オンラインでの気軽に質問などができる場の提供です。社内には独自の単語なども多く、そういった聞いたほうが早いような雑談がなかなかしづらいというのがあります。ここは今後も課題ですね。

チームがアジャイル的に自走していけるようにするための施策

長沢：Chatworkさんには会社全体としての行動規範やエンジニアのフィロソフィーといったものはあるのでしょうか？

春日：会社全体としては戦略、オペレーション、ケーパビリティの3軸で運営していこうとしています。そのための組織的な中長期的観点のビジョンについては、HRチームと協働しながら議論していく必要があると思っているところです。

今現在取り組まなければいけないのはと感じているのは、アジャイルを推進するための取り組みです。オンラインのみでのやり取りでは現場だけで全てを自走せよと言っても難しい部分があるので、組織が一緒に伴走してチームが自走するための仕掛けを作っていかなければいけないと思っています。

長沢：組織が伴走するというのは面白いですね。実際に何か取り組んでいることはありますか？

春日：アジャイル推進室のようなチームを立ち上げて、「Scrum@Scale」というスクラムをスケールさせていくためのフレームワークを適用したいと考えています。国内ではまだ導入事例があまり無いので、組織としてもチャレンジングな取り組みですね。スクラムマスターやプロダクトオーナーの視点を取り入れながら、どうすればスケールや自走ができるのかを構想中です。

長沢：オンラインは反応が見えにくいので、メンバーの理解度を把握するには工夫しないと難しそうですね。

春日：そうですね。すごく小さなサイズで、丁寧にハンズオンしてあげないといけないと思います。

責任範囲やスキルレベルを定義し評価とは切り離して運用

長沢：黒木さんから先程紹介していただいたのはLINE全体の行動規範だと思いますが、その中で特にエンジニアがどういう存在であるべきかといった定義はあるのでしょうか？

黒木：LINEの中にはレベル制度のようなものがあります。「Iレベル」と呼ばれるものがI1～I7まであり、レベルによって責任範囲や身に付けるべき能力がそれぞれの職種で定義されています。レベルを上げることを目標としたり、自分のキャリアを考える上での指針として使ってもらったりしていますね。

全社で定義しているレベル定義は抽象度が高いので、組織に合うようにブレイクダウンした上でLINE Growth Technologyとしての解釈定義をしています。

長沢：基準を浸透させる上でやって良かった取り組みはありますか？

黒木：例えばIレベルに応じて目標を立ててもらった場合、現在の立ち位置と次のステップまでの差を認識した上で、半期のうちにどこまで自分の責任範囲やスキルを上げていくか決めてもらうようにしています。目標を立てても達成まで駆け抜けるのは難しいので、定期的にきちんと振り返ることが必要です。試行錯誤中でまだ課題もあるので、来期以降も取り組み方を工夫していかなければと思っています。

長沢：目標設定というのはMBOを運用している感じですか？

黒木：あまり型に沿ったものではありません。基本的には自分が数年後に目指したいキャリアを考えてもらい、現在不足していることを落とし込んでもらう感じです。

長沢：評価とは切り離されているのでしょうか？

黒木：そうですね、評価のベースに使うものではなく、評価のプラスαの要素としては使っています。そのため、目標を達成しなかったからといって評価を下げることはありません。

育成のための制度と定着の工夫／どういう人をマネジメントに登用しているのか

育成のガイドラインとなるのは技術とマネジメントのスキルレベル

株式会社LIFULL CTO 長沢 翼 氏（以下、長沢）：次のパネルディスカッションに入ります。まず黒木さんから、育成のための制度や定着の工夫として何かされていることはありますか？

LINE Growth Technology株式会社 東京開発室室長 黒木 亮太 氏（以下、黒木）：先程少しお話した部分ですが、以下の図にあるのが「Iレベル」です。もう一つ「Mレベル」というものもあり、これはマネジメント職のレベルを示しています。

黒木：Mレベルはチーム成果を意識する部分で、Iレベルは自分のスキル高める部分という感じです。基本的にはこのレベルに沿って、一人ひとり細かい部分を定義するのが育成のベースになっています。

長沢：スキルのレベル感を提示して、それぞれが成長できるようなガイドラインにしているという感じなんですね。ちなみに、IレベルのIは何のことですか？

黒木：IndividualのIです。

長沢：I3とI4の間にM1がありますが、これは同じようなレベル感だということですか？

黒木：イメージ的にはI2が自走できるかどうかのラインで、I3はテックリードのようなポジションです。そのタイミングで役職がついたりするので、マネジメントスキルも必要なものとして書かれています。

長沢：M1からM5のレベルはマネジメントする人数なのかプロジェクトの難易度なのか、どういうところで違いが出てくるのでしょうか？

黒木：基準としては両方入っています。ステークホルダーや関連部署の多さなどプロジェクトの規模も含みますし、チームか室かといった単位も関わります。

開発メンバー全てにハンズオンのミドルマネージャー研修を実施

長沢：春日さんは育成のための制度や工夫についていかがでしょうか。

Chatwork株式会社 執行役員CTO兼開発本部長（※2020年12月時点）春日 重俊 氏（以下、春日）：当社は組織を拡大するにあたって、ミドルマネージャーを育成する必要がある状況です。そのためには会社としてマネージャーに何を期待しているのかを伝えながらハンズオンで育成しなければいけないということで、マネージャー研修を行っています。

少し前にEVeMの代表取締役社長がnoteに書いた『ベンチャーマネージャーのマニュアル』という記事がバズりましたが、これはやっていて面白いので、機会があればぜひ読んでみてください。ここで紹介されていたのが、急成長企業におけるマネージャーの役割をハンズオンで伴走するようなマネージャー研修です。マネジメント研修はいわゆる座学だけでピンとこないまま終わってしまうものも多いのですが、そうではなく例えば開発本部の全体会で発表した戦略をどのように部署に落とし込むのか、といったことに一緒に取り組みます。

ほかにも1on1をどうやるべきなのかも研修を通じて学びます。こういった形でマネージャーを育成することで、チーム全体のビルドアップにチャレンジしているところです。

長沢：一緒に考えるというのはいいですね。

春日：一方的に言われるだけでは定着しないので、お題を受けて一緒にワーク的に取り組むのは個人的にもいいなと思っています。

黒木：この研修はどの単位の人にやるんですか？

春日：今は開発部のメンバー全員にやっています。大体4、5人ほどに区切って研修しているのですが、例えばデザイナーやPM、クライアント系のアプリケーションエンジニアマネージャーなど、業務的に近いメンバーを混ぜています。自分一人で悩むのではなく、隣の人がどういう風に考えているのかといったことを見ながら一緒に学習を深めることができるので、すごく面白いなと思います。

マネージャーの資質として問われる謙虚・尊敬・信頼

長沢：マネージャーを増やすという話が出ましたが、2つ目のテーマとしてどういう人をマネージャーに登用しているのかをお伺いしたいと思います。各社の基準は僕も気になるところですが、春日さんからいかがでしょうか。

春日：現在内部で議論しているのが、Team Geekで言われているHRTという三原則です。

春日：マネージャーはチームの成果を最大化させることが職責ですが、人格には謙虚さが求められますし、相手を信頼・尊敬しているかといったことは自然と態度に滲み出てくると思います。こういったことがマネージャーの素養として必要だと実体験から感じていますし、Chatworkとしても大事にしている観点です。

長沢：HRTは非常に大切ですよね。マネージャーのみならずメンバー全員が持っていてほしいことです。黒木さんはいかがですか？

黒木：チーム成果の最大化はマネージャーに求められるものなので、そこは春日さんと同じです。あとはメンバーをサポートするところも重要な役割だと思います。そのため、マネージャーを任命する場合には、どこを任せるのかを擦り合わせるのが大切なので、そのあたりは意識しています。

マネジメントの面白さや醍醐味を伝えることが重要課題

長沢：マネージャーも結局やってみないとわからない部分がありますよね。これは答えにくい部分かもしれませんが、こういう人をマネージャーにしてみたけれど上手くいかなかったという話はありますか？

黒木：0か1かで上手くいかなかったというケースはあまりありません。ただ求めた役割に対して強みがあるないなどもあるので、期待値は伝えるようにしています。

そこが自分にとって伸ばせる部分なら伸ばしてもらえればいいですし、逆にその人にとってやりたい部分でないのであれば他の人に任せて、それ以外の部分でしっかり役割を持ってくれればいいかなと思っています。

春日：成功失敗というよりも、当社は組織拡大のため、マネジメント素養を持っている人に頼み込んでやってもらっているという状況です。その上でメンバーから現場に戻りたいと言われるとどうしようかと思うので、そこは僕自身の課題ですね。キャリアの一つとしてマネジメントをやってみようという方向を訴求しきれていないのだと思います。マネジメントにチャレンジしたいと思えるような成功事例なんかを見せながら、マネジメントの何が面白いのかをもっと上手く伝えないといけません。

実際今のマネージャー業務を見ると、月末月初の経費承認や稟議、査定だったりして、メンバーからすると「うーん……」という感じなんですよね。でもそうではなく、複数のメンバーとゴールに向かい大きな成果を出すのがマネージャーにとって何事にも代えがたい喜びだと思いますし、メンバー自身が成長して思いもかけない成果を出してくれる瞬間もあります。

そういった内容を仕組み化して、マネージャー職を面白くしていくというのが一つのテーマだなと思います。

長沢：マネージャーが大変そうに見えてしまう問題はありますよね。マネージャーが褒められることも少ない気がしますし。

春日：中間管理職で上から言われ下から言われというのは、はたから見たらやりたくないですよね。

でもソフトウェアのエンジニアはプロスポーツチームのようなもので、強いチームには強いコーチありだと思っています。コーチの醍醐味を体感できるようになれば、「マネジメントをやってみてもいいかな」と言ってくれるメンバーが増えるのではと思います。

質疑応答

リモートワークだからこそ新たに生まれたコミュニケーション方法

質問者：リモート環境での円滑なオンボーディングにおいて、やってみて良かったことはありますか？

黒木：できなくなってしまったことはたくさんありますけどね（笑）。最近はオンラインでシャッフルランチのようなことをしてコミュニケーションしています。自宅に料理を配送してくれるサービスを使って同じものを食べるなど、オンラインで新たに生まれたものを使って工夫していますよ。

長沢：メンバーからの評判もいいんですか？

黒木：人によりますね。フラットにコミュニケーションを取りたい一定数の人が任意参加して、お昼を食べながら喋るという感じです。

春日：オンボーディングに役立っているかはわかりませんが、強制的に在宅になってしまったので、感染対策としてマスク・アルコール消毒液の購入や在宅環境の整備など社員の経済的な負担を補填する毎月4000円の非常時特別手当を作りました。年間上限15万円の「一歩先の働き方支援制度」もあり、在宅に必要な環境に対する資金を会社から出してもらえます。僕が座っている椅子も半分は会社持ちです。

こういった制度の良かった点は、「在宅ノウハウを教えてチャット」というグループチャット内で異なる職種の人たちのコミュニケーションが生まれたことです。「こういうものを使ったら在宅ワークが便利になる」といった内容を意外とみんな見ているんですよ。メンバーは「春日さんこれやってみてくださいよ」と僕を人柱にしてからかいますし（笑）、個人的には悪くない施策だったのではと思います。

長沢：それは面白いですね。在宅だからこそ困ること、気になることはきっと出てきますし。

春日：日本人は真面目なので仕事に関することは自分で整備しなければいけないと思い、困っていても聞けない空気感が出てしまいます。当社のビジネスサイドは若い子も多いので、みんな愚直にやっているんですよ。でも、エンジニアサイドがキャッキャしているグループなんかを見て、「こうやっているんだ」と思ってもらえたらすごくいいですね。

長沢：「良い椅子ないですか」といった質問は職種の垣根もなくできますからね。

メンバーが多拠点にいる場合のチームビルディングのコツ

質問者：拠点間の連携における課題があれば教えてください。

黒木：東京、福岡、札幌というエリアごとの特色のフィットを見ながら始める必要があるかなと思います。福岡ならある程度Web系の企業があり、札幌はWeb系というよりもSI系が多いといったことです。いきなりドラスティックに変化させることは難しいので、信頼関係を構築するにしてもまずは小さく始めることを意識しています。Chatworkさんも拠点は多いんですよね。

春日：エンジニアは全国12ヶ所で動いています。

長沢：同じチームでも拠点はバラバラなんですか？

春日：例えばSREの部隊は東京・名古屋・大阪・鹿児島です。東京のメンバーも実家の北海道に帰っていたりするので、誰一人として同じ都道府県にいないなんてこともありますよ。

長沢：リアルでは会ったことがないメンバー同士なんですか？

春日：いえ、コロナ以前は合宿制度を設けていました。会社が予算を組んでいて、大体クォーターに1回ほどのタイミングで多拠点のメンバーがチームビルディングを高めるためにリアルに集まるんです。それも今はできないので歯がゆいですね。

長沢：普段はSlackなどのテキストチャットでコミュニケーションしている感じですか？

春日：そうですね。あと当社はデイリースタンドアップミーティングをやっているのですが、昔から自分の席でビデオ会議をしていました。多拠点なのでそれが当たり前でしたね。

長沢：では1日に1回は絶対に顔を合わせる感じなんですね。

技術的なスキルはマネージャーに必須ではない

質問者：マネージャーに技術力はどこまで求めますか？

長沢：LINEさんのスキルレベルの図で言うと、マネージャーにシニアの入り口程度の技術力は求めるということなのでしょうか？

黒木：そうですね。マネージャーは最低限シニアエンジニアになった後のキャリアパスです。マネジメントしながら自分の技術力をどこまで伸ばしていくのかはその人のキャリアによって変わるので、会社として求めるレベルを明確に定義はしていません。

長沢：Chatworkさんはいかがですか？

春日：当社のキャリアパスにはエキスパートコースとマネジメントコースという大きな2つの軸があります。

一人でプロジェクトを動かせるレベルが最低限の条件で、その後マネジメントにいくかエキスパートにいくかということになります。技術が一番できる人間が必ずしもマネージャーである必要はありません。マネージャーはチーム全体で最大の効果を得るための「場回し」というか、目的を合致させるためのファシリテーション技術なんかが必要なのではと思います。

伝えたいビジョンはしつこいほどに繰り返してようやく浸透する

質問者：組織戦略やビジョンを浸透させるための仕組みや試みがあればお伺いしたいです。

春日：当社にはミッション・ビジョン・バリューがあります。当社のミッションは「働くをもっと楽しく、創造的に」で、ビジョンは「すべての人に、一歩先の働き方を」です。ミッションはずっと変わらないもので、ビジョンはその時点で定義するものかなと思っています。

プロダクト開発においても2023年にはこうなっていたいということを言語化していて、それを半期ごとにリバイスして落とし込むという作業を繰り返しています。これは僕がやりはじめて一年半くらい経過するのですが、最初は全く手応えがありませんでした。「めちゃくちゃ滑ってるんじゃないか？自分の独りよがりなんじゃないか？」と不安にはなるのですが、やり続けたことに対して出てきた組織のフィードバックを見て、きっちり改善していくことこそが重要だと思います。

あとは、マネージャーが部署単位できちんとミッションを発信して、メンバーに浸透させていく循環を流すのも大事ですね。

長沢：半期ごとにリバイスして伝えることとPDCAを回すことは非常に大切ですね。黒木さんはいかがですか？

黒木：前職では本当に一言でわかるくらいのレベルにスローガンを落とし込んで、見える場所に貼っていました。いかに自分ごとにして、それを見えるようにするかは重要だと思います。見ないと何だったか忘れるということは結構ありますし。

春日：スローガンはしつこいくらい何度も言い続けないと、人は覚えないんですよね。考えている側は真剣に考えているので「何で覚えてくれないんだ」と思うのですが、メンバーからすると「また突然変なことを言い始めたな」というワードの一つでしかないんです。

最後に一言

長沢：ではパネルディスカッションはこれで終了します。最後にお二人から一言をお願いします。

春日：今回みなさんの前でお話しさせていただきましたが、必ずしも僕が言っていることが正ではありません。組織の状態やフェーズに合わせていろいろなトライが必要なので、自分がトライしたことが駄目だったと悲観するのではなく、一歩引いた目でなぜ駄目だったのかを評価するのが良いと思います。

今回のテーマのような内容はオフラインでもよく尋ねてもらったりしますが、こういうぶっちゃけトークをもっとシェアできるといいなと思いました。

黒木：僕も今日はお二人の話を聞いて勉強になるところがたくさんあり、楽しかったです。こういう課題はやはり企業のフェーズや規模によって対策が異なるので、そこはご自身の中で咀嚼した上で使えるものは使っていただく感じになると思います。

また、実際にどういう打ち手があるのかをカードとして持っておくのも損にはならないと思うので、いずれ使えるかもしれないという感じで頭の片隅に入れておいていただけると良いのかなと思います。本日はありがとうございました。

長沢：マネジメント手法や強い開発組織の作り方は会社によって前提が違いますので、やはり打った手によって起こった変化をフィードバックとしてしっかり捉え、さらに次の手を打ち続けるのが大事なのだろうと僕自身も体感しているところです。

僕も今日の話をいろいろと組織に生かしていきたいと思います。本日はありがとうございました。

エンジニア組織についての関連記事

エンジニアの組織図について

エンジニア組織をまとめあげる立場の方たちがどのように意思決定を行うのか、エンジニア組織のあり方についてのイベントレポート記事です。

まとめ

今回のCTO meetupでは、LIFULL、Chatwork、LINE Growth Technologyの方々に、強い開発組織の作り方について語っていただきました。今後のマネジメントや組織立ち上げの際に活かしていただけると幸いです

■FLEXYのご紹介

FLEXYは、エンジニア、技術顧問、CTO、デザイナーの方向けに案件をご紹介するサービスです。
リモートワークや週1-5日、高単価案件など、ご希望に合った案件をご紹介いたしますので、是非お気軽にご相談ください。

FLEXYに登録する