プログラマとしてのレベルをあげるには

社会人になってからプログラマになった人は、１人で最初から最後まで作るということを経験したことがない人がいるかもしれない。

設計書がすでにあって、その一部分を任せられるところからステップアップして、だんだん設計の一部を任されていったりして、そのままプログラマを卒業してしまうのかもしれない。

プログラマとして何年経験があったとしても、一部分だけを任されているだけではスキルがなかなか身につかない。というのは、ソフトウェアをどう設計して、どう分割して実装するかというのが一番の肝の部分だからである。

ずっと一部分だけを請け負っていて、ある日突然、君は経験○年だからそろそろ全体を仕切ってくれたまえ、と言われてもたぶん手も足も出ないのでは無いかと思う。破綻するプロジェクトというのは、経験○年だからこの人に任せれば大丈夫と、経験年数だけで判断したケースが多いように思う。というか実際良く見かける。

ではどうすればいいのか。経験の積ませ方としては、一部分を任せるのではなくて、小さいソフトウェアを１から最後まで面倒を見させるということではないかと思う。サンプルとして使うものではなくて、実際に現場で運用ツールとして使うものであったり、開発時に必要なツールであったり、ちゃんと開発者にフィードバックがあるものが理想である。

実際、どれだけ小さいソフトウェアでも、自分で考えて作った後、皆からあちこち仕様変更を言われることで、どのように作っておくのがよかったのか、という自己学習ができるのである。

また、仕様変更する度に「それは３日かかります」とか「それは最初から作り直しになります」とか言う開発者に対しては、仕様変更に強いプログラミングというのはどういうものかというのを教える場にもなる。

最初からいっしょにペアプログラミングでリファクタリングをするのもいいと思うが、一度自分で考えてプログラミングしてみて、現場で求められるものとのギャップというのを直に経験しないとなかなか頭に染み付かないのではないかと思う。

自分はこう思うと思ってソフトウェアを作っても、ことごとく仕様が変更されるだろう。自分の思いに反して仕様が変更された部分というのが、ある意味次にソフトウェアを作る際のノウハウになるわけである。このノウハウは一部分だけ作っていてもなかなかたまらない。全体を構築して、破壊されて、を繰り返す中にのみ存在するものである。

そういう意味で、ソフトウェア全体を構築した経験がない人がSEという名のもとに設計作業に勤しむというのは、何かが矛盾しているんではないかという気がしている。できるという人もいるのだが、最終的にプログラマに任せちゃってますよね、と思ったりするのですけれども。