会員事業部の森田です。
対象と内容
この記事は、クックパッドと同じような200～300名規模の組織で働く、「最近調整が多くてコードを書く時間がないなぁ」と思い始めた30代エンジニアを対象として、日々の調整の負担を減らすための「考え」と「行動」を整理し、まとめたものです。
組織における分業と調整
組織に所属する人たちは協力して組織目標の達成を目指します。みんなで同じことをしてもしょうがないので、必然的に役割を分担(分業)をします。分担した仕事はなんらかのタイミングで統合する必要があります。その統合が調整です。つまり分業と調整はセットです。じゃどういう分業があるのかといえばそれは組織構造によります。今回は私達が採用している事業部別組織下*1 での調整の話をします。
分業の種類
事業部別組織では垂直と水平の2つの分業が存在します。それぞれに少し毛色の違う調整が発生するわけですが、いくつかのことを意識することで調整の負担を減らすことができます。減らしても大変ですけどね。最近はいかに無駄なく調整をこなしてコードを書く時間を確保するかがエンジニア35歳定年説に打ち勝つ鍵だと思いながら働いています。では、それぞれの分業ごとに説明します。
垂直分業
まずは垂直分業について話します。垂直分業とはつまり上司と部下の分業です。そこではまず「部署内において今期はだれがどういう仕事をするか」を決めます。つまりどう分業するかを決めます。その後、必要に応じて調整をくりかえしながら目標の達成を目指します。垂直分業の調整は、後述する水平分業の調整と比べると、上司という上位の権限が明確に存在するため容易です。そのため垂直分業に関しては、調整自体ではなく、その前段階である「分業の内容を上司とともに決定する過程」に焦点を置いて話します。適切な分業はその後の調整を容易にします。(便宜上、以降は「分業を決める過程」も「調整」の一種として話します)*2
上司の責任範囲
垂直分業では部下は上司の責任範囲の一部を担います。根本的におかしなことにならないためにも上司の会社での責任範囲を確認し理解します。
自分の責任範囲
自分の経験や得手不得手などを考慮し、責任範囲を決めます。双方の腕の見せどころです。仕事に慣れないうちは「目的Aのための施策Bの効果を検証する」という責任だったものが、慣れるに従い「目的Aのための施策を考え検証する」になり、しまいには「目的Aがただしいか考え、正しくなければ何が正しいかを示し適切な施策を考え検証する」と変化していきます。
ここの認識で齟齬があると非常に辛いのでしつこく確認します。意識して3倍増しです。
権限(制約)
自分のもつ権限を確認します。権限を例えると「自社のトップページのこの領域を自由に使う」であり、制約を例えると「一人で頑張って」などです。この2つはひとつの物事を逆から示しています。また、もし部下を持つなど、人に関する権限を割り当てられた場合は、「権限受容説」を前提にしたコミュニケーションをとることが円滑に進める秘訣だと思います。
権限と責任のバランス
この2つのバランスがとれていないと誰かが苦しい思いをします。権限が足りなければ自分が、権限が多すぎれば周りが苦しみます。
失敗(成功)の定義
たまに責任に対する失敗の定義がない、つまり失敗しない仕事の責任を持っている事があります。そうなると自分でも何をしていいのか分からなくなります。責任も権限もあるのに失敗しようがない場合は何かがおかしいので確認をします。
確認の頻度
ここまでを丁寧に進めたとしても、お互いの考えにはある程度の齟齬があります。人間、簡単にはわかりあえません。そのため責任範囲がきまり、仕事を開始してしばらくは、なるべく短い間隔で話をし、お互いの考えを同期します。うまくいけばすぐに「この頻度ではいらないのでは？」と双方が思うようになるので、段々と間隔をのばします。
疑問や違和感
得てして上司は全てを把握していると思いがちですが、そんなことはありません。意識をしなければならない領域が広く、情報にも限りがあります。森羅万象を把握する神ではありません。自分が感じた疑問や違和感にたいして「上司は把握し理解しているだろう」と思わずに、確認をします。
対等な関係
当然ですが上司部下は垂直分業での役割の違いにすぎません。人としての上下関係ではなく構造による分業と考えそのなかで対等に話し議論をかさねます。
ちなみに、「そもそも意見をいうことが苦手なんだよね」という方は「アサーティブネス」という概念が役に立つかもしれません。ほかでは少し前に流行った「アドラー心理学」ですかね。
水平分業
次に水平分業について話します。水平分業とは会員事業部や広告事業部といった役割の分業です。水平分業の調整では複雑な利害関係が発生する場合が多々あります。そのような場合は各々が話し合い全体最適解を導き出すよりも、上位の責任者に決めてもらうのが理想です。*3
しかしながら、現実ではそういった責任者がみつからなかったり、みつかっても入ってもらうことが難しいこともあるので、今回は利害をふくめた水平分業の調整を自分でなんとかする際の話をします。これはつまり、特定の領域に対して責任を持つ各々が、「全体最適」という本来であれば責任外の要素を考慮しながら頑張るという構造なので、垂直分業の調整より大変です。このような構造下では交渉の色が強めにでてしまうこともある程度は仕方がありません。
コンテキスト
自分の都合をはなすとき「Xという施策をしたいのですが」ではなく「Aというコンテキスト上でBという目的があり、そのためXという施策をしたのですが」と伝えることが大切です。目的を丁寧に伝える事は調整相手が全体最適を考える上で不可欠です。
自信の程度
自分の施策にたいして「5%ぐらいの成功率かもしれない。それでもやりたい。」と思っているとします。これを説明しないと相手は「この人は大丈夫か」と心配になります。そのため、どれくらいの自信をもっているのか伝えます。たいていの人はコントロールされていないリスクに付き合いたくありません。
相手のコンテキスト
必要に応じて相手から「コンテキスト」「自信の程度」で話した内容を引き出します。
自分と相手の守りたいもの
双方の守りたいものを確認します。ここでいう守りたいものとは、たとえば「施策の効果検証」であり「ユーザの体験」であり「短期的な収益」であり「合意形成のプロセス」などです。それらの情報から譲歩可能な点が何かを整理し確認します。同時に、ここを積極的に引き出す姿勢をみせることで「この人は私達の目的や信念、利益を尊重してくれないのではないか」という恐怖を取り除く意味もあります。人は怖くなると怒り出したり頑なになります。
早めの連絡
ギリギリで伝えると蔑ろにしていると思われます。そうではなく、ただまぬけなだけなのですが、勘違いされないためにも、早い段階で情報の共有を行います。それにより、思わぬアイデアが生まれてきたり、連携した仕事ができる事もあり、一石二鳥です。
記録
言葉で合意をとっていても、大体細部で齟齬があります。後に水掛け論にならないためにも、合意した内容を文章に書き出して確認をします。
共通
最後に水平、垂直に限らず関係することを話します。
信頼関係
頑張って築きます。コミュニケーションコストは信頼関係に反比例します。
対立構造の排除
調整を対立構造と考えず、組織として良い答えを模索しているのだと常に意識します。
その他の考え
調整を支える考えは他にもたくさんあります。その中には「人としてどうなの？」と思える危ういものもあります。興味があるかたは「すぐれた組織の意思決定」のパワーに関する記載や、「すぐれた意思決定」や「影響力の武器」などで示される社会心理学、行動経済学、認知バイアスに関する情報を御覧ください。これらは危ういことをしたい人に限らず、そういうことから身を守りたい人にも役立ちます。
まとめ
調整はつかれます。「コードだけかけたらどんなに幸せか。」と思い転職してきた同僚たちが結局調整をしているのをみるたびに、大変だなと思います。残念、組織で働いている以上調整は避けられません。避けたつもりでいても行き着く先はback numberの「こわいはなし」の世界です。という話を新婚の同僚にしたところ、「恋愛のほうが簡単だ」という見解をいただきました。今後も、調整を避けるのではなく、向き合いながらも効率よくこなすことで、コードを書く時間を確保していきたいと思います。
*1:厳密には事業部に加えてエンジニアはエンジニアとして水平にゆるく部門化されているマトリックス組織です。
*2:記事を公開した当初は、「分業を決める過程」を説明なしに「調整」と表現していました。しかし、「組織における分業と調整」という文脈での「調整」ではないので誤りです。申し訳ありません。しかしながら、今回の記事の趣旨としては引き続き調整の一種として話をしたほうが分かりやすいと考え、導入に断りを入れる修正にとどめました。
*3:「すぐれた組織の意思決定」に非常にわかりやすく書かれています。
