専門職と視座

Kunzo Ishii
Jun 19 · 17 min read

こんにちは。ミクシィでスポーツやライブエンタメ関連の技術部長を担当している石井です。社内向けに書いている記事を少しづつ外部公開していきます。

Image for post
Image for post

大規模なサービス開発組織で働いていると、技術職スタッフにおいても、視座の高さを求められることが増えます。「視座の高さ」という単語は、曖昧で、入社していきなり「視座!視座!」と言われても、「えらい人がなんか言うとる」「わいには、まだ早い」くらいで、腹落ちしないと思います。しかし、給与体系にも紐づいていたりするので、給与が上がってくると、「視座をもうちょっとあげてもらわないとね…」と上長から言われれて「えー」となるかもしれません。私の考える「視座の高さ」と、なぜ専門職にも必要になるのかを説明しつつ、サービス開発と組織の関係について考えてもらう機会になればと思います。

私は、エンジニアリングを、単にプログラミングを書いたりすることで技術課題解決するということではなく、「デザインやテクノロジーを用いて、社会的な課題を解決するもの。社会をよりよくするもの」と定義しており、職能を横断したチームを率いることも多くあります(いまだサービス開発をうまく仕切れているとは言えませんが)。その中で、視座の高い専門職というのは、サービスをよりよくするために重要なメンバーと考えています。(なお、ここで言うエンジニアは、サービス開発の技術力は十分備えているはずという前提に立っています)

開発の成功と組織の拡大によって発生する問題

「視座の高さ」とは何かを説明するために、サービス開発組織の大規模化によって起こる問題について説明します。視座の高さは、特に分割が進む組織で求められる能力だからです。

メンバーの増加
ユーザーサービスを開発するチームは、目的・やりがいがわかりやすく、どちらかというと団結したチームを作りやすい組織です。もしメンバーが増えはじめてきたら、それも素晴らしいことです。サービスが順調に成長し、売上や利益が伸びているか、会社や投資家から期待され、資金が投入されているからです。

自分の感覚でいうと、何かしらのプロダクト開発組織において、10人までの規模であれば、チーム全員が目標にむけて議論し、集団凝集性が高い状態を維持しやすいでしょう。20人くらいから「おや?」と思うことが出てくるかもしれません。例えば、タスクが山積みになっていたり、若干名の間違えた採用をしてしまったりするかもしれませんが、成長フェーズであれば、乗り越えられるでしょう。

アクセルを踏むか撤退するかの判断を乗り越えたサービスは、慣性を持って成長し、プレッシャーがより強まるフェイズへ移っていくかもしれません。そうして、50人をこえ、メンバーの増加ペースも早まるでしょう。より専門性の高い業務やスペシャリストも必要になり、技術難度の高い課題は、技術指向が強い人材も引き寄せやすくなります。そして、職務能力だけでの採用が進むかもしれません。職能や機能による分業の幅は広がり、情報は溢れ、部門間の軋轢(セクショナリズム)が発生します。暗黙知による作業は難しくなり、明文化されたルールが増えてきます。

組織分割
組織の拡大にともない、コミュニケーションコストは増大し、開発がスケールしなくなります。メンバーのストレスにも大きくなっていきます。組織を分割して、そのコストを下げて最適化する方向に向かうでしょう。

組織にしろ、ソフトウェアアーキテクチャにしろ、機能を疎結合にし、依存度をさげ、凝集性の高い役割に分割することは、業務の効率化に重要なことです。サービス開発において、最適なアーキテクチャと、機能(組織)分割は、意思決定や開発速度をあげ、頻繁なデプロイ、検証に基づく反復開発(改善)を可能にします。ダイナミックな市場に立ち向かうための重要な要素であることは、間違いありません。それを容易にする技術やアーキテクチャフレームワークも目覚ましく進化を続けています。

開発領域であれば、レガシーコード(技術的負債)やアーキテクチャについても議論が活発化しているかもしれません。システム設計にあわせて、組織を分割するという逆コンウェイの考え方やマイクロサービスの潮流は、かつての私には組織面・技術面の両方を解決してくれる理想の手法にうつっていました。

コミュニケーションコストが減り、作業に集中できる。無駄な議論やストレスも減り、開発速度もあがり、ビジネスにも貢献できるはず。いいことづくしでは?これは、一面で間違いありません。しかし、それは拡大化するサービス開発組織にとって必要条件であって、十分ではありません。

