システムエンジニアが技術的な痴呆症にならないために

何も知らなければ言われたとおりに仕事をするだけ。だって、疑問を持てないから。天性の感覚・嗅覚でオカシイと気付くことができてもそれをそれを説明することはできない。だって、何と照らしてオカシイのかその比較元を知らないから。

システムエンジニアになっているということは大学なり専門なりで勉強をしてきたはずだ。学校での勉強は、知らないことを知る学びの方法を身につけるために時間を使ってきたのだ。

さらに言えば、自分が知識の観点で満足するポイントを知る機会を広く得て試してきた時期でもある。どんな知識エリアに自分が関心を持つかそれを知っていることは自分の中での判断軸になったり、精神的な平静を保つためのものでもある。

仕事についた頃は、仕事の仕方さえ知らないから先輩の言うとおり、指示とおりに仕上げることが仕事になる。納期までの言われた要求された品質で完了させる。それがそのときの仕事なのだ。

経験を重ね仕事の一部分でも任せられるようになると自分で考える時間が増えていく。そこで初めて自分が習得した方法論や技術を主体的にどう適用するのがいいのかを考えるようになる。

インプットする情報をいかに要求されるアウトプットに変換するために方法論や技術を適用することが求められる要求に対してよいかを考える。得てして、システムエンジニア自身の感情・感覚でその変換方法は選択される。

もちろん、この変換方法は間違いである。システムエンジニア自身の感情・感覚は二の次にしなければならない。それよりも求めれているアウトプットの要求は適切なのかを見ることを優先しなければならない。

そこで必要になることは方法論や技術が適用ありきでないこと。頭から決め打ちでないこと。仮置きはいいけれど、それがアウトプットの要件に照らせば適当でないこともままある。

アウトプットの要件は元を辿れば業務要件、さらにビジネス要件まで遡る。要件はいきなり実装に変換する手段をまだ誰も持っていないから局面やバックログの体で噛みくだされその度にバイアスがかかっていく。

そうしたこともあると知って変換方法を選ぶか知らないで選んだり自分の独りよがりで選んだりすることが良いかの判別ができるかどうか。そのはんべにつに必要なことは方法論や技術でしかない。

その方法論や技術が他の誰かが作ったものか自分の経験を経験値から形式知に変えたものかはどっちでもいい。客観的に使えればいいのだ。そのためには、持ち合わせだけの方法論や技術だけでは陳腐化するのだ。

一人のシステムエンジニアが習得する方法論や技術なんてたかが知れていることを認識することだ。そういった意識がなければあっという間に技術が進んでしまい取り残されまるで技術的な痴呆の状態になってしまうのだ。

技術的な痴呆症にならないためにも方法論や技術の向上・更新をする必要があるのだ。