全6474文字

どこまで現場に指示を与えるか

トップダウンの米国流がよいか、ボトムアップの日本流がよいのか、という議論は昔からありますね。

玉塚:それに関連して神武さんに伺いたいことがあります。唐突ですがシステムデザインはアメリカンフットボールの考え方に似ていませんか、という質問です。

 ボールを追う格闘技という点はラグビーもアメフトも同じですが、アメフトの場合、ワンプレイごとに攻守が入れ替わり、そのつどヘッドコーチが細かく指示を出します。選手の役割も明確に決められています。

 ヘッドコーチが司令塔になってトップダウンでチームを動かすアメフトを観ると、社員のジョブを明確に定義し、CEO(最高経営責任者)が指揮をとる米国企業に似ている気がするのです。システムデザインもひょっとしたらアメフト型ではないかと。

 というのも、アポロ計画を成功させたのはシステムデザインのおかげだと聞いたからです。宇宙や軍事に関わる巨大システムをきちんと開発し、動かそうとすると、アメフト型になるのではないかと思ったのですがいかがでしょう。

神武:まずアポロ計画についてお答えしますと、成功したのはそのシステムの中でロケットエンジンが凄かったからでも、制御ソフトウエアがうまくできていたからでもなく、全体が良かったからだ、と評価されています。全体が良かったとはシステムデザインが良かった、つまり必要な要素を適切に実現し、適切に組み合わせていたということです。もちろん、エンジンもソフトウエアもそれぞれ素晴らしかったわけですが。

 システムデザインにおいては、要素ごとの細部にこだわりながらも、まず全体を俯瞰して考えますから、トップダウンのアプローチとみなせます。ただし、限られたごく少数が逐一決めて指示していくのかというとそれは違います。

 いわゆるスーパーPM(プロジェクトマネジャ)やスーパーエンジニアが仕切る時代ではもはやなくなりました。そういう意味では、システムデザインの世界もラグビー型になってきていると言ってよいでしょう。

 なぜなら、ロケットに限らず、最近のシステムは複雑なものが多いからです。組み合わせる要素の数が増えた上に、自分のところの要素と遠隔地の他の組織にある要素とをネットワークを介してつなぐこともあります。しかも状況は常に変化し、それに応じて判断していかないといけません。

企業経営について言うと、チームのビジョンや方針、作戦を考える役割と、それらを腹に落として実行する役割が必要で、しかも各自の役割は固定ではなく、両方の役割を臨機応変に担うということですね。

日本企業が一番求めている人材

玉塚:日本企業に今、求められている役割は特に前者です。色々な要素をうまく組み合わせて新しいビジネスをプロデュースしてほしいと企業経営者は皆、思っている。その一方で既存のビジネスについても要素をうまく組み換え、更なる成長軌道に乗せていきたい。ですがいずれの担い手も足りない。

 もちろんそれぞれの要素も、そこに長けたエキスパートも大事です。製造業の社外取締役をしているのでよくわかりますが、日本の現場の匠の技はやはりすごい。

 とはいえ、よく指摘されることですが、要素ごとに改善する力は高いものの、要素をうまく束ねて全体をデザインし、大きなアウトプットを出すところが課題です。まさにシステムデザインですね。そのためにどういう力がいるのでしょうか。

神武:煎じ詰めると物事の本質をとらえる力です。システムデザインを説明するとき、「森を見て、木も見る」という言い方をよくします。森の中には丘があるかもしれないし、川が流れているかもしれない。色々な要素が絡み合っていて複雑です。

 その中から重要なところ、本質的なところを取り出す。その上で本質同士がどういう関係にあるかを理解する。これを「システム思考」と言います。

 本質の関係をつかめるとシステムを抽象化したモデルをつくることができます。システムやそのシステムが置かれる環境が複雑な場合、モデルを使ってシミュレーションをすることで、検証をしたり、顧客に求められているものなのかどうかを確認したりできるようになります。

 本質をとらえたシンプルなモデルを実現できるかどうか、反対に、本質的ではないものは省略できるかどうか、そこがポイントです。

玉塚:まさに経営そのものですね。色々な要素を抽象化してとらえ、システムとして考えられるメンバーを集め、チームを作り、そこに経営トップも入って議論する必要があります。

「Vモデル」で考える

抽象化して考えるものの、最後は実際のシステムをつくって動かすわけですから具体的な仕事になるわけですよね。

神武:もちろん、森を構成する丘や川、林のそれぞれを緻密につくることも必要です。システムデザインの考え方をまとめた「Vモデル」というものがあります。Vモデルにまとめられた考え方は大きく、「分解」と「統合」に分けられます。

 分解とは、「何らかの目的を達成するために複数の要素を組み合わせたものとそのつながり」であるシステムが、どのような要素で構成され、相互作用すると目的が達成されるかを考えることです。

 統合とは、実際にそれぞれの要素が適切に実現され、適切に組み合わさっているか、それを確認していくことです。Vモデルは、分解と統合を俯瞰的に、そして緻密に実施していく考え方が大切だと示しています。

玉塚:分解そして統合と、順を追って進めていくとなると、大事なところを繰り返しつつ、素早く設計し開発するアジャイルと呼ばれるやり方に合わないのでは。

神武:Vモデルというとシステム開発の手順を示したものと理解されることもあるのですが、必要となる考え方をまとめたもので順番を決めているわけではありません。順に実施してもよいし、必要なところを繰り返し実施してもよいし、Vモデル全体を繰り返すこともできます。

 ですからアジャイルと矛盾するものではないのです。繰り返しになりますが、分解と統合、抽象化と具体化を意識して考えることが重要です。

 どのようなやり方をとるにせよ、大きいシステムをつくるとき、チームの関係者がその議論の位置付けを理解し、議論の内容を共有していることが大切です。例えば、ある要素を設計するメンバーは自分が担当する要素の機能に加え、システム全体の機能も把握した上で考え、議論しなければなりません。

 経営トップや事業部門の幹部だけではなく、現場のメンバーも全体を把握し、その上で自分が担当する仕事を考え、判断するわけで、確かにラグビー型と言えるかもしれませんね。