はい、前回の続きとなります。前回は案件の炎上するポイントについてお話しました。今回は、どうしたらいいのさー？というお話をしようと思います。
どう進めるのがおすすめか
炎上ポイントは前回記事でなんとなく把握できたかと思います。で、どうすればいいのか。前回の最後にも書いたのですが、信頼できる実績のあるSIerを探して依頼する・・・です。もうね、コレに尽きるわけです。後は最後までしっかりと付き合ってくれる（寄り添ってくれる）ベンダーさんをゲットする感じですね。
はい、これだけだとあまりにも身もふたもないので、プロジェクトのコツをこれからお話します。
Workspace ONE プロジェクトのコツ
今回のお話もあくまでも個人の見解です。絶対にこの方法が正解というわけではないことをご理解くださいまし！
提案内容はここに注目！
まず、提案をする/受ける際のチェックポイントです。提案自体はVMwareさんから提案されるケースも当然多いと思いますが、最終的に導入を担当するSIerからきちんと提案がされているかが重要となります。メーカー作成の提案書とSIer作成の提案書は観点が異なるべきなのです。ここ重要、試験に出ますよー！
- メーカーさんの提案は顧客の要望に沿った将来のビジョンや方向性に対して提案していくことが多い
- SIerの提案はMust要件に対して明確な実現方式を提案する必要がある
- また、顧客要件に対して実現的なスケジュールを忖度なしで提示することも重要
- 要件が固まりきっていないケースも多いが、その場合はスコープについて明確に提示すべき
Let's PoCでGO
PoCとはざっくり説明すると、顧客環境を使用した本番導入前の確認作業となります。環境固有の問題点や課題の洗い出しや、顧客が実際に製品に触れる機会を創出して認識齟齬を減らすという効果が見込まれます。コレ実はめっちゃ大事なんです。
- PoC未実施で案件突入した場合、環境固有の問題が発生すると切り分けや原因特定、回避などに時間を要するため、スケジュールの遅延につながる
- 要件定義前に顧客に環境を触ってもらうことで、イメージを持ちやすくする
ワークショップをやりましょう、そうしましょう
はい、実は今回お伝えしたかったポイントです。意外と思われるかもしれませんが、ワークショップ、これ実は結構大事です。要件定義を行う前までに、ワークショップを実施/受けることを強く推奨します。
- 漠然としていた要件も製品理解が高まることで明確化する
- 製品理解が高まることで、精度の高い要件定義が可能となる
- つまり要件がブレにくくなる
- ワークショップが提示されない場合は、顧客から要望としてSIerないしはメーカーに依頼することを推奨
製品についての理解度を増やし、要件を明確にしてやりたいことのイメージを固めましょう！
ちょっと変わった要件定義
要件定義については通常のシステム導入系の進め方とは異なる手法を行っています。これは、ウォーターフォール型のシステム導入にかっちりはめようとするとうまく進まないケースが多いためです。Workspace ONEに限らず運用に密接に紐づく製品は割とあるあるですね。なので、ここでお話する内容は賛否両論あると思いますが、こんなやり方もあるんだーと思っていただければ。ウォーターフォールとアジャイルの間の子みたいな？
- 要件定義では顧客要望をすべて抽出し、優先順位をつけてスコーピングする
- PMの腕の見せ所、当初の提案内容と多少異なる可能性もあるが、限られたリソースで実現可能な範囲を見定めて本プロジェクトのスコープを確定する
- スコープ外になる箇所を顧客に説明し、別プロジェクトとして切り離す
- 要件定義はディスカッション形式で実施、方式設計まで合わせて行うことでブレを軽減させる
まとめ
- メーカー提案とSIer提案がほぼ同じ中身の場合は要注意
- 実現性に言及しているか確認しましょう
- PoCは明確な理由がない限り実施すべし
洗い出せる課題や使用感はPoCを実施して確認しましょう - ワークショップの開催を依頼すべし
やれることを知ることで精度の高い要件定義に望めます - 要件定義では現実的なスコープを定めるべし
本来スコープは提案段階で決めるものですが、本プロジェクトでは未定のケースが多いため、このタイミングで確定させましょう
ちょっと小話、いわゆるAppendix
まとめのあとにおまけの話をぶっこむスタイル。よくある炎上と言うか認識齟齬が生まれやすいポイントについてお話します。
SaaSってサービスなんですよー？
Workspace ONEをはじめ、SaaS製品は名前の通りサービスの提供です。従来のオンプレシステムのような運用、とりわけログ監視・監査という考え方を維持することはおすすめしません。オンプレ思考のまま、SaaS製品に従来の運用を当てはめると多くの認識齟齬が生まれます。サービスを購入しているということをしっかりと受け容れることが肝要です。
スコープとコストについて
プロジェクトが進むにつれて、顧客の製品理解はより深まっていきます。運用系の製品によくある傾向ですが、要件や設計の変更を依頼したくなるでしょう。SIerは顧客に満足していただきたいという思いから許容できる範囲は努力しますが、コスト的にどうしても厳しい場合は別プロジェクトとして切り離すことをご理解ください。ぶっちゃけ、提案（受注）段階でバチッと決まっていれば問題ないのですが、前述の通りまずブレるのでこの点はご理解いただければと、はい。
SaaSだからすぐ使えるんじゃないの？
はい、これ結構勘違いされているケースが多いです。たしかに、使う「だけ」であれば申し込んで少ししたら使えるようにはなります。当然、なにも設定されていないですし、どう活用するかも決まっていないただの環境で良ければすぐに使えます。すべての作業を自らやれるスタイルであれば問題はありませんが、そうでない場合が多いと思います。そのために提案う受けてベンダーを決めるわけですし。で、きちんと利活用しようとしたら当然のように事前準備が必要になるわけですね。参考までに、よくある案件（PoC、要件定義、基本設計、詳細設計（パラメータ作成）、構築、試験、引き渡し、引継ぎ）でおよそ4-6ヶ月、５ヶ月程度見越していただくと良いと思います。要件によっては期間の増減はありますが、ほぼこんな感じです。
いかがでしょうか、意外と知ってるようで知らなかったなんて話があったのかなと。少しでも参考になったら幸いです。
今回の記事は、過去に何回かWebinarやVMUGでお話したものをまとめています。
興味がある方は以下動画も視聴してみてください。
0 件のコメント:
コメントを投稿