人気ブログランキング | 話題のタグを見る

誰が決断を下すのか？　〜タスクフォース組織のすすめ

先週は入社式のシーズンだった。しかし今年はコロナウィルス禍の影響で、式自体を延期したり、全員集合の形式をやめて、オンライン配信にした企業も多かったはずだ。新入社員の側も、さぞや不安だったろうと思う。通常であれば、入社式のあとは、しばらく集合研修の形で新人教育を行い、その後に正式に部門配属になる。だが、今年はそれも分散型でオンライン教育が中心になるに違いない。

なにせ「人の和」を重視するのが、わたし達の社会の文化だ。だから顔と顔を突き合わせ、親しさを重ねることで組織を作り上げていくスタイルが、好まれる。そして一斉採用なので、「同期」という絆も生まれる。米国の会社のように、個別採用で、入社したら1時間程度の簡単なガイダンスがあるだけ、あとは業務マニュアルをポンと渡されて、割り当てられた仕事をしていく、という風ではない（もちろん米国にだっていろいろな企業があり、これは一部の例だが）。

日本では、民間企業を始め、官庁・公的機関などほとんどの組織が、『機能型組織』（Functional organization）と呼ばれる形態をとっている。だから、入社して組織に配属されるとは、何らかの機能を担う部署の、ピラミッドの一番下に所属することを意味する。

機能型組織とは、図に示すように、上に役員層（エグゼクティブ）がいて、その下に部門長（ミドル・マネジメント）がおり、さらにその下に部員がいる構造になっている。各部門は、それぞれ異なる機能的な役割を担う。たとえば図では、「設計」「調達」「建設」の例を示したが、もちろん業種業態によって、「営業・製造・物流」だったり、「診療・看護・医事」だったり、いろいろだろう。自分の業種で、読み替えて見てほしい。
誰が決断を下すのか？　〜タスクフォース組織のすすめ_e0058447_07534120.jpg
各機能は、さらに、インプット・業務プロセス・アウトプットが、だいたい決められている。設計ならば、設計の予条件や顧客要求などがインプットで、設計計算や結果のチェックや作図・仕様書作成などの作業を経て、2D/3D-CADの製作図面やモデル、技術仕様書、操作マニュアル、部品表（BOM）のリストなど、アウトプットを生み出す。

こうした機能型組織の特徴は、機能（要素技術）をベースとして、分業によって業務を進めていくことだ。部門（部署）ごとに、担当する仕事の種類が異なる（営業/会計/製造など）。各部門は、その機能的な能力・技術を磨くことで、最大効率を目指す。そして部門内では、能力・スキルや経験年数により、序列がつくられ、秩序をもって運営されていく。

機能型組織の長所は、技術蓄積・継承・業務改善が行いやすい点だ。セールスならば営業部門、設計ならば技術部門、経理ならば会計部門、という風に、仕事を進める技術やスキルの、オーナーシップが明確になっている。そして、とくに製造業の場合、権限（予算執行や人事評価）は、ライン部門長に集中している。

ただし、欠点もある。分業によって部門間に壁ができやすい、部門を超えた人材の流動性が抑えられがち、といった事がそうだ。しかし最大の問題は、複数の部門が協力して当たらなければならないような、緊急の課題や、期限付きの活動が、進めにくい点にある。

拙著『世界を動かすプロジェクトマネジメントの教科書』 では、そうした例の一つとして、新製品開発の事案をとりあげた。ある製造業の社長が、たまたま訪問した先の海外企業のトップと意気投合して、その新興国の市場向けに、共同で製品を開発する約束をして帰ってくる。主人公はその会社で働く若手のエンジニアで、技術部門に属しているが、まだ製品開発をリードできるような立場ではない。ただ、明らかに複数部門が関わらなければ、成功しないことぐらいは分かる。

開発案件の担当メンバーの一員となった彼は、その案件の行く末を心配して、大学時代の大先輩にどうしたらいいか、アドバイスをもらいにいく、という設定である。

