第６章 道しるべ 54

             4804. プログラムについて

１. プログラムの概念

(1) システムを稼働させ，頭脳の役割を果たすのが「ソフト」と呼ばれるもので，
    その正体は，膨大な「プログラム」である。

1) 人間に代わって，与えられた命令通りの仕事をする「コンピューター」は，
    その頭脳に，プログラムが組み込まれる（業務上の命令書伝達に相当する）。
2) プログラムは，人の思考手順をコンピューターに指示する命令書であって，
    システム内の情報を編集し加工する 精密な機能を果たす手順書である。
3) プログラムを作成する専門技術者が，そのシステムに精通している程度に
    比例して，完成したプログラムの質は向上する。
4) プログラムの良否がシステムの性能を決める。
      ここで注意しなければならないのは，
      命令書を書く段階までは人間の行為だということである。

(2) プログラムの命令文は 規定の手順を経てコンピュータ用語に翻訳される；

1) 不正確・曖昧だと落第（そのまえに 日本語能力の向上を望む）
2) 目的範囲・規程範囲を正確にカバーすること，多くても少なくても駄目
3) 決められた 約束ごと・手続きと手順・規格基準・法令法規に従うこと
4) 最後に，文字の欠落や誤字,文節区切りなど,単純な誤りを見落とさないこと

(3) 上記に反する，命令文の疵傷を，コンピュータの用語で「バグ」と呼ぶ。

1) どんな些細なバグでも残っていれば，巨大なシステムは動作しなかったり，
    暴走事故を起こしたりする。
2) 現在のコンピュータは，それをリカバーできない。
3) 世間によく見る事故の殆どは，信じられないほど初歩的なミスによる。
4) 高度に複雑化したシステムを構築するとき，プログラミングの過程を軽視
    することは，致命傷につながる。
5) 信頼度を確保するために，優れた「ＳＥ」が欠かせない所以である。

(4) 最近，金融機関など企業の大型合併が進められている。

    その主な理由の一つとして言われているのが，業務システムの統合である。
    ①当該企業が世界市場で自由競争の洗礼を受けるに当たって，
      世界的規模を持つ，コンピュータ支援の各種システムが必要になった。
    ②当然のことだが，その前提として，精細な情報システムが必要になった。
    それを実施するためには；

1) それぞれの企業に固有の知識が必要な，システム･エンジニアリングをこなす
    熟練したエンジニアの絶対数が足りない。その対応手段を講じる。
2) システム･エンジニアリングに要する時間は，エンジニアのマンパワーとその
    資質に依存する。信頼度を求めれば，標準的な所要時間が必要になる。
3) 信じられないほど膨大な資金を必要とする。経営層がコスト低減を求める
    時は，システムの信頼性とその有効性（投資効果）の trade-off になる。

２. プログラムの本質

   ★プロジェクトを企図し実行に移すとき，その根幹になる作業は，
     下記の３段階がある。それぞれは；
     ・[planning]      基本構想を具体化し，計画数値を策定する。
     ・[programming]  計画を実行する手続き手順の詳細を設定する。
     ・[budgeting]       計画実行に要する資金計画を算定する。
     ・[evaluation]      実施結果を評価し，効果の低い部分を修正する

(1) プログラムは工程表やスケジュールを統轄制御する

■我が国では，上記のうちplan，budget は平生から見聞きしている通りですが， [program] は，あまり耳にしません。それに代わって，よく使われ耳慣れている言葉が [工程表] であったり [schedule] です。

■そこで使われる [工程表] は，単にプロジェクト進行の時間割りであり，それが複雑になったものに，鉄道の列車ダイアがある。しかし，あくまでも平面的な時刻表の域を超えてない。

■一つのプロジェクトを実行するシステムは，高度に複雑化した積層構造を形成していることである。一般には，プロジェクトを形成する複数の目的･使命に相当する，カテゴリーの数だけの層を持っている。それは丁度，アニメーションを創るとき，数枚のフイルムを重ね合わせるのに似ている。

■平均的に，一つのプロジェクトは（５±２）のカテゴリーに分割するのが理想とされている。分割されたカテゴリー間の干渉は好ましくない。もしそれが現場で起きると，間違いなく物議を生じる。それぞれは独立して，プロジェクトをサポートしながら進行するのである。それを統轄する役割を果たすのがプログラムである。

■各Programは，幾つかに分割したカテゴリーごとに，最上位の概念であるProject Plan（入力）から，最下位の概念であるElement（出力）までを，階層的に配列し，Tree構造に形成したものを，Program Structureと呼んでいる。このブロックに時間的要素を加味したとき，一つのシステムは完成する。 その時間的要素が工程表であったりスケジュールである

(2) スケジュールは プログラムの代用にはならない

■[schedule] は[PERT] の時代に入り，表面的にその性格を一変したかに見える。けれども，現場の実態は違う。[PERT] は，あまりにも手数がかかり過ぎ，膨大な実績データが必要になる。コンピュータで処理できるとしても，貧弱なデータベースでは実行できない。現場の実情に疎い学者や研究者には理解できない。

■実際，[PERT] を実務に組み込んでいる大企業を，あまり耳にすることはない。まして，中小企業では，はじめから無理な作業である。もしあるとしても，それは本質的な [schedule] の考え方を，誤って使っているとしかいえない。

■それは，[program] は [schedule] のそれと根底から異なる点が，[program] では，実行手順が立体的に構造化されていることである。従来の線形思考のエンジニアリングでは，構造的な実行計画を立案する考え方も経験もない。

