中堅ソフトウェア会社でプログラマー歴7年の者です。最近になって顧客先へ行って設計書作成や試験計画の打ち合わせやその為の資料作成などの上流工程を行う業務が多くなってきました。ただ、私の会社ですとプログラマーでもSEでもあまり給料面の待遇が上がらないので、ひとまず上流工程業務を何度か経験したらSier企業へ転職をしたいと考えております。
私のこれまでの業務はプログラムしかほぼ経験をしてなく、また私の会社自体が開発の下請けが多い業務の為、設計より前の段階で行う作業をどのように行えばいいのか分からず不安を持っています。
顧客先でどのようにヒアリングして業務分析を行い、業務要件をまとめシステム要件に落として設計へとつなげるのかヒアリングの仕方と方法が漠然として分かりません。
上流工程を専門にしているSierで働かれている方はどのような事を顧客先ヒアリングで大事にされていますでしょうか。またその後の設計フェーズ、試験フェーズで要件の漏れがないように要件定義を作成する際に意識されているのはどのような事でしょうか?
質問
Sier業務での大事なポイントを教えてください15view
最新の専門家コラム
- 40代女性が転職で今後10年20年働ける職場を見つけるには?【リクルート出身者監修】
2022.05.16
- 転職市場で信仰残る「30歳限界説」は今どうなっているか?
2022.04.12
- 合格可能性を上げる「志望動機」の書き方3ステップ
2022.03.08
- 転職エージェントと2人3脚で転職を成功させる方法
2022.02.06
- 会社にバレずに転職活動を行うテクニック
2022.01.07
質問に回答するにはログインしてください。
回答
2件の回答
現職Sier会社勤務のPM経験者です。要件定義時にいかに、要件漏れを出さないようするかはPJの成功可否に直結する事が多いのでとても大事ですね。
経験上多いのは、開発スタート後の途中工程では、多少の要件定義に記載してないお願いをしても下請けベンダーさんも結構快く対応してくれますが、納期近くなると手のひらを反す事が多く、お願いしても聞いてもらえないですね。要件に書いてないので対応不可と言われたり、仕様変更の追加料金を要求されたり、作りたかった操作性のシステムとは違う中途半端なものができてしまったり、品質が悪いバグが潜んだものが出来上がってしまったりとなります。
そのような事がないようにするために意識するといいのは、明確にシステム要求を記載しないでも大丈夫な個所はブレ幅を持たせて記載しておくことですね。例えば操作性にユーザビリティが考慮されてる事などと一言記載しておく事で後から仕様変更と言わせないための布石を入れておくのは一つの手です。非機能要件などに思いつく要件を記載するのがいいでしょう。
また、デザイン系など出来上がった時にイメージが違う事が多くでるものに関しては、設計段階では仮合意として実機で確認できるタイミングで最終合意とする事などとして変更可能な要素入れておくといいと思います。
他のポイントとしては、試験をする際に行いたい試験が別途環境準備をしないとできないなどがあるので、この時点で受入れ試験で行いたい項目を検討しておき、試験環境構築などの要求も記載して置くこともしておくといいですね。その他にも、品質報告や詳細設計書などを納品物としたい場合はその事も記載しておいたり、試験フェーズで異常系試験や性能試験等をベンダー側で実施を行うことなども記載しおくのがいいかもしれません。
必要に応じて、要件定義に記載するのか、見積もりに記載するのか、別資料として記載するのか、いずれにしろ開発初期までに明示化するのが大事ですよ。
某大手独立系SIで10年働いてます。業務ヒアリングは難しいイメージがありますよね。
まずはお客様の要望を大まかに確認した後に、現状の業務でシステム化されてない業務の洗い出しや、システム化されていても効率が悪い業務を洗い出すのが大事ですよ。
その為には、まず現状の業務フローをつくるためのヒアリングを行うといいと思います。業務フローは色々なパターンで別れるケースが多いのですべてのパターンを網羅できるように細かくヒアリングが必要となります。
現状業務フローが出来れば、前述したシステム化されていない業務と、効率が悪い業務が可視化されますので、システム化が可能な個所と、業務効率化による生産性向上、工数削減、費用削減などの業務改善提案を行う事へとつながります。
ここまでいくとこれらを業務要件としてまとめ、どのようなシステムを作りたいかのシステム要件としてまとめられるようになっていきますよ。