診療では、分類や構造的な事を記載してきました。もう少し具体的な事に踏み切ろうとも思ったのですが、どのような治療ができるかを理解しなくては、診療方針は立てられません。
内部にひそんだ不具合への診療は、直せばいいというものではありません。と、言うのは正常と異常の境界線が具体的ではないからです。ログも、コストからくる実現範囲も、曖昧なものです。癌の転移、薬による副作用など、変化を加えれば、新たな問題が生まれるのは、人体同様で、人間的です。
【プログラム的欠陥】
他の章にも、記載しましたが、プログラムは分岐とループからできています。ITというとビジュアル的なものをイメージすると思いますが、ディプレイへの表示も、左上の座標０、０から右下へカウントアップする座標軸であり、個々の座標軸に対し、RGBという赤緑青の明るさを０～２５５まで表したにすぎません。ビット操作からレイヤーであったりモデリングだったりは、条件をつけてRGBの定義グループを作り、どの座標から表示し始めるかとなります。あるいは、各グループをさらに分けて、影を付けたり、動作パターンを設定したりと概念から概念へ的を絞りながら、定義と動作を組み合わせていきます。いまどき、RGBから、それら全ての概念を作る人はいなくて、確率した概念とそれにしたがって作成されたソフトを利用するのが主流です。業務系プログラムは、ビジュアルは簡素な分、情報と情報の概念が重要になります。簡単にいうと、人と行動です。誰が何をするのか。
人の定義でも、下記のようにあります。
- 〇〇サービスエンドユーザ（利用者）
- 〇〇サービスエンドユーザ（管理者）
- システム運用者
- システム管理者
- 〇〇業務利用者
- 〇〇業務管理者
上記の〇〇は複数のサービスや、業務を抱えている分増えます。例えばプロバイダーサービスとなると、サイトやメールを管理する事になります。サイトは、URLをどうするか、利用期間や料金は、一律か、それぞれサービスを分けて変動にするのか。申請と承認はどのようにするのか。こういった具合にいくつも情報を扱う事になります。社内業務でも社員管理は人事部が行い、勤怠管理は業務部、人件費としての経理部であったり、また、受発注業務があれば製品情報や取引先企業情報と抱える情報が増え、それぞれに申請者、利用者、承認者がいます。受発注システムを取引先企業とオンラインで結ぶとなると、どのタイミングで接続し、データを送るのか、接続エラーはといった機能の中身の情報も増えます。情報は定義し、その情報には誰により発生し、誰に伝え、自信の情報の有効性をフラグや日時で表します。ITというようにまさしく、情報概念の技術です。上記の事は、全て分岐と他の情報を取得する際のループになるのです。分岐を直すとは、正確には分岐部分に新たな分岐を追加するという事は、どのような治療になるでしょうか。システムをまったく使わなかった場合を考えてみましょう。
自社で扱っている製品に対し、新たな顧客から発注の連絡がきました。営業部から製造部に連絡がいき、製品名を数量を伝えます。製造部では部品をメーカーに発注します。部品がとどき、加工したのち、顧客に納品するという一連の業務がありました。この仕組みを作るのは、１週間とかからないでしょう。というのは、現実的にはありえないからです。顧客から発注が来る際、納品はいつか？と問われます。社内の営業は１人しかいなく、もう、顧客を受けいられない。そんな状況をどうするのか。経理部の人をとりあえず担当にしました。これが実際とシステムでは人と権限が異なるという事象です。担当営業がつけられ、製造部に連絡をとった後に顧客から価格交渉の連絡が入りました。製造部にはどの機能を省けばコスト削減につながるかと相談し、経営企画部には初顧客に対し、利益率を変更する事ができるかを相談します。どちらもNGとの回答があり、顧客と話すが、難航している中、製造部が部品を発注してしまった。というのは、部品の発注は定期的に行っている為、数量を変えるだけならコストは抑えられるが、最初に提示した納品に合わせる為に、受注が確定してからでは、特別に発注を行わなくてはならず、新たにコストが発生してしまうからです。顧客との交渉が決裂し、発注キャンセルとなりました。部品が余ってしまう為、製造部と経営企画部は相談し、キャンペーンを打ち出す事にしました。その時、定期的に納品していたお得意さんから今月だけ、２倍の数量を納品してほしいと連絡があり、キャンペーンがあだになりました。キャンペーンは好調で、何社からも発注がきています。経営者は、機会損失と不良在庫、ここ数か月の利益がどのようになっているかを知りたくなりました。この話はまだまだ、かけるのですが、実際の業務はもっと複雑である事と、目の前の業務に追われ、会社の状況が見えなくなっていきます。ここでの登場は、顧客、営業（経理兼務）、製造、経営者という人と受注、発注、製造、在庫、会計、企画といった業務です。それぞれの関係と、有効と無効、いつ、いくつといった情報を定義します。これが概念になるのですが、文量の中に突発的な事象が、ある分、分岐機能が必要なります。経営的観点から各情報のループ機能が必要になり、受注済みは何件あり、部品の在庫はいくつあり、発注はいくつ必要か、また、その料金の差額（利益）はいくらなのかを把握します。
もうひとつ、ハードディスクからの観点を書いてみましょう。これはシステムを使わなかった場合ではないのですが、単純仕組みを述べます。ある処理からディスクに書き込み指示があり、未使用領域に新たな領域を確保し、書き込みました。これも、現在実装している内容からは随分、異なります。新たな領域に書き込んでいたら、あるブロックから書き込めないという信号がきました。しょうがないので、そのブロックは今後使用しない事として番うブロックに書き込みました。と、ある日ブロックどころかディスクと接続できない事象が発生し、２本のディスクで冗長化を張っていたので、１本を障害ディスクとして、残り１本のみを使用する事にしました。ディスクを交換したので、障害ディスクという認識を正常に切り替えました。正常なディスクが２本になったので、今まで使用していたディスクでは通常の読み書きをしながら、もう一本へのデータのコピーを並行で行います。ディスクへの書き込みが遅くなってしまったので、もともと、指示をだしていた処理も、どんどん遅くなります。しかたがないので、ディスクのコピー処理が終わるまで、メモリに貯めておく事にします。ところがメモリも全て使い果たしてしまい、このままではシステム全体がとまってしまう為、別なディスクをメモリのように利用するようにしました。これも、ディスク専用のメモリがあったり、１対１の冗長以外に１対n（冗長箇所を複数のディスクに分散）の冗長があったり、固定から仮想化して利用者から意識させなくしたりといろいろあります。
人もハードも、エラーといった異常事態にどのように備えるかの分岐です。人間同士はこの異常事態をあまり意識せず、よくある事と対応する事ができますが、システムでは定義しなくてはなりません。異常事態の分岐に変更を加えるという事は、もともとの異常事態に対応できなくなってしまう可能性があります。あるいは異常事態の状況を把握していない為に、分岐の入れ方を間違い、対応できていなかった。後者は、結局何もしないのと同じですが、前者は何が起こるかわからない事につながります。極力、正常な組織に傷をつけないように異常個所をピンポイントで直す。これは外科的治療です。内科的治療は、その機能を使わない。できればピンポイント使用しないのが好ましい。人体と異なるのは自然治癒能力がない事です。運用回避という言葉が、内科的治療です。営業と経理部の兼任者の利用は一人の営業が行ったものとし、メモ欄に経理部の〇〇さんが兼任と記載するような対処です。ハードディスクであれば、もうそのディスクへの書き込みをやめて読み込みだけにするといった対処です。では、使わなくてはならない、兼任業務をシステム化したり、情報をディスクに書き込まないいけない場合は、どうするのかというとこれは外科的治療が必要なります。外科治療は別章に書きます。内科治療ではこの後、どのように使わないかを記載していきます。