だが、なぜ主人公は、そういう心配をしたのか？　もう一度、図を見てほしい。こういった組織図の、縦横を結ぶ線のことを、英語でなんと呼ぶか、ご存知だろうか。答えは、"Reporting line”だ。つまり、文字通り、レポート（報告）する関係を示す線である。具体的に、誰がどの人に対して報告するか（あるいは逆に、指示がおりるか）を、この線があらわしている。

会社の公式なコミュニケーションは、全部このReporting lineに沿って動かすのが、ルールである。線が結ばれていない人同士は、直接、指示や報告のやり取りはしない（食堂や部活でおしゃべりするような、非公式なコミュニケーションは別として）。ある部門の担当者が、別の他の部門の担当者と、なにか依頼や相談をしたい場合は、線に沿って、部門長を経由して伝達する必要がある。

たとえば設計の担当者は、設計部門長にまず書類や事案を上げ、設計部門長はそれを、調達部門長に渡す。調達部門長は、それを担当者に下ろす。これが会社組織の、公式なルールである。それをバイパスしたりショートカットしたりすると、部長から「俺は聞いていないぞ。勝手なことを決めてくるな！」と叱られたりする。なぜなら部門長は、部内の業務すべてに、一応責任を負っているからだ。

ところで、このような会社に、複数部門にまたがって緊急対応が必要な事案が、何かふってわいたら、どうするか？　たとえば拙著にあげたような製品開発でもいい。あるいは今回の、コロナウィルス禍への対策などでもいい。

たとえば図の一番下の点線で囲まれた部分のように、ある事案なりプロジェクトに関わる担当者たちが、何か調整をしなければならなくなったとしよう。その際、彼らは公式なレポーティング・ラインを通してしか、やりとりができない。組織のルール上は、直接お互いに話をすることができないからだ。

しかし、個別の事案の個別の調整を、全部、部長を通して行うのは、果たして現実的だろうか？　部長同士の会議（部長会）なんて、どこの会社でも、せいぜい週に1回か、2週に1回程度だろう。当然ながら、コミュニケーションのスピードが非常に遅くなる。

じゃあ、設計部長が個別事案の相談のために、調達部長や建設部長のところに出向いていって、話すのではどうか？　かりに部長同士が、ちょうど空いている時間をうまく取れたとしても、話し合いの結果、意見が対立したら、どうするか。

日本企業はコンセンサス（合意）で進むのが、基本だ。しかし、それでも合意できなかったら、誰が最終的に決断を下すのか？　まさか、物理的に声の大きい人か？　いや、そんな事はあってはならない（はずだ・・たぶん）。

もちろん組織図上には、「役員」がいる。だが多忙な役員が、個別の事案の調整まで全部、面倒など見きれる訳がない。

ちなみに、具体的な完了条件（ゴール）があり、複数の人が協力する必要があり、そしてリスクがあるような種類の仕事を、『プロジェクト』と呼ぶ。機能型組織では、結果として、複数の機能部門にまたがるようなプロジェクトを進める際に、問題が発生しやすくなる。部門間の課題について、誰が決断を下す人なのか、不明になるからだ。これが、機能型組織の限界だ。

いいかえると、部門横断的に（これをクロス・ファンクショナルといったりする）進めるべき事案が生じても、プロジェクト・マネージャーが存在しないのである。プロマネがいないのだから、プロジェクトの期限（納期）や必要なコストについて、全体を見て判断し、責任を負う者がいないことになる。したがって、プロジェクトの遂行スピードが遅く、誰も終了時期を確約できない状況になりがちだ。

日本の製造業は、機能型組織が強い。逆に言うと、複数の事案やプロジェクトを効率的に回すのには、あまり長けていない、といえるだろう。そしてこの事が、日本企業の競争力を阻害する大きな原因になっているのである。というのも、新製品開発競争や、新市場の開拓、そしてサプライチェーンの海外展開など、部門間を超えて対応しなければいけない課題が、今日では目白押しだからだ。

では、どうするべきなのか？　その答えが、『タスクフォース』型チームの組成である。

