自由と偽善者セミナー

第1話 プログラマ冥利

　この物語はフィクションであり、登場する人物、団体、場面、設定等はすべて作者の創作であります。似たような事件や事例もあるかも知れませんが、あくまでフィクションであります。それに対して書かれた意見は作者の個人的な意見であり、一般的な意見と一致しないかも知れないことを記します。今回もかなり湾曲した発想があるかも知れませんので、よろしくです。また専門知識等はネットにて情報を検索いたしております。呼称等は、敢えて昔の呼び方にしているので、それもご了承ください。（看護婦、婦警等）当時の世相や作者の憤りをあからさまに書いていますが、共感してもらえることだと思い、敢えて書きました。ちなみに世界情勢は、令和４年６月時点のものです。今回は、いつもにも増して、「歴史物語」、「歴史うんちく」の様相を呈しているので、ご了承ください。

　あれは、パズルクイズといっていいのか、それとも、心理クイズというべきなのか？

「真ん中の四角の枠に、入る漢字一文字はなんでしょう？」

　などという問題で、上下左右から、矢印が引っ張ってあったり、そこから矢印が引かれたりして、それぞれで、漢字二文字の熟語を作れる共通の感じ一文字が何かというのを求める問題があるだろう。

　クイズというより、なぞなぞに近いものかも知れない。よく、朝の情報番組などの、天気予報の番組内で、

「頭のトレーニング」

　と称して、やっているのを見たことがあった。

　それは、大体、ＣＭ明けまでに考えるもので、

「いつもやっている人の、勝率がどれくらいなんだろうか？」

　と考えたりもした。

　一度知り合いがやっていると聞いた時、

「俺の場合は、自分が思っているよりも、少しあるんじゃないかって思うんだ。というのも、正解する時は続けて正解するけど、成功しない時は、これも果てしなく続くような気がするんだ。だから、全体を通して考えると、率は低いような気がする。だけど、冷静に考えると、今度は正解が続く時が頭をもたげて、そんな時は、結構正解率が高いと思うんだ。要するに、正解が続く時を考えるか、失敗が続く時を想像するかの違いでしかないんだよ」

　という、

「よく分からない」

　というと、

「だって、どっちかが、その時のベースになっているわけだろう？　ベースというのは、直感で感じた最初だと思うんだよ。それが、途中から変わっていった時、変わっていく方に向かって、気持ちが傾いていく。上がっていく時であれば、思ったよりも高いと思うし、逆だったら、低いと思う。そういうものなんじゃないかな？」

　という。

　聞いていて、やっぱり分からない。だが一つ分かるのは、

「この人は、自分の思ったことを理論立てて話している時は、完全に自分の世界に入っているのだから、その考えに間違いはないと思うのだ」

　ということであった。

　それは思い込みなのかも知れないが、思い込みであっても、信憑性は高いのだ。

　その信憑性というのは、相手が、

「そう思い込んでいる」

　ということを、見ている人間もシンクロしているように見るというのは、あながち間違っている発想ではなく、自分が考えていることを相手も同じように考えていると感じることを、

「シンクロしている」

　というのだろう。

　それは、人間には、

「思い込み」

　というものがあって、

「人と同じことを考えている」

　と思うのも、一種の思い込みではないだろうか？

　そうなると、

「ただの偶然」

　というのも、思い込みであり、偶然が重なってくると、奇妙に感じるのだろうが、それだけ、他の人と考えがシンクロしているということなのかも知れない。

「シンクロとは、偶然の積み重ねだ」

　と考えるのも、おかしなことだと言えるのだろうか？

「理論的に考える」

　ということが大切なのだと思うのだが、ただ、その、

「理論的に？」

　というのがどういうことなのか、それが分からないと、解ける問題も解けないというものだ。

　今は、小学生くらいから、普通にプログラミングができるようになっている。

　昔であれば、アルファベットの、いわゆる、

「プログラミング言語」

　というものを、パソコンなどに打ち込んで、それを、機械が読み取れる、

「機械語」

　に翻訳することで、操作が可能になっていたものだ。

　さらに、パソコンが普及する前の事務処理言語として、

「ＣＯＢＯＬ」

　という言語があったというが、プログラミングだけでは動かなかった。

