データベース間を柔軟に連結させるモジュールが残ってることが分かり、一気にプロダクトのリリース条件が見えてきた！(物語概要・登場人物の紹介はこちら)
金曜日、昼のオフィス。営業の連中は昼休みが終わって、慌ただしそうに電話に出たり、コピーを取ったりしている。
開発のメンバーは対照的に、眠そうにキーボードをカタカタと打っている。
いつもの光景だ。
「皆さん、ではこの案で行きましょう！」と中野さんがにこやかに言った。
ようやく新規事業のアイディアが固まったのだ。
自然と、僕は拍手をしていた。
そして皆で拍手をした。
これで終わったわけではない、すべては始まったばかりだ。
具体的に問題点を整理し、スケジュールなどを詰めていく。
その後、最終的に役員の意思決定会議にかけられる。
「お疲れ」と僕は自然と本宮に手を差し出していた。
本宮は少し驚いたような、少し恥ずかしそうな感じで手を差し出して、握手をした。中野さんも握手を求めてきた。
前田は……PCだ。何か切ない。
僕は前田のPCのそばに寄り、手を差し出した。5秒間じっとそのまま。
何か虚しい。
「本宮さん、君のお陰だよ」と僕は言った。
「あの夜、君が……」
「べ、べつに……私はただ……」
中野さんがにやにやしている。
ああたぶんこういうシチュエーションが好きなんだろうな、と思った。
システム開発現場よりも企画寄りの考え方ですが、「アセット化」というものがあります。
アセットとは資産のことですが、金融用語ではなくこの場合、「システム開発に有効活用できる社内のあらゆる資産」を表します。
この物語では、グループウェアパッケージの「グループ・オン」と、沢田が途中まで作っていたデータベース間を柔軟に連結させる「モジュール（とその概念自体）」が分かり易いアセットと言えます。
以前から浸透している考え方ですが、私の知る中堅以上のSI企業では、ほぼ全ての会社で意識的なアセット化の動きをしています（していました）。
つまり、今後の開発プロジェクトや、保守・運用時のことを考慮して、様々なプログラムやノウハウの類いを積極的に蓄積していっているのです。
これができている企業と、できていない企業ではかなり大きな差が出るものだと感じます。
特に受注前の提案企画においては、クライアントに印象付ける提案の具体性や実現性といったものの説得力が違います。
しかもその提案はアセットがない競合他社よりも短期間で、しかも担当者が変わってもある程度対応できるのです。
目の前のプロジェクトのことだけに全力で取り組むこともとても重要ですが、頭の片隅に今後のことや、担当を引き継ぐことになる可能性などについても
置いておき、できる範囲でのアセット化を進めてみてはいかがでしょうか。
僕の経験ですが、何度も過去の自分に「ありがとう。助かったよ！」と
お礼を言ってしまうようなアセットに助けられています（笑）。
この記事に関するコメント