どの上司にも通用する説明術（9）あるシステムエンジニアの説明が「課長を怒らせた」理由

　この連載では、「ダメに見せない説明術」を扱っている。前回までは、三つ目のダメ説明である「抽象的、具体的でない、表面的」をテーマに取り上げた。10のダメ説明は以下の通りである。

　今回から、四つ目のダメ説明である「理由がない、何故？が満載、説明が不足」をテーマにする。

自分の常識が他人への説明不足を産む

　もう、10年以上前の話であるが、筆者がある人から聞いた「説明」に関する興味深い話がある。今回はこれを紹介しよう。

　販売代理店業を営むA社に戸田氏（仮名）という30歳のSE（システムエンジニア）がおり、システム部門で業務システムの保守開発を担当していた。

　そのシステムはA社の社員向け人事管理(給与計算など)の業務システムなのだが、戸田氏がSEとして担当した時点ですでに20年以上も使われていた。古いシステムであり、毎年数回の仕様変更が入るとの話だった。

　つまり、このシステムでは稼働後、保守フェーズに入ってから20年以上も毎年数回の保守開発が行なわれていたことになる。

　古い業務システムを保守した経験のある人には分かると思うが、システムは保守開発を行なうと、次第にシステム規模（機能数、画面数、プログラムステップ数など）が増大し、保守生産性が低下するものである。

　保守生産性が低下するとは、システムに機能を追加する際に、稼働直後から年数が経つほど作業工数（作業を行なう際にかかる人間の作業量）が多くかかるようになる状況を指す。

　例えば、同じような機能（画面から項目を入力して、計算を行い、結果を出力画面に表示し、同時にデータベースにも書き込む）を、稼働後1年目に追加する場合と、20年目に追加する場合では、後者の方が工数が多くかかるということである。

　システムの規模が大きくなれば、追加開発の際に「システムをどのように修整・追加すれば良いのか（何処に条件判定を追加して、どこに計算ロジックを追加すれば良いのか）」という「既存システム影響調査」の作業量が規模に比例して増えていく。これが保守生産性を下げる一つ目の原因である。

　さらに、稼働中のシステムを変更すれば、それまでも問題なく動いている機能群の退行（修整をミスして、正しく動いている機能に不正が発生すること）のリスクが発生する。そこで、退行していないかどうかを確認する回帰検証（レグレッション・テスト）も必要になる。これが保守生産性が下がる二つ目の原因である。

　一般に、稼働してからの経過年数が長く、規模が大きくなったシステムほど、この二つの原因によって発生する作業量は大きくなる。これが、古いシステムの保守生産性が低下する理由である。戸田氏をはじめとする当時のA社システム部の保守開発チームにとって、このことは「あたりまえの常識」であり、深く考えたこともなかった。

　あるとき、次第に保守生産性が低くなっていくことを疑問に思ったA社の利用部門の課長が、「なぜ、工数が以前よりかかるようになったのか？」について戸田氏らに理由の説明を求め、戸田氏が対応した。

　戸田氏の説明は利用部門に通じたのか。

　残念なことに、まったく伝わらなかったらしい。「システム規模が大きくなっている事実」「なぜ、規模が大きくなったのかの理由」「規模の増大に比例して工数が多くかかるようになっている事実」をいくら説明しても、利用部門は頭を捻るだけであったらしい。「いくら説明しても理解してもらえなかった」と戸田氏は語っていた。

　A社利用部門の課長は最後にあきれ果て「君たちの説明はまったく分からない」「どうしても理解できない」「もういいよ！」と怒ってしまったのだが、それでも戸田氏は、「どう説明してよいのか分からなかった」とのことであった。

　戸田氏は当時、「このときほど説明は難しいと思ったことはなかった。常識として自分の身体に染み付いていることほど、他人には上手く説明できない。自分の常識が他人への説明不足を産むということを痛感した」と筆者に語った。このことは今でもよく覚えている。