SEに本当に必要なのは、聞き、考え、書く基礎スキル

まぁ、みなさんご存知のとおりシステム開発は要件を聞いて、方式を設計して、実現仕様を明らかにして、日本語や図表をソースコードに置き換えて、設計した仕様どおりに動作するか検査した上でお客さまがご利用されるわけです。

いきなり、要件を聞いたらソースコードを書くなんてしない。してもいいけれど、要件からいきなりコードを作ってどうぞとやっても「これじゃないよ」と言われるのが落ちかと。なぜなら、要件を知っている人がソースコードを書いていないから。

（要件を）聞く、（要件を）理解する、（仕様を）考える、（仕様を）確認する、（実装を）考える。（ソースコードに）書き換える、（仕様からテストを）書く、（仕様どおりか品質を）確かめる、（要件どおりか）確認する。

聞き、考え、書く。

改めて見直してみるとほぼコミュニケーションをしているのだなぁと気づくものですね。

「聞く」は要件を聞く、考えた仕様が要件どおりか確認するために聞くだし、「考える」は要件を理解する、仕様を考える、実装を考える…ずっと考えるだし。「書く」は仕様を書く、ソースコードを書く、テスト仕様を書くだし。

システム開発に必要なのは読み、考え、書くという３つの基礎スキルがどれだけ大事かということなんだろう。その基礎スキルは割と蔑ろに扱われ過ぎていないかな、と。

みんなが大好きなプログラミングはたった１回しか登場しない。ブームのCIも出てくるのは１回だ。現実は、要件にも仕様にもソースコードにも間違いが混入して繰り返すと思っているから繰り返し作業を機械に代行させるのであって、要件からソースコードに一発でやりたいことが実現できるなら不要なんだよねぇ。期間や資金の都合でインクリメント開発したいっていうケースはわかってて棚に上げているけど。

プロジェクトチームがプロジェクトをうまく回すためには、どこにリソースを使っているか、それを見極める必要があると思うんだ。

現実のプロジェクトルームで起きていることを直視してみよう。

聞き、考え、書く。

２０歳を超えたいい大人が小学校から訓練してきたことが実はそれほどろくにできていないことを直視しよう。

自分の理解していることを話す相手に伝えるためにどうしたらいいのか。自分の考え方をどうしたらわかりやすく整理できるだろう。整理したことをどんな言葉で、どんな表現をしたら相手に伝わるだろう。

聞く、考え、書く、という基礎スキルにもう一度光を当てよう。