開発工程に入ると、発注側としてはやや手が離れるため少し余裕が出てくるだろう。
しかし油断は禁物で、常に開発状況や問題の共有を怠ってはいけない。そして、この余裕がある間に進めるべきことがある。
開発工程で、発注側はどのように振る舞うべきかを確認していこう。
開発工程で発注側が行う主な作業とは
今後の工程やリスク管理の観点で考えた場合、やるべきことは多いため気を抜いてはいけない。
発注側が行う作業として、以下5つの作業は漏れなく行っておきたい。
-
1両社の情報共有方法とツールの決定
-
2開発進捗や課題・問題の把握
-
3アプリの正式名称・アイコンデザインの決定、商標申請など
-
4テスト工程の準備
-
5成果物の受け入れ準備
それでは詳しく見ていこう。
1.両社の情報共有方法とツールの決定
開発工程に入っても発注側が決断すべきことや開発会社と調整して進めるべきことは次々と発生してくるものである。
些細なことに見えるが、効率を大きく左右するため情報共有方法は前もって決めておきたい。
例えば、課題管理やタスク管理、デザイン画像や議事録、スケジュールの共有などである。
これらをエクセルやワードに記入し、諸々のドキュメントをメールに添付して共有することは避けたい。
メール添付での共有はどれが最新なのか、また、両社で編集した場合に余計なマージ作業が発生するなどの問題が発生する。
常に進捗、状況が変わる情報をリアルタイムで共有することが、プロジェクトをスムーズに進めるためのひとつのポイントである。
両社でクラウド上でドキュメント共有の場所を設けたり、課題管理やタスク管理は、多少お金をかけてもASPを利用したりするなど、効率的で透明性のあるプロジェクト運営をしていきたい。
今は便利なツールが揃っている。課題管理、タスク管理ツールは、開発会社が既に利用していればアカウントを発行して貰い、そうでない場合は新規に導入すると良いだろう。
タスク管理ツールで使いやすい製品としてはいかがおすすめである。
その他、開発会社がよく使っているものとしては下記がある。
これらのツールは導入することで、開発効率が格段によくなるので、社内のセキュリティ規定で導入が難しい場合であっても、セキュリティ担当者と相談・協議する時間を割いて、導入を検討すべきである。
2.開発進捗や課題・問題の把握
発注側が開発の進捗を知る主な方法は定例会議になるだろう。
ただし、開発会社からの報告が「予定どおりです」「進捗◯◯%です」というような形式的なもので満足しないように気をつけたい。
こういったアバウトな報告の場合、開発後半になってから急に問題が発覚し炎上するケースが多い。実質的な進捗を知るためには、以下のような工夫をすると良いだろう。
いずれにしても、一方的に要求するのではなく、両社にとってなるべく負担にならない方法で進められるよう努めていこう。
3.アプリの正式名称・アイコンデザインの決定、商標申請など
開発会社から見ると、正式名称やデザインは早く決定しておいて欲しいものである。
仮のものから正式なものに変える作業が大変という訳ではないが、開発時、ストア申請に関わる内部的な名称に使うことがあるため、決めれば済むようなタスクは後回しにすることなく早く片付けておきたい。
アプリの名称は既存のアプリと被っていないか、また、決定したアプリ名称が商標に触れていないかなどの調査も行っておきたい。
また、商標を申請する場合も早めに動いておいて損はないだろう。
4.テスト工程の準備
テストは開発会社が行うが、アプリ開発のクオリティを高めるには発注側のチェックが必須であり、発注側が全く何もせずにテスト工程の終了を待つということは、ほぼないといってよい。
多くの場合、発注側にもアプリをリリースしてもらい、アプリがどのような状況になっているか確認を行う。
そのため、テスト用の端末を用意したり、リリースタイミングを開発会社と協議したり、バグの報告方法を決めたりなど、開発工程の中盤から後半で行っておくとスムーズである。
5.成果物の受け入れ準備
これらの準備作業は、開発中盤以降には考え始めたいところである。というのも、テスト工程が始まると受け入れのことを考えてる余裕がなくなる可能性があるからである。
問題なく開発が進捗していれば良いが、この先どんな問題が発生するかは分からないため、できる作業は前倒しで行いバッファを作っておこう。
また、決定したことや調査を行ったことは、社内で共有できる情報としてWikiや共有ツールなどに残しておくことも忘れずに行おう。
以上、5つを紹介してきたが、開発工程で最も力を注ぐべきは「2.開発進捗や課題・問題の把握」である。
スケジュールを遅延させないために、発注側ボールとなるタスクは早々に片付けながらいち早く問題を察知し、解決のアクションを取っていこう。