はじめに
プログラマの成果物は＿＿いろいろありますが、主にはソースコードです。
というと「当たり前のことだ」と思うでしょうか。しかし「動くプログラムだろう？」という人も多いはず。
ソースコードとは
「ソースコード」「動くプログラム」の違いが解らない人はこの記事にたどり着かないかとは思いますが、念のため説明します。
「動くプログラム」は最終的にユーザーが使うもので、コンピュータを使っている人なら誰でも、意識的か無意識かを問わず、プログラマの成果であるプログラムに触れていることになります。
ソースコードはその元（ソース）になっているもので、コンピュータにさせたい仕事（処理）の内容を書いてあるものです。コンピュータにさせる仕事の内容によって、それぞれに適した文法の違いがあり、その違いごとに「プログラミング言語」が異なるという言い方をします。
「動くプログラム」はソースコードから作られた結果であり、ソースコードはコンピュータを使う人が目にすることは滅多にありません。目にしたとしてもプログラマ以外には暗号（コード）のように思えることでしょう。
成果物として重要なのはどちらか
「動くプログラム」は重要ではないのでしょうか。反対の言葉として「動かないプログラム」というなら、それはあり得ないことなので「動くプログラム」の重要性はもう空気のように自明です。これを無くしたら成果物がどうとか以前にプログラマとして成り立ちません。
成果物とは
「ものを作る」というタスクの成果として「もの（成果物）」ができる
下記のサイトでは、このように定義されています。
成果物ってなんだろう？ | Think! management（シンク！マネジメント）
「ものを作る」目的は最終的に納品する「動くプログラム」なのだから、それが主たる成果物ではないかと思われるかもしれませんね。でもこれは「プロジェクト（チーム）」の成果物であると思うのです。プログラマの成果物、プログラマの真骨頂、それはやはりソースコードにあると思います。
ソースコードは小説家にとっての「原稿」
書籍を構成するものは文章だけではありません。小説家の書いた書籍が店頭に並ぶまで、編集、校正、装丁、製本、流通、多くの人の手が入ります。それぞれの工程で、それぞれの人の成果物のかたちがあります。その集大成が本屋の店頭に並んでいます。小説・物語の内容はもちろん作家のものですが、書籍はプロジェクトの成果と言えます。
プログラムでは、小説の原稿に当たるものがソースコード、書籍にあたるものが動くプログラムになります。ですので原稿に当たるソースコードを成果物として責任を持つのはプログラマです。
プログラムは時とともに形を変える
プログラムは、一度作ったら「はい終わり」ではありません。ビジネスの状況に応じて、節目節目で改造したり追加があったりします。
その時直すのは最初に書いた人とは限りません。その時が来るのは何年先かわかりません。運良く自分がまだ担当だとして、何年も経っていたらきっと覚えてはいないでしょう。そういう場合は、他人が書いたのと同じとしてソースコードと向き合う、つまり「読む」ことになります。
だからこそプログラマは、プログラムが正常に動くことだけではなく、読み手のことを考えてソースコードを書かなければなりません。それができるのはプログラマだけです。
プログラマの不注意はテスタが拾い上げてくれるかもしれません（したがって動くプログラムはプログラマだけの成果物ではないと考えます）。進捗の遅れはマネージャーがクライアントと交渉してくれるかもしれません。しかしソースコードに手を入れるは結局プログラマだけです。ソースコードを読みやすく維持できるのはプログラマだけです。
リーダブルコード
どのようにそれを実現するか様々な書籍が販売されていますが、ロングセラーになっているのはこのリーダブルコードです。ある程度プログラムが書けるようになってきたら「まず読んでおこう」という本です。私も通読しましたが、読みやすくとても参考になりました。言語によって、読みやすさの定義は変わるかもしれませんが、変わらないものもあります。ヨーダ記法のように、時代とともに移り変わるものもあります。
考え続ける
大切なのは考え続けること、学び続けることだと思います。ほんとうにこの書き方がベストか、他の書き方の方が読みやすいのではないか、仕様からイメージできるコードになっているか、反対にコードから仕様をイメージできるか、言語の習熟度に大きく依存していないか、広く知られているセオリー（定石、デザインパターン、規約、標準）を踏襲しているか、静的構文解析ツールなどを通した後でも問題ないのか、非推奨になっている（いずれなりそうだと予想される）関数・API を使っていないか、などなど。
過去の反省から
現在では開発の完了まで積極的にリファクタリングをして、他の人が読みやすい、読む時に迷惑をかけない、仕様変更にも対応しやすい、そして読み手のスキルレベルになるべく依存しないソースコードになっているかどうか常に心を砕いています。そのための時間も確保します。矜持と言うのは過言かもしれませんが、それがメシの種だと思っています。
派遣として様々な会社に行き、そこで様々なプロジェクトを引き継ぎ、または引き継いでもらいました。
初期の頃に書いたプログラムは＿＿さすがにもう稼働してはいないと思いますが＿＿今思うとたいへん酷いものでした。ほんとうにごめんなさい。
また引き継いだプロジェクトの中でも、残念な感じのソースコードにたくさん出会いました。