　それは、機械によって、互換性がないために、制御する言語も必要で、プログラムと一緒に制御言語まで自分で作成する必要があったのだ。

　まだ、パソコンなどという機会はなく、マウスなどというものもなかった時代は、本当に専門のプログラミングができる技術を持った一部の人しかできなかったものだが、パソコンが普及してきて、オフィスなどの、

「表計算なら、エクセル」

「ワープロ機能なら、ワード」

　と呼ばれるもので、表計算を自動で動かす、マクロのようなものは、専門知識をメーカーからの講習会などで身につけることなく、

「業務の一環」

　として、本を見ながらでも、できるような、そんな開発ツールが、格段に楽になるという先進的な技術を持ったコンピュータが開発されてきた。

　それが、ＯＳと呼ばれるもので、

「パソコンの操作全体をつかさどる、大きなソフト」

　といってもいいだろう。

　ただ、これはあくまでも、開発ツールが、昔に比べて楽になったということであり、基本的な理屈である、

「プログラミングというものの考え方」

　が変わるものではない。

　そういう意味では、自分で練習をするのも大切なことであり、パソコン初心者が、人に教えを乞う時、教えてもらおうとしている人から言われるのが、

「習うよりも、慣れろ」

　という言葉であった。

　つまり、

「練習さえ重ねていけば、いくらでも上達はするし、仕事で使うくらいのソフトは、普通に自分で開発することができる」

　という、そんな時代がやってきたということである。

　つまり、それだけ、ツールは簡単になったのかも知れないが、基本は変わったわけではないということになるので、頭の固い上司などから見れば、

「今のようにパソコンが楽になったんだから、プログラミングなんて、今の若い者だったら、誰にだってできるはずだ」

　という勝手な思い込みをする人もいるかも知れない。

　当然、

「プログラミングというのも、一種の技術であるわけで、芸術と同じで、個人差もあれば、向き不向きもある」

　といえるだろう、

　したがって、スピードも違えば、完成度も、その人の性格によって、神経質な人もいれば、ずぼらな人もいる、その性格が、プログラムには、そのまま出るといってもいいだろう。

　それを考えれば、

「いくら簡単になったとはいえ、できる人とできない人がいるのは、当たり前のことだ」

　といえるだろう。

　それは、いくら機械が進歩しても同じであるので、物事に無限ということがありえないように、

「完璧という言葉はありえない」

　といってもいいだろう。

　プログラミングは、今も昔も、そして、言語が違ったとしても、基本は同じである。

　ということは、これは基本的な事務処理であるが、まずは、１件データを読み込んで、そこで、

「データが終わりかどうか？」

　を聞く。

　これは、いわゆる、

「分岐」

　というもので、これはプログラミングの大きな要素の一つである。

　そして、終わりでなければ、データの移送を項目ごとに行ったり、神に描き出したり、別のデータに加工したりして、最期に、もういちど、次のデータを読み込む。

　そして、今度は、もう一度、分岐点に戻る。そして、分岐から、次のデータを読むところまでを、繰り返しの処理を行うことになるのだ。

　それを、

「ループ」

　という。

　つまりは、分岐とループの間に処理が行われるというわけで、そこが、基本的なプログラムの基礎になるのだ。

　プログラムが複雑になるというのは、

「ループが入れ子」

　になったり、

「分岐の部分が複数重なっていたり、一度分岐しして、その先にまた分岐が存在するというような場合のことをいうのであって、基本的には、分岐とループが重なることが、処理を多様化させて、複雑な処理も可能にするというわけだ。

　ただ、その際に問題になるのが、組み方のいわゆる、

「センス」

　というもので、

　組み方によって、複雑すぎて、次にメンテナンスをする時に、融通が利かないように組んであれば、

「頭から、組みなおし」

　などということもあるかも知れない。

　そんなことを考えていると、最初に組む時、

「いかに汎用性のある組み方をするか？」

　というのが問題になる。

　たとえば、

「誰が見ても分かりやすく、本人でなくても、改修が可能なプログラミングにしておく」

　ということも、一つのセンスとして、重要だと言えるだろう。

　そして、プログラムには、基本があり、それが応用につながるわけなので、

「応用につなげるには、基本を分かっていないとできるわけはない」

　ということである。

　基本の解読というのは、算数でいえば、

「一足す一は二」

　ということを、素直に解釈できるか？