サイロ化の発生
組織や業務の疎結合化によって、発生するのが、サイロ化問題です。効率をあげる疎結合は、その結合度が低く、凝集性が高くなればなるほど、メンバーやチームを特定の業務に集中させる一方で、全体の目的やビジョン、情報を無視することを許容します。また、逆にチームが隠蔽化してしまう可能性もあります。専門性の高い組織は、その傾向が強くなります。メンバーの「無関心」と「限定合理性」は、本来の目的を見失わせ、サービスの改善スピードにマイナスに作用することがあります。

無関心
まず、明確な役割分割は、誰もやらない領域が発生しはじめることも意識しなければいけません。安定したサービスなら良いかもしれませんが、不確実な環境に立ち向かって成長を続けるサービスや組織であれば、明示されていないイレギュラーな課題が多発します。サービスが目指す姿に無関心になっているメンバーは、当人が解決できるできないにかかわらず、これらの課題が視野に入らなくなります。

重要な課題が放置され、優先度の低い作業に労力がとられ続けることにより、全体のボトルネックになることがあるかもしれません。障害につながる課題であれば、顧客に多大な迷惑を与えるかもしれません。これは単純にリスクです。

また、無関心は、サービスに対する多様な意見をなくし、サービスの可能性を狭めます。もちろん、あらゆるアイディアがサービスの品質をあげるわけではありませんが、プロダクトオーナーの選択肢を減らします。プロダクトオーナーは、優先度についての権限と責任をもちますが、1人の人間が把握できることや知識には限界があります。多様なアイディアが組織やサービスの品質をあげるのです。

無関心なメンバーが増えてくると、マネージャーは、隙間の領域をカバーするために、新しい業務を明記し、人を増やさなければいけないかもしれません。これは予算の肥大化を意味し、コミュニケーションパスを増やすことで、さらに人員効率を落とします。もちろん、すでに手一杯のメンバーにオーバーワークをしろという意味ではありません。業務量や優先度により、組織は適切に増員する必要はあります。

「内部摩擦がないようにしたい」と、みんなが思い始めるのである。そこで、どうするか。役割分担、領域分けをきちんと決めるのである。(中略)こういう「誰もやらない領域」をもつ組織を、隙間組織という。トラブルを起こし、致命的な事故を発生させるのは、こういう隙間組織である。

技術の創造と設計」より

限定合理性
「エンジニアって合理的だよね?」と思う人はいるかもしれませんが、自分がエンジニア職だったとき、合理的だと思ったことは一度もありません。キレちらかしてたりするし、むしろ感情的な人種なのでは?と思っていたりもしました。ただ、合理的・コントローラブルな状況を好む人は多いかもしれません。私のレベルで合理性を求めるのに、一番簡単なことは、考慮する範囲を狭くすることです。不確定要素を減らしていくことが、合理的で確実性の高い答えを出しやすい環境に近づけるからです。このように、区切られた役割は、人間の心理に限定的な合理性を生み出しやすくすることを忘れないでください。

限定合理的に考えられている意見の衝突はやっかいで、論点が噛み合わず、永久に議論が進まないことがあり、時間を大きくロスします。そういった議論を終わらせるのは強制と妥協です。もちろん、論点や抽象度が噛み合っても合意できるとは限らないのですが、噛み合わない議論は100%合意には辿りつかず、協力体制を築くことができません。また、極めて限定合理的になっている場合、確証バイアスにとらわれて、情報収集に偏りが生じることも注意してください。

限定合理は、しばしばメンバーやチームを攻撃的にもします。これは組織の心理的安全性を奪い、意見の多様性・活発な議論を封殺します。最悪のケースでは、チームが孤立し、サービスにとっての最適な施策を打ちづらくするかもしれません。本来コミュニケーションコストを下げるはずの組織分割が、結果コミュニケーションコストを増やしてしまうのです。

「認識能力の限界によって、人は限定的な合理性しか持ちえない」という考えが限定合理性の考え方です。役割にかかわらず、誰しもに存在しますが、範囲を絞りすぎないように注意しなければいけません。

2つの作用
分業が悪いと言いたいのではありません。分業による個別チームの業務効率化の合算が、全体の効率化になっているとは限らない点に注意してください。これはベクトルに似ているかもしれません。分業化により、個々の力は強くなる点はプラスです。力の方向によっては、全体効率にうまく作用するかどうかが問題です。そして、間違った分業は、力の方向がズレていく可能性を高めます。

もし、組織やアーキテクチャの議論が、疎結合になることだけが目的になっているようであれば、注意してください。組織の問題から目を逸らすための分割によって新たに発生する問題はあるのです。

