クラウドワークス エンジニアブログ

日本最大級のクラウドソーシング「クラウドワークス」の開発の裏側をお届けするエンジニアブログ

2018年マネジメント振り返り

この記事は、クラウドワークス Advent Calendar 2018の10日目です。

こんにちは、プロダクトDiv. エンジニアリング部 部長の飯田です。
エンジニア組織のマネジメントは4月からやらせていただいているのですが、この記事ではこのマネジメント観点から激動の2018年を振り返ってみたいと思います。


私自身のマネジメント歴としては、4月当初は2チームのマネージャーとして始まり、その2ヶ月後にはエンジニア全体をみることになり現在に至ります。

4月から10月までの半年は、プロダクト全体の施策の攻めと守りのバランスの葛藤や、現場と経営陣の価値観の差異をどうやって埋めるのかということについて頭を悩ませてきた半年でした。

思うに、組織全体で長きにわたり分析・解決が難しかった課題としては「組織の意思決定プロセス」があげられると思っております。
現在所属しているプロダクトDivではスクラムでプロダクト開発を行なっています。チームはプロダクトオーナーを中心に意思決定を行い、自己組織化した状態で開発を進めます。

しかし、ときにプロダクトDivの外で決定した方針が入ってくるケースがあります。たとえば経営陣で進めるM&Aや事業提携、ジョイントベンチャーによる新規事業などです。
こういった急な方針転換は現場にハレーションを起こすことがほとんどです。チームで最優先だと考えていたバックログがなかったことになってしまうためです。
しかしながら、経営としても資金調達力や時価総額といった観点を元に打ちだしている施策であり会社・事業を伸ばしていくために考えた上での意思決定です。
さて、このような異なる視点で意思決定されたものをどのように開発していくべきでしょうか。

私がこのような課題に直面し、これまでの歴史的経緯も踏まえ考えた結論としては、現場のやり方をどれだけアジャイルにやっていても外部要因によるチームへの影響をコントロールしにいかない限りチームの自己組織化は達成されないということです。これを解決するためには、境界を超えて異なる価値観を融合させにいったり、対話を通してどちらかの価値観を選択しにいったりすることが必要になります。私はあらゆるチームの自己組織化を達成するために、会社としての意思決定をアジャイルに行っていくという転換をしていかない限り同じことの繰り返しになると感じていました。自分も現場も納得できてないものを頼み込んでやってもらうのは不器用な自分にはできませんでした。
これまでは組織の対立構造を前提に動いてきたこともあり、結果が出ないだけでなく退職など組織課題に直面してきました。しかしながらこの半年その状況を変えるべく様々な対話を通して全社としてアジャイルなやり方に可能性を見出すところまでたどり着きました。

今回はその過程をできる限りで記事にしたいと思います。 長くなりますがお付き合いいただければ幸いです。

半年前のエンジニア組織の課題

半年前の2018年4月がどういう時期にあたるかというと、2015年4月付近の第二創業期と言われている社員数を一気に拡大した時期から丸3年が経過する時期にあたります。

私も2015年5月に入社しまして、当時は新しいメンバーが多くチーム開発もやり始めたぐらいの時期でしたので今思うと相当カオスな状況だったように思います。 そこから3年が経ち、チーム開発も当たり前にやれるようになり、エンジニア組織としても力を貯めることができるようになりました。

しかしながら、私がマネージャーになる2018年4月前後は、古くからいたメンバーで技術面のリードやマネジメントでも長くやってきたメンバーが多く抜けてしまった時期で、組織としては非常につらい時期でした。

理由としては前述したような組織構造の問題も影響していたと思います。

この時期に新しく入って来てくれたメンバーもいましたが本当に不安だったと思います。 あるメンバーと飲みにいったときに「こんなに人が辞めるのが衝撃です。これが普通なんですか?」と聞かれたことがありました。ごめん、たぶん普通じゃない。

クラウドワークスのアプリケーションは7年も運用しており現在は非常に大きく複雑なRails一枚岩のアプリケーションとなっています。 人がやめても機能は減りませんので*1運用コストも新しい機能開発も急激にスループットが落ち、組織全体としてパフォーマンスもモチベーションも下がっていた状況でした。

