FileMakerの圧倒的な開発効率で難局を乗り切る。
要求仕様の漏れを運用テストで発見。プロジェクトは修羅場に・・・
「すいません。○○のデータはどの画面から入力するのでしょうか？どこにも入力するところがないし、テストシナリオにも載っていないんですけど・・・」
運用テストを担当していたエンドユーザ部門から、問い合わせがあったのは運用テスト終了間近で、ロールアウトプランの詳細をレビューしていたことでした。
１５ヶ月の開発期間を経て、ようやく運用テストまでたどり着いたプロジェクト。
システムテスト中に実施したユーザレビューでいくつかの手戻りがあり、当初の予定よりも３ヶ月ほどの進捗遅延が発生したが、ようやくゴールテープが見えてきた矢先のことでした。
私はその問い合わせを貰ったときに、目の前が真っ暗になり、自分の顔から血の気が引いていくのを感じました。
それは、直感的に要件定義漏れを察知したからです。
運用テストフェーズまできての要件定義漏れが、プロジェクト全体にどれだけ壊滅的なインパクトを与えるかは、大規模システムを経験した技術者であれば良くご理解いただけると思います。
あれだけの時間をかけて業務分析を行い、全ての業務フローをドキュメント化して業務要求・システム化要求をまとめたのになぜこのタイミングになって・・・
その機能を追加開発するには、恐らく２ヶ月程度の開発期間と数百万の追加予算が必要なことは容易に察知することができました。
数ヶ月の遅延と数百万円の追加予算申請は、「失敗プロジェクト」の烙印を押されるのに十分過ぎる条件です。
既に同時進行で掛け持ちしていたプロジェクトでも大きな失敗を経験していた私としては、「こちらのプロジェクトも失敗させたら、もうこの会社にいることはできない。絶対にこのプロジェクトは成功させなければ・・・」
そういう思いで望んでいたプロジェクトだったので、この要件定義漏れの事実を察知したときには、常に引出しにしまっていた「退職届」に日付を入れる日が来たか・・・
そんなことが頭をよぎりました。
追加予算は獲得できず。プロジェクトは八方塞がりの状態に・・・
とにもかくにも、要件定義漏れという事実が発覚した今、早急にそのもれた部分の要件定義書を作成と実装プランを策定、そしてベンダーより見積もりを取得し、追加予算を獲得をできるだけ早く行う必要がありました。
まず、ユーザ部門には要件定義の漏れであることを説明し、一部の運用テストを一時凍結すると同時に、要件定義作業に協力していただく約束を取り付けました。
ユーザ部門の協力もあり、要件定義が漏れていた部分のシステム化要求は思いのほか早く定義することができ、次の山である開発ベンダーのと具体的な実装方法に関する折衝に入りました。
私としては何とか最小の予算と工数で追加機能を実装できるようにしたい。
しかし、開発ベンダーからは自分が予想していた以上の工数と見積もり額を提示されてしまいました。
このままでは本当にプロジェクトが暗礁に乗り上げてしまうかもしれない。
その時は、もう自分はこの会社には居れない・・・
開発ベンダーとは、先方のプロジェクトマネージャ、営業担当者、ひいてはその上の上司まで引っ張り出して、喧々諤々の折衝をしました。
そしてようやく自分としては納得できる内容と金額の追加機能の見積もりを取得。
何とか２つ目の山を超えました。
そして３つ目の山は追加予算の稟議決裁という最大の難局を迎えます。
当たり前ではありますが、既に他のプロジェクトで相当額の追加予算を獲得してプロジェクトを進めたにもかかわらず、十分な機能を開発することができなかった失敗プロジェクトを抱えていたので、当然私が起案する稟議を合議する目は厳しくなっていました。
合議者の各方面に散々の苦言をいただき、最終的に追加予算を獲得することはできませんでした。
この機能がなかったら、このシステムの導入の目的であるいくつかの問題が解決できない・・・
３つ目の山まで来たところで、私はどうしようもなく大きな壁にぶち当たってしまいました。
不足機能をFileMakerで自作。難局を乗り切る。
そんな「修羅場」を迎えていたとき、私はプライベートの時間を使って勉強をしていたFileMakerの秘めた可能性に少しずつ気づき始めていたころでした。
自主学習は、書籍を中心にFileMakerソリューションの開発の基礎を習得した後、自分が過去にFileMaker以外の開発プラットフォームで開発してきたアプリケーションをサンプルとしていくつか開発するという方法を取っていました。
そのサンプルアプリケーションを開発しながら、FileMakerが持つ開発効率の高さ、RADツールとしての能力を、ちょうど肌身で感じ始めていたのです。
「予算が獲得できないなら、自分で作るしかない。開発プラットフォームはFileMakerだ。しかし、まだ自主学習のレベルを脱していない自分に商用利用のアプリケーションが開発できるだろうか・・・」
そんなことが頭をよぎりました。
しかし、その時に私には他に選択肢がありません。
追加予算を獲得できない今、残された道は自分で不足機能を補うアプリケーションを開発するしかなかったのです。
開発ベンダーには、FileMakerソリューションとのインタフェースファイルを定期的に出力してもらう機能のみを追加開発してもらい、それ以降の機能については全てFileMakerを使って自作することにしました。
幸いにしてその機能を使う部門のマシンには、別の案件で購入したFileMakerProがインストールされており、既に導入されていたFileMakerServerもリソース的に余裕がある状態でした。
「これはもしかしたら神からの贈り物かもしれないな・・・」
そんなことを思いながら、再度必要予算を算出し、当初の予算の１０分の１以下の金額
で２度目の稟議申請をしました。
「なぜはじめから・・・」といった声も聞かれましたが、創意工夫と何よりもその責任感を認めていただいた為か、追加予算は決裁され、３つ目の山を何とか越えることができました。
そして４つ目の山となるはじめてのFileMakerソリューション開発。
私はできるだけ「この不安」を早く打ち消したかったので、相当の睡眠時間を削って、ひたすら開発に没頭しました。
そのころはまだTO/TOGやアンカー・ブイといったFileMaker認定デベロッパーであれば当たり前の知識でさえ持ち合わしていませんでした。
しかも、FileMakerの関数名や関数の引数がまだ「自分の手に付いていない」時期でしたので、何回も何回もヘルプを参照してはデバッグして動作検証をするという新人プログラマのような開発作業でした。
さらにはアプリを作成した絶対的な経験値も皆無に等しいので、メンテナンス製のよいリレーションシップグラフの設計などもまったくもって稚拙なものでした。
しかし、結果的には２週間の開発と、エンドユーザに協力を仰いだ３日のブラックボックステストを経て、初めての商用アプリケーションを完成させることができました。
リリースから数年が経過した今でも使われているアプリケーション
このFileMakerで開発したサブシステム。
開発ベンダーの見積もりではどう急いでも２人月は必要といわれていた機能でした。
それを異なるプラットフォームとはいえ４分の１の２週間で開発。
しかも、操作性やビジュアルについてもある程度「凝ったもの」を作ることができたため、エンドユーザからの評価も上々でした。
そして、このアプリケーションは、リリースから数年が経過した現在でも問題なく動いています。
当初は次年度にやはりしっかりと予算を獲得して開発ベンダーに同じ機能のサブシステムを開発してもらうつもりでした。
しかし、システムそのものに深刻な問題が発生しておらず、エンドユーザからもそういった声は上がらないことから、結局そのまま使い続けていただいております。
実はつい先日、FileMaker認定デベロッパーに合格した後に、このアプリケーションへの改修案件をいただきました。
この改修を機に、非常に稚拙なつくりであったいくつかの部分を無償で再設計させていただき、より長く使っていただけるように改修してバージョンアップ版をリリースさせていただきました。
私はこの経験を通して、今後自分が業務アプリケーションを開発する際にはFileMakerを絶対的な軸にしようと強く思いました。
その理由は言うまでも無くこのプロジェクトにおける3つの強烈な経験と気付きを得たからです。
そのひとつが、圧倒的な開発効率の高さ。
そして２つめが、圧倒的なコストパフォーマンスの高さ。
そして最後に、技術者がソリューション開発を楽しめる開発環境であるという理由からです。
