シスエン導入がうまくいかない典型例
プロジェクトとシステムズエンジニアリング
書籍のPhase10によくあるシスエンの失敗例をいくつか挙げています。
その中でももっともあるあるかな、と思うものをあらためてブログで共有したいと思います。
https://amzn.to/47vPJkM
システムズエンジニアリング（以下、シスエンと略します）の導入において頻繁に見受けられる失敗要因の一つは、プロジェクトのリーダーとシスエンのリーダーの考え方の不一致です。
システムをエンジニアリングするリーダーが同時にプロジェクトの意思決定者も兼務することは一般的であり理想的と言えますが、スケールの拡大に伴い、両者の兼務が難しくなります。各々の役割が広範でかつ複雑になるからです。
この状況下でプロジェクトマネジメントとシステムズエンジニアリングのリーダを分けて作業することが現実的な解決策となりますが、これが新たな問題を引き起こすことがあります。
システムを確実に開発するためには、「フロントローディング」と呼ばれるアプローチが必要です。これは上流での検討を通じて各段階での計画が実現可能か確認しながら進む手法です。同時に、システム全体を俯瞰し、内部構造の開発チームにおいても適切な役割分担を行うことが重要です。これによって品質向上と開発効率の向上が期待できます。
この意義を理解しているシスエンのリーダーはどの順番でいつ何を開発していくかを検討しますが、プロジェクトのリーダーがシスエンの理念を理解していない場合、問題が発生します。
プロジェクトのリーダはフロントローディングの必要性を頭では理解しつつも、実際の取り組みにおいては過去の開発よりも膨大な工数がかかることに対する焦りを感じます。
この状況で進捗が遅く、工数が増大していることに耐えかね、プロジェクトのリーダーは理想論はさておき、「進捗が悪いならば、フロントローディングをやめて早く設計段階に進めるよう」に指示することが本当によくあります。
シスエンのリーダーはそれをやめるように提案しますが、プロジェクトのリーダーの立場や決定が優先される場合、これを防ぐのは難しくなります。このケースが非常に多いのです。
また、開発チームのアサインにおいても問題が生じることがあります。システムの機能分割と開発チームの体制が一致していれば、開発効率がとても向上しますが、プロジェクトの体制を決定するのはプロジェクトリーダーの責務でもあります。同じくプロジェクトリーダがシスエンの理念を理解していないと、プロジェクトリーダーがざっくりと頭の中でシステムを描き、部署や担当者を割り当ててしまいます。さらに、システム全体の検討を省略し、あなたのチームはこの機能とこの機能を開発してください、と、機能分割までを最初から定めるケースも見受けられます。こうした状況では、システム全体の重複や漏れが発生し、コンフリクトやミスが起きるか、すり合わせに多くの工数が費やされてしまうのです。
本来、システムをQCDの観点からコントロールする役割と、手順や技術のコントロールを行う役割は同じものを作り上げているため、考え方と進め方が完全に一致していなければなりません。
しかし、これまでのプロジェクトではプロジェクトのリーダーが優位に立ち、プロジェクトリーダがシスエンの考え方を理解できていい場合、シスエンの実践が阻害されてしまうことが本当に多くありました。
このケースはプロジェクトリーダだけではなく、部長やグループ長など、組織のリーダがある意思決定権を持つ場合も同様です。
この問題に対処するために私の提案は、システムズエンジニアリングとプロジェクトリーディングチームの結成です。このチームがプロジェクトの最高意思決定機関となり、システムの開発を効率的かつ高品質に進める役割を果たします。
これをやり切るには、プロジェクトとシスエンにおけるリーダーだけでなく、それを指名する上位マネジメントの強い意志と権限委譲がが不可欠です。
なかなかできない、と思いますが是非がんばってみてください。
今日、航空宇宙の業界でシスエンを長きにわたって取り組まれてきた大ベテランのかたにお話しを伺う機会がありました。かつて日本の産業が勢いがあり、海外が負けていた時代に、それを乗り越えようとしてシスエンが海外で広まったそうです。
その結果が今の状況です。海外ではシスエンで学位の取れる大学が普通にあるそうです。
日本はたったの数校だそうです。
いつまでもコンフリクトや抜け漏れ、後工程での混乱をやっている場合ではありません。
日本の製造業が世界で力を発揮するためには、システムズエンジニアリングの定着は不可欠です。
どうか皆さん、モノづくりをもっとステキに！していきましょう。
Comments are closed