前回、前々回でWEBサイトの作成やリニューアルを記載してきましたが、今回はその他のコンテンツとシステム編。
そんなに経験ないんで、内容は薄いです。そして、文字数や内容の量でくくり方がおかしいのは反省。
コンテンツ作成・編集
動画
- ヒアリング
- 絵コンテ？
- 打ち合わせ
- 撮影
- 編集・加工
- アテレコなど
- 提出
- 校正
- 校正対応
- 再提出
- 検収
- 納品
ページ追加
- ヒアリング
- タイトルや何を掲載したいのか、何のページで、どこにつなげていきたいのか、を確認
- 制作スタート（見積もり再提出もあり得る）
- 制作
- 原稿作成・素材の準備（クライアント）
- 取材や撮影、原稿作成・素材の準備
- 提出
- 校正
- 校正対応
- 再提出
- コーディング
- デザインOK出るまで画像でいくか、途中からコーディングやってしまうかは状況に依る。
- 提出
- 検収
- 納品
システム開発
データベース構築
ヒアリング
- どんなシステムを構築するかで随分かわるし、中身の構造の話のため、お客さんのほうは理解がしづらい。
- 出来れば、エンジニアなど、システム構築担当を一緒に連れて打ち合わせに臨んだほうがいい
- 外注先を使うのであれば、外注先に今回の案件と似たようなシステム構築の経験があるかどうかを確認してからのほうがいい。
- 何のデータベースなのか？
- どういった利用を想定しているのか？
- インポート機能は？
- エクスポート機能は？
- 帳票印刷などドットプリンタなど特殊な印刷機を使用するか？
- どういった機能がほしいのか、漏れ無く確認する権限の種類データ構造の確認どういった情報がどういった流れでどこに反映するのか？
- 外部連携はあるのか？
- サーバーなど環境は？
- ヒアリング例
- 会員サイトの運営の場合で、会員の位置づけはどのようなものか？
- 会員メリットは？
- 会員システムの課題は？
- 課題に対して何か対処は？
- 現在の会員数は何名？
- 目標会員数は何名？
- 個人会員/法人会員の区別は？
- ある場合はその割合はどの程度？
- 個人会員/法人会員においてサービスの内容は？
- 個人会員/法人会員のサービスの内容はどのように変わりますか？
- 個人会員/法人会員の募集（取得）方法は？
- 入会数は一カ月何名程度？
- Webサイトからの入会を他媒体で広告している？
- 会員のログイン数は？また、アクセス数に対する割合はどの程度？
- その他/ご希望/ご要望（機能等）/備考欄/RFP
- RFPとは「Request For Proposal」の略で「提案依頼書」という意味です。「情報システム（Webサイトも含む）を導入するにあたって、ユーザーが納入を希望する制作会社やシステム会社に提供する、導入シ ステムの概要や調達条件を記述した文書」。
UI設計
システムの内容に気を取られているとUIが結構おざなりになる。UIもきっちりデザインしないとすごく使いづらくなる。システム会社はシステムが専門であって、UIまではプロではない。
要件定義
システムの要件定義はWEBサイトの要件定義の比ではなく、それこそ各画面一つ一つの機能の確認や仕様確認。クライアントから曖昧な回答で開発に入ると痛い目に合う。
作業範囲表
作業項目を洗い出し、クライアント側の作業と開発側の作業を項目ごとに記載し、こちらの作業範囲を決める。お互いに「向こうの作業だ」という思い込みで進むと後々で大問題に発生する。
プロジェクト体制図
開発の体制図を作り、誰がどの分野の作業を担当するのかはっきり決める
見積書提出
見積書には必ず有効期限を設けておき、有名無実となっているが、書面での契約は有効なので、再見積もりで金額の改定は出来る。
契約書提携
上記の内容で問題なければ、支払いのタイミング、品質、著作権、トラブル時の対応、などを確定させて契約書を交わす。
案件ごとに契約を交わすなんて大仰な、と思うかもしれないが、宣伝広告業界がむしろ異常であり、通常、商取引は全て契約の上で成り立っている。クライアント直接の場合は契約書を交わすことに抵抗を示さないが、代理店が間に入ってる場合は契約書を嫌がることが多い。
クライアントが遠方の場合、裁判所は地元の地方裁判所にしておくと便利
契約書は通常、請け側の我々が作成する。それに契約書を作成する側は契約書に有利な条件を記載してしまえばいい。通るか通らないかは出してみないとわからない。
クライアントが原稿全然出さなくて、開発が途中で止まってるけど金額を回収したい場合など、見積もり期限と契約書を絡めて、「契約書に記載してありますが、見積もり有効期限が過ぎてますので、再見積もりとさせていただきます」とか「これまでの作業分を請求させていただきます」とか「納品とみなします」など、強制的にプロジェクトを進めることも出来る。ただし、すんなりと払わないし、それなりに協議のテーブルに何回かつかなければいけない。
開発開始
- 同時進行
- UIデザイン提出
- 校正と校正対応を繰り返す。
パートごとでの開発
よくあるのが部分ごとでの開発で、パートごとで開発をおこない、最後に各パートを結合する、という進め方をすることが多い。
アルファ版
アルファ版とは、バグを抽出するために仮組みしたシステムであり、自社内チェックのための状態。パートごとでおこなったり、少数の画面連携でおこなったり、そのときの状況にも依る
インシデント表作成
アルファ版で見つけたバグを記載し、潰していく
ベータ版
クライアントチェック用で、アルファ版で見つけたバグを潰し終わって、クライアント側で実際に使用してバグや不具合をチェックする。もちろん、これもインシデント表を作成する。
テスト版
ベータ版は納品直前の状態というところもあるが、実際にはそんなうまくいかない。打ち合わせで漏れてた部分や予期せぬバグなどは必ずある。システムの納品の前にクライアント側に操作に慣れてもらう期間をつくること。納品したところで、いきなり使えるものではない。
検収
最終版を触ってもらって、現場での使用レベルに達しているか、支障がないかをチェックして検収書に捺印をもらう
納品
フォロー
- 必ず納品後に予期せぬバグ、特殊事例時にしか出てこないバグなどが必ず見つかる。
- そのため3～6ヶ月ぐらいはフォロー対応期間を設ける
だから、それも見込んでの見積もりを。 - フォロー期間終了後は保守費をいただくことを忘れずに保守は保守で別途契約書を交わすこと。
- その契約書には必ず、作業範囲を明記しておくこと。
- システム開発案件に関しての注意事項必ずといってもいいくらいに納品後にバグは見つかる。
- 予め、それは伝えておくべきだし、一般論として、納品後にバグは見つかるものぐらいで。
- もちろん出来る限りなくすべきだが。
アプリ開発
ヒアリング
システム+WEBサイトの内容
モバイル環境の制約もあるため、かなりシビア
審査もあるため、審査内容も把握しておかないといけない
スポンサーリンク