エンジニアとして“コイツだめだな”と思う瞬間

on

ITエンジニアリングは不確かなことを確かにする
ITエンジニアリングは、顧客のビジネス要求を形のないソフトウェアとして確かなモノに形作るのです。要件定義や基本設計の上流工程であればあるほど、もやもやふわふわした要件と格闘して後続工程のインプットに変換していきます。

エンジニアも経験を積み期待の成果を出せるようになれば、上流工程の一部から携われるようになります。上流工程の一部を任されるということは、もやもやした要件やふわふわした要件から次工程のインプットに変換することを期待されます。
そりゃそうですよね。工程ごとにインプットの情報を持ち込んで、プロセスで加工して、次工程のインプットで使えるように段階を追って実現イメージに近づけていくんですから。

それがどうもわからない人が居るんですね。何をして欲しいか作業説明していても、工程の作業の意味が理解できないのか、どうなのか。

確かに、下工程ならそれでもよかったんですけどね。例えば基本設計では詳細設計が出来るように機能設計や非機能設計しているので、それを見てコーディングできるように振る舞いを決めていけばよかったわけですから。

基本設計ですでにふわふわな要件はシステム化するために枠を嵌めているのでコーディングするための仔細な仕様があっちにいったりこっちにいったりするようなことは無いわけです。あくまでも、枠の中だけに制限されている。制限されると言うか、仕様として動きを決めていくのですね。

下工程をやるなら決められた枠の中で考えればいいので、ある程度物事が大体決まった上でやればいいんです。ところが上流工程はそうは問屋が卸さない。そこにギャップが生まれる。

不確かなことを手探りしながら決めてくのが上流工程の作業です。スパッと決められることもあるでしょうが、そうもいかないこともあるものです。システムなので最後は動くしくみにしなければならないわけですが、決められないこともある。だから、今はこれで、と顧客と合意しながら方向性を共有し、ちょっとづつ進めるほか無い。

もちろん、スパッと決められて進められるものは進めますが、全部がそうは行かないんだ、そのとき、不確かなものを確かにするためにどう進めるかが、その進め方に合わせてやるしかないんです。


不確かなことを確かにするために必要なこと
不確かなことを確かなことに変換するためには、スパッと判断できることを除いて、もう、仮置きして、合意してちょっとづつ進めるほかないのです。

その進め方には、方向性を誤らない程度に枠を嵌めるけれど、それは緩いもので進めている途中では、大幅な方向転換だって置きうる可能性を秘めていることはプロジェクトのリスクとして認識しておくことは勿論、作業の担当者であってもそういったこともあるんだ、と理解してかからなければなりません。

そう考えておかないと、ふわふわした要件を現実のしくみに変換することに下した判断だからこそ、変更も十分あるし、その解決の方法についてはいくつかの選択肢からその時点では適当な解決案を比較検討の場を経なければ危なくて仕方が無い。

ダメだなと思うエンジニアは、このような状況下であっても比較検討するようなことをせず、思いついたアイデア一つに絞り、しがみついてしまう。

状況が変わることが誰だって想定できるのに、オルタネートの案を持ち合わせようとしない。情報や状況が判然としない最中にその瞬間での判断は常に変化していくことを前提としておかなければ方針転換が起きたときに対応できなくなってしまうのです。





  • 道具室(アプリとか)
  • 音楽室(PCからリンクをクリックするとき、PCにiTunesが入っているとアプリケーションが起動します）
  • 視聴覚室
  • 調達室