小説が読める！投稿できる！小説家(novelist)の小説投稿コミュニティ！

　そして、プログラムの細かい仕様もそうなのだが、システムごとの仕様も大切で、本来なら、
「このデータができていないと、ここから先は動かせない」
　などという、処理タイミングを考慮させることになる。それが、システム仕様というわけだ。
　処理タイミングというのは、結構最初の設計段階と、プログラムが完成してから、実際に処理を動かしてみると、結構、想定が狂ってしまうことも往々にしてあるだろう。
　一番の原因は、それぞれの、プログラムの処理スピードや能力が違うからだった。
「作る人間が違うのだから、それは当然のことである」
　といえるだろう。　プログラマーの割り当てが、一つのサブシステムを一人でするわけではない、どちらかというと、
「満遍なく人によって、工数の負担が増えないようにする。そうしないと、最大公約数の考えのごとく、結合テストが、最期に作る人街になってしまうからだ」
　といえるだろう。
　つまり、そういう難しいプログラムに限って、根幹部分だったりするので、そこができていないと、何も先には進まないといってもいいだろう。
　それを考えると、プログラマの配置も難しく、一人にしわ寄せが行ってしまうと、テストも問題だが、実際に納入して、本番が動き出してから、もし何かあった時の対処をするにも、一人にしわ寄せが行ってしまうと大変だ。
　もし、他部署への転勤であったり、さらに重要なプログラムを任されるようになると、ユーザーから質問や、対応依頼があった場合、
「開発を担当した人がもういないので、改修は難しい」
　ということになる。
　ただ、それは、ユーザーには、決して言ってはならないことだった。だから、納入したあとのこともできるだけ考えておく必要もあるのだった。
　プログラムを組む時も、最初の気合の入れ方で、だいぶ変わってくるものなのかも知れない。
　まずは、大きな概要からイメージをする。その時に、
「効率の良い組み方」
　というものを頭に入れておく必要がある。
　そうしないと詳細に入ってからでは、効率のいいということを初めて考えようとすると、実際のフローチャートに沿っての、
「プログラムの設計」
　に集中してしまい、両立が難しくなってくるからである。
　プログラムの設計も、最初に思い浮かんだことを、途中で変えるのは難しい。それを考えると、頭から考え直した方がいいくらいで、実際に組むところまで行ってしまえば、後戻りはできないといってもいい。
　少なくとも、プログラムの設計、フローチャートを思い浮かべた段階で、いや、どの場面であっても、後ろを振り返ると、納期に間に合わない可能性がある、自分だけではなく、他の人を待たせることになると、
「プログラマーとして、まだまだ未熟だ」
　と言われかねない。
　少なくとも、スケジュールの進捗が狂ってしまえば、テストも後ろにずれ込むことになり、最終の線は決まっているだけに、後ろにいけばいくほど切羽詰まってきて、まったく余裕がなくなってしまう。
　それをたった一人のために皆が苦しむというのは、ある意味理不尽だと言えなくもないだろう。
「プログラムの開発がうまくいかない」
　といっても、他人に頼むわけにはいかない。
　スーパーやコンビニのレジを、誰かに代行してもらうのとではわけが違うだろう。
　もちろん、どちらも大切な仕事であると熟知しているが、
「一人がこけると。皆、すっころでしまい」
　ということになりかねないからだった。
　しかも、単体テストのためのデータ準備や、仕様書を再確認し、
「予定通りのものができたかという最終チェック」
　が必要となるだろう。
　それのために、最初に組み始める前に、自分なりの進捗チェック表が必要になる。作業工程ごとにも必要だが、作業項目の半ばでの確認だってあるはずだ。
　それを分かっていないと、開発などできるわけもなく、遅かれ早かれ、プロジェクトからは外される運命にある。
「自分の工程をおろそかにしていると、どこかでやり直しを迫られる」
　ということになる。
　いくら、システム開発最初のプログラマだといっても、
「重要な部分を任されている」
　という自覚も大切なのだ。
　特にプログラマーのような、いわゆる第一線では、自分が、
「第一線にいて、自分がプログラムを組んでいるから」
　ということで、自分がすべてを作り出していると勘違いしがちなのではないだろうか？
　それは無理もないことだろう。実際に、プログラマーの中には、
「三度の飯よりも組むのが好きだ」
　と思っている人もいる。
　実際に、開発が佳境に入り、最終電車がなくなってしまい、会社に泊まり込んでの仕事となっても、
「プログラマ冥利に尽きる」
　というくらいに考えている人もいる。
　実際、
「皆、２、３日会社に泊まり込んで仕事をしても、それほど苦痛に感じない人が多いからな」
　と言っているが、それも、２０代だから言えることではないだろうか？
　そういう意味で、プログラマというのは、大体３０歳前後くらいまでであろう。
「物を自分で作り出すことが好きなんだ」
　といっている人が、最初に感じる難関である。
「自分で作ったプログラムが完成し、それを単体で動かし、最初は思ったように動かなくても、バグを取り除くうちに、徐々に完成していく。単体テストまで、すべてが新しいものを作る過程なんだ」
　と思っているのだった。
　そんなプログラムをずっと作っている時はうれしかった。
「一日に、今日は５本作った」
　あるいは、
「難しいプログラムに挑戦している」
　とそれぞれに、充実感を感じる。
「充実感は、達成感から生まれる」
　その達成感は、
「最後まで作り終えた」
　という実質的な達成感と、
「今、難解なプログラムに挑んでいる」
　という、過程的な達成感との二つがあると思う。
　後者を達成感ではなく、
「達成感抜きの充実感ではないか？」
　と思っている人がいるかも知れないが、ほとんどのプログラマは、過程の間であっても、達成感を感じているのではないかと思っている。
　それは、その日、会社を出るまで、自分で、
「キリのいいところで終わらせる」
　ということをするからである。
　確かに、キリの悪いところであれば、気持ちが悪い。それも、
「無意識に達成感を味わいたいだけだ」
　と考えたのであれば、それはそれで、
「達成感を味わうためだ」
　と思っているのだとすれば、ありえることではないだろうか？
「一人で、孤独に開発しているのは、裏を返せば、自由なのだと言えるのではないだろうか？」
　と考えられるが、
「基本、まったく何もないところから、何かを生み出すというのは、孤独なもので、だからこそ、自由な発想や、しがらみから解き放たれる時の喜びを、感じることができるのではないだろうか？」
　と思った時、プログラマ冥利、開発者冥利に尽きると言ってもいいのではないか？
　何かを作り上げようとすると、目指すものは、
「完成」
　というゴールであり、それが見えないと、本当にゴールしたのか分からない。双六なので、
「最期にピタリの目が出ないとゴールできない」
　という感覚は
「ゴールが見えない」
　ということに通じるのではないだろうか？