　ということが大切なのである。

　一度、疑ってしまうと、そこから先は、一旦辿り着いたはずのゴールが夢幻であり、Ｕターンして、元に戻ってしまっているということを、思い知らされるのと同じである、

「うまいタイミングで停まらないと、行き過ぎてしまい、後戻りする。それは、次第に後になればなるほど、ゴールが見えてこない。感覚がマヒしてしまうのだといってもいいのではないだろうか？」

　と考えるのだ。

　これが、この話の最初に提起した問題であり、

「クイズを解くタイミングを逸してしまうと、最初に思い描いた内容が、頭にこびりついてしまって、前に進まないどころか、後ろに下がっていることさえ気づいていないのではないか？」

　と感じるのかも知れない。

　プログラミングのように多岐にわたり、複雑さが増してくれば、それだけ、順応性が試されるものである。

　そういう意味で、プログラマーというものは、

「そういう多岐にわたる複雑な開発ができるように、日ごろから鍛錬を忘れないものである。つまり、習うよりも慣れろという言葉は、そういう意味を含んでいるに違いない」

　といえるのではないだろうか？

　さらに、システム開発を仕事ということになると、まず、第一線は、プログラマーということになり、基本的に、

「先輩や上司が書いた仕様書を元にプログラムを組む」

　ということにある。

　その仕様書には、まず、入出力のファイルやデータ名が記されていて、さらに、出力項目の定義、入力項目のどこから持ってくるか？　などということが書かれることになり、そして、後は内容の細かい指示である。

　前述の分岐点の内容や、ループのタイミングなど、詳細定義と呼ばれるものが書かれているのだ。

　そういう仕様書を渡され、

「いつまでに」

　という工期が決められ、それまでに、プログラマは、プログラムを組んで、そして、自分でデータを作り、単体テストまで終わらせておく。

　一つのシステムを作るのに、何十本ものプログラムの作成が必要となるので、上司も数名、プログラマも数名でそれらの作成に、仕様を作成するメンバー、実際にプログラムを組むメンバーがいて、プロジェクトチームが組まれることになる。

　もっとも、

「プログラムを組む」

　という段階は、作成段階では最後の工程となるわけで、後はテストに進むことになる。

　最初は、まず、企画からになるだろう。

　システムを組むというのは、ユーザーがあって、ユーザーがどのようなシステムを欲しているかということを、ユーザー側で考え、そこには、予算の問題なども絡んでくるので、経営陣や、管理部の意向も絡んでくる。そのため、大まかな開発期間などが決められ、会社の方針として、プロジェクトチームの結成を行う。

「どれくらいの人数で、責任者を誰にするか？」

　というくらいまでは、選出されるだろう。

　その中で、営業が何人、システムが何人などという細かい人選は、プロジェクトに移ってからのことになる場合が多いだろう。

　そして、システムに移ってから、今度は、全体の工期から、開発の細かい工期の作成に移ることになる。例えば、

「大まかなシステムの流れをいつまでに組むか？」

　それと並行しての、人選も行い、それが終わると、今度は、設計段階の大まかな打ち合わせ、そこには、人選されたシステムの人間の出席が必要になる。

　そこから、それぞれのシステムの仕様に入る前の大まかな設計が行われ、初めて、外洋設計書に、仕様、プログラマの名前と、それぞれの工数が書かれることになる。

　そして、同時に、仕様に掛かる期間、単体テストを含む、プログラム開発の期間、そして結合テスト、さらに、総合テストを経ての、納入ということになる。

　だから、実際の納期がそこで決まるのだが、最初に決めた大まかな納期に沿うように計画されることになる。

　もちろん、最終納期が基本となってくるので、間に合わないと考えれば、人間を増やし、予算オーバーも辞さない計画で行かなければいけない。そういう意味で、最初の受注した段階で、ある程度のことを決めておかないと、修正が多岐にわたることになる。それは実にまずいことだ。

　プロジェクトチームに入ると、予算を考えながらの開発となってきて、仕様に入ってくると、まだまだ、定期的な会議が行われ、それぞれの部門での進捗管理が大事になってくる。

　最大公約数的な考え方になるので、基本は、一番遅いところに合わせることになる。

　つまり、

「最後までできてからの、次の段階に入ることになる」

　というのが基本だった。

