話題になったデジタルメディア「街角のクリエイティブ」に掲載されている
「広告用語で『鶴の恩返し』を読んでみた」。

さまざまなバージョンで提供されている「○○を童話で読んでみた」シリーズですが、私たちも、システム開発・BI用語でやってみたら面白いと思い、実際に「桃太郎」で読んでみました。

システム開発・BI用語で「桃太郎」

むかしむかし、BIシステム導入に数億円をかけていたぐらいのむかし、あるところに、かつてはシステム開発で単価300万を稼ぎ出していたコンサルタントで今は営業となったおじいさんと、保守プロジェクトを長らく担当しているおばあさんが会社におったそうな。

おじいさんは各ベンダーの営業担当周りに、おばあさんはお客様のプロジェクト（PJ）ルームへと出かけて行きました。

おばあさんが朝一番のメールを見て、昨晩のレポート更新ジョブが無事に完了したことを確認し、「ホッ」としたつかの間、ついにきた、ついにきたと、ERPシステム置き換えに伴うBIシステム全面刷新のRFPが訪問先のお客様から渡されました。

「これは大規模PJになるわ」

おばあさんはRFPの紙を手にとり、家に持ち帰りました。

おじいさんとおばあさんがRFPの回答を作っていると、なんと同じPJにいる新人社員がRFPの回答案を書いてメールで送ってきたではないですか。

今まで良い新人に恵まれなかったおじいさんとおばあさんは大喜びです。

「これはきっと、伸びる社員だ」

この新人社員を、おじいさんとおばあさんは「RFP太郎」とニックネームをつけ、大切に育てあげました。RFP太郎は、BIシステム開発のPJをいくつも経験して、やがて超デキるBIコンサルタントになったそうな。

そんなある日、RFP太郎が言いました。

「私、炎上し続けている鬼ヶ島社向けBI開発PJへ行って、PJを終わらせてきます」

おばあさんにきびだんごのマークのはいったビジネスパートナー（BP）への発注書をいくつか作ってもらい、鬼ヶ島PJへ向かいました。
その途中、Dog社の営業からメールが来ました。

「RFP太郎さん、次はどの案件に行くのですか？」

「今話題の、O社向けBI開発PJの件です。全体的に人が足りてないみたいでとりあえず画面周り部分で入りつつエンドユーザーに気に入られてPMやろうかと」

「あのPJですか・・。結構いろいろな話を聞きますよね。
ETLツールが得意の開発メンバーいるのですが、どうですか？1名お出します。私たちはプライムとして入りたいのですが、直接の口座が無いので無理なんです。」

次に、今度はMonkey社の営業がたまたま訪問してきました。

「RFP太郎さん、次はどの案件に行くのですか？」

「例のPJへ、炎上案件を終わらせに行こうかと」

「すごいですね！それでは、DB設計ができる開発メンバーとかいらないですか？ちょうど別案件が終わったところで、優秀なメンバーが1名いるので出しますよ。すぐ経歴送りますね」

時を同じくして、Bird社の営業からも電話が来ました。

「RFP太郎さん、何やら聞きましたよ、次の案件。例のO社案件、行くそうじゃないですか」

「あら、もう有名ですか？そうなんです」

「それでは、ジョブ管理ツールができる開発メンバーが必要でしょう。1名お出しますよ」

こうして、ETLツール、DB、ジョブ管理ツールの設計ができるBPを手に入れたRFP太郎は、各々に基本契約書ときびだんごマークの入った発注書を送り契約、ついに鬼ヶ島PJへとやってきました。

鬼ヶ島PJでは、複数ベンダーで構成されたメンバーが、主たるPMがいない中、要件定義書、設計書と議事録を並べて、お互いに会話もせず昼も夜もないシステム開発の作業を黙々と進めています。このPJこそ、まさに不夜城であり、メンバーは鬼の形相です。

RFP太郎は、

「みんな、Subversionで最新版を落としてから内容を確認するように。それ、かかれ！」

Dog社のETLツール担当、Monkey社のDB担当、Bird社のジョブ管理ツール担当はみんな、八面六臂の大活躍です。議事録の内容と比較して反映されていないデータ加工処理を見つけ出し、設計書のExcelから自動的にテーブルを作成するDDLを実行するマクロを作成し、夜間ジョブの実行可能時間にBI側の処理をしている時間が無いことを見つけ出します。

RFP太郎はというと、お客様と再度要件の打ち合わせをするべきだと訴え、タスクに大ナタを振りました。

「それなら君がPMをやってくれ！」

このことで、仮置き的に置いていたPMは手を引きました。

これをきっかけに、RFP太郎とメンバーは、ウォーターフォール型の開発からアジャイル型の開発に手法を変えて、要件凍結を挟み、要件の解釈・認識のずれによる後戻りを防ぎながら、炎上したPJを終えました。

おじいさんとおばあさんは、RFP太郎がBPをうまく活用してPJをこなすことができるようになる姿を見て、その成長ぶりに大喜びです。

そしておじいさんとおばあさんとRFP太郎の3人は、このことをきっかけに、多くの案件を成功させていきました、とさ。

めでたしめでしたし。
おしまい。

用語集

BI：Business Intelligenceの略。システムやデータベースのことを知らない人でもデータを取得し問題点の発見や業務判断、改善ができるようにする仕組み

ベンダー：ツールやシステムの開発を行う会社のこと。

RFP：Request For Proposalの略。作ってほしいシステムの詳細な説明が記載されている資料で、これを各ベンダーに送り、そのシステムを作りたいベンダーが回答を送り返す、という流れとなる。
ERP：Enterprise Resource Planningの略。受注や購買、生産、販売、在庫、人事、会計など、会社が業務を行うにあたり必要なデータを管理するシステムのこと。一般的に業務システムといわれる。

PJ：Projectの略。一般的にBIシステムの開発も何人かのメンバーが集まり開発することが多い。

ETL：Extract Transform Loadの頭文字。データを抽出し、加工し、格納するツール・システムのこと。一般的に取得したいデータはそのまま分析できる形になっていないことが多く、データを加工するETLツールは必須ツールとなる。

DB：Data Baseの略。データベース。基本的にはデータをテーブルと呼ばれる表に格納する。表がたくさん集まった一つのまとまりがデータベース、で差し支えなし。

BP：Business Partnerの略。自社のメンバーだけではどうしてもシステムを開発するに人が足りない、技術が足りないことがあり、その場にご協力いただく他社様のこと。

ウォーターフォール型開発：要件定義、設計、開発、テストを順番に行っていく開発手法。従来の手法で、大規模システム開発にはとてもマッチするが、最近の低予算かつ短期間、要件が定まりきらないシステム開発には向かない。

アジャイル型開発：要件定義、設計、開発を短期間で何度も繰り返して高めていく手法。100%のものを最初から出そうとするのではなく、20%ほどの時間で70%程度の未完成でもお客様とイメージを合わせながら進めていく手法。お客様が欲しいものに近づいていけるのでとても効率的な手法だが、きちんと要件を凍結しないと要件が膨らんで大変なことになる。うまくコントロールする技術が必要。

要件：お客様が実現したいシステムの機能やシステム全体像のこと。それを決めるのが要件定義、というフェーズ。なお、BIではどういうグラフをどう配置して、などの画面周りを決める必要があり、お客様も要件を定めるのがとても難しく一度決めても後で変更が付きまとう。その結果、アジャイル型開発はBIには良く似合う。