システムエンジニアが上流をやり抜くために必要な二つのメジャーという考え方

on

システムエンジニアで上流といったら、企画から基本設計（システム方式設計）くらいまでのイメージが一般的に言われている範囲だと思うのでそれを前提にして進めます。「違うよ」と思ったら、ここではそういう前提なんだ、くらいで。

システム開発をざっくりと言えば、要件というモヤっとした状態から文章と図表に置き換えるのが上流設計で、文章と図表をプログラムに変換して動くものにするのが下流工程です。だいぶ、乱暴な言い方ですけど。

上流というか要件に近くなればなるほど、実現したいシステムはモヤっとしたイメージしかなくて、リリース前のテストのタイミングになれば要件を具現化した状態に近くなります。リスクを不確実という捉え方で図にしたものが「不確実性のコーン」というものです。

話を戻して、もやっとしたイメージを段階である工程を追うごとに実現したい要件の仕様を決めていくやり方がウォーターフォールなのですが、このときに必要になるのは二つのメジャーを使う、ということです。

一つ目のメジャーは、モヤっとした要件をきいて、自分の経験値や形式知に近いシステム方式を選択して、要件を実現できる方法の候補を選ぶことになるのですが、ここで、自分の持っているメジャーを使って選択をします。

なぜ自分のメジャーをつかうことが必要になるかというと、システムエンジニアとして専門家の知見が求められいるからです。更に言えば、自分の持っている経験値や形式知という軸を持って判断をしないと外部から突っ込まれるたびに一から考え直すことになって、導き出される結果が根拠のないものになってしまうからです。

二つ目のメジャーは、自分の持っているメジャーで選択した候補を伝える相手、通常は顧客ですが、そうしたステークホルダーと共通の理解ができるメジャーでプロットし直すために必要になります。ITの知見がなくて専門家のシステムエンジニアにアウトソースしているわけですから、要件を持っているドメインの顧客と理解ができる共通言語に置き換えるために二つ目のメジャーが必要になるのです。

とは言え、この二つ目のメジャーを持つことはちょっと難しいかもしれません。いきなり、二つ目のメジャーを作ろうとはせず、少しずつ意識してトライアンドエラーをしながら、使いこなしていくのが良いかもしれません。