標準機能があるのに、
なぜ追加開発するのか

FIRST QUESTION

最初に思ったのは、
「標準機能じゃダメなのか」だった。

Windchillは、 ゼロから作るシステムではありません。

製品情報や設計データを管理するための 機能がすでに用意されています。

画面もある。

データを扱う仕組みもある。

オブジェクトや製品構成を 管理する考え方もある。

そのため、 追加開発の話を聞いたときに、

「それは標準機能ではできないのか」

という疑問が出てきました。

既にあるものを使えるなら、 その方がシンプルです。

それでも、 実際の案件では 独自の機能が必要になることがありました。

WHY CUSTOMIZE

パッケージの考え方と、
現場の業務が完全には一致しない。

パッケージ製品は、 多くの企業で使えるように 作られています。

つまり、 ある程度共通化された 業務の考え方を持っています。

一方で、 実際の企業には その会社なりの業務があります。

長年使ってきた運用。

独自のデータ。

独自の承認方法。

他システムとのつながり。

パッケージ側の標準的な考え方と、 現場の業務が 完全に一致するとは限りません。

このズレをどう埋めるか。

そこで出てくるのが カスタマイズでした。

CAN vs SHOULD

「作れる」と
「作るべき」は同じではない。

技術的に実現できるかどうかだけを考えれば、 追加開発で対応できることはあります。

Javaを書けばいい。

JSPを変更すればいい。

独自ロジックを追加すればいい。

他システムとの連携処理を作ればいい。

ただ、 実装できることと、 実装した方がいいことは別でした。

一度独自機能を作れば、 その機能もシステムの一部になります。

修正が必要になれば、 その独自部分も確認する必要があります。

周辺機能との影響も見なければならない。

パッケージのバージョンが変われば、 独自機能への影響も確認する必要が出ます。

STANDARD FUNCTION

標準機能に寄せるという選択肢もある。

パッケージを導入するなら、 標準機能を活かすという考え方もあります。

今までの業務を そのままシステムへ持ち込むのではなく、

パッケージ側の仕組みに合わせて 業務を変える。

そうすれば、 独自開発を減らせる可能性があります。

ただし、 これも簡単ではありません。

システムに合わせて 現場の業務を変えるということは、

今までのやり方を 変えるということでもあります。

それが本当に可能なのか。

なぜ今の業務になっているのか。

そこまで見ないと、 「標準機能を使えばいい」と 簡単には言えません。

EXISTING BUSINESS

「今のやり方」には、
何かしら理由がある。

開発側から見ると、

「なぜこんな運用をしているんだろう」

と思うことがあります。

でも、 現在の業務には それまでの経緯があります。

過去のシステム。

他部署とのやり取り。

現場での使い方。

外部システムとの関係。

その背景を知らずに、

「標準機能に合わせればいい」

と決めてしまうのも違います。

逆に、

「今までこうだったから、 そのままシステムでも再現する」

だけでも、 パッケージを使う意味が薄くなることがあります。

この間をどう考えるかが 難しいところでした。

IMPACT

一つの変更でも、
影響範囲は一つとは限らない。

既存のパッケージ製品へ 手を入れる場合、

変更した箇所だけ見ればいいとは限りません。

画面を変更する。

その裏で呼ばれる処理がある。

その処理がオブジェクトを更新する。

更新されたデータを 別の機能が利用する。

場合によっては、 他システムにも連携される。

既存システムだからこそ、 変更前に 今どう動いているのかを見る必要があります。

Windchill案件で 既存コードを追る時間が長かったのも、 このためでした。

Eclipseを見ても構成が分からなかった話 →

REQUIREMENT

開発者だけでは、
「作るかどうか」は決められない。

技術的には、

「標準機能で対応できる」

「追加開発すれば実現できる」

という判断はできます。

でも、

どちらを選ぶのかは 技術だけでは決まりません。

利用する側が 何を必要としているのか。

今の業務を変えられるのか。

どこまで独自仕様を残すのか。

費用や期間をどう考えるのか。

いろいろな条件が関係します。

ここから先は、 単純なプログラミングの話ではなくなります。

顧客との要件調整については、 次の記事で整理します。

顧客要件と仕様変更の話を読む →

WHAT I LEARNED

パッケージ開発では、
作らない判断も必要になる。

当時の自分は、 開発の仕事は

「要件が来たら、 それをどう実装するか考える」

ものだと思っていました。

でも、 パッケージ製品を扱うと、

そもそも標準機能で 対応できないのか。

本当に独自機能が必要なのか。

業務側を変える方法はないのか。

追加した後の影響はどうなるのか。

実装に入る前に 考えることが増えます。

そこで初めて、

「作ること」だけが 開発ではない

という感覚が少し分かりました。

SUMMARY

標準か、カスタマイズか。
技術だけでは決められない。

パッケージ製品には 標準機能があります。

それでも、 実際の企業の業務と 完全に一致するとは限りません。

そのとき、

標準機能を使うのか。

業務を変えるのか。

追加開発するのか。

選択肢が出てきます。

追加開発すれば 実現できることもあります。

でも、 独自機能を増やせば その後もその機能を 見続ける必要があります。