人の振り見て我が振り・・・開発案件進行例
案件概要
某大学より学内にてWEBベースの入試要項の管理サイトを構築したいと要望がありました。
皆さんの進行上の参考になれば良いなという思いを込めて、プロジェクト進行時私が想定した注意点、重要点などをご紹介します。
要望内容
- WEBベースであること
- リテラシーの低いスタッフでも扱えること
- 誰が、いつ、どこを修正したか、明示的に確認できること
- 低予算での対応、ただし運用しながら拡張していくので、ミニマムスタートで良い
- 開発期間は先方の希望と予算面も考慮し、2ヶ月以内としました。
開発工程 ～概要～
- 基本システムの検討
- 複数の候補をピックアップし、メリット・デメリットとともに顧客に提案しますが、開発サイドの意向も含めて、スムースに開発できるシステムのメリットをアピールするよう進めます。
- テスト環境の構築
- 本番環境と出来る限り同等の環境にすることが最善ですが、OSやPHP、データベースのバージョンを合わせきれないこともありますので、バージョン誤差の知識を持って開発を進めることが重要です。
- ユーザビリティを含めたシステム仕様概要策定
- 既存システムを活用するため、カスタマイズ範囲を限定し、顧客と認識を共有することがトラブル回避に繋がります。
- リスクヘッジだけを考慮した提案の場合、顧客のワクワク感が薄くなるため、十分な満足度を持たせられない状況に繋がります。「出来ること」「出来ないこと」を開発サイドと意識を合わせて、顧客には「出来ないこと」を明確に伝え、「出来ること」では積極的な提案をすることで、進行時・納品時の顧客の満足度が大きく違います。
- 「出来ないこと」を伝える際、予算面、技術面での不可理由を伝え、予算面での対応不可要件については、しっかりと技術的裏付けを取り、次の提案に繋げることで継続受注の可能性を模索します。
- テスト環境での開発着手
- 進捗報告では定期的に作業報告をすることで顧客の安心感を維持します。テスト環境で閲覧させることも手段の一つではありますが、開発途中での閲覧は不要な要望や不安を抱かせる可能性があるので、十分注意して閲覧させるかを判断しています。
- 本番環境構築と移行
- テスト環境で顧客検証を行うこともありますが、今回の場合は旧システムが稼働しているなど、移行に大きな弊害がないため、プログラムのフィッティング確認も含めて、本番環境に移行することを進めました。
- 本番環境での動作確認
- テスト環境とOSバージョンなどに違いがあるため、その点を中心に確認作業を進めたました。
- 顧客による検証作業と調整作業
- ここで「3」で顧客と共有した完成イメージの共有精度が重要になってきます。本件の場合は全体的なイメージの温度差は少なかったため、大きな問題は起こりませんでした。一部「追加要望」として機能追加がありましたが、技術的にも対応可能だったため即対応しました。
- ここで重要なのは顧客が追加を認識した要望であると思います。現場は追加、顧客は仕様内という温度差がトラブルに繋がります。
- 納品完了
- 稼働後も操作などの質問や微調整、不具合などの対応を可能な範囲で行い、顧客にも納得感のある納品が出来たと思います。
顧客との完成イメージの共有
通常の開発案件の場合、仕様策定を綿密に行った上で開発着手するのですが、本件含めてWEB開発の案件には期間・予算面で仕様策定の作業を十分に行えない場合が多々あります。
限られた状況の中で完成イメージの共有をすることで、”理解”、”納得”を最低課題として作業を進めることを常に意識しています。
本件の場合、”ミニマムスタート”の完成イメージを共有すること、”ミニマムスタート”のイメージを共有することが本件のスムースな進行のキーワードだと考えました。
まずは既存システム活用によるデザイン的表現のイメージ共有、対応可能な機能拡張のイメージ、次の展望を顧客にイメージしてもらう意図として、拡張機能の技術的裏付けを取り、今後の拡張展望などを伝え、進行上、完成品の”不満”からくるトラブル回避と、継続発注への信頼を持ってもらうことを意識して資料作成と調整を進めました。
プロジェクトの進行は、強み弱みを理解した上で、双方が納得（出来れば満足）感の持てる演出も重要なテクニックになると思います。
システム検討
要望を踏まえ、スクラッチの開発よりもオープンソースまたは安価既存システムを流用する方向で検討をし、Mediawikiを採用を提案しました。
以下は検討内容です。
concrete5
環境：php+MySQL
ライセンス：フリー
参考：履歴の解説ページ
opencms
環境：Java+MySQL
ライセンス：フリー
参考：履歴の解説ページ
MTCMS
環境：MovableTypeをベースにプラグインとして機能拡張
ライセンス：有償
検討内容
”concrete”と”OpenCms”の２製品はカスタマイズも可能であることで最終検討まで至ったが、顧客が望む履歴表記とは方向性が違ったため不採用。
MTCMSはサーバーを含めた月額制の有償でため、コスト面で不採用。
結果、MediaWikiを採用し、構築を開始。
Mediawiki
Mediawikiとは
Wikipediaのために開発されたwikiシステム。
ライセンスはオープンソースであること、wikiシステムとしては、Wikipediaを代表例として成長・成熟されている。
不特定多数の編集を意識しているため、履歴表記方法に工夫があり、今回の案件ではその点が採用決定の大きな要因となりました。
環境：
※今回はMYSQLにて構築
採用理由
明確な履歴機能
- だれが、いつ
- どこを
要望を一通りクリアしていることが採用理由となりました。
テストサーバー
OS：centos5
言語：PHP5.5
データベース：MySQL5.5
本番サーバー
OS：centos6.6
言語：PHP5.3
データベース：MySQL5.1
苦労話
「リテラシーの低いスタッフでも扱えること」が、要望の大きな課題でした。
そこで入力を簡略化できるよう、情報毎にテンプレート化し、HTMLを意識せず、如何に情報のみを更新できるようにするか、を考慮し作業を進行しました。
今後の課題
運用時の更新状況を見ながら、入力方法の簡略化とユーザービリティの向上
現時点では開発サイドでも検討・実行されたユーザービリティになっているため、実運用の中での要望などに対応する。
開発期間などの課題から深いところまでの開発着手が出来ておらず、現在はテンプレート化に対応し、特殊タグを意識せずに出来る限り編集対象のテキストに集中できるよう考慮しましたが、まだまだ検討の余地は残っていると思います。
今後は拡張開発をするなど、編集機能の充実を提案できればと考えています。
印刷用データへの吐き出し
最終的な大学の希望は、毎年発行される入試要項冊子の印刷データとして成立させることです。この対応により年度編集の管理をシステム化してきたいと考えています。
技術的な課題として、ＣＳＭの吐き出し、PSDにて印刷時のレイアウトまで構成した吐き出しなど、印刷会社と意見調整をして進めていく必要があります。
デザイン的な表現力の拡大
Wikipediaを対象に開発されたシステムですので、デザイン的表現の検証を進め、Wikipediaライクなデザインから脱皮させることが出来れば、情報管理ツール以上に公開情報としてのメリットも創出できるのではないかと考えています。
転用の可能性
社内用マニュアルアーカイブなど情報の集約など
ビジネス用途で考えた場合、デザイン的にはWikipediaと同等になるため、社内活用が良いのではないかと思います。
不特定多数が編集に参加でき、且つ「誰が」「いつ」「どこを」が管理できるツールとしては非常に魅力的なシステムだと思います。