• 

改修効率化、経営層の理解がカギ

システム改修業者を変えても効率が改善されないという問題は、多くの企業で起こっています。
その原因は、大きく分けて2つ考えられます。

1つ目の原因は、システム開発の全体像を理解していないことです。

システム改修は、単なるプログラミング作業ではなく「要件定義・設計・開発・テスト・運用・保守」など、さまざまな工程が連携して進むものです。これらの工程を適切に進めるには、システム開発の知識と経験が必要です。しかし、多くの経営層は、システム開発の専門知識を持っていません。そのため、システム改修業者に任せっきりになり、効率の悪い改修が行われてしまうことがあります。

2つ目の原因は、システム改修の目的を明確にしていないことです。

システム改修には、さまざまな目的があります。例えば、業務の効率化、コスト削減、セキュリティ強化などです。目的が明確になっていないと、必要な改修内容が漏れたり、不要な改修が行われたりする可能性があります。また、目的が明確でないと、改修後の成果を評価することも難しくなります。

これらの原因を解決するためには、経営層がシステム開発を理解することが重要です。そのためには、経営層向けのシステム開発の基礎知識や、システム改修の目的と効果を理解するための研修などを行うことが有効です。また、経営層とシステム開発部門の間で、システム改修の目的やスケジュール、成果などを明確に共有することも重要です。

以下に、具体的な解決策をいくつか挙げます。

• ・経営層向けのシステム開発の基礎知識研修を実施する
• ・システム改修の目的と効果を理解するための研修を実施する
• ・経営層とシステム開発部門の間で、システム改修の目的やスケジュール、成果などを明確に共有する
• ・システム改修の成果を可視化し、経営層に定期的に報告する

これらの対策を講じることで、システム改修の効率を改善し、経営層が求める成果を達成しやすくなるでしょう。また、システム改修業者の選定を慎重に行い、経営層と協力してシステム改修を進めることで、効率の良い改修を実現できるでしょう。

改修の落とし穴

ここで、既存システムの改修見積りが高くなってしまうという、ある例え話をします。

++++++
ある古い家があり、その家は数年にわたって様々な人々によって改築や修理が繰り返されてきました。
壁には隠された配線や配管があり、床下には古い構造が残っているかもしれません。

新しくその家の改修を依頼された大工が現れたとします。この大工は腕が良く、最新の工具を持っています。しかし、彼はこの家の過去の改築の経緯や隠された構造を知りません。

一方、家の建てられた当初から修理や改築を手掛けてきた経験豊富な大工がいます。彼はどこに古い配線があり、どの部分が特に注意が必要か、どんな材料や方法が以前使用されていたかを正確に知っています。

新しい大工が改修を開始すると、壁を開けたら古い配線が出てきたり、床を剥がしたら予想外の構造が露呈したりします。予想外の障壁に直面し、露呈した時点で対策を考えなくてはなりません。

こういったリスクを考慮すると、必然的に新しく改修を手がける大工の見積りは高くなります。
++++++

システムの複雑性を「見える化」

システムの複雑性は、システムの規模や機能の数、相互接続の複雑さなどによって定義されます。
複雑なシステムは、理解や変更が困難になるため、システムの品質や信頼性を低下させる原因となります。そのため、システムの複雑性を見える化して、その程度を把握することは重要です。

システムの複雑性を見える化する方法は、大きく分けて2つあります。

1つは、定量的な指標を用いる方法です。
例えば、データベースのフィールド数、プログラムの行数、クラスの数、関数の数などを数えて、システムの規模を測定することができます。また、処理の複雑さを測定するために、サイクル数やメモリ使用量などの指標を用いることもできます。

もう1つは、定性的な評価を用いる方法です。
例えば、システムの設計図やドキュメントを分析して、システムの構造や機能の複雑さを評価することができます。また、システムのテスト結果や運用実績を分析して、システムの安定性や信頼性を評価することもできます。

データベース全体のフラグを用いるフィールドの数を数える方法は、定量的な指標を用いた方法の1つです。フラグは、ある条件を満たしているかどうかを表すために使用されるデータ型ですが、フラグを用いるフィールドの数が多いほど、システムの状態を管理するための処理が多くなると考えられます。そのため、この指標を用いることで、システムの複雑さをある程度把握することができます。

しかし、この指標にはいくつかの限界があります。

まず、フラグを用いるフィールドの数は、システムの複雑性を完全に反映しているとは限りません。例えば、フラグを用いて表現できる状態を、別のデータ型を用いて表現することもできます。また、フラグを用いるフィールドの数は、システムの設計者の能力を直接反映しているとは限りません。フラグを用いる理由は、システムの状態をより効率的に管理するためである場合もあれば、システムの設計者の能力が不足しているためである場合もあります。

そのため、システムの複雑性を見える化するためには、複数の指標を用いて、多面的に評価することが重要です。また、定量的な指標と定性的な評価を組み合わせることで、より精度の高い評価を行うことができます。

SEの視点はビジネス全体ではない

システムエンジニア（SE）の「オンスケです」「今やってます」という言葉は、多くのビジネスパーソンにとって安心感を与えるものでしょう。しかし、その言葉を鵜呑みにしてはいけません。なぜなら、SEの見えている範囲がビジネス全体ではなく、自分の担当プログラムということが多いからです。

SEは、システムの「設計・開発・運用・保守」を担う職種です。システムは、ビジネスの要求を実現するために構築されるものであり、SEはビジネスの理解が不可欠ですが、現実にはSEがビジネスの全体像を把握できていないケースは少なくありません。

その理由は、SEの業務が専門的なものであるため、ビジネスの全体像を把握する時間や機会が少ないことにもあります。また、SEは自分の担当プログラムの責任を負っており、それ以外の部分には関心が薄いということもあるでしょう。

そのため、SEが「オンスケです」「今やってます」と言ったとしても、ビジネス全体のスケジュールや進捗状況と必ずしも一致しているとは限らず、むしろ、自分の担当プログラムだけがオンスケで、他のプログラムが遅れているという可能性もあります。

また、SEはプログラムが終わったら完了したという認識を持っていることが多いです。これは、SEがプログラムの開発に集中し、プログラムの完成をゴールと考えてしまうことに起因していますが、システムは、プログラムが完成しただけでは完了したわけではありません。システムがビジネスの要求を満たすためには、システムのテストや運用・保守も必要です。

そのため、SEの「オンスケです」「今やってます」という言葉を鵜呑みにするのではなく、ビジネス全体のスケジュールや進捗状況を把握することがとても重要です。また、SEと定期的にコミュニケーションを取り、システムの開発状況や課題を把握しておくことが望ましいでしょう。

まとめ

いかがでしたか？

複数の医師から意見をもらうことをセカンドオピニオンといって、医療の業界でも普通になってきました。ITの業界も本当に正しい対応がなされているのか、数字で見えにくいソフトウェアだからこそ、信頼できるITアドバイザーを据えることが、システム維持管理にとても大切です。

プロジェクトに途中から参画する場合は設計を熟知できているわけではありせん。しかし、これまでの経験やノウハウを活かし、ベンダー変更によって引き起こされる障壁をあらかじめ推測したり、露呈した障壁に対して迅速な指示をすることはできます。

2025年の崖で転がり落ちないためにアタラキシアDXによる診断だけでもご相談くださいませ。