本記事は株式会社Works Human Intelligenceのアドベントカレンダー、「Develop fun!」を体現する Works Human Intelligence #2の24日目になります。
弊社ではアドベントカレンダーを2枚実施しております。1枚目もぜひご覧ください！
本日はクリスマスイブということで、(特に社内にとって)スペシャルな記事をお送りいたします！
1枚目のクリスマスイブ、クリスマスは弊社のSREチームを代表する2名が記事を担当しています。
イブを担当する加藤( @FumiakiKato )は、弊社のnote記事でも紹介されているように、2020 APN AWS Top Engineersを受賞したAWSエンジニアです。
また、クリスマスを担当する新村( @Hokuto-Niimura )はSREチームの責任者であり、最近ではデブサミでも公演を行うなど、対外発信も積極的に行っています。
アドカレ2枚目でも1枚目に負けないクリスマスを！とお願いして回った祈りを捧げた結果、これまたワークスHIを代表する2名に、記事に携わっていただけることになりました！
そのうちの一名が、弊社のテックリード部隊を束ねる金子です。
金子はワークスHIの前身であるWorks Applicationsに2002年に入社後、数年間プロダクト開発に従事した後は、技術研究や先進技術を用いたツール開発などの、R&Dに分類される組織の立ち上げから携わり、リーダーとして組織を大きくしていきました。分社化ののち、ワークスHIでは再び1からテックリード部隊の立ち上げを行い、現在では6グループ、31人の部署を束ねるテックリード部門の長を務めています。
そんな金子は マネージャーの仕事は如何にメンバー一人ひとりの主体性を引き出すかである と語ります。本記事では、その信念のもと、金子がこれまでどのようにR&D組織を創ってきたのか、またこれからテックリード組織をどのように変革しようとしているかについてのインタビューの様子をお届けします。
0から作り、大きく育てる
金子さんが最初に技術系チームに所属されたのはいつのことでしょうか。
自分が入社したのが2000年のことで、そのときには技術に特化したチーム、というのは存在していなかった。
当時のCEOから技術系の組織を作りたいという話があり、新しい組織を立ち上げることとなった。この組織は20名位で共通基盤を受け持ちながら、全社的な技術追求を目的とするもの。
この時の組織が技術基盤開発グループで、今日まで存在する技術チームのルーツとなったものだ。
技術基盤開発グループではどのようなことをされていたのでしょうか。
グループにおける使命としては、プロダクトを横断して、必要な技術研究、技術追求を行うことが大きなテーマの一つではあったが、発足から数年間は製品の新バージョンの安定化に注力していた。
安定化が一段落した頃、技術基盤開発グループは発足本来のテーマを見つめ直すこととなった。このまま製品の共通基盤も持っている、という状態だといつまでも技術追求に集中することはできないだろう、という判断を行いこの役割を切り離すことにした。
この切り離しにより新たに技術領域を担う新組織が誕生した。製品評価系グループと、技術的な問題解決や技術研究を担うグループがあり、僕は後者の担当になった。
最初は6人くらいの組織であったが、その後だんだんと人数が増えていき、40人くらいの組織にまで成長した。異動によって増えた人数もあったが、技術的なバックボーンを持つ新卒/中途人材を専門職として採用することが始まったことも大きかった。
その組織では0から自分たちで仕事を作っていったのでしょうか。それとも何か上から託されたミッションがあったのでしょうか。
一部やってくれ、と依頼された仕事もあったが、大半の仕事は自分たちで見つけていった。新卒エンジニア教育コンテンツの作成に取り組んだり、COMPANYのバージョンアップのためのツール作成を行ったり、AWSが始まったばかりのときにCOMPANYをEC2インスタンス上で動かす取り組みをいち早く行ったりした。
当時はAWSコンソールの使い方が難しかったこともあり、AWSインスタンスの操作/管理を行えるWebアプリケーションを自分たちで作ったりしていた。この取組も後にCCMSという独立したサービスとして別部署で展開することになった。
振り返ってみると、__0から作った仕事は、多くの小さなチャレンジにまず取り組んでみて、その中でうまくいきそうなものを見極め、そこに注力する、というやり方で生み出してきた__ように思う。
会社として提供するサービスを改善する取り組みが多かったように思いますが、技術研究的なことにも取り組んでいたのでしょうか。
先に言った取り組みに関しても、意識していたこととしては新技術や言語、フレームワークを取り入れてみる、ということだ。
先進的なフレームワークなどは、新しい価値を提供してくれる反面、フレームワーク自体がまだ不安定だったり、不具合が残っていたり、ネットや書籍上に蓄積されたノウハウが少なかったりする。そのためいきなりメインのプロダクトで採用してみるのはリスクを伴う。
そこで、単に技術研究をするということだけでなく、社内で使うツールやWebアプリケーションを実際に作り、その際に新技術を使ってみる、といった取り組みを行った。それによりツールやWebアプリケーションによって価値を提供しつつ、作る過程で新技術に対するノウハウを蓄積する、ということをやっていた。知見はドキュメント化したり、問い合わせ窓口を設けたりして、プロダクト側で新技術を使いたいときにナレッジ共有できるようにした。
COMPANYの後継となる新製品の開発開始時には、分散DBシステムCassandraの構築/運用ノウハウの研究や、自然言語処理の基礎研究を専門チームを作って取り組んだりしてきた。
クリエイティブな価値創出をスピーディに実現する組織とは
組織としてのアウトプットの大半は自分たちで見つけた仕事が元になっているということですが「組織としてこの仕事に取り組んでみよう」という意思決定はどのように行っていたのでしょうか
扱っていたテーマは、大半がメンバーからの提案が元になったものだった。最初に独立したときの6人は、元々プロダクト開発の仕事の中で技術的なWillや課題意識を持っているメンバーが中心だったのでアイデアに困ることはなかった。
新規配属者にはCOMPANYというプロダクトそのものや、プロダクト開発部署側の課題を理解してもらうため、最初はプロダクト開発者と協業する仕事を依頼することにしていた。
例えば、技術基盤のとあるチームがバッチ処理をマルチスレッドで処理することができるフレームワークを開発していた。新規配属者にはプロダクトの処理コードをこのフレームワークを利用した形に書き換えることをやってもらったりした。他に依頼したこととしては、実際にユーザー先の環境で生じるパフォーマンス問題やミドルウェア、ネットワーク系に関わる問題解決等があったと思う。
プロダクト開発部署と関わってもらうことで、COMPANY自体が抱える課題や開発組織、開発プロセスや開発ツールについての問題点や解決策を自分たちの目と頭で考えてもらい、提案してもらう流れを作れたのではないかと考えている。
組織の人数が増え、扱うテーマが増えることでマネジメントの難易度は上がるようにも思いますが……
扱うテーマが増えるにつれ、チームは別れたものの、最初のうちは人数が多くても全体で週1回はMTGを行うなどの取り組みにより、一つのフラットなチームという意識を持てるようにしていた。
MTGではマネージャー、メンバー等の立場に関係なく自由闊達に意見交換をする。新しいチャレンジをするときは組織図上のチームの垣根を超えたプロジェクトを作ってそこにやりたい人が参加する、という形をとったりしていた。
厳密に組織が決まっている場合、チーム外に質問するコストが高いというようなこともあるだろう。ワークスHIとしてはそういう組織ではなく、フラットなコミュニケーションを推奨してきたが、テックリード部門としては文化作り、文化の浸透を特に強く意識していた。
振り返ってみると、テックリード部門として数多くのチャレンジをしてきたが、結果に至るチャレンジを多数出せた理由は一つ。それより遥かに多くのチャレンジを行い、多くのPDCAを回したからに他ならない。
なるほど。それだけPDCAを高速で回せた理由のひとつがフラットな組織、フラットな関係ということでしょうか
上意下達型の組織にはもちろんメリットもあるが、0から1を作る、0が1になりうるかを見極めるケースに置いては全くフィットしない。起業でよく言われることとして、100個アイデアを出してやっと1つ成功するアイデアにたどり着けるか、というのもある。
新しく取り組みを行ったり、そのために人や予算を動かす場合には上層部に対して費用対効果を定量的に提示する必要があると思うが、当時は意外とそうではなかった。特に同時に複数のメリットを追求しうるケースにおいては定性的なメリットの定義を持ってチャレンジが認められることが多かった。そもそも創造的なチャレンジにおいては、「やってみないと分からない」ケースが殆ど であり、CEOにもそれを理解してもらっていた。
しかし、もちろん「うちの部署は短期的にも長期的にもどれだけ事業への貢献が見込めるか、数字で出すことは全くできません」では流石に許されない。そこで、予算や人月のn%を定量的な効果が出せる仕事に回すので、残りを創造的な取り組みへ当てたい、というような交渉を上層部と行っていた。フラットな組織と言ったが、自分のマネージャーとしての役割として、「メンバーのこれをやりたい、という提起を実行できる環境をいかに作るか、そのために必要なリソースをいかに融通するか」 を自らに課していたし、今でも意識している。
フラットな組織づくりをベースに会社をより良くしていく
テックリードとして、今後どのような点に注力していこうと考えていますか？
実はすでに研究開発のようなことを始めている。一例ではChatBotのチームでGCPやAzureが提供する機械学習の活用の研究を始めているとかね。テックリードとしてはこうした研究開発的な取り組みも進めたいと思っているが、もう一つ、プロダクト開発において共通で必要となる機能、基盤づくりを進めたい、と考えている。
これは認証のような普遍的なものだけではなく、我々の製品においてコアといえる従業員にまつわる情報や、各種条件設定を各プロダクト、サブシステムが開発する際に一から設計したり、連携したりといったことをせずに、利用できるもののイメージ。
ただ、これらを開発するに当たっては、基盤側の観点だけで開発を進めるのではなく、プロダクト開発側が使いやすいものにすることを意識して進めて行きたいと思っている。
かつての新製品開発において、各プロダクトで共通で利用するモジュールに関しては基盤チーム側で一手に引き受けることで、プロダクト開発チーム側は自分たちがより価値を出せる機能開発に集中してもらおう、という体制を整えようとした。コンセプトとしては良いのだが、この取り組みは結局うまく行かなかった。失敗の原因は複数あるが、最大の原因は別々に作ることによる弊害にあったと考えている。
使われる側が使う側のニーズをすべて想定しようとしたり、使う側が使われる側にいろいろな期待をしたりしても、この両者を別々に開発してしまうと、そこには様々な齟齬が生じていき、両者の溝は深まっていく。
こうした失敗を防ぐには、出来るだけ両者の組織的、人的な距離を縮め、フラットな状態にする。出来れば一緒に作るようにするくらいがよいのではないか、と考えている。
実際には難しいかもしれないが、最終的にはプロダクト開発チーム各々が、ある業務機能、ある基盤機能の開発の双方を受け持つ、というような体制が作れないか、というイメージを持っている。
最後に社内、社外のエンジニアに向けてのメッセージをお願いできますか？
自分の行動を最終的に決めるときには、それが自分にとって良いことかどうか、で判断すれば良いと思っている。
だが、その選択が最終的に自分の状況を本当により良くするのかを判断するのはなかなか難しい。そこで僕は、自分の選択が自分の会社であったり、社会のためになるのかという軸で判断することにしている。
属している会社や社会がより良くなれば共同体のクオリティが上がるわけで、回り回って自分のためになるだろう、と信じて今までやってきたし、実際にその判断基準で概ね自分にとって良い結果を得られてきたと思う。
世の中のためというのは綺麗ごとではなくて、そういうところにピンを置いたほうが自分の状況を良くする、という観点からも間違いはないだろう、ということ。
分かりづらいかもしれないが、自分の中ではなんとなくそうだろうと思っている。
最後に
最後までお読みいただき、ありがとうございました！
より変化が激しくなるこれからの時代こそ、__「0から組織を立ち上げ、拡大させる」ためには、「PDCAを高速で回し大量の仮説をどんどん検証していく」「中でもうまくいきそうな仮説を育てる。育てるために必要なのはフラットな組織。」「組織の規模がある程度大きくなったらチームは必要だが、組織全体はフラットな関係性を維持する」__といった意識が必要かもしれません。