児玉：本日は、お忙しいお時間を頂きましてありがとうございます。どんなお話が
聞けるのか楽しみで来ました。
藤田：何を話そうかと、仕事が手につかなかったよぉ～。
児玉：え～。ますます何から話していただけるのか楽しみです！！
藤田：僕はね。役所関係のシステムしか手がけてきたことがないんだよね。新卒で
入社してずっとこの業界にいるけど、その中でいつも思っていることは、ど
うやったらプロジェクトはうまく成功できるのかな？ということなんだよ。
何万というシステム開発が行われているけれど、プロジェクトが何らかの理
由でうまく稼動せず、使用されていないものが結構あると聞くよ。
しかも投資額は何億だったりするわけでしょ・・・・もったいない話だよね。
例えば、①：納品したのは形だけでユーザーは全く使わないとか、
②：納品する前にプロジェクトが終了とか、
③：納期がきても完成していないとか・・・そこには、必ず原因があるはず
でしょ？
何が問題なんだろう？といつも、いつも自問自答しているんだよ。
だからこそ、プロジェクト成功へのプロセスを確立する鍵を見極めることこ
そが、僕の課題だし、使命だと思っているんですよ。
児玉：それは、私も感じることがあり、使命にして頂いているのは心強い！！私と
しても教えて頂きたい課題のひとつです。だからとても嬉しいです。なぜ、
多額を投資しているにも関わらず納期遅延や、要件に合わないものができて
しまったりするのか？考えにくい話が多すぎますよね・・・
ぜひ、お話をお伺いさせてください(^^)!
藤田：新卒の就職のなかでコンピュータの周りに就職する学生はたくさんいるんだ
よね。コンピュータ産業が根を張っていくためには昔みたいに特殊な作業じ
ゃなくて、たいていの人がそれなりに出来る底辺の広い作業になってきたで
しょう。それは産業として根付くためには大切な事だけれど、しかし、何年
かするとほとんどの人がＳＥといわれる職種になっちゃう。 業務系SE，基
盤系SE，運用技術系ＳＥなどという名で仕分けしリスクが分散されたように
見えるけれど、このＳＥという名の職業の守備範囲は不明瞭でしかも、限り
なく広いんだよね。野球にたとえるなら、ピッチャーでありながら、内野も
外野も守る・・・くらいのイメージだよね。
児玉：守備範囲を聞いただけでも現実的にありえませんね・・・・
藤田：野球だったらありえないよね・・・。でもこの業界では当たり前なんだよね。
シリーズ第一弾で話されていた「ＤＢの基礎知識は、不変！」とは、僕も確
かにそう思っている一人だね。ＤＢの考え方が普及してこの業界は飛躍的に
技術が向上したと思うよ。しかし、ＳＥの仕分けの仕方が技術側の分業にな
っていて、少しも業務よりの仕分けをしてないんじゃないの？と感じるね。
児玉：確かにそうですね。システムエンジニアの肩書きが付いているだけで、マル
チな人として見てしまいますね。その人に聞けばなんでもわかる＝技術的な
見解＋業務的な内容把握もバッチリな人！という感じで、ついつい先入観で
依頼してしまいがち・・・。
藤田：そこでね。僕の経験の中で、成功したプロジェクトを検証したときに見えて
きた事の話をしたいと思うんですよ。あるお客様から「システム導入を手伝
ってよ！」といわれたんです。 「オリジナルで一から開発したいんだよ！」
と希望されていたんだけどね。条件を伺うと、納期までの期間も短いコスト
を考えると一からの開発範囲では無かったんだよね。だから受ける条件とし
てＰＫＧの導入を薦めたんです。大まかな条件は双方確認できたので、導入
プロジェクトを立ち上げる事にしました。
ＰＫＧ選定後のカスタマイズ、導入に責任をもつのがこのプロジェクトの役
割なんです。そこで僕はね
「①業者（ＰＫＧ）→②開発会社(我社)←③ユーザ－」のトライアングル地
帯の潤滑油になる人を②：自分の会社の中で一人抜擢して、その人に仲介の
役目をお願いしたんだよね。
仲介役の条件は、
a）：ユーザーの業務を理解していること、
b）：ある程度の技術スキル、何らかの開発経験がある、
c）：ある程度、理論的にシステム構成を理解している、
d）：物怖じせずに人と話ができる・・・くらいの人だったね。
仲介の内容は、まず、①からカスタマイズ要件を聞き出す。③からＰＫＧの
業務機能要件をまとめる費用対効果のないカスタマイズ要求事項は整理して
採用しない提案や代替案をだしたりする①、③の両方の合理性のバランスを
とる役目をお願いしたんです。
そして大事な事は、Ａ：①－②間（業者と開発スタッフ）にはシステム語
Ｂ：②－③間（開発スタッフとユーザー）には業務語で話をし、両方の話を
それぞれの言葉で翻訳する役目をお願いしました。
その担当は、３社（①②③）の信頼関係をうまく潤滑して築いてくれましたし
予定期間よりも短期間で成功しました。このプロジェクトを検証したとき、
今のプロジェクトは、ＳＥという名の職業がすべてやっているんじゃないの
という現実がわかりました。
ＳＥが①：要件設計しながら、③：お客様との業務要件をもまとめる・・・
さらに、必要であれば設計書も書くし、コーディングの進捗が遅れていれば
プログラムも手伝う！！スーパーマンの世界だよね（；。；） そこにかな
りの矛盾や無理があることを理解している上司は、少ないんじゃないか？
業務も、技術もどちらも知っているＳＥを中間に配置すれば、業者とユーザ
両方に解決策を即座に翻訳し、提示できる！＝「時間の無駄を省き、開発担
当ＳＥの負荷を軽くし、３社間の考え方の溝を埋め理解を深められる」。こ
ういう役割のＳＥが「第3者」的な立場でいれば、物事はかなりの確率でスム
ーズに運ぶはず！！その存在を確立することこそがプロジェクトを成功に導
くと確信しました。その役割を僕は、「プロジェクト・コンダクター」など
と勝手に呼んだりしました。
僕は以前、このポジションを「業務ＳＥ」と読んでいたんだけど、ＳＥとつ
くと途端に、設計行為、業務要件を固める作業が別々の分業とならず「業務
要件をそろえる」と「設計する」と一気に全部引き受けなければいけない状
態に陥いるわけです。しかし、これは必要とされるスキルが全く異なるわけ
です。 ＤＢ，ＮＷ、サブシステムごとに要件をきいて、お客の業務要件
をきいてくれ？といわれてもできない。ユーザーはシステム語では話ができ
ない・・業務語じゃないとね。だから、業務に精通していてシステムのこと
が解る通訳がいれば、先手先手でイメージが掴め、ニーズを聞き進めること
が出来るんだと思いますよ。技術スキルがあれば、システム設計の理論が理
解できているので先手、先手で進行できるこの立場の確立が成功への鍵なは
ずだよ！！それをＳＥ、ＰＬに代替してしまっていることが、業界の大きな
問題だと思うね。ＰＭ、ＳＥ、ＰＧ、ＰＬ、ＮＷ技術者、ＤＢ技術者、そし
てＳＥ・・・。 ＳＥって得たいのしれない職種だよね・・・・。
細分化はされてなく、分業でもなくＳＥの名のもとに何でも知っているし、
なんでも理解できている！
何でもやるという得体のしれない職種となっているので、「ＳＥになるだけ
で大変だぁ～！！」となってしまうんだよ。
ＰＧ：規則のもとに正確に書く、品質の問題が最優先課題
ＳＥ：「ちゃんとやる」＝細分化していないので、途端に忙しくなるし、重
圧責任も重くなる。でも、とにかく「ちゃんとやる」で、プロジェクトを成
功させることが目標？？？ 何か変だよね。
児玉：確かに、お話をお伺いすればするほど、ＳＥという名の職業は得体が知れな
い中途半端な位置づけですね。また、ＰＧの次のステップがＳＥで・・と簡
単に言ってしまいますが、ＰＧを３年経験したらＳＥの知識が身につきます
ということは無いですよね。技術への好奇心はたっぷりあるが，一方で変化
する技術へのキャッチアップが悩みでもあるし、全く違う対人交渉スキル
（コミュニケーション）が必要になりますよね。技術職を希望してきた人に
してみれば、パソコンが相手だったものが人に変わるわけですから、職種を
変えたようなものですよね。その点、「プロジェクトコンダクター」は実に
いいですね。
これは成功する秘訣になるのもわかります。
藤田：そうなんだよね。ＳＥ＝技術スタッフ、プロジェクトコンダクター＝業務要
件技術要件の取りまとめを行う人、ユーザ向け翻訳家、と分業して確立する
ことがうまくいく秘訣だということはどのプロジェクトに当てはめてみても
思うところだね。 「岡目八目」という言葉があってね。囲碁の言葉なんだ
けど、意味は対戦している当事者よりも、傍で見ているほうが正しい次の手
が解るという事なんだ。客観的に、人のやっていることはよくみえるけど、
自分のことはよくわからない。実務を実際自分がやらないから、そのシステ
ムについて、大胆、画期的、無責任なことがいえる。誰しも、自分のやって
いることに無駄はない。自分は必要なことをやっているから正しい。自分に
間違いはない。と思っている。しかし、実務に関わっていない第三者が傍か
らみたら、無駄なことは見えやすいし、実際多い。コンダクターの役割を担
う能力は、岡目八目に徹するかどうかという事になるかもしれないね。
プロジェクトが成功するかどうかは、みんながどういう観点で動いているか
でわかるんじゃないかな？プロジェクトがうまくいっているときはそのプロ
ジェクトを客観的にみて、温度差はなにも感じない・・ただしうまくいって
いるとも感じないものだよ。 反面、失敗しているプロジェクトはなんとな
くわかる・・温度差があるからね
チームがなんかヘンだなとわかる。それは、ＭＴＧで言い合ってケンカみた
いになっているけど、そこに温度差がなければうまくいくんだよ
児玉：温度差を感じなければうまくいく・・・・そういうものなんですね。
この業界にもいろんな位置づけ（ＰＭ・ＰＬ・コンサル・システムアナリスト
がありますが、ひとつの地位役割分担として「プロジェクト・コンダクター
が確立して認められるとホントに数多くの悩みを解決してあげられますね。
藤田：そうだね。「プロジェクト・コンダクター」が行司役として核になっていれ
ばユーザーの説得、開発スタッフの進捗管理・・・等の双方の課題に風を通
した動きを期待できる。これを担ってくれる人はホントに必要だよね。ＳＥ
という論理的な世界の中で業務設計を長年やっている人に、いきなり人と人
の狭間を埋める役目を頼んでも、頭が切り替わらないでしょう？？？？論理
的な見解をいくらユーザーに説明したところで、全く理解できないよね。
しかし、残念なことにこの「プロジェクト・コンダクダー」は何の成果物も
産まないんですよね。だから社会認知をされるのはかなり難しいよね。
今は業務ＳＥの名の下に統合されているからね。。。。
メモ書き程度くらいしかないのでドキュメンテーションの価値は無いもんね
だけど重要なんだよね。
児玉：ホントに必要なことはわかります。が、現実的に育てるのは難しいですね。
もって生まれた性格や気質に起因するところが大きいですよね。
藤田：そうだね。だけど、ますます必要になるし、確立していかないといけないん
だなということがやっとわかったんだよね。僕らの仕事は戦術は「岡目八目」
で、やっていることは「翻訳」なんだよね。言語をしゃべっている人々から
３ヶ国語くらいを一度に一人のＳＥに翻訳し、てよといっているようなもの
ですもしかすると、業務を熟知している人を開発会社につれてきてＳＥにす
る方がこの地位を確立するスタッフを育成するのは早いかもしれないね。
そういう流れはないもんね。。。。
僕も、この業界にいる限りこの課題に少しでも貢献できるようにこれからも
実践していきたいね。
児玉：本日はありがとうございました。
インタビュア－：営業 児玉美佳子
2008年3月7日取材
