良く起こす失敗要因「隠れたリンクに気づかない」

樹木構造の組織では、たとえば営業部門と技術部門に明確に縦割りで分割してしまうと、互いに関連（リンク）があるのにそれが意識できずに行動して
失敗が起こることもよくあります。

現実には、まったく別系統の末端のパート同士が互いに影響しあっていることは珍しくなく、これを「見えないリンク」と呼びます。樹木構造のなかで部署間のリンクを絶たれた組織では、隠れたリンクが思いもよらない失敗を誘発することがあります。

物理的な例を１つ考えてみましょう。

たとえば、パソコンをつくるとき、その組織はハードディスクやメモリ、制御用電子部品などの系統に分けられ、そこからさらに部品ごとに細分化してそれぞれ作業を進めるのが一般的です。

しかし、機械のなかのすべての部品と部品の間には見えないリンクが張られていて、ひとつの部品の働きが他の部品に影響を及ぼすことがあります。その見えないリンクに気づかなかったり、細分化された組織にあってそれを考えることもなく進めるために起きる失敗がよくあります。

たとえば、メモリそのものに問題がなくても、ＣＰＵ部分で生じている熱が、まわりの電子機器の制御に悪影響を与えて誤作動を起こしＰＣを暴走させるようなことは起こり得ることです。

本来、ＣＰＵと制御用電子部品には伝導される熱の影響といった点で密接なリンクがあるのです。だからこそヒートシンクや空冷/水冷のＣＰＵクーラーなどがあるわけです。

そうした関連の存在に気づかずに、それぞれの担当部署がそれぞれの担当分だけしか見ずに仕事を進めていると、必ず失敗を起こすことになります。

しかし、人間は「組織」と言う輪の中に入ると、それ以外については「我関せず」という姿勢をとる人も少なくありません。自組織の自分に割り当てられた仕事以外に興味を持つことを面倒と思い、敢えて面倒ごとには首を突っ込みたくないわけです。それが結果的に盲目性を助長させることになるとしても、です。

ところが、ソフトウェア開発の現場ではこれと同じようなケースに対して、ある意味で普段から解決策を以って取り組んでいます。それが

　影響範囲の調査

です。
「不良」「不具合」「バグ」と言った、予期せぬ問題が生じた場合、あるいはこれから開発するにあたって、変更する予定の箇所が特定できた場合、ソフトウェア開発の現場では必ずと言っていいほど、この「影響範囲の調査」を行います。

それでも問題が解決しないケースが後を絶たないのは、この「影響範囲の調査」を勘と経験と度胸（KKD）に頼るだけで、何一つ根拠のない対策しか実施していないためです。それはロジカルにアルゴリズムを組むエンジニアのすることではありません。

元来、これを仕組みとして正しく理解していれば「影響範囲の調査」はほぼ100%の割合で解決することが可能です。そして、その仕組みの根幹を成すのがプログラムたちが

　共有するリソース

の存在です。

プログラム間であれば、『引数(の値もしくはアドレス)』が共有するリソースでしょう。

データベースを介していれば、『特定のデータ』でしょう。

ファイルであれば、『ファイルそのもの』があれば『特定のシーク先情報』かもしれません。

他にも共有されたメモリが対象かもしれませんし、それ以外の外部リソースである可能性もあります。

しかし、プログラムである以上、そのプログラムが操作しているリソースを１つ１つ調べていけば、アクセスレベルが"Private"でない以上、必ず影響範囲が外部に及んでいる可能性があると言うことです。

ＩＴが「情報を取り扱う技術」である以上、情報がどこでどのように使われていて、どういった影響を及ぼすのかは、プロフェッショナルである私たちが知らなくていい情報のはずがありません。

それらの考察を整理したものが

として過去にまとめたものです。

これが仕事…タスク間であれば、『場所』『時間』『人』なども共有するリソースになりますね。

これらが重複すると、仕事が成立しない事故が起きることがあります。

たとえば、15時から会議を予定していて「会議室」を予約していたのに、15時になって見てみると、他のチームが会議室を占領していた…とか。

しかし、自分が所属する組織以外のことに見向きもしないようだと、他部署の『人』が、さらに別の部署の仕事とブッキングしていても、「我関せず」のまま自分の都合だけ押し付けようとすることになります。

本来、これは「隠れたリンク」ではなく「盲目的なリンク」と呼ぶべきかもしれませんが、こうした影響を見ようとしない、気づこうとする努力をしないうちは、よくある失敗として今後も継続することになるでしょう。

　外部リソースをどうやって共有するか

そしてその外部リソースの共有をどうやってオープン化するか、整理するか、問題が起きた時にすぐに確認できるか。チーム、グループ、部署、組織、etc.…呼び名はそれぞれですが、そういった単位でどのように管理できるかが、その集団における事故の頻度や影響度合いに大きく関与していくことでしょう。