エンジニア
リスク管理で問題を防ぐ
リスクを察知して対策を打つことは、プロジェクトが失敗しそうな状況を未然に防ぐことができるので有効ですが、機能させるにはコツがあります。事前にリスクを見える化し、継続的にレビューして精度を高めます。
デジタル力で生き抜く!
リスクを察知して対策を打つことは、プロジェクトが失敗しそうな状況を未然に防ぐことができるので有効ですが、機能させるにはコツがあります。事前にリスクを見える化し、継続的にレビューして精度を高めます。
企画した商品やサービスを売れるものにするためのニーズ調査では仮説と検証が役に立つ。仮説を立てずに一から順に調べていたのでは効率が悪すぎるからだ。そしてその検証の際に自分という対象者を入れることでさらにスピードアップできます。
完璧な計画など存在しませんが、大事になるのは実現に不可欠なキーポイントを見つけ事前に実現性を検証することです。着手段階ですべての課題の解決方法がクリアされていれば、あとは時間をかけて作るのみです。見積段階で8割がた見通せていることが成否を分けます。
プロジェクトの規模を見極めたいのでとざっくりとした見積の提示を求められることがありますが、このときの開発期間やコストがそのまま利用されてプロジェクトが始まることがあります。それを防ぐためには見積の条件を明記して条件が変われば見積を変えられるようにしておくことで身を守りましょう。
開発中に仕様が最後まで変わらなければ非常に良いのですが、往々にして要求そのものが変わったり、仕様の矛盾を解決したり、業務の実態に適応させるために仕様変更は発生します。そのとき、仕様変更をきちんと管理して、なぜ・どう変わったのか、いつから変更したのかを記録することは大事な仕事です。
技術者同士の会話なら専門用語を使って話した方が正確で間違いのない議論になるのだが、非技術者に話すのに同じように専門用語を使っていては相手に伝わらない。正しく理解してもらうことが大事だから、難しい言葉を使わずにわかりやすく説明するかが大事だ。
進捗報告は得てしてやった作業をしがちだ。しかし上司が知りたいことは、その結果仕事が順調なのか、遅れているのか、遅れているけれどリカバリー可能なのか、といったことだ。遅れを起こさないためにも進捗報告をしっかりやって行くことが大事だ。
プログラマは初期の頃には簡単にバグ修正できても、テスト工程が始まった以降はそう簡単にはできません。バグの内容、原因、どのように対応するか、修正方法、修正後の確認とバグの管理を厳密に行わなければなりません。
顧客が望んでいるものを作るためにも、顧客の要求と開発するものを定義した要件書を常に紐付けて管理します。また、開発が進める中でも顧客の要望とズレていないかを日々確認することで、最終納品での顧客要望とのズレに気づくというミスを防ぐことができます。
開発を進めるに当たり、開発工程を守って進めていくことはとても大事です。その中でも成否を握るのが要求獲得の工程です。顧客の悩みを知り、それを解決することが求められています。要求の理解が間違っていると、できあがったときに問題が起きます。