PM視点で読み解く 基幹システム運営録 5： 改善は作り直しではない — 判断を積み替えるということ
第4話では、現在の基幹システムの構成と、その背景にある意思決定について整理しました。
では、このような既存システムを前提としたとき、どのように改善を進めていくべきなのでしょうか。
基幹システムを見ていると、「一度リセットして作り直したい」と感じる瞬間は少なくありません。構成の複雑さや技術的負債、理想とのギャップを前にすると、そのように考えるのは自然なことだと思います。
しかし実際には、基幹システムを全面的に作り直すことは容易ではありません。業務を止めることはできず、データ移行の難易度も高く、見えていない依存関係も多く存在します。仮に作り直せたとしても、同じような問題を別の形で抱える可能性もあります。
では、どうするのか。
本稿で扱うのは、「作り直す」以外の改善の考え方です。
基幹システムの改善とは、設計をゼロからやり直すことではありません。過去の意思決定を前提に、現在の状況に合わせて判断を見直し、少しずつ構造を変えていくことです。
本記事では、このような「判断を積み替えていく」という視点から、既存システムをどのように改善していくかをPMの観点で整理していきます。
1. 導入：なぜ「作り直したい」と思うのか
皆さんは基幹システムに対して様々な不満を持たれているのではないでしょうか。
- 入力がしづらい
- 項目が多すぎ、かつ何がどこに影響するのかわからない
- 複数のシステムにアクセスしなければいけないのは面倒
- ちょっとした改善要望がものすごく時間がかかったり、却下されたりする
- etc...
このようなことが続くと、段々とイライラしてきて「全部一から作り直せばいいじゃないか！？」と考えてしまうのも自然なことです。しかしながら、こうなっているのはこれまでの歴史的経緯が背景にあることは、これまでに述べてきた通りです。
システムを止めずに、その都度発生する要件に対応しているうちに、こうなってしまっている。一から作り直したいという気持ちに深く同意しつつも、少なくとも、多くの現場では現実的ではないと私は考えています。
- 技術的負債
- 複雑化した構成
- 絡み合った運用
こうしたことを無視して、感情としての「リセット欲求」に従うべきではありません。
2. 一歩ずつ改善。そして、改善とは何か？
さて、基幹システムの全面刷新が
- データ移行の難しさ
- 業務停止リスク
- 学習コスト
- 見えていない仕様や運用
- 想定外の依存関係
といったことから、全面刷新には非常に高い難易度が伴うと一旦理解いただけたとして、では、どうすれば良いのでしょうか？
それはとても凡庸で、つまらない結論になってしまうのですが、少しずつ、一歩ずつ改善していくしかありません。
目の前の床に落ちているゴミを一つ一つ拾っていくようなステップを刻むことになります。
様々な制約や関係者、既にある運用に配慮しながら、制約の中での最適化を行っていきます。
影響範囲を丁寧に調べ、ボトルネックを特定し、優先順位をつけ、変更コストを見積り、リスクを評価し、そしてそれら全てを関係者に説明してまわり、進めていくことになります。
そこには、ドラスティックな改革はありません。でも、一つ一つ小さな歪みを整えていくようなあゆみを続けて、ある日振り返ると大きな成果がそこには積み上がっているものです。そして、その一つ一つのステップで行われていることは、再設計ではなく、作り直しでもなく、過去の判断を少しずつ積み替えていくということなのです。
これまでを否定するのではなく、ここに至った経緯を理解して、現状を理解して、少しずつ整えていく。少しだけ変えてみて、わかったことをフィードバックとして入力し、また少しだけ変えてみる。その繰り返し。
3. PMに求められる姿勢
さて、そんな小さな継続的改善を基本ポリシーとするPMに求められる姿勢とはなんでしょうか？
当初、頭をよぎったのは
- 最適化より業務の継続性を重視すること
- 意思決定の粒度を細かくし、その責任を明確にすること
- バランス感覚を持ち、否定ではなく肯定で未来を語ること
といった諸要素でした。
「なぜこんな設計にしたんだ」と過去を責めるのではなく、「今の状況を踏まえると、次はどう改善できるか」を考える。
その姿勢が、継続的な改善には重要と考えているのです。
しかしながら、こうした要素よりも、というよりその根本に必ず必要になるものがあると最近気づきました。
それは、リスペクトです。
ステークホルダ、関係各位に対するリスペクト。
これまでの経緯に対するリスペクト。
現状に対するリスペクト。
こうしたリスペクトがなければ、長期間にわたる地道な改善の旅程に誰もついてきてくれないでしょう。
短期的にドラスティックに変える取り組みであれば、リスペクトは必須のものではないのかもしれません。
ですが、基幹システムの改善、運営においてはリスペクトは必須であると考えています。
4. まとめ
基幹システムの改善に、魔法のような解決策はありません。
一度全てを壊して作り直せば綺麗になる、というものでもありません。
現実には、
- 業務を止めず
- 利用者に配慮し
- 制約と向き合い
- 少しずつ改善を積み重ねていく
という地道な歩みが必要になります。
それは決して派手な仕事ではありません。
ですが、その小さな積み重ねこそが、数年後に振り返ったとき、大きな改善へと繋がっていくのだと思います。
そして、その改善を支える土台になるのは、技術だけではありません。
これまでの経緯、現在の運用、そして関わる人たちへのリスペクト。
基幹システムの改善とは、システムだけを変える仕事ではなく、人と業務の歴史に向き合いながら、未来へ少しずつ判断を積み替えていく営みなのだと思います。
