見積の時点で機能の想定に漏れがあると工数が増大する
見積時点で機能が洗い出せておらず、始まってから想定していなかった機能に対し、工数が増大することがあります。
そこでせめて、最低限のチェックができるようにと観点表の作成を始めました。
見積時点でこのくらい考えておきたいと思っている内容です(どこまでできるかは期間に応じてですが、、、)。
設計にも使えるかと思うのでQiitaにメモとして残しておこうと思います。
何か書籍を参考にしたわけではないので、間違いや自分はこうしているというものがあれば
コメントいただけると幸いです。
新規システムの場合
全体に関わる部分や共通ルールの検討をするための時間を見積もりに忘れないこと。
具体的には下記作業を想定する必要がある。
(似たようなプロジェクトがあれば、それを流用することも想定可能)
業務フローを理解できているか
業務フローと業務化する対象範囲を把握し、要件に落とし込む。
この時に実現方法にとらわれる(ユーザが望んだ機能をそのまま実装する)と
本来の目的から遠ざかったり、効率の悪い機能になる可能性があるので
純度の高い要求を導き出すこと。
フレームワークや言語の選定
現場で利用したことのある言語か否か、PJメンバーの習熟度により、
実装方法の検討時間や、チートシート(各々に好き勝手に実装されると、品質が担保できなくなることの対策)の作成が必要となる
開発ルールの制定
ソースレベルでの品質をどのように担保するかの決定
レイヤーアーキテクチャ等の設計思想をPJメンバーへ教育する必要があるかどうか等の教育工数も検討すること。
メンバーのレベルと期間によってはルールは最低限にし、品質とコスト・納期でトレードオフの関係となる。
システム全体のルールの制定
システム全体での
エラーの扱い方、ログの出力粒度、バリデーションをクライアント・サーバ両方で行うか否か
同時実行制御をどこまで厳密に行うかを検討する。
これも、品質とコスト・納期でトレードオフの関係となる
レビュールールの決定
品質レベルとレビューをどのフェーズ(設計、実装、テスト)で行うか
メンバーのレベルによって検討すること。
また、この時にソフトウェア等を用いて、人手で対応する箇所を減らす工夫も検討したい
非機能要件の確認
顧客により、非機能要件を提示してこないこともあるので
見積前にどこまで何を担保しなくてはいけないのか確認が必要
セキュリティレベルの確認
認証方法やロールベースアクセス制御の仕組みを検討する
ユーザの種類がどのくらい存在するか
管理者、一般ユーザ、システムユーザ等
顧客の種類により権限管理の難易度が変わってくる
ユーザ毎に機能の挙動を一定のルール化しておく
ここでいうユーザは、開発者用ユーザー、顧客用ユーザー、システム利用者用のユーザーのこと
顧客用ユーザーはすべての機能、システム利用者の情報が観れる等
一般的な機能の漏れ確認(検討事項の洗い出し)
提示された要望の業務プロセスが理解できているか確認
各機能に過不足なくCRUDすべて用意されているか
登録する機能は存在しているが、削除する機能を忘れていた等を防ぐ
(ex) フォルダのアップロード機能に対し、フォルダの保存期間の設定等。
保存期間が必要であれば、削除用のバッチやその他仕組みが必要となる
各機能の同時実行制御(排他制御)の検討
複数ユーザが同時に機能を利用した際に、同時実行制御の仕組みが必要か否かを検討する
編集機能の同時実行制御
画面の表示から更新の間に他のユーザが更新する可能性が存在する。
更新時に再度サーバ側でデータの取得を行い、更新可能な状態か判定を入れることを検討する。
更新可能な状態はシステムによって異なり、判定後の処理もシステム次第
- ex.
- そもそも編集機能のある画面へのアクセスを1人に絞る
- 編集完了時に他の人が更新したので更新できません。とエラーを出す
- データ更新を後勝ちにする(同時実行制御を行わない)
- リアルタイムに反映されるようにする(同時実行制御を行わない)
各処理に対するユーザへのフィードバックが考慮されているか
読み込み時の画面表示等
各機能に対する「戻る」「取り消す」処理が考慮されているか
ユーザが操作ミスした際に簡単に処理を元に戻せるようになっているか
非機能要件が考慮されているか
表示時間等を考慮しなくてはいけない機能(検索等)は、チューニング等必要になる可能性を考慮する
ユーザ側に履歴やログを見せる必要があるか
顧客側から要件として漏れている可能性もあるので確認しておく
既存のデータに手を加える機能かどうか検討する
既存機能への影響調査の期間の工数をとるか検討すべき
脳内でロールプレイしてみる(時間に余裕がある場合)
実際に現在想定している機能を複数の種類のユーザで操作することを意識し、業務フローを確認する。
メール送信機能がある場合
メール送信がリアルタイムか、非同期か検討
バッチ等を使って送信するのか、操作に対しすぐに送信するか検討
メール送信失敗の検知が必要かどうか
宛先が存在するかどうかや相手先に届いたかを検知する(バウンスメールの解析)のは多く工数がかかることを念頭に入れる
顧客へ必要か絶対に確認すること。
上記検知の機構のあるなしで迷惑メール対策のレベル感も変わってくる
メール送信失敗時のリトライ検討
メール送信失敗時のリトライ機構の検討
(リアルタイムであれば、ユーザ側で再操作など)
迷惑メール対策
どのくらいのレベルで必要か。
存在しない宛先への大量送信や、一定期間での大量送信により
迷惑メールと判定される可能性があるため対策が必要
メール送信数の制御
メールサーバの負荷対策の意味合いもあるが、迷惑メールに分類されないための対策としても必要
しかし、各キャリアは迷惑メールの判定方法について公開していないので、
既存のシステムを参考に設計するしかない
バウンスメールの解析
届かないメールアドレスの大量にメールを出していると迷惑メールと判定されてしまうため
定期的なメールアドレスのクリーニングが必要になる。
そこでバウンスメールの解析により下記内容を確認し対策を行う
・存在しないメールアドレス
・メールサーバのダウン
・受信者側の受信トレイの容量不足
一覧表示機能がある場合
表示・読み込み方法を検討する
ページングを用意するのか、スクロールに合わせて遅延読み込みするのか
表示上限を検討する
- 表示・読み込み方法に合わせて、一回で表示する上限について検討する
一覧表示にどんな機能が必要か検討する
ここは表示速度にも関わってくるので非機能要件とともに、どこまで作りこむか見当が必要
- 検索機能
- 検索項目により検索が遅くなる可能性もあるので非機能要件含め要注意
- フィルター(検索よりも簡易的なやつ)
- ページング
- ソート
一覧表示されることや検索等されることを意識してデータ構成を検討する
- タグ付けできるようにしフィルター機能を実現する等
初期の並び順を検討する
業務フローやどのように利用されるかを検討し、初期表示の想定を行う
増減できる機能(項目を増やす減らす)がある場合
上限や下限を定義する
(1件は必ず必要なのか、0件も許すのか)
上限や下限での処理を検討する
ダイアログを出すのか、増減用のボタンを非活性・非表示にするのか等
増減両方を考慮していることを確認
増やす操作だけ考えて、減らすときの操作を検討から漏らしてしまったことがあるため注意
添付機能がある場合
クライアントサーバ間の受け渡し方法が検討されているか
複数添付可能か
1つずつアップロードするのと、複数一括でアップロードするのでは
一括アップロードが難易度が圧倒的に高くなる
ユーザの利用OSが考慮されているか
WindowsやMacが混ざっていると文字コードや各OS用の対策が必要となる
クロスブラウザが考慮されているか
IEが対象に入っているか等で実装方法が変わる
ファイル名の保持方法の検討
論理的にDB等でファイル名を保持するのか、アップロードされたファイル名をそのまま利用するのか
格納先の検討
同じファイル名が上書きされないよう、フォルダは一意になるように生成する等検討する
バッチ機能がある場合
起動のタイミングの検討
エラー時の検知・アラート方法の検討
エラーハンドリング方法が変わる。ログに出すのかメールを出すのか等
リカバリー方法が検討されているか
エラーが発生した際に、途中から再実施できるようにするなど考慮が必要
他システム連携が存在する場合
連携先システムからエラーが返ってきた際のハンドリングを検討
連携先の項目や形式、桁数が分かる資料を受領済みであるか考慮できているか
双方の認識のずれはお互いにダメージがでかいので、綿密な確認が必要となる
機能(ロジック)に悩んだ場合
悩むということは必要以上に難しくなっている可能性がある
過剰なユーザへの新設設計になっていないか
そのせいで動作が遅くなる等ほかの問題が生じている可能性もあるので
トレードオフを考慮し、顧客側と調整すること
必須ではないと考えられる新設機能は複雑になるくらいであれば、捨てる勇気を持つ
ロジックが複雑になる場合は、画面の想定や機能自体がよくないことを疑うことも必要)
全体として確認すること
実装を考慮した際に複雑な機能になっていないか。あまりイメージの湧いていない機能が存在しないか
該当機能は見積もりからのブレも大きくなりがちなため、仕様が簡潔になる代案を提案することや
バッファーを多めに設けておく等検討が必要となる
今後のメンテナンス性を考慮できているか
ユーザの利便性を重視しすぎて、一つの機能へ複数の処理が入っているケースにおいて
1つの機能が他複数の機能へ影響を与えるような構成になっていないか注意する。
メンテナンス性と機能の利便性のトレードオフを考慮し、
メリット・デメリットをまとめ顧客側と調整する必要がある。
メンテナンス性が悪い = 障害発生率が上がる = トータルとして機能の利便性が下がるという考え方も出きる
改修による影響範囲を確認できているか
影響範囲を考慮していない場合、コストのブレが当然ながら大きくなる。
見積時間がなく、洗い出せない場合は調査期間をコストに入れることで、大きなブレによるプロジェクトの炎上を防ぐ必要がある
随時更新していこうと思います。