タスクフォース(Task force)という言葉は、元々米軍が使い始めた、軍事用語である。日本語で言えば「機動部隊」に相当する。すなわち、特定の課題（Task）に対応するために、臨時で動員した人員組織（force）を意味する。

タスクフォースにアサインされた人は、原則として、もともと所属していた部署の仕事は中断して、その特定課題の仕事に専任する。通常は、執務場所も移動して、タスクフォース・チームとして同じ場所に顔を合わせる。そしてチームのリーダーやサブリーダーの指示の下に、仕事をする。そうして、最終的に所定の任務を達成したら、チームは解散となり、メンバーは元の部署に戻っていく。だからタスクフォースは、時限的な組織である。

これに対して、機能部門はパーマネント（永続的）な組織である。永続的だから、若手の教育研修とか、技術蓄積とか、業務改善といったことにも取り組む。タスクフォース・チームでは、原則としてこういった事は行わない。そもそも、仕事のできない、「使えない」人材は、普通タスクフォースにはアサインされない。きちんと能力をもった選りすぐりのメンバーを、一時的に集めて、機動的に課題に当たるのである。

なお、「タスクフォース・チーム」と、「プロジェクト・チーム」は同じものか、違うのか、という問いがある。ネットを調べると、タスクフォースは短期的で、プロジェクト・チームは長期的な仕事に使う場合が多い、などという解説が出てくる。

だが上に述べたように、時限的（有期的）で明確なゴールがあり、複数の人間が協力して当たらないと成功しないような仕事は、原理的にすべて『プロジェクト』である。だから基本的に、両者は同じものだ。実際、欧米のメジャー企業では、Project task force(PTF)という言い方も、よくしている。

タスクフォースの特徴は、とりくむ特定課題について、責任を任されている事だ。必要な権限と、予算と、人員をつけられている。だからこそ、機動的に判断して動けるのである。逆に言うと、細かいこともいちいち上の判断を仰がなければいけなかったり、予算の執行権がなかったり、勝手に人を引き剥がされたりするようでは、タスクフォースは課題解決の責任を負えない。

無論、予算枠が足りない、人が足りない、といった問題は現実にはありがちだ。しかし、だとしたらタスクフォースのリーダーは、その事実を上位マネジメントに訴えるべきだし、逆に上位の管理者（会社の重要なタスクフォースだったら普通は役員層）は、タスクフォースがちゃんと任務を果たせるよう、支援する責務がある。

タスクフォースでは、リーダーが、強いリーダーシップを持つことが大事だ、といった解説もよく見かける。もちろん、それは大切だ。だが、もっと大切なことがある。それは、

　「チームのメンバーは、自分の元の部署の利害や部門長の命令ではなく、タスクフォース・のリーダーの判断に従う」

という行動習慣を全員が持つことだ。それを周囲も認めることだ。

たとえば自分が物流部門出身だったとしよう。ある時のリーダーの指示・判断が、どう見ても物流コスト的に余計かかりそうだったとする。仮にたとえそうだとしても、タスクフォースにいる限りは、その指示に従う必要がある。もちろん、リーダーに意見を言うことはあっても良い。しかし、最終的な判断の権限は、リーダーにある。

そこで、出身母体の物流部門の価値基準を優先して、指示を実行しなかったり、あるいは物流部門長にかけあって反論したり、してはいけない。タスクフォースのリーダーと、もとの所属部門の部長の意見が異なったら、タスクフォースの指示で動くべきだ。そうしないと、部門間の合意で決めていたスローなやり方と、何も変わらなくなってしまう。

リーダーはいろいろな角度から、課題の全体像を見て、判断するはずだ。もしかしたら、かりに結果として物流コストが上がっても、製造リスクが下がるのかもしれない。どちらにしても、結果に対する責任は、タスクフォースのリーダーが負うからだ。責任と権限範囲は、対応しなければならない。これが組織の原則である。

時限的で、緊急度が高く、集中して取り組まなければならない課題については、ある程度、権限もタスクフォースのリーダーに移譲（集中）する必要がある。それは、一時的な処置である。安定した時期は、部門間のコンセンサスと、公式なレポーティングラインだけで仕事を動かしてもいい。緊急時は、そうはいかない。

