« チーフ・テクノロジ・オフィサ(CTO)ってチーフ・エンジニアと違うの? | メイン | 【速報】TonchidotのSekai Cameraについて15分調べて1時間ブレストしたレポート »

ベンダ企業でのクライアント・ファースト思考はユーザ企業でのCIO/CTOに通じる

今回の想定読者は「いずれユーザ企業に移ってCIO/CTOを目指す」というベンダ側(SIer)の人です。システム開発の「超上流」フェーズでクライアント・ファーストの仕事をすることは、ICTベンチャーのCIO/CTOに通じると思います。(※超上流とは、システム化の方向性、計画、要件定義などのフェーズをいいます)

■超上流工程の重要性

前回の記事ではCTOの仕事について次のように書きました。

技術力を保有することも、製品開発という行為も、すべて「事業の成功」のための手段でしかない。高い技術力を保有することに、どれほどの資源が必要か、考えないといけない。製品開発という行為に、どれほどの資源が必要か、考えないといけない。

チーフ・テクノロジ・オフィサ(CTO)ってチーフ・エンジニアと違うの? (ZEROBASE BLOG)

何をシステム化するか、何に投資するか。それは何をシステム化しないか、何に投資しないかを考えることでもあります。個別のシステム開発においても同様です。それを考える超上流フェーズが重要だということです。

■何を作るべきか考えるのは誰の仕事か

近年「共通フレーム」などで「要件定義はユーザの責任である」という超上流の考え方が紹介されます。それ自体はよいことだと思います。ただし、留保つきで。

プロジェクトのオーナーはユーザー企業自身であり,「システム化で何をしたいのか」はユーザー企業にしか決められない。そう考えれば,本来,要件定義以前の「超上流」フェーズはユーザー企業自身が主導すべきだ。しかしこれまでは,ユーザー企業側に,この意識が弱かったのではないだろうか。

「超上流」を成功させる17ヶ条:ITpro

ユーザが要件定義にコミットしていない状況においては、「ユーザも言ったことに責任を持つべき」という主張が有意義です。無責任なユーザのせいで失敗したプロジェクトの責任を、ベンダにかぶせるべきではない。そういう状況を無くすために業界としてメッセージを発するのはよいこと。

しかし、ユーザが超上流にコミットしている場合はどうか。相変わらず「ユーザ企業自身が主導すべき」なのだろうか。そうは思えない。その先に進むべき。ベンダはユーザに主導してもらうのではなく、専門家(プロフェッショナル)として主体的にユーザから情報を引き出し、ユーザを理解すべきだ。積極的に自分から顧客理解プロセスを推進すべきだ。「超上流フェーズはユーザ企業自身が主導すべき」などと言って自分の役割・可能性を矮小化し、狭い専門領域に引きこもるのは、悪い意味で「専門家的」な発想ではないか、と思うのです。

※ビジネスモデル、組織の力学が、個人の努力を妨げる場合がある。従って、現場の担当者個人の問題にしてはならない。これについては機を改めて論じたいと思います。
※受託開発企業としての事業戦略、つまり「事業領域の選択」という問題は避けました。経営判断として「超上流はユーザに任せる」という会社があっても構わない。ただし、その場合も、ほかのベンダがその役割を担うべき。どの企業がやるかはともかく、どこかの企業がやるべき。なぜ強く「べき」と言えるのかといえば、「超上流をないがしろにすれば失敗する」と当のSI業界が言ってるわけですから。
※もしユーザ企業にベンダ出身の優秀なCIO/CTOがいれば、彼が主導して社内で超上流フェーズをやってしまえばいい。そういうCIO/CTOになる、というのが今回の記事の主旨でもありますね。

■CIO/CTOの役割

CIO/CTOは、システム開発せずに済ます方法を考える必要があります。一方、ベンダ側の超上流フェーズ担当者も「クライアント・ファースト=顧客の利益を最優先※」で考えるならば、不要なシステム開発は避けるべきです。

※クライアント・ファースト・・・クライアント・インタレスト・ファーストという言葉もあり、おそらく同じ意味で使われていると思うのですが、もし違いがあればご指摘ください。おもにコンサルティングなどのプロフェッショナル・サービス分野で使われる言葉です。

しかし、現実にはどうか。多くのシステム受託開発企業の経済原理、行動原理は異なります。必要性のないところに必要性をでっちあげてでも、要件を膨らませて、受注額を増やすのが、よい案件獲得担当者とされる。とうていクライアント・ファーストとは呼べない。顧客利益と自社利益が一致しない。利益相反の状態です。

こういう仕事を長年やってきて、ベンダからユーザに移ったら、「古巣」の感覚で「システム開発にはカネがかかる」と思ってしまうかもしれない。

本来、ユーザ企業のCIO/CTOやIT部門としては、最小のコストで最大の成果を得るトレードオフの問題に取り組まねばならない。ならば、ベンダ側にいるときから、そういうトレードオフの問題に取り組んでおきたい。つまり、クライアント・ファーストの実践は、ユーザ企業でのキャリアにつながる。

■立場の違い

ユーザから見て理想的なベンダは、顧客理解力があって、「何を作るべきか」にコミットしてくれる。自社のCIO/CTOのような観点で提案してくれる。そういうベンダが理想的でしょう。

例えばこういう取り組み。顧客が「事業の成功」をどのように定義しているかを理解する。組織の行動原理は、現在の競争環境、戦略のゴールは何か。担当者の個人的な関心・利害・価値基準は何か。こういった背景を理解する。その上で、はじめて「情報通信システムによって何を解決したいのか」という話をする。適切な問いを立て続けに発することで、適切な「システム化の方向性」を導き出す。

■まとめ

あなたがクライアント・ファーストを実践するメリット。

  • 顧客に信頼される。
  • 顧客にとって本当に価値のある提案ができる。
  • それは自社、顧客だけでなく経済社会の観点でも素晴らしいことだ。
  • そういう仕事をすることで、あなた自身の価値も高まる。

同じゴールが共有できたなら、発注者と受注者という枠で、お互いの役割を線引きする意味があるのか。力を合わせて同じ仕事に取り組めばいいじゃないか。その経験は、やはり発注者と受注者という枠にとらわれずに、どちらでも役立つ経験なんじゃないか。と、そういう主旨です。

今回の内容(きれいごと)について、いろいろと「できない理由」を指摘されることが予想できます。デメリット、障害、抵抗について触れていませんから当然です。また機を改めて論じたいと思いますので、いろいろとご指摘ください。そのなかから次の議論を選ぶかもしれません。

[PR] 人材募集 - ZEROBASE Inc.

トラックバック

このエントリーのトラックバックURL:
http://zerobase.jp/mt/mt-tb.cgi/420

コメントを投稿

(いままで、ここでコメントしたことがないときは、コメントを表示する前にこのブログのオーナーの承認が必要になることがあります。承認されるまではコメントは表示されません。そのときはしばらく待ってください。)

About

2008年09月08日 21:11に投稿されたエントリーのページです。

ひとつ前の投稿は「チーフ・テクノロジ・オフィサ(CTO)ってチーフ・エンジニアと違うの?」です。

次の投稿は「【速報】TonchidotのSekai Cameraについて15分調べて1時間ブレストしたレポート」です。

他にも多くのエントリーがあります。メインページアーカイブページも見てください。

Powered by
Movable Type 3.35