問題は解決するな！？(VA/CDとシステムズエンジニアリングの考え方)
「意識」がうまくいかないことを創り出す？
日々の業務の中でうまくいかないことばかりだと感じていますか？
うまくいくことよりも、うまくいかないことの方が少ないと思っていますか？
本当に、うまくいかないことばかりなのでしょうか？
人間は見たいことしか見ない、聞きたいことしか聞かないと言われています。
人間は意識で物事を見たり、聞いたりしているという事です。
例えば、よく通る街中でコンビニに意識を向けるとあちこちにコンビニがあったことに気がついたり、春に今まで気がつかなかった桜の木に目がいったり、賑やかの居酒屋で会話が出来たりするのは、意識が見たいものや聞きたいことを選択しているということではないでしょうか。
つまり、意識がうまくいかないことに向かっているから、うまくいかないことばかりが見えたり、聞こえたりするのではないでしょうか。
見えたり、聞こえたりすることは今ある現実ですから、意識がうまくいかないことを創り出していると言う事ができるのではないでしょうか。意識は重要なのだと思います。
「問題」を「課題」に再定義して、最適解を求める
長い間の教育・学習の効果（刷り込み？) で、私たちは「問題」と聞くと反射的に「正解」がある、「正解」を出さなければと感じてしまいます。「問題」に対して「正解」を出すと○をもらい、それ以外の解は不正解で×とダメだしされてしまいます。日々の業務の中で「問題」を創り出して、「正解」を出そうとしていませんか？
優秀なエンジニアであればあるほどこの「問題」と「正解」への意識は強いのではないでしょうか？
日々の業務での「問題」って何でしょうか？その「問題」の「正解」って何でしょうか？
「問題」に対して「正解」を出そうとする意識がさらに「問題」を難しくしていませんか？
「問題」を解決すると新たな「問題」が生じるとは、よく言われることです。例えば、Software開発でのバグ修正では、バグばかりに意識を働かせて修正を加えると全体のバランスが崩れて、新たな更に大きな不具合を創り出すことはよくある話ではないでしょうか。「正解」への意識が、新たな「問題」を創り出しているということだと思います。
一方で、「問題」と同じような意味で使われる「課題」という言葉があります。
同じような意味で使われることが多いのですが、「問題」と「課題」は同じでしょうか？
「問題」とは違って、「課題」と聞いたときには、「課題」に対して「正解」を出すことに意識を結びつける人は少ないのではないでしょうか。「課題」に「正解」は必要ないと感じ、大きな解の広がりを感じませんか？
「問題」には、過去やマイナスのイメージを感じ、「課題」には、未来やプラスのイメージを感じるのではないでしょうか。「問題」は部分最適化であり、「課題」は全体最適化といったイメージも浮かんでくるのではないでしょうか。
「問題と同じ次元には（真の）解はない」と言われたりすることを、聞かれた事のある方もいらっしゃると思います。
ここで言う「次元」とは何でしょうか？どうすれば、異なる次元に移れるのでしょうか？
エンジニアの直面する「問題」で、一番は多いのは、「二律背反」ではないかと思います。様々な「二律背反」を経験されていると思いますが、どのように対応されてきましたか。
例えば、非常に一般的な機能とコストでの「二律背反」、機能を盛り込むとコストがUpすることへの対応は、VA/CDの真価が最も問われる、当たり前すぎる案件ですが、どのように対応しますか？
まずは、見えていることに囚われないことではないでしょうか？見えている機能とコストに囚われて、「問題」と認識すれば、「問題」と同じ次元で解を探すことに陥ります。
では、どうするか？「問題」を「課題」に再定義して、最適解を求めていくことになります。システムズエンジニアリングの考え方と手法の登場です。
非常に簡単に言えば、機能とコストを俯瞰し、構成要素と構成要素間の関係性を整理していくことで、最適解を探し、検証していくという手順を取ります。
目の前に見ていることを俯瞰するのは、次元を変える一般的な手法になります。
次元を変えるということが、見えていることを「問題」から「課題」へ再定義する入り口になります。
開発初期段階からシステムズエンジニアリングの考え方を取り入れましょう
では、俯瞰するとは、どんなことでしょうか？よく言われるのは、「俯瞰＝鳥の目」です。
地面の上で目の前に見えていることに向き合うことから、空の上から同じことを見ることに視点を変えることで次元を変わるということです。
なんとなくイメージできましたか？このイメージいただいたことを「二律背反」というエンジニアの「課題」に適用させるのが、システムズエンジニアリングです。
もちろん「俯瞰」だけが次元を変えるためのものの見方ではありません。利害関係者の視点を取り入れることやそもそもの製品やサービスのコンセプトに立ち返ることもシステムズエンジニアリングの重要な考え方になります。
次に、構成要素と構成要素間の関係性を整理することになります。
ここで、重要なことは、構成要素も見えていることに囚われないということです。
要求から引き出された機能を実現するための物理的要素が構成要素であると考え、ここでも次元を変えることを意識して、構成要素と構成要素間の関係性を整理していくことを行います。
ここまでの取り組みをどのように感じますか？
これを後追い、製品開発が終わった時点で行うとすると、なんと非効率的だなと感じているのではないかと思います。重要なのはそう感じてもらうことです。
開発の最初から、この取り組みを行えば、効率的にVAできると思いませんか？
Running Changeの観点からは、効果額とか削減額といった指標で成果を測定すること、VA/CDでのコスト管理を評価していたのかと思いますが、今は原価や売価への考え方も変わってきており、最初の段階からコストを創り込む考え方を取ることが最適であると考えられています。これらを具体的に取り組むこと、システムズエンジニアリングの考え方や手法を製品開発が終わってから、後追いで行うのではなく、製品サービス開発の段階で取り組むことへの提案が「VA/CDのためのシステムズエンジニアリング」です。
（ミームテック技術士事務所 室橋 雅彦)
◆より具体的な考え方と手法にご興味のある方へ [関連セミナー情報]
