トピックス

シリーズ「この人に聞く」第4弾は、市川様からのご紹介で株式会社PUCの
藤田 博幸様にお伺いいたしました。
毎回、インタビューした内容を掲載させて頂きます。「仕事は楽しく!継続は力なり!」をモットーに、年間12回を予定して皆様にお届け致します。「ぜひ!私も取材してほしい」といううれしいお誘いをお待ちしております。


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

児玉:本日はありがとうございました。
インタビュア−:営業 児玉美佳子
2008年3月7日取材

                              

このHPのメニュー一覧

| トピックス | サービス | 製品紹介 | 会社情報 | 採用情報 | ホーム |
| WebFOCUS質問窓口 | WebFOCUSUSAフォーラム | 業務開発支援 |
| 営業分析アプリ:コクピット | 経営情報アプリ:ActiveManager |
| WebFOCUSメニューポータルアプリ:CHANGE |損益計算書1 |
損益計算書 |
| 売上分析グラフ | 日時進捗グラフ | 販促経路別ウエイトグラフ |
|販促経路別粗利グラフ|回収形態別売上グラフ|組織別売上総括レポート|
| 職種別売上実績グラフ | 当月達成分布図 | 商品別売上高ウエイトグラフ |

|特定労働者派遣許可 |福岡営業所開設 | インタビュー記事 |HP更新履歴|
|サイトマップ|アシスト社リンク| IBI(WebFOCUS製造元リンク|お問合わせ|
| 火消し | HP内検索 | Oracle/Lifekeeper導入支援|
|物流販売管理システム|プロジェクト管理システム開発|Web@レポーター|
|車両運行管理システム | 調剤局業務システム開発 |
|Mail@Finderシステム開発| PDA検品太郎システム開発|
|
PDAレストランシステム開発| Applixware Anyware|Web@レポーター|
| Quick販売管理システム |

|インタビューK|インタビューJ|インタビューI|インタビューH|インタビューG|インタビューF|
|インタビューE|インタビューD|インタビューC|インタビューB|インタビューA|インタビュー@|

当社スタッフの出身地は以下のとおりです。
北海道(函館) 青森県 秋田県 茨城県東京都千葉県埼玉県 神奈川県大阪府兵庫県福岡県宮崎県中国(青島)

pagetop

HOME

個人情報保護規程

お問い合わせ

COPYRIGHT © 2004 Joho Builders Inc. All rights reserved.