　マスタスケジュールに沿って、

「どの工程をいつまでにこなすというのを、開発項目ごとに進捗を管理する」

　それが大切で、当然、仕様を書く人間は、システムの全体像を分かっていないと、書くことはできず、仕様を貰ってプログラムを実際に組む方も、その趣旨を分かったうえで組まないと、効率が悪かったり、どこかに負荷がかかってしまう、そんなプログラムを作っていると、予期していなかったデータが入ってくると、誤作動を起こしたり、動かなかったりするという、問題となるのだ。

　そして、プログラムの細かい仕様もそうなのだが、システムごとの仕様も大切で、本来なら、

「このデータができていないと、ここから先は動かせない」

　などという、処理タイミングを考慮させることになる。それが、システム仕様というわけだ。

　処理タイミングというのは、結構最初の設計段階と、プログラムが完成してから、実際に処理を動かしてみると、結構、想定が狂ってしまうことも往々にしてあるだろう。

　一番の原因は、それぞれの、プログラムの処理スピードや能力が違うからだった。

「作る人間が違うのだから、それは当然のことである」

　といえるだろう。　プログラマーの割り当てが、一つのサブシステムを一人でするわけではない、どちらかというと、

「満遍なく人によって、工数の負担が増えないようにする。そうしないと、最大公約数の考えのごとく、結合テストが、最期に作る人街になってしまうからだ」

　といえるだろう。

　つまり、そういう難しいプログラムに限って、根幹部分だったりするので、そこができていないと、何も先には進まないといってもいいだろう。

　それを考えると、プログラマの配置も難しく、一人にしわ寄せが行ってしまうと、テストも問題だが、実際に納入して、本番が動き出してから、もし何かあった時の対処をするにも、一人にしわ寄せが行ってしまうと大変だ。

　もし、他部署への転勤であったり、さらに重要なプログラムを任されるようになると、ユーザーから質問や、対応依頼があった場合、

「開発を担当した人がもういないので、改修は難しい」

　ということになる。

　ただ、それは、ユーザーには、決して言ってはならないことだった。だから、納入したあとのこともできるだけ考えておく必要もあるのだった。

　プログラムを組む時も、最初の気合の入れ方で、だいぶ変わってくるものなのかも知れない。

　まずは、大きな概要からイメージをする。その時に、

「効率の良い組み方」

　というものを頭に入れておく必要がある。

　そうしないと詳細に入ってからでは、効率のいいということを初めて考えようとすると、実際のフローチャートに沿っての、

「プログラムの設計」

　に集中してしまい、両立が難しくなってくるからである。

　プログラムの設計も、最初に思い浮かんだことを、途中で変えるのは難しい。それを考えると、頭から考え直した方がいいくらいで、実際に組むところまで行ってしまえば、後戻りはできないといってもいい。

　少なくとも、プログラムの設計、フローチャートを思い浮かべた段階で、いや、どの場面であっても、後ろを振り返ると、納期に間に合わない可能性がある、自分だけではなく、他の人を待たせることになると、

「プログラマーとして、まだまだ未熟だ」

　と言われかねない。

　少なくとも、スケジュールの進捗が狂ってしまえば、テストも後ろにずれ込むことになり、最終の線は決まっているだけに、後ろにいけばいくほど切羽詰まってきて、まったく余裕がなくなってしまう。

　それをたった一人のために皆が苦しむというのは、ある意味理不尽だと言えなくもないだろう。

「プログラムの開発がうまくいかない」

　といっても、他人に頼むわけにはいかない。

　スーパーやコンビニのレジを、誰かに代行してもらうのとではわけが違うだろう。

　もちろん、どちらも大切な仕事であると熟知しているが、

「一人がこけると。皆、すっころでしまい」

　ということになりかねないからだった。

　しかも、単体テストのためのデータ準備や、仕様書を再確認し、

「予定通りのものができたかという最終チェック」

　が必要となるだろう。

　それのために、最初に組み始める前に、自分なりの進捗チェック表が必要になる。作業工程ごとにも必要だが、作業項目の半ばでの確認だってあるはずだ。

　それを分かっていないと、開発などできるわけもなく、遅かれ早かれ、プロジェクトからは外される運命にある。

「自分の工程をおろそかにしていると、どこかでやり直しを迫られる」

