BPR（ビジネスプロセス・リエンジニアリング）とは業務本来の目的に向かって既存の組織や制度を抜本的に見直し、プロセスの視点で、職務、業務フロー、管理機構、情報システムをデザインしなおすことで、最近ではこれをDXと呼んでいたりします。
「塩漬けシステム」という表現は一般的に、長期間更新や改善が行われていない古いシステムを指します。レガシーなシステムをどのように対処していくかという方法は、新システムの目的、現在の状態、組織のニーズによって様々です。
旧システムがまだ有用で、随時アップグレードや更新を行っていれば、大きな新しステムの入れ替えは必要ありません。しかし、多くの場合はシステムに関する知見が乏しいまま運用を行ってきていて、細かなアップグレードを怠っていたようであれば、新しいシステムに置き換えるという一大プロジェクトとなってしまうでしょう。
一方、システムが古くなりすぎてアップグレードが不可能または非効率的である場合には、新しいシステムに置き換えることを検討することがあります。新しいシステムに置き換えるには、時間とリソースを必要としますが、長期的に見れば効率性と生産性を向上させる可能性があります。
新しいシステムに移行するまでの間、またはシステムのアップグレードが予定されている間、既存のシステムを機能し続けるためには、適切な保守とメンテナンスが必要です。システムがもはや必要でない、または効率的でない場合、そのシステムを完全に廃止することも考えられます。一つのシステムという視点ではなく、業務に関わるすべてのITという視点でアプローチし、システムの機能、コスト、リスク、そして組織のビジネスニーズを総合的に考慮することが必要です。
俯瞰的にITを分析するにはITに詳しいコンサルタントと、開発現場に詳しいエンジニアの両輪がとても重要になります。日本のプロジェクトの失敗確率は50%と言われいる通り、その背景にはシステムのことはわからないのでITベンダーに丸投げしていることが失敗の原因として多いようです。しっかりと旧システムと新システムの変更管理プロセスを用いてスムーズな移行を計画し、リスクを最小化することが重要です。
どこから手をつけるか
小さな規模のときから、システムを業務に合わせて作ってきた「こだわりシステム」の場合は、システムが非常に複雑で理解や修正が難しく、しばしば「スパゲッティコード」や「レガシーシステム」の問題となります。まずドキュメンテーションの更新と整備から始めることです。システムがどのように動作するのか、そのコンポーネント間の関連性は何かを理解し、その中で属人化している情報を拾い集めるためにはドキュメンテーションが欠かせません。
やはり、重要な点はシステムの知識と経験を持つ専門家の協力です。社内にそのようなエキスパートがいない場合、外部から専門家を招くことを検討することも有効な手段となるでしょう。
ある程度のメンテナンスされているシステムであれば、その複雑さを理解しやすくするために、リファクタリングも考えられます。リファクタリングは、コードの機能を変えずに内部の構造を改善することで、可読性がよくなり、さらなる理解を容易にします。
リスクを抑えるために、システム全体を一度に置き換えるのではなく、小さな部分から始めて段階的にシステムを新しいものに置き換えていくことも有効です。これはストラングラー・パターンと呼ばれる手法で、新旧のシステムを同時に稼働させつつ、少しずつ新システムへと移行していく方法です。これについても、時系列で情報を見通せる専門家の力を借りるべきでしょう。エンジニアは完成に向けて進めることを得意としているため、完成した新システムと業務のギャップを埋めるには難しいかもしれません。
いずれにしても、相当な時間とリソースを必要とします。そのため、組織全体のサポートと理解が重要となります。これらの対策を通じて、複雑なシステムの問題を小さな部分に分解し、解決していくことが大切です。
専門知識を学んでいないSEが対応することも多い
ITエンジニアの能力を評価する際、IT知識の教育背景は一つの要素ですが、必ずしもスキルという指標だけではありません。特定の分野での専門的な学習を積んできたかどうかは重要ですが、それ以上に重要なのは、個々の能力、経験、専門知識、そして継続的なプロジェクトへのコミットメントです。
プログラミングスキルや知識について、専門的な学問を学んでいない人でも、現場で得た経験や独学による知識を通じて高度なスキルを獲得していることがあります。業務的な問題解決能力と技術的な問題解決能力はことなるため、スキルシートや業務経歴だけの判断は困難かもしれません。長年にわたる実務経験は、教育とは異なる視点と深みをもたらすことはありますが、実際にどのような問題に直面し、それをどのように解決してきたのか、問題解決した内容は業務が中心か技術が中心かを聞くことが大切です。
IT分野では、特定のスキルや知識を証明するための認定試験や資格が数多く存在します。これらは基礎的なスキルを持っているか、ひと目で知ることができます。
どのような背景を持つ人を採用するか、またはどのチームに配属するかは、その人が必要とされる具体的なスキル、タスク、そして組織の文化によります。エンジニアのスキルはその範囲はとても広く、知識だけでなく、業務における問題解決の能力、技術における問題解決の能力、創造性、チームワーク、コミュニケーション能力、そして学習意欲なども含まれます。特にソフトウェア開発の領域では、新しい技術が絶えず登場していますので、新しい知識や概念を早く活かすことができるメンバーは重要になることでしょう。その技術を実際の問題解決にどのように適用するか、どのようにその技術がビジネスの目標やユーザーのニーズに貢献するか、整理してもらうのもいいかもしれません。
全世界のエンジニアが直面する課題として、これらのスキルをバランス良く持つことが求められています。
抽象と具体をうまく理解できていること
情報を整理していく上で、抽象的な概念と具体的な実装の両方を理解し、うまく論述できる能力は、システム設計において非常に重要です。これにより、エンジニアはシステムの全体像を理解し、具体的なコードのレベルでの問題をより大きなコンテキストで考えることが可能になります。抽象的な思考は、システムがどのように動作すべきか、どのような設計原則に基づいて構築されるべきかを理解するのに重要なスキルです。
しかし、それだけが全てではありません。ソフトウェア開発はチームワークであり、プロジェクトの成功は個々のエンジニアのスキルだけでなく、チーム全体のコミュニケーション、コラボレーション、そして組織全体の文化やプロセスにも大きく依存します。
経験豊富なエンジニアが新しいアイデアや技術を採用しない、または古い方法に固執する傾向があると危険信号です。しかし、実績のない方法や技術については組織にとって挑戦となる場合があります。経験と知識は重要な資源であり、それを最大限に活用するためには、組織全体で学習と成長を促進する文化を同時に育てることが非常に重要です。これには、新しい技術の探求、異なる視点の尊重、そして失敗からの学習について寛容でなければなりません。
組織には様々な年齢、バックグラウンド、スキルセットを持つ人々が存在し、それぞれが持つ視点や経験がチーム全体を補完し、成長させることが可能なのです。新しいアイデアや経験をバランス良く混ぜ合わせることで、より強固で効果的なシステムを設計し、開発することができます。
まとめ
ITベンダーとプロジェクトマネージャーで大きく結果が変わる新システムを成功に導くためには、一つの目標に向けてチームを導き、問題を解決し、成功に導くための環境を作り出す人物です。これは、技術的なスキルだけではなく、リーダーシップにも大いに依存します。リーダーはビジョンをもとにチーム全体が達成しようとする目標を明確にし、それに向けての進行方向を示す必要があります。
現場とシステムに傾倒しすぎているリーダーもプロジェクト進行中は迷子になりやすいですし、受注だけを取ってくるといった営業に傾倒しすぎているリーダーも問題の本質を捉えにくいですから、ちょうどいいバランスのとれたITコンサル＆システムエンジニアのタッグが重要ですね。
どうしていいかわからない、こだわりの塩漬けシステムのご相談はアタラキシアDX株式会社まで。SaaSを使った解決方法などもご提案可能です。
