シェア
はてブ
2020年10月28日、ファインディが主催するウェビナー「エンジニア組織づくりの失敗談義〜しくじりから学ぶ次世代のチームとは〜」がオンラインにて開催されました。
本ウェビナーではChatwork株式会社の門田矩明さんをお招きして、ファインディ株式会社CTOの佐藤とともにエンジニア組織づくりにおける失敗談をテーマにお話いただきました。 イベント参加者の皆さまの失敗談も交えながら展開されたトーク内容をお届けします。
- まずは、しくじり先生たちの自己紹介からスタート
- 参加者からの失敗談その1：勉強会を開催したが、期待ほど人が集まらない
- 参加者からの失敗談その2：「大丈夫です！」が、全然大丈夫じゃなかった
- 登壇者2人の代表的なしくじりエピソード
- 0→1、1→10それぞれの組織フェーズにおける失敗と学び
- エンジニアの評価制度・社内制度におけるベストプラクティスとは
- 失敗の先に、どのような組織の変遷があったか
■登壇者プロフィール
門田 矩明(Chatwork株式会社) [@nottegra]
2012年サイバーエージェント中途入社。メディア系新規サービス立ち上げにエンジニアとして関わった後、広告系SaaSサービスの責任者として、開発組織の改善やサービス提供体制の整備をしつつ、ダイレクトスカウトや技術広報などを用いた採用力の強化に従事。 数々の失敗経験をアンチパターンとして蓄積しながら、成功に導くために「人」と「チーム」を中心とした組織作りに取り組む。2020年にChatwork株式会社に入社。急拡大する事業を支える開発組織の強化施策や、エンジニア採用強化に奔走中。
佐藤 将高(ファインディ株式会社)[@ma3tk]
東京大学 情報理工学系研究科 創造情報学専攻卒業後、グリーに入社し、フルスタックエンジニアとして勤務する。 2016年6月にファインディ立上げに伴い取締役CTO就任。 大学院では、稲葉真理研究室に所属。過去10年分の論文に対し論文間の類似度を、自然言語処理やデータマイニングにより内容の解析を定量的・定性的に行うことで算出する論文を執筆。
■モデレーター
田頭 一真(Findy株式会社)
株式会社ドリコムでIP系ゲームアプリの開発ディレクターを経験後、2018年6月にファインディへジョイン。Freelance事業と転職事業のユーザーサクセスの立ち上げ〜グロースに携わる。
まずは、しくじり先生たちの自己紹介からスタート
──本日はよろしくお願いいたします。まず最初に、Chatworkの門田さんから自己紹介をお願いします。
門田： 門田と申します。2012年にサイバーエージェントに入社し、メディアでサーバーサイドのエンジニアをやった後、広告系SaaSサービスの責任者をしていました。いろいろな開発組織の施策をやってきて、その中であった数々の失敗をブログやnoteに書いているので、“しくじり芸人”みたいに呼ばれることが多いです。
今年の夏にChatworkに入社しまして、まだChatworkではしくじっていないので、今日披露するエピソードの中には含まれていないんですが（笑）、本日はよろしくお願いします。
──続いて、佐藤さんの自己紹介をお願いいたします。
佐藤： ファインディでCTOをしている、佐藤と申します。 Twitterでは筋肉CTOとして活動しているんですけども、もともとはグリーでバックエンド、フロントエンド、ゲーム開発QAのエンジニアを3年ほどやっていました。
ファインディでは「Findy」や「Findy Freelance」の立ち上げを行い、現在はエンジニア組織のパフォーマンス可視化サービス「Findy Teams」の事業責任者をしています。色々と0→1で作る経験をしてきたので、たくさん失敗もしてきました。今日はその一部をぜひお話しできたらと思っております。どうぞよろしくお願いいたします。
参加者からの失敗談その1：勉強会を開催したが、期待ほど人が集まらない
──パネルディスカッションの前半では、参加者の皆さまから事前にいただいた失敗談に、お二人からコメントをいただければと思っております。まず1つ目は、「社内勉強会を主催したが、聴講者が期待ほど集まらない」という失敗談です。門田さん、似たようなご経験はありますか？
門田： そうですね。わかりみが強い、としか言いようがない。
佐藤： （笑）。
門田： ほぼ同じ経験をしたことがあります。ただ1つ言えるのは、期待したほどではなくとも、集まった人はゼロではなかったんだろうなって。
人数が少なかったとしても、来てくれた人を大事にしないといけないと思うんです。そのためには、少ない人数でも場が盛り上がるように話を振るとか、一体感を出してその人数でも回るようにするとか。
人が少ないということは、1人ひとりの顔がわかりやすいので、「なんで来てくれたんですか？」と、ちゃんとヒアリングして固定客に繋げていく。次に登壇してもらうきっかけにもなりますし、そうやって満足度を上げることが大切ですよね。
あと、「期待ほど集まらない」とありましたけど、そもそも期待しないのが精神衛生上は一番かなと思います。2～3人来たらなんとかなります。
一同： （笑）。
──ファインディでは社外向けの勉強会を定期的に開催していますが、佐藤さんも似た経験はありますか？
佐藤： 結構あります。勉強会やセミナーを「このネタめちゃくちゃ面白いんじゃないか」と思って企画したものの、実際にconnpassを公開してみると、参加してくれるのは内部の人だけで、全然来てくれないみたいな（笑）。
コンセプトは良くてもタイトルがイケてないとか、夜遅くにイベントを公開しちゃって誰も見てくれないとか。企画したものをいかに届けるかを考えるところは、すごく大事だなと思いました。
ただ、失敗してナンボという部分もあると思うので、人が来なかったとしても、それをどうやってリカバリーしていくかですよね。失敗を嘆くよりも、いかに失敗を帳消しにするようなアクションができるかが、一番大事なんじゃないかと思います。
門田： それで言うと、勉強会に来てくれた人数よりも、発表したスライドを見てくれる人数の方が多いんですよね。なので、勉強会に来た人数はそれほど重要ではなくて、勉強会はスライドを公開する口実みたいなところはあるかもしれません。
勉強会に来たのが50～100人として、スライドだとだいたい800～1000人とか、10倍くらいの人に見てもらえたりして。だから、勉強会に来た人数で嘆く必要はないというか、まだ終わっていないと思います。
佐藤： たしかに。いかにリカバリーするかというか、むしろそっちがメインなんじゃないかっていうのはありますね。
・期待値を上げすぎず、継続できるように小さく成功させる
・失敗に囚われず、それをどうリカバリーしていくかが重要
参加者からの失敗談その2：「大丈夫です！」が、全然大丈夫じゃなかった
──2つ目の内容に移ります。「進捗確認で『大丈夫です！』と言われていたのに、全然大丈夫じゃなかったことが発覚した」という失敗談です。似たようなご経験はありますか？
佐藤： これもよくある話ですよね。「大丈夫ですか？」って聞くと、自分もそうなんですけど「大丈夫です」と反射的に返しちゃうことが多いので、いかに「大丈夫ですか？」という質問をしないかっていうのは、結構気をつけてコミュニケーションを取っています。
──コメント欄でもいただいていますが、「何か問題ないですか？」と声をかける、クローズドクエスチョンで聞くなど、皆さん工夫されているみたいですね。
佐藤： 大事ですね。
──門田さんも似たようなご経験はありますか？
門田： ありますね。これは、相手に期待していることがわからないと、”大丈夫”という言葉が指している定義がわからないと思うんですよね。なので、「こういうことを期待していて、大丈夫っていうのはこういう状態ですよ」っていうのを、ちゃんと伝えてあげる。そういうすり合わせが大事なのかなと思います。
多くの場合、リリースや納期など何らかのスケジュールがあると思うんですけど、期日から逆算して「あなたにどこまでやってほしい」という伝え方をする。その人がどこまで自分でやっていいのかわかってない状況も大いに考えられるので、一緒にそこを掘り下げて逆算するとか、そういったことは必要かなと思います。
佐藤： 具体的なところをちゃんと話すというのは大事ですね。
・「大丈夫ですか？」と聞くのではなく、質問の仕方を工夫する
・相手に期待している内容を、具体的なところまで掘り下げて話す
登壇者2人の代表的なしくじりエピソード
──ここまでは参加者の方々の失敗談でしたが、実際にお二人が経験した失敗についても語っていただければと思います。まずは門田さんのエピソードからお願いします。
門田： 僕の失敗は、「別の組織の成功施策を取り入れた」ことです。例をあげると、Googleの20%ルールを導入して失敗したり、別の組織のグレード制度を導入して失敗したり。別の組織の成功施策を取り入れて失敗したエピソードだけで、4つくらいあります。
門田さんのnote：失敗したエンジニア組織施策としくじりの反省
──続いて、佐藤さんのエピソードもお願いします。
佐藤： 僕の1番のしくじりは、「該当するバグと対応方法を常に教えた」ことです。これまでたくさん失敗してきましたが、「開発が面白くないのでやめてください」というフィードバックが来てしまったのがこれなんです。
具体的にお話すると、もともと0→1で立ち上げていたので、僕が9割以上を作っている状況で、僕はどこにどんなバグがあるかを把握していました。それを新しく入ってきたメンバーに対して、「ここにこういうバグがあって、GitHubのURLここで、こう直せばいいよ」と全部教えていたんです。
改善のスピードを上げて、早く次のステップへ行きたいというのが僕の意図だったんですけど、チームメンバーにとっては作業になってしまって、開発の面白さを殺してしまっていたんですね。
何のためにやるのかとか、期待する結果とか、正しいissueの書き方を前職で学んだにも関わらず、ずっと1人だったので全然やっていなかったんです。人が入ってきた時点で、そこを正しくやっていくべきだったなと改めて思いました。
0→1、1→10それぞれの組織フェーズにおける失敗と学び
──次のパートでは「失敗からの学び」にフォーカスしていきます。1つ目のテーマは「0→1、1→10それぞれのフェーズごとのエンジニア組織を作るには？」という内容で、失敗と学びについてお伺いしたいと思います。
門田： まず、0→1のスタートアップに関しては、役割を細分化しすぎてしまったという失敗がありました。広告系のシステムを作っているチームだったんですが、1人1システム担当みたいな感じで、設計も上流工程をチームのリーダーがやって、設計したものをメンバーに降ろして各システム担当が作るという体制でした。
最初から細分化して進めてしまったので、お互いのシステムのことをあまり把握していなかったんですよね。設計も上流工程をリーダーがやっているので、お互いの構造も知らなければ設計もよく理解していなくて、カバーできない状態になってしまった。実際に運用タイミングになって、いろいろと上手くいかなかったので失敗かなと。
0→1は、人も物もモノリシックに作っていく。同じものを複数のメンバーで触る環境を作ってあげることが、重要なんじゃないかなと思います。つまり、お互いに自然とカバーできる形を目指すべきというのが学びですね。
もう1つは1→10で、いわゆるグロースのタイミングです。0→1でリリースした後、新規機能追加などでプロジェクトがたくさんできて、作ってはリリースして解散して…を繰り返すと思うんですね。その時、プロジェクトをやっていた人たちが異動したり、退職したりしていくと、1人プロジェクトがたくさん出来上がります。
そうなると、「何々の機能を追加できるのは、〇〇さんしかいない」ということが起きる。例えば、サーバーが落ちた時に「保守できるのが〇〇さんしかいないけど、電話が繋がらない」とか。なので、開発時の体制と運用時の体制を、ちゃんとセットで設計しておくべきというのは学びとしてあります。
佐藤： 僕もわりと似た内容です。前職で大規模なシステムを作っていた中での失敗として、密結合のサービスになっていて、「あるサービスをgit cloneしてこないと、メインのサービスが立ち上がりません」みたいな問題があって（笑）。逆に、疎結合にしたプロジェクトもあったんですが、それはそれで開発スピードが全然上がらないという問題があったんですよね。
学びとしては、やはりスタートアップでやっていく上で、ある程度は密結合にしてスピードを重視する。妥協するところは妥協するけど、例えばDB構成など変更しづらいものは妥協しない、ということですね。フロントなどは2～3年のライフサイクルがあるので、場合によってはフロントだけ作り変えるとか。
門田さんがおっしゃったように、最初はモノリシックなリポジトリで始めて、状況に応じてリポジトリを分けていったり、マイクロサービス化していったりするのは、全然ありだと思っています。
まず最初は、限られた時間で価値を出すところに執着して、可能な限り後回しにしていくのが大事かなと。エンジニアとして、本当はしたくないんですけどね（笑）。ただ、そこはいかにプライドを捨てて前に進むかが、0→1では特に必要かなと思います。
エンジニアの評価制度・社内制度におけるベストプラクティスとは
──続いてのテーマは、「評価制度・社内制度の失敗パターンは？」という内容です。これについて、まずは佐藤さんからお願いします。
佐藤： 僕の失敗パターンとして、全員が納得するような評価制度を作ろうとして、時間をかけすぎたというのがあります。エンジニアの目標設定って難しいんですよね。コードの行数が100行増えたらA評価とか、つい書きがちなんですけど、いやいや最後1時間くらい無限にパッチ書いたら100行とか増えちゃうじゃん、みたいな。
営業なら、売上で判断しやすかったりしますけど、エンジニアの書いた1行のコードの価値を算出するのは難しい。なので、結論としては、丁寧な1on1が必要だなと。評価制度に100%納得いく人っていないので、納得いかないことをコミュニケーションで解消して、きちんと全員の納得感を醸成することが1番大事かなと思いました。
──コメントで「エンジニアの評価制度って、どのタイミングで入れたらいいんでしょうか」という質問が来ていますが、いかがでしょうか。
門田： これは難しいですね。僕も同じ質問を返したいぐらい（笑）。ただ、ニーズがないのに入れてもダメなんだろうなっていうのは、実際の失敗として感じていて。「評価制度を入れなきゃどうしようもない」という状況になったら、入れた方がいいんだろうなとは思います。
佐藤： 今、Findy Teamsを立ち上げるにあたって、エンジニアの評価で困っていることを20～30人くらいのCTOの方に聞いてみたんです。組織規模によって困っているポイントが変わるのかなと思ったら、みんないつでも困っていて。「そのフェーズではこういうやり方が合う」というのは、全くないんですよね。
CTOの目が離れて、エンジニアマネージャーがいる組織になったら、評価制度が必要かもしれない、というくらい。一方で、30人くらいのエンジニア組織でも、評価制度を入れていない会社さんもあったりする。評価って本当にベストプラクティスがなくて、自分たちでそれっぽい解を見つけていく、超難しいものなんだなと今ひしひしと感じています。
──コメントで、「評価に完成はないと思う」という名言をいただきました（笑）。続いて、門田さんからも評価制度・社内制度の失敗パターンについてお話いただければと思います。
門田： 前職で、だいたい3回くらいグレード評価制度の設計や導入をしました。評価や給与に関係するものもあれば、給与に関係しない名誉グレードみたいなものもあったんですけど、どれも実態や運用が伴わず失敗しています。
グレード制度を作ろうとしたタイミングで、既にある評価や年収に無理やり合わせて制度を作ることになるので、同じグレードの人でも年収が違うとか、そういったことを吸収して作らないといけないんですよね。なので、グレード制度はスタートした瞬間から、失敗する可能性がすごく高いものだと思います。
実際、グレード制度を止めて、MBOパターンの評価の見直しを進めたら、そっちの方が満足度が上がったんですね。期初目標を立てやすくする方法を考えたり、評価面談の改善をしたり。そういったことをした方が満足度が上がったので、グレード制度だけが解決策ではないというのはあるかなと思います。
学びとしては、「組織はここを目指すべき」みたいな、少し離れたところを目指そうとする”組織ビジョン駆動”は、失敗しやすいなと感じていて。今あるニーズに合わせてモノを作る”現場ニーズ駆動”は、失敗しにくいと思っています。どちらも失敗する可能性はあるんですけど、失敗のしやすさに違いがあるという感じですね。
失敗の先に、どのような組織の変遷があったか
──最後に、Chatworkとファインディの組織づくりにおいて、失敗の先にどのような変遷があったのかについて触れていければと思います。それでは門田さんからお願いします。
門田： 2014～2015年頃、Chatworkの開発組織は20名くらいでCTO直轄でした。この頃はインフラ専任がいなくて、障害対応に課題がありました。
2016～2019年には約30～40名になり、CTO1人では厳しくなってきたので、開発本部機能を追加。SREでインフラの安定化を図ったり、技術領域で組織を分けたりしました。組織の専門組織化によって起きたのは、技術要素での閉塞感です。サーバーサイドの人が「フロントやりたいです」と言えば、部署を異動しなければならず、気軽な技術チャレンジが難しくなっていました。
今の開発組織はデザイナーなどを入れて60名くらいで、職種での細分化はさらに進んでいます。それぞれにマネージャーを置いていて、1人のマネージャーが担当するメンバーが7～8名と結構多い。専門組織化の問題が進んでしまっているのと、深刻なマネージャー不足が起きています。マネージャーの負荷が高く、かつスケールにはマネージャーが必須なので、これ以上スケールさせることが難しいというのが、今抱えている問題です。
今後は、100人以上に耐えうる構造を考えています。フィーチャーチームやコンセプトチームなど機能分割チームの構造にして、そこからマイクロサービス化を目指します。それに伴って、組織を横断して技術を支援するアーキテクトチームを設置しようと思っています。そして、マネージャーを1チームずつに置いていると、深刻なマネージャー不足に立ち向かえないので、マネージメント機能を分離させる設計を考えています。
今とても人が足りなくて、いろんな職種の募集をしています。出していないものもあるので、カジュアルにお声掛けいただければ嬉しいです。あと、＠Chatwork_devという、Chatworkのデベロッパー向け広報アカウントがありまして、こちらでいろいろな投稿をしているので、ぜひ皆さんフォローしてもらえればと思います。
──ありがとうございます。続いて佐藤さんからもお願いします。
佐藤： 僕らは2016年に会社をスタートして、2017年に転職サービスの「Findy」、2018年に「Findy Freelance」をリリースしました。
今年2020年には「Findy Teams」のβ版をリリースしまして、来年に向けて正式版の公開をしています。僕が開発のマネジメントをしつつ、業務委託メンバーが6人くらい、エンジニアが2人という感じのプロジェクトです。
企画のメンバーもいるので、なかなか大規模なサービス開発なんですけど、まだまだ採用も追いついていなくて。サービス開発を一緒にやっていただける方を、絶賛募集しています。立ち上げ段階で、いろいろなしくじりができるチャンスなので、ぜひよろしければ（笑）。
──それではお時間となりましたので、最後に門田さんと佐藤さんから一言ずつコメントをお願いします。
門田： すごくたくさんの方にお集まりいただいて、しくじりってやっぱりコンテンツ力高いんだなと確認できました。まだChatworkではやらかしていないんですけど、もしあったらまた公表しますのでお待ちください（笑）。本日はありがとうございました。
佐藤： コメント欄もすごく盛り上げていただいて、皆さんいろいろと共感されるところがあるんだなと改めて感じました。これからもガンガン失敗していきたいと思っていますし、いかにその失敗を乗り越えていくかが大事だと思うので、どうやって乗り越えたかをまたご共有させていただけたらと思っています。本日は皆さんどうもありがとうございました。
──皆さま、本日はありがとうございました！
以上で本イベントは締めくくられました。ここまで読んでいただき、ありがとうございました！
＜イベント資料＞ Chatwork開発組織の変遷
次回イベントのご案内
日時：11/26(木)19時〜21時【エンジニア職種徹底分析〜PdM入門編〜】スマニューたいろーさん×クラシル奥原さん〜エンジニアからのキャリアチェンジ〜 findy.connpass.com
よろしければ、エンジニアの皆さまはFindyでご自身のスキル偏差値を測定してみてください。
[正社員の方]
ハイスキルなエンジニアのプレミアム転職サービス Findy
