社内横断の技術組織を終わらせました
内容がネガティブに取られそうで、公式なところに書くべきではないので個人ブログで書きます。
この記事は、公式なブログで僕が書いた「社内横断の技術組織をはじめました」という記事へのアンサーブログになります。
※元の記事は探せば出てきそうだし、個人的なブログと紐付けるべきではないのであえて出しません。
特定の誰かを陥れる目的ではなく、完全に個人の責任として、始めたものを終わらせてしまったことへの事の顛末を記録する目的で書きます。
はじめに
去年(2016年)の年末ぐらいに、社内にある幾つかの事業部を横断する技術組織を立ち上げました。
そして、3ヶ月ほど運用した今年(2017年)の3月末、この組織は解散となりました。
この記事では3ヶ月のあいだに実施した内容となぜ解散に至ったのかを書きたいと思います。
始めた理由
僕の所属している会社には、大きな事業部が3つあります。 1事業部の技術責任者として数年働いて、幾つかの課題を感じていました。
CTOの不在
幾つか新規事業が立ち上がったりしていて、既存事業からエンジニアを異動させたりする際に、各組織との調整が難しく、毎度アサインに苦戦していました。 技術ボードと呼ばれる各事業部の技術責任者の集まりはありましたが、全員が兼任なのもあってワークしづらく、推進力にも課題がありました。
この頃の僕はCTO的な、会社全体の利益を第一に考え、英断できる存在が居れば解決できるのではないかと感じていました。
品質面に対するレビュー不足
新規事業で初回リリース時の品質を起因にした問題が起き、計画がかなり遅れる事態が発生していました。 既存事業でも大きなサービス障害や運用コスト高騰が発生していて、こちらも解決に時間がかかっていました。
僕の方では、新規へは初期段階設計レビューやリリース前のレビュー、既存へは運用に対してのレビューを実施することで解決できると感じていました。
技術広報の不足
2016年の頭から9月ぐらいまで、技術広報を勝手にサブミッションとして設定し、更新が2年以上止まっていたエンジニアブログを復活させてみたり、外部との勉強会の共催や社内のエンジニアの登壇をお願いしたりしていました。
理由としては自分の事業部にいるエンジニアの雰囲気を変えたかったことと、苦戦していたエンジニア採用につなげることを目的としていました。
やってみて、自分の事業部だけ盛り上げる必要は無く、会社全体での技術広報を行うほうが一番効率が良いのではないか、と感じていました。
ですが、自分以外の事業部を含め勝手に広報するのは難しく、なんらかの「理由」が必要ではないかとも感じていました。
そんな中、2016年の年末頃、会社で社員から全社施策を経営陣に提案するイベントが有り、僕はそこで「CTOの役割を内包する事業部横断の技術組織の設立」を提案しました。 具体的には、僕が技術横断組織の専任として半ばCTO的な役割を果たすというものです。
提案は承認され、品質レビューや技術広報、各事業部に対する組織バランスの観点から、各事業部から特定の技術分野に強いメンバーに何人か入ってもらい、2016年の年末に横断技術組織をスタートさせました。
それぞれの施策の結果
具体的にやったのは、以下の内容です。
- 新規プロダクトに対する設計レビュー
- 既存プロダクトに対する運用レビュー
- 新規と既存プロダクトの状況を経営陣へ毎月レポート
- 新規技術の導入検証・サポート
- 全社的な技術広報
特に自分が所属していなかった事業部について、状況の把握や信頼を得るために座席を近くに移したり、意識的にサポートを厚くするなどを行いました。
結果どうだったのかを幾つか書いていきます。
時間がかかってみんなストレスが溜まる新規レビュー
新規プロダクトのレビューは、初期設計時に要件レベルからヒアリングを行い、ビジネスモデルの理解や専門的なドメインの理解まで含めて行いました。 ある程度は意味のあるものにはなったとは思いますが、当然時間はかかりました。
新規プロダクトのメンバーに求められているのはスピードであり、早めに着手しながら不確定要素を詰めていく必要があります。 時間をかけて品質を上げる方法を取っていた僕とは相反するものだったと思います。
また、リリース前にもレビューを実施し、運用に耐えられるかどうか判定をして、NGな場合はリリースしてはいけないという縛りを設けていましたが、 これも新規プロダクトのメンバーにとっては、「一発で通らないとスケジュールを脅かす存在」と認識されてしまい、 レビュー判定の場は、本来の運用時の問題点を予め潰す役割は薄く、指摘を回避しレビューが通るように対応されていたと感じています。
当たり障りの無いことしか表現できない運用レビュー
既存プロダクトの運用レビューでは、サービスダウンやシステムトラブルの件数、1stビューのレスポンスタイム、システムコストをKPIとして算出し、それぞれのKPIに対しての改善策をレビューするという方式を取っていました。
これらの情報は僕でまとめて役員などの経営層へレポートすることとなっていて、レポートするフォーマットをそのまま使用して各プロダクトへのヒアリングとレビューを行っていました。
技術的負債やわかりやすい問題であれば判断を間違うことも無いですが、技術的に困難だったり対応に時間のかかる問題に対して僕が誤った報告をした場合は、プロダクトの計画に大きな影響を与えてしまうため、
レビューの場ではプロダクトのメンバーも非常にセンシティブになっていたと感じています。
僕もその雰囲気を感じつつ正しい表現をして報告をする必要があるため、毎回ヒアリングとレビューはお互いにストレスがかなりかかっていたのを覚えています。
本来レポートする理由としては、ブラックボックスになりがちな技術に起因するサービスの問題に対して、第三者レビューを行い妥当性を説明することなのですが、 最終的に、プロダクトサイドはミスリードさせないため、僕はストレスを回避するために細かい表現を控えるようにし、当り障りのないような表現ばかりになっていました。
兼任状態が続き、進まない新規技術検証
当初から既存プロダクトの1つで突発的なアクセス負荷によるサービスダウンが何度かあり、その解消のため継続的な負荷試験環境の整備とその運用フローの整備を担当することになりました。
運用はプロダクトで行う想定だったため、運用負荷を減らすためにSaaSの利用など念頭においていました。 当然、SaaSもいくつかあるためそれぞれ検証を行いましたが、その間にもサービスダウンは発生していて、「早く解決して欲しい」というプロダクトサイドの思いと非常にズレたことをしてしまっていたと思います。
また、以前の業務は全て引継ぎ専任化はしていたものの、まれに見るトラブル頻発でサポートにまわることが多く、ほぼ兼任に近い状態になっていたため、検証と導入に対しての時間が全く取れないようになってしまっていました。
結果、導入途中のままプロダクトへ引き継ぎになり、期待された成果を残すことはできませんでした。
別途、サイトパフォーマンス計測のSpeedCurveの導入も行いましたが、プロダクト側での活用が難しく費用対効果の面で見送りになっています。 こちらも僕の方で運用フローをプロダクトサイドと調整した上で軌道に載せられなかったことが要因かなと思います。
やる必要の薄い「全社」広報
当初、クックパッドやはてなのような、技術に強いイメージを会社に対して付けていくことを目標として、会社名を背負った勉強会主催や技術カンファレンスへのブース出展などの技術広報を行いました。
僕の会社は事業部がいくつもあり、それぞれのビジネスモデルが全然違いました。「なんでもある」ことを僕は広報の武器になると思い込んでいましたが、
とある技術カンファレンスでブース出展し、1日中呼び込みと応対をしていた際、
広報するものが複数あるとかえって印象に残らない事、
特定のプロダクトに絞った広報をする場合それはもはや僕ではなくプロダクトサイドで広報すれば良いという事を痛感しました。
むやみやたらに会社名を背負っても意味はなく、全社広報をやる必要性に意味が無いことがわかりました。
終わった理由
ここからは組織が終わるまでの部分について書きます。
成果が出せなくて、そもそも証明出来ないかもしれない
当初の設立時から、施策を行わなかったとしても上手くいったのではないか？など、横断組織の成果をどう証明するか、が重い課題としてありました。
そんな中、前で書いたようにレビューなどに始まる施策が上手く行かない状態が続いたため、 横断組織の施策によるハッキリとした成果は出ない、もしくはかなり証明しにくいのではないかと感じはじめました
問題解決は組織じゃなくても出来ると気がついた
これもやってみてわかったことですが、個々の事業部は独立して成立しているので、まずは自分たちで解決しようとする気持ちが存在します。 それらを無視して、いきなり横断組織が介入することは自治権への干渉にあたり、反感をまず招きます。
要は自分たちで実行した先、困ったときに相談できるモノがあればよいのですが、
それらは権限を持った「組織」というよりは、ゆるい横のつながりである「コミュニティ」が最適なのかなと感じます。
特定の技術要素に強い人や興味を持つ人をゆるくつなげる施策さえ成功することができれば、問題は解決出来ると思っています。
「なにをやっているのかわからない」と染み付いた組織イメージ
設立時、やりたいことの趣旨の説明を全社に対してと個別組織に対して実施しました。 ただ、全体への概念レベルの説明では「実際に何をするのか、してくれるのかわからない」というイメージしか保たれませんでした。
そんな中、全体に伝えることができそうな明確な成果も出ない状態が続き、次第に「あの組織が何をやっているのかわからない」という声が聞こえるようになりました。 横断組織には兼務で所属し、レビューなどにかなり時間を割いてくれるメンバーばかりで、僕から全体に対して成果をアピール出来ない状態を非常に申し訳ない気持ちで過ごしていました。
技術広報の勉強会などを強化していたため、成果が出ない中で僕がソーシャルシェアなど目立つことばかりやっているよう見えたことも、ネガティブに映ったのではないかなとも思います。
精神的な負荷と地に落ちた信頼
これが一番大きな理由です。
専任として入っていながら、明確な成果を出せそうに無く、まわりのイメージも良くない状態のまま続けているのは、かなり精神的な負担として僕の中に蓄積していました。 次第に躁とか鬱とかみたいな状態が現れるようになって、周りに対して悪影響を及ぼすほどになっていたと、振り返ってそう思います。
今回の組織は「周りの信頼と理解」が何より重要なファクターだと思いますが、最終的に連鎖的に問題(※)を引き起こしたため、
いちばん大事な信頼が地に落ちるレベルまで落ちていきました。
※感情的な対応とか、非論理的な対応とか。
終わり方は、役員からのストップです。
ストップをかけてくれなければ、今もズルズル不毛に続けていたかもしれません。
最後に
組織は解散しましたが、経営層とのコミュニケーションは残っていて、技術周りに関して「相談」という形で適宜話をしたりされたりしています。 おそらく色々な面を配慮して、このような形を取ってくれているのだと思いますが、だいぶ気持ちも楽でありがたく思っています。
僕は元々の事業部の仕事に戻ることになりました。 3ヶ月間の成果は出なかったですが、確実に経験は自分の身に付いていて、3ヶ月前とは視点も意識も変わったようには思います。
失った信頼については少しづつでも行動でまた積み上げていけばいいかなと思っています。
僕と同じように、横断組織を作り、問題を解決しようと考える人は多いと思います。
僕の知見が世の中の誰かの助けになればと思い、記録します。
