エンジニアが得意でない考え方を共有することのメリット

TLに流れてきたモノゴトの候補群から採用する際のロジックを作る(=ルールと表現しても良い)という考え方がとてもしっくりしてというか、わたし自身の考え方と似ていて好感を持ったことがありまして。

 

エンジニアのお仕事って最終的に判断するのは顧客だったり、チームの中ではプロジェクトマネージャだったり、アーキテクトとロールとして権限=最終責任を負える役割の人がするのだけれど、そこに行く過程で多くの判断の積み重ねを繰り返していて、そのほとんどがチームの一人ひとりのエンジニアが担っているという事実をエンジニアはもう一度、理解し直すべきだと思うのです。

 

ときどきどうしたものかなーと思うのは、ただただリーダ役や顧客に判断を仰ぐエンジニアを見かけるときなんですよ。あれ、本人は仕事を進めたいからというか、仕事が進捗しないと責められると思っているので必死なのかもしれないですけれど、システムの専門家としてはどうかなぁ、と。

 

例えば、システムの仕様について判断を得たいとすると、その仕様には様々な解決手段があるわけです。適用する技術が存在するだけ。実際には、想定している前提事項や外部からの制約条件で絞り込みされて、それでもまだいくつかの選択しか残る。

 

じゃあ、それを選べと言われた顧客が選べるかといえば、それは専門家でないのだから、技術的な観点での判断を要求するのは無理強いなことをしているだけなのです。そりゃ決められなくてずるずると進捗がスリップするわね。

 

エンジニアも仕様などを考えるときに、多くの情報を揃えて色々と考えて仮説を立てて仕様の合意に至ると思っているのですが、-さすがに思いついたポッと出のアイデアをそのまま仕様にしたりしていないですよね-、その過程では、それを考えるタイミングで確保できる情報をベースに制約条件と前提条件などや機能の振る舞いとしての事前事後条件を含めて仕様のあり方を図式化と言語化していると思うんですよね。

 

で、このケースは良いだとかこっちのケースは要件が実現できなくてダメだから、と判断のステップを踏んでいるのだと思うわけです。

 

それを明示化して共有したらどうなんでしょうか。

 

所詮、隠すことは何一つないのですよ。お金は顧客にもらっているのだし。まあ、1から10まで洗いざらい晒されても顧客はどうして良いか困りますけどね。

 

でも、仕様の考え方、ロジック(と言っても仕様の中身ではなくモノゴトの決め方)を説明してその上で、相談相手に期待する役割をしてもらえば良いのですよ。

 

そのロジックは日頃ブログで書いているトップダウンで考えようというのに結びつきます。概念から説明して行くとそれの判断を求められる方も情報が大局から掴めるので追いついていけるんですよね。それがボトムアップでしたら積み上げようとすると仔細な仕様だと詰めきれていないことが多くてそこにアラが出てあら探しになってしまうので。