ところが、長らく機能型組織の中だけで生きていると、この原則が見えなくなりがちだ。部門間のバランス・オブ・パワーで生きていると、誰かに一時的に権限が集中するのを、反射的に嫌う傾向がでてくる。これが、タスクフォース組織を活かせるかどうかの、一番のボトルネックなのだ。

もちろん、これは、物流のことをろくに知りもしないリーダーが、何でも勝手に決めていい、という意味ではない。そのために、物流部門から「仕事のできる」メンバーをタスクフォース・チームに入れてもらったのである。そのメンバーも、物流の観点から課題を考え、影響を考慮し、リーダーに提案しなければならない。

つまり、タスクフォース組織を組む際には、影響のありそうな関連機能の部門から、なるべく広くメンバーを入れる必要がある。課題やプロジェクトに利害関係を持つ人のことを『ステークホルダー』と呼ぶ。タスクフォース・チームは、外部のステークホルダー（つまり社内の関連部署の部門長たち）から、やいのやいのと助言だの苦言だのをもらって右往左往せずにすむように、あらかじめステークホルダーの技術や知見を「内部化」しておくのである。

逆に言うと、機能部門長は、タスクフォースに人を出してほしいと要請された場合、余っている人を出すのではなく、ちゃんとした能力を持つメンバーを出す必要がある、ということだ。これもまた、多くの日本の組織では、言うは易く行うは難し、である。部門長は、自部門の都合を第一に考える習慣が強いので、有力なメンバーを割かれるのに抵抗感を持つからだ（それに、大抵の組織では、そもそも有能な人が足りない）。

また、上記に関連して、タスクフォースは、独立した予算枠と執行権を持たなければならない。特定課題に関連する物流コストがアップしても、それは物流部門の成績に集計されるのではなく、タスクフォースのコストになる。こうして、外部からの独立性を担保するのである。

上に述べた拙著『世界を動かすプロジェクトマネジメントの教科書』のケースでも、本当は、共同製品開発のためのタスクフォース・チームの設置を、すぐに社長が命じるべきだったのだ。だが、社長はそういう事をしないで、案件を、ただ機能型組織に任せた（丸投げした）だけだった。誰がプロジェクト・マネージャーで、どう決断していくのかすら、分からない。そういう状況下にあって、主人公がどう動くか、またそれを助けるための組織的な形態は何か（著者としては実はこの部分の解決に苦労したのだが）、ご興味があればぜひお読みいただきたい。〜以上、コマーシャルの時間でした（笑）。

ともあれ、まとめよう。タスクフォース・チームとは、特定の課題を解決するために、時限的に集められた組織である。それがちゃんと機能して活きるためには、守るべき条件がある：

(1) タスクフォース・チームは、独立した権限と予算執行権を持つ
(2) 幅広い関連部署から有能なメンバーを集める
(3) 各メンバーは（出身部署の利害代表者として動くのではなく）、タスクフォース・チームのリーダーの決断に最終的に従う

このようにして、機動的な部隊を動かし、「誰が決断を下すのかわからない」状態を避けるのである。

ただし上記の「幅広い関連部署」を考える際には、ある問題や対策が、どこまで広い影響範囲を持つのかに関して、きちんと豊かに想像力を働かせる必要がある。想像力と書いたが、それは、物事の依存関係（連鎖的な因果関係）を、幅広くたどっていける論理的な思考能力である。

いいかえると、タスクフォースを成功させるためには、『システムズ・アプローチ』が大事だ、という事だ。じゃあ、そのシステムズ・アプローチとは何か、という話になるが、これはまた深い議論が必要なので、別の機会にまた書こう。


＜関連エントリ＞


by Tomoichi_Sato | 2020-04-07 08:18 | B2 スコープ・WBS・プロジェクト組織 | Comments(0)
<< 「プロジェクト＆プログラム・ア... 書評：「ザ・クリスタルボール」... >>

ファン申請

※ メッセージを入力してください