ちょこっとぶりの登場です、プロジェクトマネージャーの間藤です。
「一年の計は元旦にあり」では、プロジェクトの計は？
私ならプロジェクト計画と答えます。
アプリ開発のプロジェクトにおいても、計画がどこまで詰められているかによって、プロジェクトの結果が大きく変わってしまいます。
最初から「全ていい感じに」でいってしまうと、手戻りによるスケジュールの遅延や予算の超過、認識違いによる顧客とのトラブル発生、納品を受けてもらえないなど、ただでさえ炎上しがちのプロジェクト、準備ゼロだと必ず炎上してしまうでしょう。
「でも、何をどこまで決めればいいの？」という方もいらっしゃると思いますので、参考までに私がプロジェクトを開始する前のプロジェクト計画で何を決めているか紹介します。
この記事では架空のプロジェクトを想定して書いていきます。
目次
その１. プロジェクト体制
Point 1. 顧客の体制図も書く
よくあるのが自社の体制だけを書くというものですが、プロジェクト関係者を全員分書きましょう。特に今回のプロジェクトのように、アプリとAPIで会社が異なる際はなおさら明確にしておきましょう。
Point 2. 決裁権の明確化
担当者から確認OKをもらえていたが、実は決裁者の確認がまだで、手戻り発生！なんて事ありませんか？きちんと「誰に承認をとればOKなのか」確認しておきましょう。
Point 3. 窓口は1つにしてもらう
担当者A：ここのボタンのサイズは小さいから大きくしてください。
担当者B：ここのボタン、重要ではないので、このサイズのままでお願いします。
担当者C：ここのボタン不要なので、削除してください。
って、言われたらどうしますか？
「言っている事バラバラなんですけど！」
ってなりませんか？最悪の場合、「私たちの意見をまとめてください」なんて事にもなりません。
ですが「そのまとめるお金もらっていますか？」
後から、問題にならないために、最初に決めておきましょう。
泣きを見るのは我々です。
その２. 成果物の動作サポート環境
Point 1. ターゲットユーザーが利用するOSを確認しよう
例えば、業務アプリで、アプリを利用する端末のOSのバージョンが全て最新ということを分かっていれば、最新のOSのバージョンを書きましょう。プロジェクトにおいて予算と納期は決まっています、使われないOSを想定して実装やテストほど無駄なものはありませんよね？削りましょう。
Point 2. 開発で利用するフレームワークのバージョンを確認しよう
例えば管理画面系で有名なCSSフレームワーク、AdminLTEを利用するとしましょう。サポートしているブラウザやバージョンは確認していますか？もしかすると、CSSフレームワークが顧客の希望する動作サポート環境外のことがあるかもしれません。そうなったら大変です、CSSフレームワークを上書きして修正しないといけない、なんてことも。。。
ちなみに、AdminLTEのサポートブラウザと端末はこちらから確認できます。
Point 3. ターゲットユーザーが一般ユーザーの場合にはシェアを確認しよう
業務アプリと異なり、ターゲットが一般ユーザーの場合には、シェアを確認しておくのがオススメです。
世界中のiPhoneユーザーがターゲットの場合にはAppleの公式サイトを確認しましょう。
日本のiPhone・Androidユーザーがターゲットの場合には、こちらのサイトがオススメです。
世界中のAndroidアプリのシェアはGoogleの公式サイトで確認しましょう。
Point 4. 低いバージョンを採用するデメリットを考えよう。
Point 3でOSのバージョンシェアの話をしましたが、低ければ低いほどパイが取れるというメリットに対して、古いバージョンをサポートすることで、例えばAPIが利用できないや、古い端末での不具合にハマる・テスト・バグ修正の工数が膨れ上がるというデメリットがあります。
シェアが少なければ基本的には削りましょう。顧客への案内として、類似アプリや今流行のアプリのサポートバージョンを引き合いに出して話すと承認が得られやすいです。
その３. プロジェクト作業範囲
上記については、初回のお見積もりの際などにもヒアリングにて明確にするのが普通ですが、担当レベルでしか共有できていない場合もあるのできちんと共有します。
プロジェクト関係者全員で認識を合わせるために、各社の作業スコープを明確にしておくことが重要です。
その４. 確認と戻しの期間について
中間成果物・納品物について顧客側の確認にどのくらいの日数が必要にあるのかはとても重要です。
特に、顧客は本プロジェクトに関することに全ての時間を使えるわけではありません。場合によっては展示会に参加などで全く確認が取れない期間が発生することもあります。
これらの情報をきちんとヒアリングした上でスケジュールを立てましょう。
その５. コミュニケーションプラン
Point 1. ツールのメリット・デメリットを意識して利用する
表の通りです。
Point 2. 電話や会議のあとには必ず記録を残す
「言った・言わない」問題が後で発生します。
また、プロジェクトメンバーや新規で入るプロジェクトメンバーも理解できるように、きちんと記録を残しておきましょう。
その６. キックオフMTGのすすめ
プロジェクト計画は作って終わりではありません。プロジェクト関係者全員で共通認識を持つことが重要です。
そのための手段として、キックオフMTGの開催をオススメします。
自分達にとっては見慣れた計画書であっても顧客にとっては、初めて見るフォーマットであり、ツールも同様です。
きちんとキックオフで１つずつ読み合わせを進めていくことで「読んでいませんでした」ということも防げるので、必ず実施しましょう。
まとめ
最初にどこまで決めておけるかで、プロジェクトがスムーズに進むか、予算の超過や納期の遅延になるかが決まります。
決めていなかったことが原因で手戻りが多発するとプロジェクトメンバーのモチベーション低下にも繋がります。
これからプロジェクトマネジメントをされる方は、ぜひこの記事を参考にしていただければと思います。
「プロジェクトの計はプロジェクト計画にあり」
