■背景
PoCとして頭から爪先まで全ての業務に関わることができたプロジェクトであったため学んだことを次回生かすため文面に残す。
※プロジェクトの責任を負っていたため全て自身へのヘイトになるため誰かを咎める内容ではないことが公開できる良い機会となった。
また、プロジェクト管理や進め方で悩んでいる人へ些細なナレッジであるが役立つことを願う。
目次
- 私たちはプロであって作業者ではない。
- WBSでは顧客に何ができたらいいか伝わらない。
- 顧客はPoCの目的を達成するための過程がわからない。
- システムでできることを増やすのではなく、効果の薄いところを削る。
- システムを導入しても使わない
- 最後に
１. 私たちはプロであって作業者ではない。
突然だが、私はシステムを提供する組織の人間としてお客様が望むシステムを実現し、提供することが使命であると考えていた。これは間違ってはいない。だが、今の私は肯定できないのである。
お客様が望むシステムを提供する＝顧客満足、強いては導入時にお客様が喜んでくれると顧客満足になると考えてしまう人は多いのではないだろうか。しかし、これはとんでもない間違えだったのである。
なぜなら、作業者であってプロではないからだ。わかりやすく作業者である医者の例を挙げてみよう。
〜病院にて〜
患者：最近胃が痛くて胃癌だと思うのです。手術で胃のがん細胞を取り除いてくれないか。
医者：わかりました。今すぐ手術をしましょう。
〜〜〜〜〜〜
確かにすぐに患者の言う通り手術を行えば短期的には患者の満足度は高いだろう。
なんてあの医者は、スピード感あり、クリティカルな対応をしてくれるんだ！素晴らしい！と思ってくれるはずだ。
では、次の想定しうるシーンを覗いてみよう。
〜病院にて〜
患者：あれから期間経ちましたがまだ胃が痛く。。。
医者：ん〜ちょっと検査しましょう
＝＝検査後＝＝
医者：これ癌じゃないですね。がん細胞は毎日できるんですよ。それを前回取り除いただけですね。ただの胃潰瘍ですね。
患者：え？手術代返すのと慰謝料寄越せ！！
医者：あなたが癌って言ったんじゃないですか。
〜〜〜〜〜〜
この医者の対応を私たちはプロと呼べるだろうか。見ようによっては詐欺師にすら見える。
過去を振り返ってほしいのだが、ITのベンダー取引では往々に起こっていることである。
お客様が必要としている、お客様のイメージするものを提供したい、お客様の意見通りのシステムを作ろう！
これはもはや詐欺師なのである。
本来、私たちはプロであるからお客様の要件はそのまま呑まない、要求だけを追い求めるのである。
要件は私たちが組み立てるものである。
プロとしての医者は言うまでもないが以下の対応であるべきだろう。
〜病院にて〜
患者：最近胃が痛くて胃癌だと思うのです。手術で胃のがん細胞を取り除いてくれないか。
医者：胃が痛いのですね。あなたの言うように胃癌の場合もありますが、他の原因かもしれません。
さらに言うと、胃癌でも手術をしなくても他に治療手段があります。
まずは診断からさせてください。
〜〜〜〜〜〜
コントロールは知識を持つものがするべきだ。
あなたの仕事はプロか作業者か今一度考え直すべきである。
２. 具体的かつ項目数の多いWBSでは顧客に何ができたらいいか伝わらない。
・ざっくりとした抽象的な項目にお客様が動かなければいけないことを明記すべきである。
お客様との打ち合わせでWBSを進捗確認として提示する。
やる気があるお客様はWBSの項目を全て見て理解しようと努めてくれるだろう。
お客様として何をどこまでにするかイメージのすり合わせを行ってくれる。
そんなお客様がいたらどんなに楽なプロジェクトになるか。自分がお客様になった時、そんなことをするか。しないのではないだろうか。
基本ベンダーに委ねるし、WBSの項目を注視しない。
ふーんこんなの作ったんだ、スケジュール通り進んでいるのか、何してるか分からないけど順調ならいいだろう。
こんな感じで内容なんて把握しないし、する方が特殊だ。
WBSで何ができるのか、それは社内の人間が把握するための進捗確認用ではないだろうか。
綺麗なわかりにくいWBSより、お客様とマイルストーンをしっかり意識づけられるお客様視点の
WBSを作成すべきである。
・順調に進んでいるならメールでWBS、順調に進んでいる報告をすれば良いのである。
現状の成果物を見える形で見せることができれば尚何の問題もないだろう。
順調に進んでいるのであれば進捗確認の打ち合わせ等いらない。
問題があったりしっかり認識合わせをするために打ち合わせの時間をとった方が決まったお金で質がより上がる。
３. 顧客はPoCの目的を達成するための過程がわからない。
先ほどまでで述べてきたように、お客様のほとんどはPoCの目的を達するための手段を知らない。ほとんどの場合、当初思い描いていたシステムを作れさえすれば目的は自動的に達成されると考えているからだ。システムを導入して業務を効率化させようが目的の場合だとしても本来やらなければならないことは業務を効率化させることなのである。しつこいようだが、業務の一部をシステム化する=>業務効率化にはならないのである。
むしろ、システムを導入することでお客様は元々の業務と作成したシステムの知識が必要になるので負担になる場合も考えられる。これは案件を回している途中にふと気付く時もある。
途中に気付き、この範囲をシステム化してしまうと逆にマイナス効果になる。だから、範囲を変えさせていただきたいと提案してもお客様はシステムを作ることが目的になっていることが多いため止められないだろう。
つまり、初めに変更する権限をもらっておくべきなのである。
範囲が少なくなり、工数が余ればその分返金か別の工程に力を注ぐように交渉すればよい。
もう一度言うとこれは初めに合意をとっておかないと3方悪しと最悪の結果をもたらすだろう。
４. システムでできることを増やすのではなく、効果の薄いところを削る。
これも3と同じで最初に合意をとっておく必要がある。
一般的に機能を削るイコール価値が減ると思うものである。
機能とは土地のようなものである。
人気があるところは１坪あたりの値段が高くなる。対して、人気のない土地は言うまでもない。
しかし、土地の維持、管理費はほとんど同じなのである。
私たちは国を経営しているのではないため重箱の隅のような土地を持ち、維持管理しなくてもいいのである。
ミニマムスタートという言葉が最近流行っているが、流石に規模のミニマムではない。ほぼ確実に使われる芯となる機能を絞って作ることである。
市場調査をガッツリするより、同時並行で実験をしていきたい、そのためにPoCなどを使うのではないだろうか。
システムとしてA機能、B機能、C機能を実装したとする。
システム利用者はA機能とB機能を使い、C機能は1割も満たない利用者しか使わない。
C機能は実装したが凍結させた方がいい。
なぜなら、C機能を保守する工数をとることができるのであればA機能、B機能の強化や他の追加機能を試すべきである。
もし、あなたが最終的に世界にシェアされるシステムを作りたいと考えていても、最初は小さなターゲットに最適化されたシステムを作るだろう。いきなり世界最適化なんてよほどの資金力がないとできない。
５. システムを導入しても使わない
どんなに便利なシステムでも知らなかったり、たどりつけないと誰にも恩恵をもたらさない。
良いシステムを作る=>使われる ではなく 使われるように工夫する=>システムを評価 されるのである。食べログと同じで星5でも評価者が1人では良い店と思われないだろう。
それより、星3だが評価者が100人の店の方が良い店だと思うのではないか。
何度も言うがシステム化が目的の案件なんて存在しない。
使われないと無意味なのだ。
システムを作る以上にシステムが使われるにはどうするかを実施すべきだ。
実にシンプルなことである。
目的→目的を達成する方法→導線の変更やいらない作業の洗い出し→システム化した方がいいところ→PR
どう考えてもシステム化は手段のごく一部にしかならない。
６. 最後に
覚書として忘れてはいけないやるべきことを記載する。