エンジニアはコミュニケーションをできるだけ排除して、コードを書かなければいけないと考えている。しかし、チームが合意していなかったり、情報が伝わっていなかったりすると、君が正しいコードを書いているという保証はない。

Team Geek」より

大規模な組織を同じ方向に向かわせるもの

規模が大きくなっていくチームが、それぞれの役割に集中しながらも、全体の統一感が失われないようにするために、大きく2つの手段あり、1つが組織分割やルールやガイドラインなどの明確化された「仕組み」、そしてもうひとつが「ビジョン」だとか「文化」と呼ばれるような抽象度の高いものの浸透です。この2つを組み合わせて、組織をマネージします。どちらか片方に偏った組織は、個人的にはイノベーティブな集団にはなり得ないと考えます。前者は工場のようですし、後者は宗教です。

「仕組み」だけでは解決しない
決まった業務が永久に続く場合の効率化は、抽象化と自動化をモットーとする、エンジニアリングの得意領域です。しかしながら、サービス開発は常に動的に環境が変化します。固定化された役割は柔軟性がなく、イレギュラーな課題への対応速度を落とします。また、全てを細かくマニュアル化するのは膨大なコストです。

また、抽象度の高い概念は、サービスに多様性・可能性を残すことでもあります。ソフトウェアのアーキテクチャとも似ている考え方かもしれません。可能性は、争いを引き起こす毒になることもありますが、サービスをよくもします。

アーキテクチャの形状の目的は、そこに含まれるソフトウェアシステムの開発・デプロイ・運用・保守を容易にすることである。それらを容易にするための戦略は、できるだけ長い期間、できるだけ多く選択肢を残すことである。

Clean Architecture」より

スタンドプレーから生じるチームワーク

「仕組み」は、様々な個性を持った人間の集団に対して、完全には機能しないのが面白いところです。コミュニケーションを減らすために、抽象度の高くしておく。これは、非効率で本末転倒に見えるかもしれませんが、環境が動的であり、組織が大規模になればなるほど、両方を組み合わせたほうが効率が良いのだろうと思います。時代が進めば、原理の解明も進み、また変わってくるかもしれませんが。

「ビジョン」だの「文化」だの言うものは、予測できない事象に対し、複雑な判断をしなければならない際に、より少ないコミュニケーションで、個々のチームが権限を委譲され、スタンドアローンな判断をしながらも、全体として統一感を持った方向に進んでいくためのものです。

「視座の高いメンバー」とは

高いところから見ているというイメージは、会社全体を俯瞰的に見れているかどうかということです。それだけ影響範囲を広げて、考えることができるかということだと私は認識しています。自分の業務領域だけでなく、チーム・会社全体について考えみることができるかという意味です。これは視野の広さと言えるかもしれません。さらに、会社やチームなどレイヤーの高い目的を考えられているかどうかです。

「ミッション」や「ビジョン」というものがあったとしても、自分の領域にしか興味がないメンバーだけだと、それは機能しません。視座の高いメンバーというのは、全体の方向性を確認し、チームや自分が向かっている方向が間違えていないか考えられたり、議論できるメンバーということです。

視座をコントロールする
全員が、経営者やマネージメントのロールをこなすわけではありませんから、全員に高い視座は必要ないのでは?と思われるかもしれません。もちろん、経営者やマネージメントはロール上、高い視座・広い視野が必須になりますし、羅針盤として方向性も示さなければなりません。

そして、会社は様々なロールで成り立っていて、それぞれの領域で働いているはずです。俯瞰的にばかりみていては仕事は進みません。自領域にフォーカスし、解像度を高めて業務を遂行しなければなりません。ただし、視座をあげて考えられるメンバーがそれぞれの領域にいなければ、上述したような問題が起こるというだけなのです。

真にフラットな組織をつくる
「高い」「低い」というと、視座が高い人がえらい人ような気がするかもしれませんが、そういうわけではありません。組織にとっては経営者やマネージャーですら1つのロールでしかないこともおぼえておいてください。考える範囲が広がれば広がるほど、個人が把握できる内容は薄くなります。それぞれの領域での意見を持ち寄り、全員が高い視座で情報共有や議論することにより、サービスがより正しい知見を取り込めると言えます。

視座の高いメンバーが少ない場合、「下のメンバーがやること」「上のメンバーが決めること」と自分たちの役割を切ってしまう(切らざるをえない)ため、動的な役割変更ができず、フラットな組織を作りようがありません。なお、このような組織で、サーバントリーダーシップを採用すると破綻するのでお勧めしません。

