概念的な考る力の習熟度を測ることは難しい

見積もりとプログラミング
見積もりのレビューやプロジェクト計画のレビューをしていて感じていることは、見積もりしている案件をどのように捉え、どのように形作っていこうとするのか、形のないものから概念を作り出すことに苦労をしないエンジニアと概念化することに手が止まるエンジニアと両極端に分かれるということだ。どちらかというと、概念化できる力を持っていないエンジニアの塊の方が大きい。概念化できる力を持っていないエンジニアの技術力はどうかと言えば、プログラミングのコンピテンシは十分持っており、技術的にも全く問題なかったりする。
多くのエンジニアは、ひとりの担当エンジニアから経験を積み、何人かのエンジニアのリーダになったり、その先にはプロジェクトのリーダをするキャリアパスを目指すだろう。ひとりの担当エンジニアなら自分の範囲のプログラミングをしていればいいのだが、ステップアップしていくと、担当する業務が曖昧なことを具体的なイメージに変換するような業務も担当するようになる。そのとき、それまでプログラミングで必要としていた能力と違う、概念的に考える力がより必要になってくる。

それは、進め方、段取り、ストーリー
機械が相手ではなく、顧客と接し、顧客の曖昧模糊とした表現やRFPなどの行間から、見積もりをする場合、言葉からイメージ化する概念的に考える力が必要になる。プログラミングのときは、前工程で作成した仕様書があるから、枠の中だけでプログラミングも出来たが、口頭や文書の概念から具体的なイメージに落とし込みをするときに、その力の技量がはじめて露呈し、行き詰まるエンジニアが度々現れる。
そのようなエンジニアが見積もりやプロジェクト計画を作るとdeliverablesのイメージが定まっていないから、そのdelivarablesを作るための自分達の中の進め方や、その段取りに思慮が足らず、とてもではないが合意することが出来ない。自分達の進め方の軸がないから、顧客とのすりあわせも思うようにすすまない。
大概、このような事象はレビューになってから発現することが多く、−それはそうだ、レビューアはすべての技術者を知るわけではないのだ−、それをリカバリするのは大変な苦労になることが多く、そのような場面に直面するたびに概念的な考る力の習熟度を予め測ることができたらなぁと思うのだ。