業務システム開発の難しさ

業務システム開発の難しさについて考えたことをメモ書き。

【1】システム開発の対象は、業務システム以外にも、Webもあれば、最近ならスマフォやタブレットなどもある。
Webやスマフォ、タブレットは、リリースやデプロイ作業が自動化できるれべるになっていれば、アジャイルに開発しやすい。
リリースサイクルを短くできるならば、顧客を要件定義に深く巻き込むことで、オンサイト顧客に近い立場で開発しやすい。

しかし、業務システム開発は、機能が膨大なシステムになりやすく、全体像を見えるようにするのが難しい。
でも、それ以外にも、アーキテクチャの観点と体制の観点で、Webやスマートフォンの開発よりも難しい点が多いと思う。

【2】業務システムのアーキテクチャの観点では、いつも下記の4つにいつも苦しんでいる。

(2-1)ERPの導入方法(一括移行、段階移行、パイロット導入)
(2-2)ERPのリプレース(リライト、ラッピング、リホスト、リエンジニアリング)
(2-3)システム間連携 or 外部接続(リアル連携、メッセージキューイング、バッチ処理、EAIなど)
(2-4)データ移行(マスタ、トランザクションのデータ変換)

一つのシステムを作りこむだけでも大変なのに、複数の部門へシステムを導入して運用に載せたり、複数のシステムとデータ連携したりする作業がどうしても発生する。

外部接続やデータ移行は、その技術レベルはさほど難しくないし、事例も数十年以上前からあるのに、いつもトラブルが発生する。
設計の詰めが甘かったり、性能要件の考慮が漏れていたりしたために、動かしてみて初めて障害に気づく時が多い。
リプレース作業も、ハードウェアを交換するだけで、プログラムはそのままでいいはずなのに、ApacheやDBなどのミドルウェアのVerUpによって、プログラムのリコンパイルが発生したり、リライトが発生したりする。
更には、回帰テストしてみると、バグがどんどん出てくる時もある。

複数の部門に導入する場合、現場の責任者や担当者に説明会を開き、納得させて、実際に運用してもらわないといけない。
すると、彼らから信頼を得るために、色々と交渉したり折衝する必要が出てくる。
しかし、ベンダーとユーザ企業の間で役割が曖昧な場合、この辺りのやり取りがうまくいかない時がある。

多分、体制が不十分なために、ベンダー担当者も現場担当者も当事者意識が薄くなり、本気で業務システムを運用しようという雰囲気にならないのだろう。

【3】業務システムの上記4つの問題点に対する解決方法は、僕はまだ知らない。
古くから知られている技術であるにも関わらず、今もなお、問題解決はコンテキスト依存が多すぎて、この手法が良いというレベルまで落としきれていない。
でも、それぞれの技術の詳細をリストアップしてみると、利点と弱点は明確になっているので、1つずつ潰していくしかないのだろうと思っている。

また、体制面の問題は、ベンダーの上司(プロジェクトオーナー)やユーザ企業のオーナー(プロダクトオーナー)を巻き込んで、いかに彼らに動いてもらうようにするかが大切なのだろうと直感している。
現場リーダーがいくら頑張っても、ユーザ企業の担当者がこちらが準備したシナリオに納得して動いてくれないと、ゴールに導けない。

そのためには、現場リーダーには、プロジェクトオーナーやプロダクトオーナーというパトロンが必要なのだと思う。
彼らがバックにいて、現場リーダーを支援してくれるからこそ、プロジェクトは前進するし、現場担当者も当事者意識を持って本気を出して当たってくれる。

そんな事を考えると、スクラムというフレームワークはうまくできていると思う。
プロジェクトの体制を一から作らずとも、スクラムのフレームワークを適用すれば、ベンダーやユーザ企業の担当者に役割がアサインされ、有機的に動く仕組みが整う。
そんなフレームワークが適用されていなければ、現場リーダーが自ら体制を作り、提案して、根回ししないといけない。

【4】システム開発は技術だけでは解決できない部分が多い。
その部分はアーキテクチャだったり、体制だったり、開発プロセスだったり、色々ある。
その部分をもっと明確にまとめてみたい。