というわけでA社の営業支援システムのはじまりはじまり。
まずこれまでの資料を見ておいてくれと言われた。まだ予算がつかないのか、やることがないのか、そんなところだろう。資料に目を通してみると一番重要なのはコンサルティングフェーズの議事録だった。お客さんの業務をどのように効率化するかをゼロから考える通称コンサルと呼ばれるコンサルティング担当の会社が、お客さんとのヒアリング（聞き込み）で大体どういう風に業務改善したら良いかをレポートにまとめて提出していたので、そこから何をシステム化するか選び出していく途中だった。このレポートが早く手に入っていれば良かったのだが、このレポートはあとになってひょっこり出てきたので当時は見ることが出来なかった。議事録だけ読んで理解しろというのは結構無理な注文だと思う。
私がプロジェクトに入ったとき、私もいれてメンバーは三人しかいなかった。一人はそこの部署の若い部長さんで、前髪が若干ハゲ上がっているところを含めて若い頃の志村けんに似ているので、覚えやすいよう志村部長と称することにする。この部長は三十代後半で部長になったという頭のキレるとされた人だが、一方で夜中になるとキャラがガラリと変わって風俗の話ばかりするらしい。私と仲の良い同僚でこの人の下にいる人がいるのだが、彼は家が新宿に近いからという理由で夜中に何度も志村部長から電話で呼び出されて飲みに行っていたらしい。
もう一人のメンバーは私より少し年下の男で、後日最強のネタキャラとして広く名を轟かせることになる。彼は体格のいい中型犬のような外見をしているので、ワンダーと掛けてワン田君と呼ぶことにする。彼の特徴は、話していて一見普通っぽいことを言っているようなのだが、だんだん違和感が出てきて、よくよく話を整理してみると一体何が言いたいのかよく分からないという点にあった。中立な言い方をすれば、人と考え方の道筋が違う人であり、一言で言えば変人なのだった。真に不幸かつ笑えるのは、彼は自分が変人だということを意地でも認めないところで、こういうのを指してこっけいという言葉があるのだと思う。
志村部長は今回のプロジェクトに一人どっぷり浸ると同時に、管理職として他の案件の営業的なことや管理もやっており、私とワン田君にプロジェクトについて説明している時間がないとのことで、二人は資料を読んでまとめながらプロジェクトについて語り合う日々が続いた。ワン田君によると今回のプロジェクトは、うちの会社では珍しくお客さんからの一次受けつまり子受け孫受けではなく直受けつまり直接仕事を請ける立場にあり、お金もたっぷりもらえるそうなのだった。プロジェクトの規模も最終的には百人ぐらいになると言い、中核メンバーたる我々は下請け会社の社員を沢山使って仕事をするのだと言っていた。それを私は話半分に聞きながらへえとかふうんとか言っているうちに私たちは仲良くなった。彼は電車の中でも普通の声で客の会社の実名を上げて会話しはじめる。自分がこのプロジェクトに関われることがよほど誇らしかったのだろう。
彼は以前メーカーで仕事をしていたらしく、そのときの話を苦労話として自慢げにしていた。今回のプロジェクトでいわゆるホストつまり汎用機と呼ばれる融通が利かない代わりに速くて信頼性が高い高価なマシンを使うことになっているらしいのだが、彼はホストを扱った経験があるとかで、ホストがいかに金と人の掛かるものなのかということを何度も私に話して聞かせてくれた。ホスト一台動かすのに数十人の人間を用意しておかなければならない、などということを自分のことのように自慢げに話す。会社の近くの寮に住まわされて夜中たびたび呼び出されていたとか、それでも給料が安かったとかの苦労話を色々してくれた。普通の人ならうんざりするかもしれないが、私はそんなに嫌いではなかった。それをこういうところに書くというネタ収集的な目的があるからだろうか。
私たちの席は、フロア内の窓際のPCサーバがいくつも無造作に置かれている横に、そこだけ隔絶されたようにポツンと六つの机が島になっている場所だった。PCサーバはほどなくして新設のマシンルームにすべて移されるのだが、このときは結構いい加減に並べられていた。隔絶された島には机が六つあるのに周りには彼と私しかいないことに多少不安を覚えつつ、今回のプロジェクトは幕をあけたのだった。
やがて来たその人は来た初日からテンションが高かった。彼はお笑い芸人コンビおぎやはぎの矢作にそっくりな外見をしているので矢作さんと呼ぶことにする。彼はトークが上手で話がとても面白かった。キャバクラに行くとトークだけで女性にモテたという話を人から聞いた。この矢作さんがワン田君をいじりまくる。
矢作「おまえ英語得意なんだってな」
ワン田「大学院の頃、研究室にいたフランス人と英語で喧嘩してました」
矢作「ほんとかよ」
ワン田君は突っ込まれていくうちに、喧嘩は筆談も交えてだったとか、徐々に話が小さくなっていき、それさえ疑われているうちに「もういいです」といじけてしまった。白黒はっきりさせようと、なぜかみんなでTOEIC勝負やろうぜという話にまで発展するのだが、結局立ち消えた。
矢作「ワン田君、ボーナスは何に使うの？」
ワン田「いえ特に予定は…」
矢作「じゃあ俺にノートパソコン買ってくれ」
ワン田「なんでですか」
やがてボーナスが出ると、その頃に私たちの島に客先から男女二人組が戻ってきていたのだが、みんなでワン田君を追求したところ、ボーナスで投資信託を買ったことが判明する。二人組の男の方が金融関係に詳しかったのでさらに追求すると、ワン田君がなんと中南米のハイリスク債券を組み込んだ商品を買っていたことが分かる。何を決め手にしてそれを選んだのか、ちゃんと考えて指標を見て決めたのかと、散々馬鹿にされるワン田君であったが、その後は周囲の予想を裏切って利回りが7%を超えたらしい。
ちなみに金融関係に詳しい男の方は、このプロジェクトに参加したくて仕方がなかったようだったが、志村部長に直談判したところアサイン（仕事割り当て）の関係上無理と言われ、そうこうしているうちに会社に来なくなってあとで聞いたら辞めていた。
ワン田君が飲み会の幹事をすると必ず何かが起きる。なべの店をとったのにみんなの期待を裏切ってなべ料理のないコースにしていたり、最後の一本締めで掛け声を「せーのっ」と掛けるし、収支計算報告を見ると2000円×2が2000円になっているなどおかしいところが多くてみんなで問い詰めると領収書を失くしたと言ったりする。テレビ会議用のマイクを買いに行ってなぜかカラオケ用みたいなマイクを買ってくる。身だしなみもヘンなときがあって、妙に着衣が乱れていたり、ネクタイを首に直接巻いてて問いただすと「電車が混んでいて…」と言い出すし、ネクタイ忘れて会社近くのコンビニで買おうとしているところを目撃され急に声を掛けられると購入前のネクタイを懐にしまおうとしたりしたらしい。
ワン田君に対する矢作さんの突っ込みがまた冴えていて、珍しくワン田君の携帯が鳴り出して慌てて喫煙所に小走りで向かうところを「地球防衛軍からだ」と付け加える。仕事を振るとき、風邪で一時期非常に特徴的なマスクをつけていたので「その件はうちのキャシャーンにやらせますので」「ほら、キャシャーンきちんと対応しろよ」。ワン田君はいっぱいいっぱいになってくると人の話が聞こえなくなるのだが、それを「あの人が出てきてるから聞いてねえな」「あ、ほらまたあの人が出てきてる！」とからかう。しまいには「僕の優秀な部下が速攻行きます」と揶揄する。
プロジェクトとは一つの目標に向かって限られた時間で行うことだ。そのためには、お客様と一緒に到達点を決めなければならない。私たちはシステム屋なので、どういう感じのシステムをどこまで作り上げるのか、そしてそのシステムに付随して設計書などをどんな形でどの程度作らなければならないのかを決める。延々時間を掛けてもいられないので、それらを作るためにどの程度の時間が掛かるのかを見積もってお客様に提示し、それを元にスケジュールの作成をする。それが終わると、誰が何をやるのかを決める。こうして段取りを決めていくことを一般にプロジェクト・マネージメントと呼ぶ。
矢作さんは北大の農学部出身という変わった学歴を持ちながらも、こういう段取りを決めてプロジェクトを推し進める能力のある人だった。プロジェクトを進めるにあたって何をしなければならないのかを挙げてくれと、彼は私とワン田君に指示した。私は設計書の雛形を作る必要があることなどを挙げたため、外部設計書の雛形の素案を作ることになった。一方ワン田君はハードウェア面を中心に挙げたため、その後の彼は調達などを中心に動くこととなった。
他の会社はどうか知らないが、私たちの会社は設計書の枠組みとしてそれほどカッチリした形式を持っていなかったので、これまでのプロジェクトの設計書の雛形を寄せ集めることになった。というか実はCMMという考え方の元に事業部でプロジェクトの進め方をまとめた資料があったのだが、そんな資料があることさえあまり知られていないというお寒い事情があった。私は一応知っていたので矢作さんにその資料を見せたのだが、ここの部のやり方と隔たっているのか結局利用されなかった。
志村部長のプリセールス活動によりもう要件定義は終わったという認識でいたため、これから私たちが作らなければならないのは外部設計書と呼ばれる設計書だった。ところが私はこの外部設計書という言葉自体をここで初めて聞いた。私にとって設計書とは、基本設計書と詳細設計書しかなかった。いわゆる設計担当が基本設計書を書き、プログラミングをする人が詳細設計書を書きながらコードを書くという分担があるというぐらいの認識しかなかった。ところがこの部ではどうやら違うらしい。ここでは設計書は、外部設計書と内部設計書に分けられているらしい。外部設計書とは顧客とすり合わせなければならない外側の設計であり、内部設計書とは私たち内部の技術者が分かっていれば良い内側の設計のことなのだ。このように分けることで、顧客に確認を取らなければならない設計書と確認不要な設計書にはっきり分けることが出来る。これがもし違って基本設計書と詳細設計書に分けると、顧客によっては詳細設計書まで確認作業が必要になってきて、余計な時間が掛かってしまう。
問題はそのあとにあった。外部設計書は顧客に見せる設計書なのだから、あまり細かい設計は記述しないようにしたほうが良いはずだろうと考え、私はなるべく大雑把に外部設計書の雛形を作成した。するとそれは違うという。内部で閉じている設計以外はすべて外部設計書に記述しなければならないのだと言われた。これではまるで詳細設計書ではないか、こんな細かいところまで顧客に見せるとなると大変だと食い下がったが、結局これはこういうものなのだということで矢作さんや志村部長らに押し切られてしまった。これはうちの会社だけの考え方ではなくて、主にホスト系のカッチリした設計文化を持つ分野でとられる手法のようで、たまたまその分野を知らなかった私にとっては違和感のある方法だったが、一度でも経験したことのある人にとっては当たり前のことのようだった。だからその後この設計書の雛形が大きな問題となるのだがそれは避けようのないことだった。
この件で押し切られた私は、じゃあそういうことならと、この部の他のプロジェクトの設計書をなるべくほとんどそのままの形で部分部分拝借する形で適当に取りまとめて提示して終わった。正直ちょっとやる気がなくなっていたが、ここの部のやり方を勉強しようというひねくれた気持ちで遂行した。
そろそろ開発用のマシンが必要だということになって、ワン田君がIBMから見積もりを取って具体的に発注を掛ける段取りに入っていった。電話で向こうの担当者と何度もやりとりを交わすワン田君だったが、あるとき電話口だけでは分からないことがあって、ちょっとお待ちくださいと言っていったん受話器を置いて調べ物を始めた。そこへ矢作さんが割り込んでワン田君に質問をした。ワン田君は矢作さんの質問に答えたことで電話のことをすっかり忘れ、そのまま他のことを始めてしまい、ふと気づいたら15分ぐらいIBMの担当者を待たせてしまっていた。気の毒なIBMの担当者は電話を切らずに待っていてくれていた。
ということで私は矢作さんから技術的な検討をする役目をしてくれることを期待していると言われた。ところが志村部長にはそんな意識はあまり無かったようで、とりあえず外部設計をコアメンバーで進める方針が示された。矢作さんは矢作さんで、ここに来る前に参加していた大きなプロジェクトで、技術チームを立ち上げる必要性を感じていたフシがあった。ところがうちの会社は技術系の人間をあまり評価しない土壌があり、私はここの会社に来てからそれが不満であった。だから私としては技術だって重要なんだということを主張するために進んで技術的な役目を引き受けて活躍するよう努力すべきだったのかもしれない。だが私はこの土壌にうんざりしていたので、皮肉を込めてこう言ってしまった。ここの会社では技術的なことをやっても評価されないので出来れば要件定義をやりたいと。私はこの言葉を矢作さんに直接言うのではなく、矢作さんの前でワン田君との会話の中で言ったのだが、いま振り返って考えて見るとこの言葉を矢作さんの前で言ってから矢作さんとの仲がギクシャクしていった気がする。
ちなみにこのときいったん取り掛かった外部設計は、その後まったくの無駄となる。というのは、そもそも外部設計を始めたのは、志村部長がもう要件定義は終わったものと考えていたからなのであるが、実はこのとき終わっていたのは予算の見積もりのための要件定義であり、まだまだこれから本格的に要件定義をしなければならなかったのだ。
その後わたしは一応技術検討をすることになり、まだ余裕のある時間でだらだらと調べ物をして資料にまとめた。この業界の技術の進歩は早く、私が以前使っていたIBMのVisualAgeという開発環境は既になく、後継としてIBMがオープンソースコミュニティに提供したことで有名なEclipseという開発環境の有料強化版があったが、私にはどういうものかよく分からなかった。それに私はJavaの技術にそんなに詳しくなく、とはいっても仕事でTomcatも含めてサーバサイドJavaは人より詳しくはあったが、技術を取捨選択するほどの知識もなかった。具体的に言うとlog4jやらtaglibやらなにやらの周辺技術のうちどれとどれを選択してどういう枠組みでコーディングをしていくのか決めなくてはならないのだが、こういうとき学生の頃なら読んでいた技術誌程度の知識でもあれば良かったものの最近の私はそういうものにあんまり興味がないのでほとんど知識がなかった。だから調査に大分時間を掛けてしまったのだが、定時帰りしつつのんびりやっていたこともあり、これはあくまで私の憶測だがそういったことで私は徐々に矢作さんからの信頼を失っていったのだと思う。
SOAとはその名の通りサービス中心の考え方で、一つのシステムを複数のサービス体系に分けて考え、それらのサービス一つ一つを独立して作りつつ、サービス間の連携を考えてシステムを組み上げていく方式である。この方法のメリットは、古いシステムを一つのサービスユニットとして考えることで、古いシステムに新しいシステム内に組み込みやすいことや、一つ一つのサービスユニットが小さく分けられるため部分部分の設計が容易になることなどが挙げられる。一方で、個々のサービスユニット同士をくっつける段階で互いの思惑が外れて調整が必要だったりと統合にコストが掛かることである。
私たちの会社は、顧客を取り扱う海外製の強力なミドルウェアの代理店をしているため、顧客を扱うサービスユニットだけを担当する予定だった。つまりSOAだとサービスユニットごとに独立しているためそれぞれ別の会社が開発を担当することが出来るというメリットがあるわけだ。サービスユニットというのは大雑把に考えるとクラスライブラリみたいなもので、顧客を扱うための処理の一切合財がカスタマと呼ばれるサービスユニットで提供されることになる。
一方、ビジネスロジックの中心的な部分は、なんと顧客A社のライバル会社であるB社の情報システム子会社がやることになった。なるほど理屈の上から考えると確かに同業他社の情報システム子会社なら、同じ業界の業務に精通していて当たり前だ。形の上でも別会社だし特に問題はないだろうという判断が働いたものと考えられ、その割り切りの良さには感心するが、本当にこれで良いのか気になる。
ほかにも他のミドルウェア関係でもう一社入っており、今回のシステムでは三社が開発に参加することになった。本当はコンサルティングを担当した会社も開発に参加する予定だったが、開発の体制が組めないという理由でなんとうちの会社がその部分も担当することになる。いまから思うと本当に開発体制の問題なのか疑わしく、単に逃げただけじゃないかと思われたが、そんな経緯があって我々が今回のプロジェクトに掛ける意気込みは高まるのであった。
うちの会社が扱っている顧客関係のミドルウェアというのは、シンプルに使おうと思えばいくらでもシンプルに使えるのだが、複雑なシステムに対応させるときはかなり難解になる。このミドルウェアを売るための部隊がまた別のオフィスにいて、あとで結局そこから増援を頼むことになるのだが、まずはこのミドルウェアについて勉強しようということで、会社が用意している段取りを踏んで社内で講座を開いてもらってみんなで受けた。
それから志村部長とみんなでどのように顧客を処理していくかということで頭を絞った。若健さんはこれまでにこのミドルウェアを使ったプロジェクトを成功させていたのだが、今回とは複雑さが違うためか、随分頭をひねっていた。正直私もあまりついていけなかった。今から思うと、仮に私があんまり有能な人間でなかったとしても、普通の人間にも分かる程度の設計に落とせなかったことがこのプロジェクトのつまずきの一つだと思う。ここでもうちょっと詳しく説明したいところだが、説明してしまうとどういうミドルウェアか分かってしまい、会社が特定されてしまうのでやめておく。
若健さんはバドミントンを趣味とする体育会系の人で、あっさりした性格が好感触だった。年も私と近く、多少の会話もしたが、私から見るに彼は女好きで、会社でも主に女性とよく話をする人だった。後日席替えが行われたときに私は彼の隣になり、私たちの対面にはマタンゴさんとその後輩の女性が配置されるのだが、彼はよく彼女らと雑談をしていて、私もよくそれに混じった。だがついに、私と彼との間でプライベートなことを話す仲にはならなかった。大したことのないことなのかもしれないが、私はこれをコミュニケーション上の問題だと考え、世間話的に冗談っぽく志村部長にこのことを話したのだが、志村部長は私が陰口を言っているぐらいにしか取れなかったようだった。後日これが実は彼に降りかかった大きな問題となった可能性については後述する。
マタンゴさんは当初は別の案件に投入されるはずだったのだが、ユーザインタフェースつまり画面系に強いからという理由でこのプロジェクトに引っ張ってこられた。というのも、これは私の勘ぐりすぎかもしれないが、私があまりにひどいHTMLを書いたのも理由の一つではないかと邪推する。という冗談は置いておいて、かなり前の見積もり段階でお客様からユーザインタフェースに倍ぐらい時間が掛かることを覚悟してくれと言われていたのだ。私はそれを聞き、じゃあなるべく早く着手しておいたほうがいい、と矢作さんに形ばかりのHTMLをサクッと書いてこれを顧客に持っていったらどうかと渡した。自分で言うのもなんだがかなり手を抜いた代物で、しかし細かいレイアウトとかよりまず機能から入るべきだと思っていたし、あとで慌てるよりも早いうちに問題意識ぐらい持っておいたほうが良いという意図があった。運が良ければ顧客のほうからユーザインタフェースの素案を出してくれるきっかけぐらいにはなるだろうと思ったのだ。マタンゴさんは女性なせいなのか設計書の書き方もすっきりしており、画面を表す図形が妙にポップだったりと見やすかった。
設計書の書き方にはセンスというものがある。データの流れを中心にした図だとか、処理の流れを中心にした図だとか色々あるのだが、システムの要点をはっきりと俯瞰できるような資料にするためには、それらをうまく組み合わせたり、少し論理的整合性を崩さなければならなかったりする。それをやるために必要なのがセンスである。
同時期に、速水もこみちの顔をくしゃっとさせたような長身の男が入ってきたので、彼のことをちょっと崩してモコメチ君と呼ぶことにする。この人はプロジェクトが忙しくなっても毎週水曜は必ず定時帰りしてクラブで踊っているという噂なのだが、無口であまり喋らないのでそれほど会話しなかった。彼はそのためもあって技術系の人間であるとされ、HTMLを起こす作業が私からマタンゴさんに移る前にいっとき彼がやっていた。彼は客先でもほとんど喋らないらしく、マタンゴさんのほうが後輩なのにも関わらず彼はマタンゴさんから怒られていた。
まずアクタチームというのは、システムを実際に操作する人間をシステム上で管理するサービスユニットを担当する。営業支援システムなので主に営業マンが使うわけだが、営業マンにも分類や階層が存在する。分類によって権限に細かい違いがあったり、上下関係により操作を代行できたりするという要件を、うまくシステム化する必要があるからだ。このチームのリーダーとして、元は技術商社でバリバリ仕事をしていたというおっさんが入った。この人はやたらと過去の自分の仕事ぶりを自慢するので、見栄春さんと呼ぶことにする。
この人の話はとても大きくて、以前手がけたプロジェクトで百人が俺に反対したけど押し切って結局俺が正しいことが証明されただとか、街で見かけるこの端末は俺たちがやったんだとか、聞きもしないのに色々な武勇伝を延々と語った。しかも新しいメンバーが入ってくるたびに同じ話をするのでそのたびに私は苦笑した。と揶揄してしまったが、話の内容はそれなりに面白かったし、話半分に聞いてもそれなりのキャリアのある人なのだということは分かった。
私は当初カスタマチームにいたのだが、アクタに近いところを担当するようになったため、アクタチームの見栄春さんとたびたび言葉を交わすようになった。今回のSOAつまりサービス・オリエンテッド・アーキテクチャというやり方は、サービスユニット間の細かい連携が鍵となる。そうでなくてもそもそもプロジェクトを遂行するにはコミュニケーションが大切だ。見栄春さんは自分で考えた仕様を携えてたびたび私の席に来て説明していった。正直あんまり私に関係ないことを話されてもしょうがないのにと思ったりしたが、こういうことをやるのはとても大事なことだとのちに気づく。
プロジェクトが進むと見栄春さんの下に新人さんとメーカーから転職してきた中途の人が加わる。二人とも経験が足りていないということで、見栄春さんが色々教えてあげていたらしいのだが、その様子を逐一私に話してきた。これこれこういうことをさせることでこういう力がつくだとか、例によって聞かれもしないのに喋るので、私もまあそれなりに興味がないこともなかったが、適当に相槌を打ちながら聞いていた。
それからほどなくして、書類などのやり取りを物理面から管理するロジと、論理面から管理するクレームというサービスユニットが生まれた。この二つは納期が遅いため、じっくり取り掛かっても間に合う。この二つのチームのリーダーに、やたら駄洒落を連発するおとっつぁんが入った。この人のことを駄洒落さんと呼ぶ。だんだんネーミングが安直になってきた。見栄春さんと駄洒落さんは二人とも教育熱がある人だったが、見栄春さんが何でも自分で直接指示したがるのとは対称的に、駄洒落さんは一歩引いて下の人間に仕事を任せる比重が高かった。
これらのサービスユニットのチームをまとめあげるのが志村部長だったが、さすがにここまで人数が増えてくると意志の疎通のために取れる時間が少なくなってきた。志村部長はこのプロジェクトだけに関わっているわけにはいかず、他のプロジェクトの客先に行って営業的なことをしたり、50人ぐらいいる部員の面倒を見なければならなかった。そうなると自然に志村部長の時間の取れる定時後に連日ミーティングが開かれるようになり、夜遅くまで打ち合わせをしなくてはならなくなっていった。そのうち矢作さんが冗談混じりに、このプロジェクトって完全に志村さんがボトルネックになってるよね、と言い出した。
そろそろメンバーが固まってきたということで、ようやくプロジェクトのキックオフの飲み会が開かれた。そこに事業部長と担当営業なんかも加わり、さあこれからがんばっていこうと気合を入れなおした。その飲み会で私はたまたま事業部長や志村部長の近くの席になったため、これが私の良いところでもあり悪いところなのでもあるのだが、軽い気持ちで事業部長に対して、志村部長がプロジェクトのボトルネックになってるという話をした。するとどうやら彼らもそのことは認識していたようで、事業部長は志村部長がこのプロジェクトに専念できるように仕事を多少引き受けたりしているということを聞かされた。後日それが不十分だったことを自ら認める発言を事業部長がしているので、この時点では問題は完全には解決していなかったのだということが分かる。
ほどなくして、顧客との打ち合わせに参加していた四人の間で、顧客の中のある人の名前が頻繁に出てくるようになった。どうやら顧客の中にとても主導的で頑固で職人的な人がいるらしいということが伝わってきた。後日私もこの人に会うようになって納得したのだが、いかにも江戸っ子風の白髪混じり短髪ごま塩頭のおやっさんが声を張り上げて場を圧倒している場面に出くわした。この人が声を張り上げているときに資料の紙を一枚手に持って空中で静止させると、1メートル以上離れているのに紙が振動でブルブル震えた。イメージ先行でこの人のことを源さんと呼ぶことにする。この人の肩書きは本部長で、今回のシステムの総責任者というべき人だった。
源さんのすごいところは、各チームごとに週一回開かれるミーティングに毎回出席して自分の思いのたけを語ることであった。一回のミーティングで一時間から長いときで数時間も掛かるのに、それを各チームのミーティングにほぼ毎日出て同じテンションを保って参加していたのだ。しかも技術畑出身なのでデータベースの細かいところなどの詳細設計にもガンガン指図してくる。既存システムのサンプルプログラムにもこの人の名前が書かれていたので、現場の叩き上げの人なのかもしれない。
この人がウンと言わなければ何も決まらない。源さんに手を焼いたのは私たちだけではなくて、向こうの社員全員がひれ伏していた。インタフェース担当の丸メガネの社員なんかは、源さんと歳が比較的近く部署も同じなのにも関わらず、源さんと直接打ち合わせをすることを避けて自分のアイデアを私たちに持ってきて、それを検討して私たちから源さんに出してくれないかと言ってきたほどだった。私たちは一応そのことに反発しつつも仕方なく途中まで従っていたが、最終的にはなんとか社内で話し合ってもらうことができた。
志村部長はこの源さんにガッチリついていき、源さんの信頼を得ることに成功したようだった。源さんが考えたシステムイメージの理解に努め、それを配下の各チームリーダーに伝えることが志村部長の重要な役割だった。各チームリーダーはそれぞれの領分のことに通じてはいたが、源さんが何か言ってもそれが何を言っているのかその場では分からないことが多いらしい。そこで彼らはいったん持ち帰ったあとで、志村部長から解説してもらって理解するという流れが出来上がっていった。
源さんは頭の回転が速い人だった。その場その場で色々なことを思いつき、これはどうだとその場で討議が始まる。じっくり考えている時間はない。源さんの言葉を素早く吸収し、その場ですぐに意見を言えなくては信頼を失ってしまう。事前に検討内容が知らされるわけではないので準備のしようがない。前の週に決まったことをこちらがまとめて持っていっても、またすぐに新しいことを考え出して検討を迫ってくる。難しい顧客だと志村部長が言っていた。
源さんは女好きのようで、そのせいか知らないが営業のほうから女性を一人プロジェクトに呼んでいた。その人は結構カジュアルなファッションをしていた。デキる女性のイメージは、80年代は原色のスーツ、90年代はシックな装い、そして00年代はついに一歩間違えればコギャル風になったのかと思った。客と他社と全体でバーベキュー大会をやったことがあったのだが、彼女は「失礼ながら当日はさらに小汚い格好で現れますので」と自覚があるようで、当日は穴の空いた古着のジーンズで現れた。客の会社はその分野でのシェアはそれほどないものの超有名企業のグループ会社で、その会社自体もテレビにコマーシャルを打っていてそれなりに有名な会社なのだが、内部は結構緩いようだった。それはそれでうらやましい。
ちなみにこの会社は、本物の顧客データをテスト目的でうちの会社に貸与するにあたり、かなり強気な契約の文面を突きつけてきた。それはうちの会社の顧問弁護士をして一方的で劣悪と言わしめたほどで、向こうもそれはよく分かっているようだったが、その会社の親会社のほうが子会社に決まりを押し付けているそうなのでどうしようもないらしい。結局関係者同志の尽力で何度も文面の修正と確認のやり取りを続けて歩み寄ってなんとかなったが、多分実際に何かあったときは絶対に問題になったと思う。
*
あまりにも量が多くなったので分けることにした。というわけで次回に続く。