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

　ということは、これは基本的な事務処理であるが、まずは、１件データを読み込んで、そこで、
「データが終わりかどうか？」
　を聞く。
　これは、いわゆる、
「分岐」
　というもので、これはプログラミングの大きな要素の一つである。
　そして、終わりでなければ、データの移送を項目ごとに行ったり、神に描き出したり、別のデータに加工したりして、最期に、もういちど、次のデータを読み込む。
　そして、今度は、もう一度、分岐点に戻る。そして、分岐から、次のデータを読むところまでを、繰り返しの処理を行うことになるのだ。
　それを、
「ループ」
　という。
　つまりは、分岐とループの間に処理が行われるというわけで、そこが、基本的なプログラムの基礎になるのだ。
　プログラムが複雑になるというのは、
「ループが入れ子」
　になったり、
「分岐の部分が複数重なっていたり、一度分岐しして、その先にまた分岐が存在するというような場合のことをいうのであって、基本的には、分岐とループが重なることが、処理を多様化させて、複雑な処理も可能にするというわけだ。
　ただ、その際に問題になるのが、組み方のいわゆる、
「センス」
　というもので、
　組み方によって、複雑すぎて、次にメンテナンスをする時に、融通が利かないように組んであれば、
「頭から、組みなおし」
　などということもあるかも知れない。
　そんなことを考えていると、最初に組む時、
「いかに汎用性のある組み方をするか？」
　というのが問題になる。
　たとえば、
「誰が見ても分かりやすく、本人でなくても、改修が可能なプログラミングにしておく」
　ということも、一つのセンスとして、重要だと言えるだろう。
　そして、プログラムには、基本があり、それが応用につながるわけなので、
「応用につなげるには、基本を分かっていないとできるわけはない」
　ということである。
　基本の解読というのは、算数でいえば、
「一足す一は二」
　ということを、素直に解釈できるか？
　ということが大切なのである。
　一度、疑ってしまうと、そこから先は、一旦辿り着いたはずのゴールが夢幻であり、Ｕターンして、元に戻ってしまっているということを、思い知らされるのと同じである、
「うまいタイミングで停まらないと、行き過ぎてしまい、後戻りする。それは、次第に後になればなるほど、ゴールが見えてこない。感覚がマヒしてしまうのだといってもいいのではないだろうか？」
　と考えるのだ。
　これが、この話の最初に提起した問題であり、
「クイズを解くタイミングを逸してしまうと、最初に思い描いた内容が、頭にこびりついてしまって、前に進まないどころか、後ろに下がっていることさえ気づいていないのではないか？」
　と感じるのかも知れない。
　プログラミングのように多岐にわたり、複雑さが増してくれば、それだけ、順応性が試されるものである。
　そういう意味で、プログラマーというものは、
「そういう多岐にわたる複雑な開発ができるように、日ごろから鍛錬を忘れないものである。つまり、習うよりも慣れろという言葉は、そういう意味を含んでいるに違いない」
　といえるのではないだろうか？
　さらに、システム開発を仕事ということになると、まず、第一線は、プログラマーということになり、基本的に、
「先輩や上司が書いた仕様書を元にプログラムを組む」
　ということにある。
　その仕様書には、まず、入出力のファイルやデータ名が記されていて、さらに、出力項目の定義、入力項目のどこから持ってくるか？　などということが書かれることになり、そして、後は内容の細かい指示である。
　前述の分岐点の内容や、ループのタイミングなど、詳細定義と呼ばれるものが書かれているのだ。
　そういう仕様書を渡され、
「いつまでに」
　という工期が決められ、それまでに、プログラマは、プログラムを組んで、そして、自分でデータを作り、単体テストまで終わらせておく。
　一つのシステムを作るのに、何十本ものプログラムの作成が必要となるので、上司も数名、プログラマも数名でそれらの作成に、仕様を作成するメンバー、実際にプログラムを組むメンバーがいて、プロジェクトチームが組まれることになる。
　もっとも、
「プログラムを組む」
　という段階は、作成段階では最後の工程となるわけで、後はテストに進むことになる。
　最初は、まず、企画からになるだろう。
　システムを組むというのは、ユーザーがあって、ユーザーがどのようなシステムを欲しているかということを、ユーザー側で考え、そこには、予算の問題なども絡んでくるので、経営陣や、管理部の意向も絡んでくる。そのため、大まかな開発期間などが決められ、会社の方針として、プロジェクトチームの結成を行う。
「どれくらいの人数で、責任者を誰にするか？」
　というくらいまでは、選出されるだろう。
　その中で、営業が何人、システムが何人などという細かい人選は、プロジェクトに移ってからのことになる場合が多いだろう。
　そして、システムに移ってから、今度は、全体の工期から、開発の細かい工期の作成に移ることになる。例えば、
「大まかなシステムの流れをいつまでに組むか？」
　それと並行しての、人選も行い、それが終わると、今度は、設計段階の大まかな打ち合わせ、そこには、人選されたシステムの人間の出席が必要になる。
　そこから、それぞれのシステムの仕様に入る前の大まかな設計が行われ、初めて、外洋設計書に、仕様、プログラマの名前と、それぞれの工数が書かれることになる。
　そして、同時に、仕様に掛かる期間、単体テストを含む、プログラム開発の期間、そして結合テスト、さらに、総合テストを経ての、納入ということになる。
　だから、実際の納期がそこで決まるのだが、最初に決めた大まかな納期に沿うように計画されることになる。
　もちろん、最終納期が基本となってくるので、間に合わないと考えれば、人間を増やし、予算オーバーも辞さない計画で行かなければいけない。そういう意味で、最初の受注した段階で、ある程度のことを決めておかないと、修正が多岐にわたることになる。それは実にまずいことだ。
　プロジェクトチームに入ると、予算を考えながらの開発となってきて、仕様に入ってくると、まだまだ、定期的な会議が行われ、それぞれの部門での進捗管理が大事になってくる。
　最大公約数的な考え方になるので、基本は、一番遅いところに合わせることになる。
　つまり、
「最後までできてからの、次の段階に入ることになる」
　というのが基本だった。
　マスタスケジュールに沿って、
「どの工程をいつまでにこなすというのを、開発項目ごとに進捗を管理する」
　それが大切で、当然、仕様を書く人間は、システムの全体像を分かっていないと、書くことはできず、仕様を貰ってプログラムを実際に組む方も、その趣旨を分かったうえで組まないと、効率が悪かったり、どこかに負荷がかかってしまう、そんなプログラムを作っていると、予期していなかったデータが入ってくると、誤作動を起こしたり、動かなかったりするという、問題となるのだ。