この頃から何が問題なのかを継続的に考え始めましたが、マネージャーになってから最初の仕事は大局的な改善よりも目の前の細かい組織課題をいったんひたすら潰しにいくことでした。

エンジニア組織の立て直しへ

マネージャーになるまでは1チームのプロダクトオーナー(その前はエンジニア、スクラムマスター)をやっていたので、担当していたチームメンバーとはよくコミュニケーションを取っていたのですが、全体を見るとなると全員のことをもっと知る必要があります。

なのでこの時期はとにかく全員と話すということを短期間で実行しました。1週間の予定はほぼ1on1で埋まり、その中でこれまでのマネジメントの課題を言語化しながら、各メンバーとの信頼関係をどうやって作るかということを進めてきました。

しかしながら1on1をしていると本当に1on1だけになってしまいます。(マネージャーあるある)一定期間後は頻度を落として課題解決のために時間を使うようにしていきました。

小さな改善を積み重ねる

当時の観点では、退職によって組織の持続性が失われてしまうという漠然とした大きな問題があり、それに紐づいて細かな問題が芋づる式に起きる構造だと認識していました。したがって、ここの問題への対症療法を繰り返していきました。

チームビルディングのような単純なチーム内の課題解決の支援だったり、障害対応のようなチームを超えた枠組みの整備だったり、はたまたフルリモート・フルフレックス制度*2*3のような環境整備だったり、全力採用*4したり。

当時はあらゆる観点からある意味力技で組織をつなぎとめる動きをしていました。 しかし自分自身のキャパシティも限界はあるのでどこかでこのマネジメント自体を持続可能にする転換が必要だと感じていました。

マネージャーでエンジニアリング組織論への招待の読書会を開催した

マネージャーになる前から表面的な課題感についてはある程度こうしたらいいという感覚があったためそれを試していくだけでも改善は一定進んでいったのですが、マネジメントに関しての体系的な知見は持っていなかったことと、マネージャーのチームとしても改めて言語化してみることでナレッジの蓄積になる可能性があるということから、「エンジニアリング組織論への招待」の読書会を開催しました。

読書会は1時間で前半は読みながら気になったキーワードを付箋に書き出し、後半で順番に発表しながら議論を行い考えを深めていく形式で行いました。 マネージャーチームとしても課題認識をすり合わせ、共通言語を作っていくことがまず出発地点になるので、読書会でいろいろな意見が出て思考が深まりました。

この本は本当に共感するところが多く、我々の抱えていた問題をうまく言語化してくれたなぁと感じました。マネジメントする人でなくても組織の状態を計るのに役に立つと思います。おすすめです。*5

f:id:yo-iida:20181210123221p:plain:w600
初期の頃の付箋。議論が白熱してなかなか付箋が出ないことが多々ありました。

エンゲージメントスコアによる組織状態の可視化と全社でのマネジメントノウハウの集約

さて、少し話は変わりますが、弊社はリンクアンドモチベーション社の提供するモチベーションクラウドによってクオーターごとにエンゲージメントスコアを算出しております。

ちょうどマネージャーになりたての時に担当していたチームはスコアが高かったため、経営陣と当時スコアの高かったチームのマネージャーが集まって何がうまくいったのかを言語化する取り組みがあり、そこに呼ばれました。

この時私はアジャイルコミュニティでいただいた知見を元に支援型のマネジメントを行ってきたのですが、偶然にも開発以外のマネージャーもうまくやっているチームは似た価値観を持ってマネジメントを実践してきたことがわかってきました。

これまで営業組織も含めた全社的なマネジメントの価値観はどちらかといえば目標必達型の率先垂範のリーダーシップが主流のように見えていましたが、実はふたをあけてみるとうまくいっているチームはサーバントリーダーの考えに近い実態が見えてきたのです。

この議論の流れから、チームの持っている課題感と経営陣の持っている方向性がすり合っていないまま大きな意思決定をしたが故にうまくいかなかったという過去の反省を踏まえ、少しずつそういったプロセスを良い方向に持っていけるのではないかという考えが私の中で大きくなりました。

1on1から代表が認定スクラムマスター研修に参加することになった