全員が高い視座を持つ必要はない
大規模な組織であればこそ、専門性が極めて高いメンバーが必要になることもあるでしょう。視野が一極集中しているがゆえに、その分野で唯一無二の力を発揮できる人はいます。技術指向で輝く人もたくさんいます。大規模な組織には多様なスキルが必要なこと、人が関心を持てる領域や方向はそれぞれ異なること、人生に求めることは人それぞれであることなどを理解して、組織を構築する必要があります。

開発チームに権限を与えて自律性を高めると、悲惨な結末になる場合があります。これまで仕事を他者に押し付けてきた人は、他者を非難するのが当たり前になっていて、仕事の全責任を負うことを心地よく感じないかもしれません。(中略)しかし、組織にはすべてを機能させる別の種類の人たちが必要なことも認めなければなりません。

マイクロサービスアーキテクチャ」より

また、組織サイズによっては上位レイヤーのミッションは抽象度が高くなりすぎるはずで、いきなりそこまで視座をあげてといっても興味が持てないというのが普通だとも思います。その場合は、マネージャーが中間のミッションを作ったり、サービス全体最適とのバランスを取る必要があると考えます。担当領域が依存度が低くあれるかなどを検討し、業務内容を明文化します。その場合の業務メンバーには、かなり高いレベルでスキルを求めていく必要も多いでしょう。

分業化しやすいものとして専門性が高いものと、もうひとつは単純作業があります。分業化された業務は産業構造において、ニーズがあればあるほど「代えが効く」「自動化に近づいていく」業務だと考えており、本人のキャリアにとってもリスクになるケースがあります。メンバーのキャリアを構築する上でも、マネージャーはメンバーが特定の専門性の高さだけで、市場競争力があるかを考えてアドバイスをしなければいけません。

サービス開発組織を大きくするときに

最近はあまりないですが、自分がなにかしらのプロダクト開発組織を持つときに、意識していることを書いていきます。ただし、構成メンバーによって毎回パターンが変わるため、正解はありません。

情報を行き渡らせ、互いの意見を傾聴する
上からも下からも出来る限り情報をオープンにし、互いに傾聴する文化。例えば、デザイナーやエンジニアにも、法律や会計の話などもする。それで納得感が得られることもあるし、他領域の事情を知ることで、興味を持ったり、視野を広げる人もいる。なお、起業したり、CTOを目指すなら、ファイナンスは勉強しておいたほうがいいです。むしろCFOになれ(え

プロアクティブなメンバーの割合を維持する
よく言われるように、採用や評価で、スキルは必要条件ということを意識する。カルチャーマッチと言われるもの。感覚的に、担当業務より1レイヤー上くらいまでは視座があげられるメンバーで、チームの50%以上を占めるようにする。100%に近づけるのが理想かもしれないが、実質は難しい。マネージャーだけが視座があげられるチームだと、マネージャーが少ししんどい。また、そのようなチームでマネージャー自身も視座が低い場合、チームごと孤立する可能性がある。

プロダクトのオーナー(シップ)を維持する
サービスが大きくなってくると、プロダクトオーナーやプロジェクトマネージャー(スクラムマスターかもしれない)が、多様な業務に忙殺されてくる。気がつくと、サブサービスへの権限委譲と組織運用(仕組み作り)だけになり、サービス全体で品質・価値を見ている人がいなくなる状態になるので、それは避ける。プロダクトオーナーのタスクを適宜分散させ、プロダクト全体へのオーナーシップを維持する。

数値での目標管理は十分でないことを理解する
ルールやガイドラインは限定合理性を加速するのは述べたとおり。目標値(KPI)は、特に扱いが難しく、明確であるがゆえ、そこに答えを求める人が増える。様々な指標のモニタリングや分析は非常に重要でマスト。一方、おそらく、ほとんどの指標がサービスが上手くいっているという答えにはならない。多くの経営戦略や目標設定の参考書で、目的と目標は分けて考えなければいけないと書いてあるのと同じ。OKRなど、目標管理のフレームワークには、そのようなもの(定性・定量)が入っているので活用する。

完璧な組織を作ろうとしない
組織の境界を見極めるのはとても難しいし、動的に変化する。最初から抽象だけを考えてアーキテクチャを組むのが難しいのと同じ。少なくとも、私には無理。具体をみながら、ダイナミックに組織を変更していく。

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store