パッケージインテグレーションとエコサイクル

私はパッケージソリューションの企画手伝い and 開発 and 保守というお仕事をやっているので、お客様はいろんな業界に渡ります。官公庁であったり、銀行であったり、製造業であったりするわけです。得意分野のノウハウを価値として売っているため、お客様の業務内容に深く入り込むことはあまりありません。

http://d.hatena.ne.jp/int128/20090129/1233240746

昨日のエントリで上のように書いたものの、これではプロダクトを売っているように読めてしまいますね。私のところではプロダクト単体を売るのではなく、SIを行うことを前提にパッケージを売っています。基本的にはお客様の要件を実現することを優先します。

パッケージがお客様の要件を満たせない場合は、基本的には仕様の標準化を行ってパッケージに取り込みます。その仕様があまりにも特殊な場合はSI案件で個別にカスタマイズをします。

そんな事情から、パッケージのリリーススケジュールは常にSI案件に振り回されます。うちの機能を取り込んだバージョンを試験が始まるまでに提供してほしい、といった要望は日常茶飯事です。バラバラに走っているSI案件と個別に仕様調整し、それぞれ要望されたスケジュールまでに提供できるよう管理するのが私の役割です。To-BeとAs-Isをすり合わせるお仕事ですね。実装を深く知っていること、仕様のあるべき姿を持っていること、そして業界動向に詳しいことが求められます。難しい。

SI案件の要望をパッケージに反映してより魅力的なプロダクトに仕上げるエコサイクルは、実はオープンソース開発に似ています。作ったら終わりではなく、継続的にソフトウェアを成長させられるため、ソフトウェア開発の本質と合致しているんじゃないかと最近思っています。

ただし、このエコサイクルを成功させるには3つの条件があります。

1つ目は業務が大きく変わらないパッケージであること。お客様ごとに仕様が全然違うのであれば共通化する意味がありません。これで失敗しているケースは多々あります。

2つ目はSI案件とパッケージチームが近くにいること。いつでも口頭で質問できるぐらいの距離でないと意思疎通が図れないので破綻します。

3つ目は専属の開発者がいること。実装を深く知っている上で仕様調整しつつ、過去の事例をもとにトラブル解析をやらなければならないので、極めて属人的な状態になってしまいます。

エコサイクルが上手く回れば結構面白いので、技術者に向いている仕事かもしれませんね。ただ、昨年末から慢性的に負荷の高い状態が続いていて、いつ落ち着くのか見えないところがストレスです。お金があっても簡単に人を増やせないので難しい。