代表の吉田(以下吉田さん)とは不定期に1on1を開催しています。

ある日の吉田さん1on1でマネジメントについていろいろと話している中で以下のような会話がありました。

吉田さん「マネジメントの価値観ってどこからきてる?」

飯田「スクラムですね」

吉田さん「それってどうやって学んだの?」

飯田「もともとはエンジニア組織の中では実践はされていて、2018年からは自分から外に出てインプットの機会を増やしました。1月にRSGTにいって、3月に認定スクラムマスター研修にいって、それまでなんとなくやっていたものを改めて体系的な知見をインプットして最近ようやくちゃんと馴染んで来たかんじですかね」

吉田さん「なるほど、それってエンジニアじゃなくても受ける価値あるのかな?」(!?)

飯田「あると思います。現場としても価値観について興味持ってもらえて、共通言語があるというのはうれしく思いますし。」(おおおお)

吉田さん「そうなんだ、じゃあ行ってみようかな」(!?!?!?!?)

飯田「まじっすか!」(まじかまじか)

ということで、何気ない1on1の会話の中から社長の認定スクラムマスター研修受講が決まりました。

正直言うとこの時はまだ信じられなくて後日本当に行ったのを知って結構感動しましたw


f:id:yo-iida:20181208025926p:plain
1on1後slackでマネージャー陣に共有したところ。全員何が起こったのかわからない様子。

その後の吉田さんの変化

実際研修の内容をどのように思われるかも気になっていたのですが、有意義な研修であったとおっしゃっていたのでほっとした記憶があります。

その後は朝会などでも「スクラムの考え方では〜で、、」といった発言が増えたことで、すくなくとも価値のあるものとして捉えてくれていると感じました。

こういったアプローチは「形だけではなんとも、、」というような懐疑的な意見もあるだろうなとは思いつつ、私としては現場がどういった考えでどういったプロセスで仕事しているか知らないところから、一通り体系的な知識を持っていて共通言語でコミュニケーションができるようになったことは非常に大きなステップだと考えています。

たまに言葉の使われ方でちょっと違うかも?となることはあったりしますが、そんなことはどうでもいいのです。私も間違えます。大事なことは自分たちの根底にある価値観に同じように価値を見出してくれている状態なのです。

そのような観点でこの取り組みはよかったなぁと思うと同時に吉田さんのフットワークの軽さに素直にすごいなと感じたエピソードでした。

アジャイルな意思決定に向けて

もともとの課題感は、現場でのやるべきことの優先順位と経営からみたときのやるべきことの優先順位がすり合っていないことによる現場への負荷やモチベーションの影響でした。

私はその意思決定もプロダクトバックログのように、同じ基準の上で優先順位を議論してイテレーションを回していくことで現場のやりたいことと経営のやりたいことが納得した上で実行していけるのではないかという仮説を持っています。

しかし、そのレイヤーで考えた時、優先順位の議論に入ってくるのはプロダクト開発の関心ごとだけではありません。経営企画やビズデブ(営業主体でサービス開発をする部門)やコーポレート(経理、法務、総務、人事などの管理部門)の関心ごとも同じ基準の上で優先順位を議論する必要があります。

となると、いよいよ全社としてアジャイルなやり方に振ってみることを検討することになるわけです。

今期スローガン「Be Agile」とマネージャー研修そして活動の広まり

クラウドワークスは今期全社で「Be Agile」というスローガンを掲げています。開発だけじゃないですよ。全社です。

このスローガン自体も実は吉田さん1on1の中で「今期は"アジャイルにやろう"とかがいいんじゃないですかね?」と提案したところから議論が始まりました。

当初は開発の文脈の言葉を全社のスローガンとして置くことに懸念もたくさんありました。言葉から入ることで価値観の押し付けにならないかとか、言葉だけが先行して中身が伴わず結果としてもよくわからない状態になってしまうのではないかとか。

しかしながら発表後はよくわからないところはあるもののいったん乗っかってやってみようという反応が多く、アジャイルの理解を支援していく活動をしっかりやっていこうと決意しました。

