チームなのに「1人」になってしまう構造
伊藤直也氏（以下、伊藤）：ちゃんと作っていくものやミッションと組織の構造をきちんと合わせていきましょうというのが、マネジメントの基本としてものすごく大事です。しかし、形を合わせただけでは、その通りに機能してくれないことがあります。
これはKaizen Platformにいたときにあったことですが。Kaizen Platformは内製組織らしく、さっきみたいにプロダクトマネジャーが真ん中にいて、エンジニアがいて……という構造になっていて、各ユニットごとにきちっと切ってありました。
しかし、よく見ると、各ユニットのなかではエンジニアが3人くらいずついますが、エンジニア同士があまり一緒に仕事をしていないんですよね。
そこで、エンジニアと1:1の面談をして「最近どう？」と聞くと、「う～ん、なんか最近1人で仕事している感じですね」とみんな言っていて、「あれ、なんかおかしいな」と思ったんですよ。チームとしてミッションはちゃんと持ってるのに、みんな1人で仕事してると感じている。
なぜそうなっていたのかというと、仕事をアサインするとき、PM（Product Manager）がなんとなく過去の経緯でエンジニアに「これお願いします」とアサインする構造になっていたんですね。
さっきの日経さんの兼務の話と一緒なんですけど、このPMの人が「この人が終わったら、次この人にお願いします」「この人が次に空きそうなので、このプロジェクトやってもらいます」といって、全部詰め詰めでプロジェクトを切っていくんですよ。
そうすると、PM的にはリソースを無駄なく使ってスループット（時間あたりの処理能力）が最大化されるように見えるからいいんだけど、数人のエンジニアからすると、プロジェクトが終わった瞬間に、前のプロジェクトとぜんぜん関係ないことを仕事として振られて、毎回コンテキストスイッチが発生しちゃうんですよね。
各エンジニアが仕事を始めるタイミングも、それぞれバラバラになっちゃうから、1つの物事にチームで取り組んでる……という認識ができ上がりにくい。
そこで、「これよくないね」「これだと、チームに事業のラーニング結果が溜まらないからなんとかしたい」と話をしました。
そのときは、たまたま会社の中にチームとしての会話がうまくいってるところがあったので、そこと同じ構造にしようという話をしました。そのチームの中にはリーダーシップを発揮できる人がいて、基本的にはPMとこのリーダーがよく話していたんですよね。このリーダーが、その他のメンバーを巻き込んで「どうやってやっていこうか」と話をする形になっていました。
PMが個々人のエンジニアのアサイン権限を持つのではなく、例えば、エンジニアのリーダーと話し合いながら「どうやってやっていくか」を決める構造を持っていたのと、チームのなかに業務のコンテキストが閉じやすい業務割り振り……独立性の高い業務をチームとしてミッションに持っていたのが大きかったんですよね。
その他のチームもこの構造に変えて、だんだんとチームがチームとして機能するようになっていきました。
ふだんうまくいってるときは別にいいんですけど、チームがチームとして機能してないとき、ある人が見積もりをミスしたり、思っていたりよりも大変で作業が進まなかったりすると、みんな1人で仕事してるからヘルプできないんですよね。隣の人が同じコンテキストを持ってないですし。そして、ドツボにはまっちゃうエンジニアが出てきて、けっこうしんどい思いをしてた。
隣の人がきついときにヘルプできるためには、常日頃ラーニング結果を一緒に蓄積していくのがものすごく重要なので、そういう形にしていくことをしました。
人ではなく、組織構造をコントールする
ここから言えることとして、まず1つは「マネジメントは“偶然”を期待しちゃいけない」です。組織のチーム構造やチーム活動は、偶然いい人が入ってきて、いい感じにやる気を出して、いい感じにチームを作ってくれるというのは、なかなか起こらないんですよ。
まれにそういうことはあるんですけど、マネージャーとしてはそこ頼みではよくなくて。いかにして、そういう状況を自分で作り出すかが重要だと思います。
これはすごく重要なことなんですけど、もう1つは、マネジメントの対象をきちんとコントロール可能なものかどうかを見極めることです。
個々人の意識や心がけといった、そういうものは基本的にコントロールできないものと思ったほうがいいですよね。本当は、放っておいてもチームメンバーとうまくやってほしいし、情報共有も積極的にしてほしいんだけど、チームというものの捉え方や情報共有の意識が高い・低いには個人差があります。それを「意識を高く持て！」と言っても高くならないじゃないですか。
意識はコントロールできない。でも組織構造は、当たり前ですが、いくらでもコントロールできるんですよね。だからといって、あんまりごちゃごちゃ変えちゃいけないんだけど。
基本的には、なにか会社や組織で問題が起こったときに、たとえそれが人に起因する問題でも「これはあの人ができないからダメですね」と言ってそこで議論を終わらせてしまうのではなく、常に人ではなく「構造」に原因を求めるように思考を働かせて、その構造的問題を見抜こうとするのがすごく重要です。
さっきのKaizenの例がいいんですけど。エンジニアと1on1で面談すると「1人で仕事しちゃってます」と言うけれど、「なぜ2人も3人も、同じようなことを言うんだろう？」なときに、どこの構造が「1人で仕事をしちゃってる」状況を招いているのかをきちんと探って見つけ出すのが、マネージャーとして重要だったということです。
優先度が上がらないタスクは、組織構造で解決する
組織構造でもう1つ大事な問題は、マネジメント経験ある人はよくわかると思うんですけど、「物事の優先度は組織構造が規定することが、けっこうある」です。
会社の中で、「ここの優先度をもうちょっと上げてやってほしい」と思ってるけど、そのまま放っとくと、ほかの重要な案件が入ってきてそっちに手がつかない……なんて、よく起こりますよね。そういうときこそ、組織構造をいじるのが効果的です。
典型的なことは、ここに書いてますけど、「運用の自動化」や「レガシー基盤を刷新する」「技術的課題を解消する」「クラウドサービスを導入して運用負荷を下げる」など、やっておけば後々すごく助かるけど売上には直接的なインパクトを及ぼしづらいことですね。
こういうことをやるときには、組織的にチームを1個作って、そこへ人をアサインすること。そうすると、否が応でもその人たちはやらざるを得ない状況に立たされるので進みます。
問題は、「そういうことにエンジニアを固定的にアサインしていいかどうか」「経営陣などステークホルダと合意がとれるかどうか」がありますが、そこはまた別問題なので、後に回しましょう。
これはエンジニア起点のけっこう楽しそうな話です。これ以外にも、例えば決済プラットフォームで、「地味なところだけど、バックエンドをきちんと開発しておきたい」ときも、きちんと構造を作ってあげて、人をアサインするのが大事です。
組織構造に、正解はない
さっき話したとおり、組織の構造をなんのためにきちんと固めていくのかというと「ラーニング結果をため込んでいく」が本質です。組織の形をコロコロ変えていると、そもそもその結果として溜まったものが全部失われちゃう。ラーニング結果はなるべく保存する形で、変化を徐々に加えていくのが、けっこう大事なことだと思ってます。
そういう感じで組織の形は、マネジメントとしては自覚的に作っていかないといけないんです。
僕が尊敬しているグリーの藤本（真樹）さんとか、クックパッドの池田（拓司）さんが言っているんですけど、基本的に、こういう組織の構造には正解がありません。あと時間的なパラメーターもあります。
クックパッドのこのブログに書いてるんですけど、最初はデザインの組織的な問題を解決するために横串の組織にしてずっとやっていて。そこから、標準化されなかったデザインが標準化されたり、横同士のつながりができて情報共有が行われてうまくいったり、なんてことが起こったそうです。
ただし、長年それでやっていると、その人たちが事業と直接つながってないから、プロダクトへのオーナーシップが失われることがあります。だから今度は「縦に変えた」と言ってたんですよ。
会社の大きさが変わった、あるいは、横中心にしてから何年経ったかなどで「時間が経ったからそろそろ変化させなきゃいけないね」ということもけっこうある、というか、しょっちゅうあります。固定的に「これがいい」があるとは思わないで、常に変化するつもりで進めたほうがいいんじゃないかなと思います。
こんな課題の話でいいんですかね？ 大丈夫ですかね？ こんな感じでいきますよ。
（会場笑）
