大手自動車関連会社のテレマティクスサービスを支える全てのサーバーサイドアプリケーションが利用する開発運用フレームワーク。 当然、多くの大手総合ITベンダーも利用します。 この開発運用フレームワークを資本金も非常に少ない零細SIerのマネージャとして受注、開発し、計画的運用の終了まで数年もの間、利用推進を含む展開はもちろん保守まで数年間にわたって携わりました。 またこの活動により、自らのチーム内に先進的なチームを生み出すことになりました。
本フレームワーク開発は技術系開発担当会社として要件策定に参加したことをきっかけに始まります。
当時、顧客の保有している大規模開発運用フレームワークは、実際にはフレームワークと呼べるものではなく単純なメソッド群となっていた上、コピペ開発の繰り返しにより類似機能が大量に存在し、内部のメソッドを呼び合うことも相まって管理が行き届かないバグの温床となっていました。 また、現場の多くの人のフレームワークの意識もフレームワークとしては乏しいものでした。
このため、今後数年間の開発を支える開発運用フレームワークはどんなフレームワークであるべきか？その意見を出すために要件策定に参加を求められたのです。
要件の策定が始まると一般的なフレームワークとして必要な考え方だけでなく、利用するだけで24/7(24/365)運用への適合、現在想定できない将来の案件にも対応できる柔軟性、さらに今後のクラウドプラットフォームへの移植までもが要望として盛り込まれることになります。
これらを一つ一つ丁寧に想定して、お客様とコミュニケーションを重ね、要件の骨子を作成していきました。 実は当然要件が固まったタイミングで自分たちはこの案件には関われない想定だったため、かなり理想に近い内容を要件を取り込みました。
要件の骨子がまとまり出した頃、まだ我々は見積もりをすることまで想定していませんでした。開発ベンダーの多くは我々より大きくて体力のある大手総合ITベンダーばかり、その中でも受注するベンダーは概ね予想できたからです。
要件を作成した我々にも見積もりの依頼が来ることになります。 当然、大手総合ITベンダーと相見積もりとなりますが、企業規模も単価も異なる我々が受注できるはずもない、ただの咬ませ犬として提出することになると考えましたが一度乗りかかった船。丁寧に見積もりを作成し提出および説明したことを覚えています。
既定路線として受注すると考えていた大手総合ITベンダーの様々な要因が重なり、我々の提案が採用・受注が決まったのです。
ここからは想像を超えた苦難がまっていました。 とにかく利害関係者が多く、先進性を望む顧客やステークホルダーおよび利用者がいる反面で変化を嫌うステークホルダーや利用者がいた事、零細企業が大手の多ベンダー開発の中核を担う事などによる周囲の不安の払拭のために説明を求められる状況が続きます。 それら一つ一つ粘り強くメリットの説明および承認を得ながら、要件策定から一貫したポリシーを持って開発を行いなんとかリリースすることができました。
テレマティクスサービスを支える全てのサーバーサイドアプリケーションが利用する特性上、多くのベンダーが適切に24/7(24/365)運用できるようにアプリケーションを作成する必要があります。 フレームワークをただ作るだけでなく、適切に展開し利用の促進を図るとともに、関係者の理解度向上も含めて行うことが必要になりました。 利用に必要なことが丁寧に記載された要件策定者や概念設計者向けのマニュアル・実装者向けのマニュアルの作成を行うとともに、定期的な説明会の実施などを継続的に進めます。 新規のフレームワークの採用に難色を示すベンダー様にもメリットを説明し、時としてベンダー様のオフィスで直接開発者に説明会を実施させていただき、現場の開発者に利用したいと伝えていただくなど、ボトムアップも含めた協力も得ることで、なんとか全数利用を軌道に載せることができました。
クラウドプラットフォーム黎明期にクラウド対応した開発運用フレームワークだったため、頻繁なバージョンアップが必要になるとともに、サービスの新機能開発に伴い常にアップデートを迫られます。 また、大規模なフレームワークがゆえにバグが見つかることもあり、また要件策定時に想定していなかったパフォーマンス・安定性の問題や想定していない利用方法の抜け穴に対する迅速な対応が必要になります。 零細企業で人員も少ない状態かつ他の開発案件もある中で、いつでもチームが稼働できるような状態を維持し、大きな改修案件も含めて常に安定したサービス提供できるように保守をすることもとても難しいことでした。