「ユーザーに向き合い、本質的に価値の高いものから素早く届けていく」といった価値観は開発関係なく経営企画でもビズデブでもコーポレートでも一緒だと思うんですよね。自分たちの仕事の先にそのサービスを受ける人がいるので、そのやり方をどんどんよりよいものにしていくという考えは全社的にもベースにしてもよいと確信していました。

その文脈でまずはクォーターに一度開催しているマネージャー研修の中のコンテンツとしてアジャイルの説明と、各マネージャーがアジャイルについてチームメンバーと議論をしていける土壌を作るためのワークショップを開催しました。

f:id:yo-iida:20181208034431j:plain:w260 f:id:yo-iida:20181208033628j:plain:w260 f:id:yo-iida:20181208033609j:plain:w260

先日一部で話題になった吉田さんの以下の記事もマネージャー研修やそれまでの議論を経て言語化されたものです。

マネジメントにおける「当事者意識を持て」という言葉の死 | クラウドワークス社長 吉田 浩一郎のブログ

こちらの記事もいろんな反響がありましたが、私から言えば、融和が進んだ大きな一歩が言語化されたということに尽きると思っています。 組織の意思決定プロセスにおいてこれまでなかなか歩み寄る対話ができていなかった。そこに同じ言葉で対話できる場ができたのだからこれは大きなことだと言えるわけです。


現在は全社員向けにも相談会形式でアジャイルの実践を継続的に取り組めるようにする支援を開催しています。

この取り組みは現在理事として参画している一般社団法人アジャイルチームを支える会で開催している相談会のイベントを社内に移植したものです。 準備コストが少ないので一人でも継続的に開催できることがメリットです。

それ以降も、各部署単位での研修・ワークショップが行われたり、少しずつ試行錯誤の広まりを見せています。

結局エンジニア組織としてはどうなったのか、そして次のチャレンジ

現場の課題感から全社を巻き込んだ話に発展しましたが、結局現場としてはどうなったのか?

でいうと、残念ながらまだまだ課題だらけと考えています。

納得できる可能性の高い議論の土台は作ったが、実際の意思決定の質やプロセスにはまだまだ課題があるし、課題をもっと深掘りしていくことで当初考えていたよりももっと複雑な問題に変化するかもしれません。

具体的には直近の新規の取り組みに関しては一方的なコミュニケーションではなく双方で見えているものをベースに何を優先するのかの議論ができました。しかし、そのような議論が当たり前にできるようになるには継続的なコミュニケーションが必要です。

課題に正しく向き合い、正しく解決策を選んで実行していくことが重要だと考えています。

よかった変化としてはアジャイルスクラムに関する学習にお金を使いやすくなりました。
今の流れでGM, デザイナーのマネージャーが認定スクラムマスター研修を、プロダクトオーナー4名が認定スクラムプロダクトオーナー研修を受講しました。来年のRSGT2019のスポンサー費用も取ることができました。
これまで技術的な投資は比較的やりやすかったですが、こういった研修などはあまり前例がなかったため新しい事例となってよかったです。人が増えると議論が巻き起こってさらに学習の質が高まるのでチビチビ使わずにどーんといったほうがいいですね。

ここまでいろいろなことをやってきたことを振り返ってみましたが、俯瞰してみるとミクロな課題とマクロな課題にフォーカスしていて中間の課題にあまり打ち手を打てていませんでした。
チームを超えたエンジニアの戦略や文化をどうやって作っていくかとかそういうものですね。
今後はいったん落ち着いてそういったエンジニアの文化のリビルドにパワーをかけていくことになりそうです。

そのためにはマネージャー層を厚くしていくことが不可欠だと考えています。一緒に組織課題を楽しんで乗り越えていける人が増えるとよいなと思っています。

最近はエンジニアリングマネージャー界隈も盛り上がってきていますが、コードだけではないエンジニアリングの仕事も面白いですよ。 組織の持続性についてはまた別の観点からEngineering Manager Advent Calendar 2018で記事を書いてみようと思っていますのでご興味あれば見てみてください。

qiita.com

ではでは、私からはこのへんで。

明日は@yusuke_andoによる「マーケターがSQLを使ってデータ分析ができることの3つの効能」です。

一緒に組織をよりよくしてくれる人を募集しています

www.wantedly.com

© 2016 CrowdWorks, Inc., All rights reserved.