私のターニングポイント
システム更改における「現行踏襲」のくびき
富士通 吉田治郎
今月から始まる、新シリーズの先鋒を務めさせていただきます。今回の私のテーマは「私の失敗談」です。ビジネスや人生に失敗はつきものですが、その経験から得られる教訓や、対策、苦い思い出などをお楽しみいただければ幸いです。開き直り、無理をせず、気張らずに書いてまいりますので、どうぞよろしくお願いします。内容は、すべて事実に基づくものですが、一部、脚色、変更しております。
要件が「現行踏襲」になっていた
簡単に自己紹介させていただきます。富士通（株）営業の吉田と申します。８０年代富士通に入社。当初から通信装置の営業として実に１５年以上、通信装置の販売一筋業でした。しかし２０００年に初めての転勤で大阪に赴任、以降、特定のお客さまを担当する営業として、顧客の求める、通信装置、情報機器の販売や、システム開発も担当しております。転勤はその後も続き川崎、大阪、四国、東京と異動し、今日に至っております。
今回の私のテーマは、失敗談「現行踏襲」です。システムインテグレーションではありふれた失敗だと思います。構築から数年を経て、機器の保守切れなどによりシステムの再構築が必要となりますが、その再構築の仕様条件として書かれる「現行踏襲」の一言。課題への対策は仕様再調整、開発要員などリソースの投下ではありますが、富士通独自の取り組みも記載いたします。
２度目の大阪勤務の時、２０１０年少し前のことになりますが、ある企業グループの警備会社様のシステム開発が対象です。お客さまのお仕事は機械警備が中心でした。
皆様は機械警備ってご存知でしょうか？ wiki曰く、「警備員・守衛や用務員を置かず、代わりに警備対象施設にセンサーを設置して建造物侵入や火災等の異常を機械で察知し、その発報を遠隔地で受信し、警備員が現場へ急行し初期対応をとる形態の警備業務」とのことです。
身近な例ではホームセキュリティでしょうか、侵入者や火災などをセンサーにより感知して、駆けつける。でも、ここでのメインの警備対象は現金自動預け払い機（ATM）でした。商業施設や、オフィスビルにあるタイプで、時間になると無人でシャッターを開閉し、定期巡回はもとより、現金の補充・回収を機械内のセンサーの通知を受け、駆けつけるものです。非常にクリティカルな案件です。当時もシャッターの開閉時間がズレ大変お叱りを頂きました。
システム開発ではこのATMの稼働履歴や、現金充当回収や、障害時の駆けつけなどを指令所に通信、中継、連携するハードウェアとシステムの更改案件でした。更改の引き金はハードウェア、OSの保守切れであり、顧客は「現行踏襲」を要件とされた次第です。
抜本的対策が必要なシステム
システム開発を経験されたことがある方であれば、もうご想像の通り、失敗プロジェクトの定番です。構築から１０年を経たシステムの更改。
・現行システムの仕様書不備（機能更改や、機能追加の未反映）
・現行業務の有識者が「いない」または少数
・現行踏襲の要件で未規定、曖昧な仕様も全て包含して発注
踏襲する旧システムも富士通が作っていました。そのため予想されるリスク回避に向けて旧システムを開発した富士通のグループ会社を中心に体制を構築しましたが、結果は 改修につぐ改修、納期遅延、品質問題と非常に厳しいものでした。中でも記憶が鮮明なのが
試験項目の不足です。機能は開発できてもその機能の目的の認知不足から、試験項目が網羅
できず、何度もお叱りと、試験項目の山積みとなった事です。
今でこそハードやOSなどの変化をアプリケーションから隠蔽し、システム改修を最小化する技術などもありますが、当時は手作り、日々お客様に叱咤される状況でした。
現場では要員増強を逐次実施しておりましたが、追いつかず、また旧システムのハード保守切れが迫るなか、スケジュールの目途が立たない状況でした。
営業として社内報告のエスカレーションを加速し、次の対策を取りました。
・プロジェクトマネージャ補佐の着任
（エースの投入、ただし現体制の維持など諸般の事情を考慮しプロマネ補佐とし投入）
・社内プロジェクト監査部門によるマネジメント強化
・人と設備の追加稟議起案と大規模かつ最終投入（逐次投入ではムリでした）
そうなのです。お金と人材をかけた抜本的な対策しか打ち手がなかったのです。今更ながらお客さまに何度も頭を下げて、仕様検討への新メンバー参加をお願いし、仕様承認プロセスを整理、合意しました。これ以上の赤字拡大を防ぐために思い切った人と設備の投下を行いました。いわば延焼が拡大しないために投資を行い、死守すべき範囲を自ら作った次第です。
解決にいたったのは8年後
前述の対策で一応の開発クローズ、無事サービス開始が出来ましたが、根本問題である「現行踏襲」問題の解決に至ったのは、更に８年を経て、次のシステム再更改時になります。既に自身は転勤で係ってはおりませんが、この当時の山を乗り越え、課題を認識できていたからこそのの成果だと思っています。
解決は富士通の「フィールド・イノベータ」の参加によるものでした。フィールド・イノベータの詳細はURLを記載しておきますが、私なりにその組織の機能を簡単にご紹介すると、次のようになります。
・経営トップの課題、戦略の認識共有
・現場・事実の可視化（コンサルではない）
・システムを錆びさせない（使われない、陳腐化しないシステムの開発、維持）
本メンバー参加により次の更改時には「現行」とは何か、必要な機能・目的の見える化、更に将来を見据えてシステム提案までできたものです。
１０年前のこととは言え、書いていると隔世の感があります。今は、クラウド、SOE、アジャイル開発、デザイン思考と新たなアプローチ、手法も広がっています。先日お話しをお伺いした別のお客さまの開発案件では、仕様変更、仕様追加が大歓迎だそうです。変更や追加が出るのは、それだけ使われ、期待がある証拠だそうでうす。
今回こんなに古い失敗談で何か有益なことをお伝えできるとも思えませんが、あえて言えば躊躇せず、根本問題に飛び込んでいかなければ活路はないのかもしれません。なかなか出来ないのですが。
*ご参考
富士通の「フィールド・イノベータ」
https://www.fujitsu.com/jp/about/businesspolicy/fieldinnovation/about/
■Wi-Biz通信（メールマガジン）の登録はこちら