システムエンジニアは、体系的に考えることを訓練しなくてはならない

システムエンジニアは、体系的に考えることを訓練しなくてはならない。そして、実践できなければならない。まだ、あなたのエンジニアキャリアが数年なら体系的に考えることが必要なときがくることを頭の中に記憶しておこう。

設計書を書くのもシステムエンジニアの仕事の一つだ。だから、書く。書けと機能を渡されたら苦も無く調べることは調べ、聞くことは聞き、そして設計書を書くことが出来るだろう。それは、渡された責任の範囲を遂行するだけの力量を持っていると期待されているからだ。期待される技量と持ち合わせる技量のギャップはあるだろうけれど、期待値に届かない技量しかないかもしれないけれど、それにチャレンジする気持ちがあるならas isの技量を正しく伝えた上で、ギャップのリスクを共有して遂行するだろう。

でも、その仕事はもらったもので部分でしかない。全体は知らないわけだ。木しか知らない。森は仕事を任してくれた人にしかわからない。

システムエンジニアには意外と、与えられた仕事はできるけれど、体系だってモノを整理したり、分界したりすることがスッと出来る人がいない。意識していないからそれを考えもしない。

人は意識して行動をして失敗して工夫して諦めず繰り返すことが出来る人か出来ない人かに分かれる。それができる人は、あとはそれに何を載せるかだけの違いだとしか思っていない。

全体を考える、体系的に考えるとはとても難しいことだ。何を持って全体とするか。体系的に考えられるということは、一度は体系的に一度森を見ているからというバックグランドが必要だ。無から生み出すことはそれこそ無謀だし、出来るとするならそれは我流でしかない。いや我流でも構わないけれど、すでに世の中にいくらでも出回っているものならそれと全く違うような構成で体系を考えるのは思考に制限を設けるように感じるかもしれないけれど、その思考したものは誰かに伝えるコンテンツであるのだから相手の理解を得ようとするならば、これまでのナレッジの上に立たざる得ない。それは嘆くものではなくて、等価の理解を得るために必要なことだ。

何れにしても、体系的に考えることが出来なければ全体である森を知ることはできないし、上流工程なら全貌を見渡すこともできずにこの先プロジェクトがどうなっていくか行く末を知ることなんてできるはずがない。そして、大体あてずっぽうとしか言いようがない計画ははずれる。これは絶対に言えることだ。そんなで当たらない。そもそも当たる外れると表現するものでもない。賭けをしているわけではないのだから。

言い換えよう。予測したとおりの未来と現実にどれだけ較差があるか否か。その較差を生む一つのファクタが体系を知っているかどうかだ。体系を知らなくては抜け漏れにより較差を生む。

なら、どうしたらよいだろう。ワタシの経験から言えば、知りもしないモノなのだから、書籍、インターネット又は参画したプロジェクトで得られるナレッジを寄せ集めるほかない。それは自分で自分用に育てるほかないのだ。経験だけだと、担当した工程の構成しかわからない。手を広げプロジェクトの全体の構成を手に入れられるのならそれはナレッジそのものだし、そのナレッジでもプロジェクトによって要件定義から受入試験までカバーしているかどうかは契約に依るのだから。そうやって育てるほかないのだ。

そして章立てや構成のレベルを調整しながら、そのときのワタシの体系としておくのだ。そのとき必ずココロに置いておかなければならないことは、このワタシの体系は知っていることだけの体系であってまだまだ知らないこともあるかもしれないのだ、と言うことを。

それを忘れなければ、ワタシの体系をベースラインにモノを考え、知らないことを知れば補完することが出来るので今いる立ち位置に関わらず森の中のどこにいるのか迷うこともなく穏やかにプロジェクトに打ち込むことが出来るに違いない。

そうそう、設計書なら必ずインプットがあってアウトプットがある。だから、入ってくるものと出ていくものが途中で加工されるにしても紐づいている。その紐づいていることがわかる様にしておこう。