ソルクシーズのグループ会社「株式会社インフィニットコンサルティング」のITコンサルタントが、【ユーザー企業側からみたITプロジェクトのノウハウ本】を出版しました。
「システム企画」や「RFP※作成」「ベンダー選定」「プロジェクト推進」の方法を、実際の現場レベルで使える形で説明している本です。
※REP: Request For Proposal（提案依頼書）
出版を記念して、著者の田村昇平（たむら しょうへい）さんからお話をうかがいました。
● ITコンサルタントって、どんな仕事なんですか？
一言で言うと「ITプロジェクト」を成功に導くために、「ユーザー企業」・「ITベンダー」にノウハウを提供する仕事です。
当社のコンサルティングは、ITプロジェクトの目的を達成するまで責任を持ちます。上の図で言うと、通常【システム企画】から【システム導入】まで関わります。場合によっては、導入後に定期的に訪問して【効果測定】についてアドバイスをします。
● この本はどうやって出来上がったんですか？
私はITベンダーのSE出身で、インフィニットコンサルティングに入社して8年目です。ITコンサルタント1年目の時に、「ユーザー企業の立場でITプロジェクトを成功させる」方法についての知識がなかったので、まずITプロジェクトについて書かれている本を読もう、と大型書店に行ってみたんです。
でも、ユーザー側から見たITプロジェクトについて解説した本がないことに気づきました。
あっても部分的にしか書いていない。例えば”システムの企画の作り方”とか”RFPの作り方”とか、断片的な解説書はあるんですが、全工程を解説したものがない。プロジェクト後半の工程になると全然ない。“受け入れテストのやり方”を解説した本なんてないんです。
その後、現場で経験を積み、試行錯誤してオリジナルの方法を編み出しながら、3つの現場を掛け持ちしていたとき、どの現場でも同じような質問をされるので「これって共通の悩みなんじゃないか？」と気づいたんです。
それからは仕事帰りの電車の中で、その日に受けた質問と回答を日記のようにEvernote※に書きためていきました。書き始めてから出版まで3年。最初の2年は出版のあてもありませんでしたが、「本を出すんだ！」と思って書いていました。
「ユーザー側のノウハウ本が世にないなら自分で書いてシェアしよう！」
「自分が培ったノウハウを世に広めて、ITプロジェクトの成功率を高めたい！」
という気持ちで書き続けました。
「自分のやり方が通用するのか？」を世に問いたい、という思いもありましたね。また営業的な観点からは、コンサルって品質を形にして見せられないので、形としてあらわすには何か？と考えとき「本だ！」と思いました。
こうして、いろいろな現場で受けたいろいろな質問と回答をストックしていったら、全工程について【ITプロジェクト成功のノウハウ】が形になりました。
※Evernote：思いついたアイデアや情報を一ヶ所にまとめて管理できるインターネットツール。スマートフォン・パソコン・タブレット端末からアクセス可能。
●執筆して新しく気づいたことはありますか？
この本に書いてある、ひとつひとつのテーマを実行するのは難しいことではありませんが、
「ひとつ知らないだけですごく損をしちゃう。知ってるか・知らないかというのが、ITプロジェクトの運命を左右する」
と感じるようになりました。
例をあげると、ユーザーはふつう「システムのテスト結果」なんて詳しく確認しないことが多いですが、「テスト結果を見せてください」と要求するだけで、ベンダーのテスト作業の質が向上したりするんです。
●『はじめに』に書いてある「Win – Winのアプローチ」ってどんな方法ですか？
弊社は【ユーザー企業の立場にたったITコンサルティング】が特徴ですし、私の基本スタンスもそうですが、実は「ベンダーの味方にもなりたい」と思っています。
自分がベンダーSEだった時代に、ITプロジェクトの進捗が遅れるとベンダーを叱ったりするユーザーを目にしてきました。当時はプレッシャーをかけられるのがいやでした。
でも「なんでユーザーはそんなことをするのかな」と考えたら、プロジェクトの舵取りをベンダーに“丸投げ”してしまうからだったんです。ユーザー自身がコントロールできないから、遅れるとストレスをためてしまうんです。
コンサルタントになってから「プレッシャーをかけるのは、実は逆効果なんですよ」ということをお客様に伝えると「え？他にもやり方があるの？」と言われたこともあります。
叱ったところで、お互いの不信感が増幅されるだけだし、ベンダーの「ユーザーに貢献したい」という気持ちが薄れていくんです。
コンサルタントになって始めてのプロジェクトで、受け入れテストの時、ベンダーに厳しい要求をしてしまったことがあります。「自分の発言のせいでベンダーを苦しめてしまった」と後悔した苦い体験です。
その時点の判断は勇気をもってしたし、間違ったとは思っていませんが、「もっと前の工程でできることがあったのではないか？」「同じことがあったらもっと貢献するような動きができるんじゃないか」と思っています。
プロジェクトは雰囲気が重要です。
ユーザーもベンダーも、「間違っている」と思うことは間違っていると言って、お互い悪いところを直す。そこに気づかせて改善方法を提案できるのがコンサルタントという立場です。どちらの気持ちもわかるのが自分の強みかもしれない。いろいろな現場・立場を経験して、だんだんプロジェクトを俯瞰できるようになりました。
プロジェクトの雰囲気がよくなって、前向きな気持ちになると、ベンダーからの提案が増えるし、ユーザー側も改善しようと動き出します。結果的にシステムの品質が高まるんです。
雰囲気って大事ですよね。「毎日職場に行きたくなる」ようなプロジェクトにしたいな、って思ってやってます。雰囲気はシステムの品質に思いっきり反映すると実感しています。
【前編】はここまで。【後編】では、執筆にあたって苦労したことなどをきいていきます。
●『情シス・IT担当者［必携］ システム発注から導入までを成功させる90の鉄則』（技術評論社） 4月11日 発売
●本に関する詳しい情報、およびご購入方法は「株式会社インフィニットコンサルティング」の書籍紹介ページでご確認いただけます。
