会員事業部の森田です。

はじめに

この記事は、クックパッドと同じような200～300名規模の組織で働く、「最近調整が多くてコードを書く時間がないなぁ」と思い始めた30代エンジニアの方を対象として、調整の負担を軽減するために私が日々考えていることをまとめたものです。

組織における分業と調整

組織に所属する人たちは協力して組織目標の達成を目指します。みんなで同じことをしてもしょうがないので、必然的に役割を分担(分業)をします。分担した仕事はなんらかのタイミングで統合する必要があります。その統合が調整です。つまり分業と調整はセットです。じゃどういう分業があるのかといえばそれは組織構造によります。今回は私達が採用している事業部別組織下*1での調整の話をします。

分業の種類

事業部別組織では垂直と水平の2つの分業が存在します。それぞれに少し毛色の違う調整が発生するわけですが、いくつかのことを意識することで調整の負担を減らすことができます。減らしても大変ですけどね。最近はいかに無駄なく調整をこなしてコードを書く時間を確保するかがエンジニア35歳定年説に打ち勝つ鍵だと思いながら働いています。では、それぞれの分業ごとに説明します。

垂直分業

まずは垂直分業の調整についてです。垂直分業とはつまり上司と部下の分業です。そこで発生する調整は「部署内において今期はだれがどういう仕事をするか」といったものになります。今回は上司との調整を前提として話をします。

上司の責任範囲

垂直分業では部下は上司の責任範囲の一部を担います。根本的におかしなことにならないためにも上司の会社での責任範囲を確認し理解します。

自分の責任範囲

自分の経験や得手不得手などを考慮し、責任範囲を明確にします。双方の腕の見せどころです。仕事に慣れないうちは「目的Aのための施策Bの効果を検証する」という責任だったものが、慣れるに従い「目的Aのための施策を考え検証する」になり、しまいには「目的Aがただしいか考え、正しくなければ何が正しいかを示し適切な施策を考え検証する」と変化していきます。

ここの認識で齟齬があると非常に辛いのでしつこく確認します。意識して3倍増しです。

権限(制約)

自分のもつ権限を確認します。権限を例えると「自社のトップページのこの領域を自由に使う」であり、制約を例えると「一人で頑張って」などです。この2つはひとつの物事を逆から示しています。また、もし部下を持つなど、人に関する権限を割り当てられた場合は、「権限受容説」を前提にしたコミュニケーションをとることが円滑に進める秘訣だと思います。

権限と責任のバランス

この2つのバランスがとれていないと誰かが苦しい思いをします。権限が足りなければ自分が、権限が多すぎれば周りが苦しみます。

失敗(成功)の定義

たまに失敗の定義がない、つまり失敗しない責任になっている事があります。そうなると自分でも何をしていいのか分からなくなります。責任も権限もあるのに失敗しようがない場合は何かがおかしいので確認をします。

確認の頻度

ここまでを丁寧に進めたとしても、お互いの考えは多かれ少なかれ食い違いっています。人間、簡単にはわかりあえません。そのため責任範囲がきまり、仕事を開始してしばらくは、なるべく短い間隔で話をし、お互いの考えを同期します。うまくいけばすぐに「この頻度ではいらないのでは？」と双方が思うようになるので、段々と間隔をのばします。

対等な関係

当然ですが上司部下は垂直分業での役割の違いにすぎません。人としての上下関係ではなく構造による分業と考えそのなかで対等に話し議論をかさね調整します。

ちなみに、「そもそも意見をいうことが苦手なんだよね」という方は「アサーティブネス」という概念が役に立つかもしれません。ほかでは少し前に流行った「アドラー心理学」ですかね。

水平分業

次に水平分業の調整についてです。水平分業とは会員事業部や広告事業部といった役割の分業です。水平分業の調整では複雑な利害関係が発生する場合が多々あります。そのような場合は各々が話し合い全体最適解導き出すよりも、上位の責任者に決めてもらうのが理想です。*2

しかしながら、現実ではそういった責任者がみつからなかったり、みつかっても入ってもらうことが難しいこともあるので、今回は利害をふくめた水平分業の調整を自分でなんとかする際の話をします。これはつまり、特定の領域に対して責任を持つ各々が、「全体最適」という本来であれば責任外の要素を考慮しながら頑張るという構造なので、垂直分業の調整より大変です。このような構造下では交渉の色が強めにでてしまうこともある程度は仕方がありません。

コンテキスト

自分の都合をはなすとき「Xという施策をしたいのですが」ではなく「Aというコンテキスト上でBという目的があり、そのためXという施策をしたのですが」と伝えることが大切です。目的を丁寧に伝える事は調整相手が全体最適を考える上で不可欠な情報です。

自信の程度

自分の施策にたいして「5%ぐらいの成功率かもしれない。それでもやりたい。」と思っているとします。これを説明しないと相手は「この人は大丈夫か」と心配になります。そのため、どれくらいの自信をもっているのか伝えます。たいていの人はコントロールされていないリスクに付き合いたくありません。

相手のコンテキスト

必要であれば「コンテキスト」「自信の程度」に書いた内容を相手から引き出します。

自分と相手の守りたいもの

双方の守りたいものを確認します。ここでいう守りたいもの、たとえば「施策の効果検証」であり「ユーザの体験」であり「短期的な収益」であり「合意形成のプロセス」などです。それらの情報から譲歩可能な点が何かを整理し確認します。同時に、ここを積極的に引き出す姿勢をみせることで「この人は私達の利害や目的、信念を尊重してくれないのではないか」という恐怖を取り除く意味もあります。人は怖くなると怒り出したり頑なになります。

早めの連絡

ギリギリで伝えると蔑ろにしていると思われます。そうではなく、ただまぬけなだけなのですが、勘違いされないためにも、早い段階で情報の共有を行います。それにより、思わぬアイデアが生まれてきたり、連携した仕事ができる事もあり、一石二鳥です。

記録

言葉で合意をとっていても、細部で食い違っていたりします。後に水掛け論にならないためにも、合意した内容を文章にし内容を確認します。

共通

最後に水平、垂直に限らず関係することを話します。

信頼関係

頑張って築きます。コミュニケーションコストは信頼関係に反比例します。

対立構造の排除

調整を対立構造と考えず、組織として良い答えを模索する場であると常に意識します。

その他の技術

調整を支える技術は他にもたくさんあります。その中には「人としてどうなの？」と思える危ういものもあります。興味があるかたは「すぐれた組織の意思決定」のパワーに関する記載や、「すぐれた意思決定」や「影響力の武器」などで示される社会心理学、行動経済学、認知バイアスに関する情報を御覧ください。これらは危ういことをしたい人に限らず、そういうことから身を守りたい人にも役立ちます。

まとめ

調整はつかれます。「コードだけかけたらどんなに幸せか。」と思い転職してきた同僚たちが結局調整をしているのをみるたびに、大変だなと思います。残念、組織で働いている以上調整は避けられません。避けたつもりでいても行き着く先はback numberの「こわいはなし」の世界です。という話を新婚の同僚にしたところ、「恋愛のほうが簡単だ」という見解をいただきました。今後も、調整を避けるのではなく、向き合いながらも効率よくこなすことで、コードを書く時間を確保していきたいと思います。