マネジメントもHackできる
株式会社うるるは、40万人以上のクラウドワーカーを抱えるクラウドソーシング事業「shufti（シュフティ）」のプラットフォームを活用しながら、さまざまなサービスを展開している。中でも、萩原氏が所属するNJSS事業部では、「入札情報速報サービス NJSS（エヌジェス）」を提供している。NJSSは、官公庁や自治体から公示される年間100万件の入札情報を人力で収集しており、2020年1月現在で1470万件の公示情報と1160万件の落札情報を保有している。
NJSS事業部でエンジニアリングチームを率いる萩原氏は、「エンジニアたるもの組織づくりもエンジニアリングしよう」と、マネジメント業務で悩みを抱えるエンジニアたちに語りかける。
萩原氏がこの考えに至った原点には、萩原氏がうるるに入社した2013年頃に流行していたグロースハックがあるという。
当時の上司が「エンジニアもサービスの成長を考えて、施策企画から検証まで一緒にやろう」といった考えの持ち主であり、萩原氏は「サービスにおける課題の仮説を立てる」「仮説を検証するための施策を立案する」「施策を自ら実行して仕組みをつくる」「施策を振り返る」といった一連の流れを経験することができた。このグロースハックを実践する中で、「自らがつくった仕組みを通じて、ユーザーに影響を与えることができる実感を得られた」と萩原氏は振り返る。
その後、初めてのマネジメント業務に就くことになり、何ともいいにくいしんどさを感じていた萩原氏は、「マネジメントがうまくいかない」とメンターに相談した。すると、そのメンターは、現状をヒアリングした上で、「あなたなら、どこにどんなパッチを当てますか？」と聞いてきたのだ。最初は意味がわからなかったという萩原氏だが、確かによく考えてみると、不具合に対してパッチを当てると考えればマネジメントもエンジニア業務と同じように考えることができ、結果的にHackできるということがわかったのである。
ここでいうHackとは、一般的に想起されるような「ちょっとした小技を用いる」ことではない。「構造のスキマを知り、それを埋める」ことが萩原氏の語る、Hackの意味するところだ。
なぜマネジメント業務はしんどいのか
そもそも、なぜマネジメント業務は難しいのだろうか。その理由をひもとくために、萩原氏は次のスライドを提示した。
これは「エンジニアとしての開発業務」と「マネージャーとしてのマネジメント業務」を、「仕事の対象」「不具合の発見と修正」「仕事による成果」の観点で比較したものだ。ここからマネジメント業務をしんどいと感じる要因として、次の3つが見えてきたそうだ。
- 不確実性の高いもの（＝人＋プロジェクトの概念）を相手にするので、不安が大きい。
- 課題の抽象度が高く、本質を捉えたり、認識を合わせたりするのが難しい。
- 手を動かせばものができていた環境とは違い、仕事の成果がわかりにくい。
このマネジメント業務特有のしんどさを回避するために、先に紹介した「マネジメントをHackする」考え方が有用なのだ。
実際のマネジメントをHackするステップは、「理解」→「設計」→「実装」の順に進めていく。開発業務でプログラムやアーキテクチャを理解するのと同様に、まずは見えないものを可視化して、構造を理解するところから始める。次に、改修すべき箇所を見つけ出し、そこに変更のプログラムを実装するように、スキマに入り込むための施策を設計し、実施していく。
Hackの楽しさをマネジメントでも感じよう
萩原氏は「理解」→「設計」→「実装」のステップにのっとり、実際にHackを用いた具体的な取り組みとして、2つのケースを紹介した。
ケース1：機能する組織をつくっていく
背景：約半年間でチームメンバーを6人から21人まで大幅に増員する計画が発足した。しかし、マネジメント業務に不安を覚えていた萩原氏は、何をすべきか考えあぐねていた。
理解：機能する組織にするために、米国の経営学者であるチェスター・バーナード氏が提唱する「組織の3要素」に当てはめて、今の組織に足りないものを考えてみた。組織の3要素とは、「共通の目的を持っていること（共通の目標）」「互いに協働する意思があること（協働の意欲）」「円滑な情報共有を図れること（コミュニケーション）」である。
設計：チームメンバーが増えると同時に、プロジェクトが増えても、チームとして協働の意欲を維持するための仕組みが必要であり、コミュニケーションの希薄化を避けながら、チームとして追い続ける共通の目標を定める必要があることが見えてきた。
実装：組織の方針を定め、チームメンバーで意見を出し合い、自らの行動指針を定めた。この過程を通じて、互いの価値観を理解し合うことができ、透明性を担保すると同時に、心理的安全性を高めることもできた。
「価値を素早く提供し、将来の価値低下を防ぐことを目指す組織でありたいという思いを込め、『More Value, Keep Value』という基本方針を定めました。また、行動指針として『N-Dev Spirits』を定め、社内に掲示しています。これらができたことで、それぞれ携わるプロジェクトはバラバラでも、メンバー全員で向かう方向は1つになり、組織の3要素を備えたチームになっていると自負しています」（萩原氏）
ケース2：エンジニア組織を会社の武器にしていく
背景：うるるの経営層には技術畑出身者が少なく、今後の開発組織のあるべき姿を考えてほしいと萩原氏に依頼があった。
理解：「開発という役割は、ユーザーに価値を届けるプロダクトづくりのための役割の1つにすぎない」という考えに至った萩原氏は、エンジニアだけでなく、その他の役割も含め、プロダクトづくりに必要な役割を整理するために、プロダクトマネジメントについて学ぶことにした。そして、プロダクトマネジメントトライアングルに当てはめて、不在役割をすり合わせればいいと思うに至ったのだが、その過程でさまざまなスキマが見えてきた。
設計：そもそも役割を整理できておらず、不在役割についてどのようにカバーし合うのかについて、経営層とすり合わせられる状況になかった。萩原氏は自分の考えで、自社の役職をプロダクトマネジメントトライアングルに当てはめた図を作成し、経営層との会話を始めることにした。
「実際には、このトライアングルを用いながら、まだ経営層と会話をしている最中で、成果を発表できる段階にはありません。僕の個人的な考えとしては、不在の役割を埋めていくときに、外から人を採ってくるのではなく、今、社内にいる人間のキャリアアップに向けた育成に力を入れるべきではないかと思っています」（萩原氏）
このように2つのケースを挙げながら、Hackの考え方をマネジメント業務に当てはめられることを示した萩原氏。
「エンジニアのみなさんは、構造を理解してスキマに入り込む『Hack』は得意ですよね。この考え方をすると、マネジメントのしんどさの原因がはっきり見えてきて、モヤモヤすることも減るはずです。僕らの得意な領域に引き込むことで、マネジメントもきっと楽しくなると思います」とエールを送り、講演を締めくくった。
お問い合わせ
株式会社うるる