■日常，我々が接するメディアから見聞きする「プログラム」という用語で，国産情報によるものは少ない。その殆どは 米国から配信された記事によると考えてよい。日本でせいぜい出てくる言葉は「工程表」です。(誤用かor単にそれだけか)

■「プログラミング」の段階を，プロジェクトの「工程表」作成に置き換えてしまい，簡易に済ませている（甚だしくは工程表すら無いものもある)。

(3) プログラムの重要性を弁えた人を求める

■では，何故プロジェクトが実行されているのかと言えば，それは，末端の実施部門に所属する，老練な技能者が，それぞれ，彼等の流儀でプログラムを作成しているのである。

■近年，経験十分で，折り合いを付けることに長け，円熟した，老練の技能者が，現場から消えつつあることに，早く気付くべきである。何故ならば，最近の事故や故障の類は，デスクの一見理知的な技術者が見落とす欠陥を，チェックする機能が劣化しているからである。つまり，現場に老練な技能者が居なくなったからである。

■プランだけがあって，プログラムのないプロジェクトは，行動計画のない，いわゆる，机上のプランであって，実現にはほど遠い，言葉だけの空言に過ぎない。
エンジニアリング･ミスガ多い。予算は粗雑で，概して過大見積りになる。

■欧米諸国が日本に対ししばしば指摘する，誠意ある行動を見せよとは，そのことを指している。だが，日本が悪意をもっているわけでもない。ただ，きちっとした，プログラムを提示できないだけである。 縦割りピラミッド構造社会，線形思考の日本では，水平方向の連携と相互関係を重視し，その有機的かかわりを明示するプログラミングは，不向きな手法である。

■日本のあらゆる階層で（特定の国際的企業を除き），最大の弱点は「プログラム」力の貧弱さ，無理解さである。 世界的に，現場主義が注目を浴びている時代にそぐわない。 巨大プロジェクトを可能にするために， ｢プログラミング能力」は必須の要件である。

■日本企業が海外の巨大プロジェクトに応札する時，プロジェクト･エンジニアリングで，度々失敗を繰り返している理由はそれです。海外諸国からは，日本企業の経営者らは，損失の発生原因をよく理解できてないと言っている。

■日本企業共通の現象として，失敗したときに様々な理由を列挙する頭脳は備えている。指導者達は殆ど日本の最高学府で教育を受けているが，プログラミング（段取り作業とみなしている）などは，下級な仕事としか理解してないし，また，そのように教育されているようです。

(4) プログラムの存在が危機を回避する

■過去において，世界的に名をはせた我が国の著名エンジニアリング会社が，最近，目に見えて不調である。よくよく見ると，熟達のプロジェクト･マネージャーが居なくなってからである。彼等は，長年の経験から得た「プログラミング」術を心得ていたが，企業内部の不見識さが，跡継ぎの人材を手当てしてなかったのである。

■日本でも，ある職業人「現場の仕事師」は，驚くほどの「プログラミング」力を持っている。 多くの人達が見逃しているのが，先刻ご承知の，現場でいう｢段取り」のできる，技能者達です。

■その中でも 最も優れているのが「とび職」でしょう。彼らの仕事は，日々の仕事が命がけの仕事だからだと思う。 僅かの段取りミスも許されない，命に関わる仕事をしているからです。百メートルもの高所で，些細な手違いがあっても，段取りが違ったり忘れたりしていても簡単に下まで降りるわけにもいかない。それぞれの異なった職種の仕事師の間で連携がとれなかったり，他の支援手段を何も用意してないなら，全員が作業を中止するしかない。そうなると，プロジェクトのプログラムは停止し，作業の再編成が必要になる。そこに生じる損失は，プロジェクト関係者全員の責任なのである。

■典型的な例が米国にある。アポロ計画のサターン13号が起こした事故で，NASAが演じた，見事な衛星救助作戦がそれです。一旦絶望視された乗員3名は無事帰還した。彼らの「プログラム･ファイル」には，完璧なまでの「手順書」が完備されていた。下敷きになる，精細な「プログラム･ファイル」があったからこそ，それに基づいた作戦計画がたてられ，「救助プログラム」が短時間にまとめられました。もし，下敷きがなければ，前例のない救助プログラムを，短時間で完成することは出来なかただろう。

■典型的企業では，恒例行事の段取りは全て，総務部の平準的業務と決まっているようです｡彼らは「式次第」程度のことなら十分こなます。しかし，大プロジェクト遂行の「段取り」即ち「プロジェクト遂行プログラム」を編成することは，ほぼ不可能だろう。

(5) 先端企業でプログラムの重要さが認識され始めた

■近年，先端企業や海外で評価の高い企業では「プログラミング」の重要さを強く認識し始めた。そして，密かにその増強に努めている。（日本の上層部にいる識者達はまだ納得してない。プログラミング業務を現場の役割としか見なさない。）
  ・「システムエンジニア」と呼ばれるプログラマーが多数存在しているはず
  ・彼らは通常「ＳＥ」と呼ばれています。しかし，ここで一つ問題がある
  ・現存の彼ら「ＳＥ」の殆どは，「コンピュータ･エンジニア」でしかない
  ・当該するプロジェクトの専門家ではない。
プロジェクト･プランの実行プログラミングは，「プロジェクト･マネージャー」が行うべきである。そうでなければ，プログラミング作業はうまく処理できない。

■別の見方をすれば，日本には，プロジェクトを「プランニング」出来る専門家であって，しかも，一方で ｢プロジェクト･プログラミング」が出来る専門家は，現在は希である。これは，日本の企業，それにもまして国家的な不幸です。

               ― 以上 ―