　ということになる。

　いくら、システム開発最初のプログラマだといっても、

「重要な部分を任されている」

　という自覚も大切なのだ。

　特にプログラマーのような、いわゆる第一線では、自分が、

「第一線にいて、自分がプログラムを組んでいるから」

　ということで、自分がすべてを作り出していると勘違いしがちなのではないだろうか？

　それは無理もないことだろう。実際に、プログラマーの中には、

「三度の飯よりも組むのが好きだ」

　と思っている人もいる。

　実際に、開発が佳境に入り、最終電車がなくなってしまい、会社に泊まり込んでの仕事となっても、

「プログラマ冥利に尽きる」

　というくらいに考えている人もいる。

　実際、

「皆、２、３日会社に泊まり込んで仕事をしても、それほど苦痛に感じない人が多いからな」

　と言っているが、それも、２０代だから言えることではないだろうか？

　そういう意味で、プログラマというのは、大体３０歳前後くらいまでであろう。

「物を自分で作り出すことが好きなんだ」

　といっている人が、最初に感じる難関である。

「自分で作ったプログラムが完成し、それを単体で動かし、最初は思ったように動かなくても、バグを取り除くうちに、徐々に完成していく。単体テストまで、すべてが新しいものを作る過程なんだ」

　と思っているのだった。

　そんなプログラムをずっと作っている時はうれしかった。

「一日に、今日は５本作った」

　あるいは、

「難しいプログラムに挑戦している」

　とそれぞれに、充実感を感じる。

「充実感は、達成感から生まれる」

　その達成感は、

「最後まで作り終えた」

　という実質的な達成感と、

「今、難解なプログラムに挑んでいる」

　という、過程的な達成感との二つがあると思う。

　後者を達成感ではなく、

「達成感抜きの充実感ではないか？」

　と思っている人がいるかも知れないが、ほとんどのプログラマは、過程の間であっても、達成感を感じているのではないかと思っている。

　それは、その日、会社を出るまで、自分で、

「キリのいいところで終わらせる」

　ということをするからである。

　確かに、キリの悪いところであれば、気持ちが悪い。それも、

「無意識に達成感を味わいたいだけだ」

　と考えたのであれば、それはそれで、

「達成感を味わうためだ」

　と思っているのだとすれば、ありえることではないだろうか？

「一人で、孤独に開発しているのは、裏を返せば、自由なのだと言えるのではないだろうか？」

　と考えられるが、

「基本、まったく何もないところから、何かを生み出すというのは、孤独なもので、だからこそ、自由な発想や、しがらみから解き放たれる時の喜びを、感じることができるのではないだろうか？」

　と思った時、プログラマ冥利、開発者冥利に尽きると言ってもいいのではないか？

　何かを作り上げようとすると、目指すものは、

「完成」

　というゴールであり、それが見えないと、本当にゴールしたのか分からない。双六なので、

「最期にピタリの目が出ないとゴールできない」

　という感覚は

「ゴールが見えない」

　ということに通じるのではないだろうか？

　毎日を、そんなプログラムを組むながら、

「今は充実しているけど、そのうちに、組みたくても組めなくなり、まもなう、そんな自分も今度は仕様書を書く方の仕事にステップアップすることになるんだ」

　と感じているのは、今年２８歳になる、松下という男だった。

　彼は、最初からプログラムを組む人間ではなかった。

　元々大学では商学部で、

「営業職を目指して」

　入社してきたのだった。

　それが、会社の都合からか、途中で、

「情報システムに配属替え」

　ということになった。

　最初は本社で、営業のノウハウを覚えて、支店に配属になり、そこで、本部からの意向を加味した営業計画がやりやすいようにと、最初、本社の営業で、言い方は悪いが、洗脳して送り込むことにしていたようだ。

　それだけ、本部と支店の間では、考え方などが違っていて、第一線と後方部隊なので、同じ営業でも違っているのは、無理もないことなのかも知れない。

　そこまでは考えていた松下だったので、営業という職に少し疑問を持っていた。そのせいもあってか、

「情報システムに行け」

　と言われて、さほどショックでもなかった、

　同じ本社内なので、引っ越しの必要もない。ましてや、引継ぎをすることもないので、ある意味、身一つでの異動だった。それが、松下の運命であれば、抗うこともしないというものである。