システムは完成品ではない。育てるものだ。
Configurationが変えた私のシステム観
うわっ！システムがプログラムを書かずに姿を変え始めた！
■ システム構築には自信があった
システム開発に携わってきて、気が付けばプロジェクトをコントロールする立場になって8年が経っていた。
若い頃はJavaを中心としたシステム開発に関わり、設計から開発、テスト、運用まで一通り経験してきた。
正直に言えば、システム構築にはそこそこ自信がついていた。
要件を聞く。
設計する。
開発する。
テストする。
リリースする。
そんな流れが当たり前だと思っていた。
ところが、その考え方を大きく揺さぶられる経験をした。
海外製パッケージシステムの導入プロジェクトだった。
■ ロンドンで学んだ新しいシステム思想
お客様のシステムを構築するため、私はロンドンで2週間の研修を受けることになった。
そこで学んだのは単なる製品知識ではない。
システム構造そのものの考え方だった。
当時の私は、「お客様の要件はプログラムで実現するもの」だと思っていた。
もちろん設定は使う。
OSの設定。
サーバ設定。
ログの保存期間。
メモリ割り当て。
ジョブスケジュール。
プログラムを最適に動かし、運用しやすくするためのConfigurationである。
つまり、Configurationはシステムを支える裏方だった。
■ Configurationの役割がまったく違った
しかし、そのパッケージは違った。
驚くほど多くのConfigurationが存在していたのである。
しかも目的が違う。
システムを動かすためではない。
顧客ごとにシステムを変えるために存在していた。
承認フロー。
画面項目。
入力ルール。
通知条件。
業務プロセス。
顧客ごとの個別要件をConfigurationで吸収していた。
最初は驚いた。
「こんなことまで設定でできるのか？」
「これ、本当にプログラムを書かなくていいのか？」
研修中、何度もそんな疑問を持った。
■ システムは完成品ではなく成長するもの
だが次第に理解していった。
このシステムは完成品ではない。
成長することを前提に設計されているのだ。
運用しながら改善する。
顧客から新しい要望が出る。
すぐに開発しない。
まずConfigurationで吸収する。
それでも足りなければ次のリリースで機能追加する。
システムはどんどん育っていく。
そして顧客に合わせて変わり続ける。
■ 本当に重要なのは運用だった
私はそこで初めて理解した。
本当に重要なのは開発だけではない。
運用である。
運用しながら学び、
運用しながら改善し、
運用しながら価値を高めていく。
システムの寿命はリリース日から始まる。
開発完了はゴールではない。
スタートだったのだ。
この経験は今でも強く記憶に残っている。
■ システム競争力はコードか、Configurationか
なぜなら、日本のシステム開発は今でも「要件を固めて開発する」発想が強いからだ。
もちろんそれも必要だ。
しかし本当にそれだけで良いのだろうか。
顧客ごとに違う業務。
変化し続ける市場。
AIによって加速する要件変更。
そんな時代に、すべてを開発で解決しようとするのは限界があるのではないか。
むしろ、
「どこまでを設定で変えられるか」
こそがシステム競争力になるのではないだろうか。
議論を呼ぶかもしれない。
しかし私は最近こう考えるようになった。
未来の優れたシステムとは、
優れたプログラムを持つシステムではなく、
優れたConfigurationを持つシステムなのかもしれない。
■ ロンドンで得た最大の学び
ロンドンで学んだ2週間は、単なる製品研修ではなかった。
システムの未来を考えるきっかけだった。
そして今でも新しい技術に出会うたびに思う。
システムの世界は、本当に奥が深い。
まだまだ知らないことがある。
だから面白い。
コメント
コメントを投稿