こんにちは。やまさんです。
いつの時代でもSEを悩ませる
仕様変更・・・
なんで仕様変更は発生するのでしょうか。
この記事ではSEを悩ませる仕様変更が
なぜ発生するのか分析していきたいと思います。
目的と達成基準を決めていない
突然ですが、あなたは参画しているプロジェクトの
目的と達成基準を答えられますか？
達成基準は設計書に書いている機能を
実装することじゃないの？
その先がもっと大切なんです。
システムはお客さんとっては、
何かの目的を達成するための手段です。
逆に言うと、手段でしかないんですよね。
システムを導入することで何を実現したいのか。
実現するとはどういうことができていれば、
実現したといえるのか。
これが大切になってきます。
- プロジェクトの目的
システムを導入することでお客さんは何を達成したいのか - プロジェクトの達成基準
システムを使うことでお客さんがどういう状態になれば目的を達成したと言えるのか
目的と達成基準がプロジェクト序盤、
特に要件定義の段階で決めれないと
プロジェクト中盤や後半になって
仕様変更が発生してしまいがちです。
要件定義工程はお客さんとプロジェクトの目的、
プロジェクトの達成基準を決める工程だと
言ってしまっていいでしょう。
それぐらいプロジェクトの”目的”と
”達成基準”は超重要です。
なぜかというと、要件定義工程で決めた
”目標”と”達成基準”はプロジェクト全体が
進む方向性になるからです。
でも、意外に”目標”と”達成基準”を
答えられないSEは多いの現実です・・・
お客さんが仕様変更を出す理由は
以下が大半を占めます。
- 出来上がったシステムが自分たちの考えていたシステムではなかった。
- お客さん自身がどんなシステムを作ればいいかプロジェクト初期で分かっておらず、プロジェクト後半なって気づいた。
やまさんもSEです。
そんな仕様変更を過去に
何度も受けた経験がありました。
何度も徹夜で対応しました。
仕様変更を受け徹夜して作った機能が
さらに仕様変更が発生して
なくなったこともありました。
→２回目の仕様変更で１回目の仕様変更が
なかったことになったという意味です。
すごい落ち込みますよね^^;
絶対に仕様変更は受けない。
その決意を貫き通せればいいんですが・・・
プロジェクトマネージャーなどの会社の上位層が
”受ける”と決定してしまった場合、
どうしようもないですよね。
お客さん側からしてみても、システムは
完成するまで全体が見えにくいものですし、
工程が進んでから仕様が分かることもあるので
ゼロにするのは難しいのです。
ただ、仕様変更はプロジェクトを炎上させる火種、
デスマーチのきっかけなので
極力、防がないといけないです。
仕様変更を防ぐためにはシステム導入の目的と
達成基準を考える必要があります。
システム導入の目的と達成基準の考え方
お客さんが考えるものじゃないの？
それだと仕様変更を嵐はやまないから
考え方を説明していきますね。
最初に注意点だけ言っておくと、
システム導入の目的と達成基準は
お客さんにしか設定できないです。
ただ、SEがこれを予想できるか
できないかで言うと・・
できます。
特に達成基準は論理思考という思考法を
使うと考えやすいです。
論理思考
物事を構成要素に分解し、要素を分析して組み立てる思考法
ロジックツリーで考えると分かりやすいですね。
ロジックツリーの一番上の部分が”目的”です。
その下に達成基準というツリーを
作っていきます。
今回はこのままだと抽象的すぎるので
例を出してみたいと思います。
具体例で論理思考の使い方を解説
例えば、小売業のお客さんがスマホアプリを導入して
アプリからユーザが商品を買えるようにしたい、
と考えていたとしましょう。
まずはシステム導入の目的を考えます。
今回の目的はスマホアプリという
”販売ルートを増やすことで売上アップを目指す”
という分かりやすい目的が立ちそうです。
では、次に達成基準を論理思考で考えます。
スマホアプリで商品を購入してユーザのもとに
商品を届けるためには最低でも以下のことを
達成する必要がありそうです。
①スマホで商品を閲覧できること
②スマホで商品を購入できること
③ユーザが購入した商品を小売業のお客さんが
ユーザのところまで発送すること
達成基準はシステムを使う人が
どんな操作を行うか順を追いながら考えると
考えやすいです。
これではあらすぎて不十分なので
さらに構成要素を分解します。
「①スマホで商品を閲覧できること」を
分解してみましょう。
- カテゴリ分けされた商品の一覧を
画像付きで閲覧できること - ユーザが入力した文字で商品を
検索できること - 値段などの商品の詳細情報を閲覧できること
- 現時点の在庫状況と購入した場合の
予定お届け日を見れること - 口コミ情報を見れること
- ユーザと似た属性の他のユーザが
閲覧している商品が見れること - おすすめ商品が見れること
他にもありそうですが、長くなりそうなので
ここでストップしておきます（笑）
見ていただきたいのは下２つです
- 口コミ情報を見れること
- ユーザと似た属性の他のユーザが
閲覧している商品が見れること - 小売店のおすすめ商品が見れること
これは必要な機能なのでしょうか。
お客さんに聞いてみないと分かりませんが、
今回のシステム導入の目的が
”販売ルートを増やすことで 売上アップを目指す”
なのであれば、達成基準に含まれる
必要な機能である可能性が高いです。
当然ですが、商品を買ってもらわないと売上は
アップしませんよね。
売上をアップさせるような機能（要素）は
実装するかしないか、要件定義の段階で
決めておく必要があります。
逆に言うと、こういった要素が
プロジェクト後半での仕様変更、仕様追加に
つながります。
実際の開発だと、そこまで開発すると
要員やスケジュールの関係で開発できない、
といったケースもあるでしょう。
ただ、要件定義工程、
つまりプロジェクト序盤の段階でお客さんへ
伝得ておく場合と、
プロジェクト終盤の土壇場の段階でお客さんから
言われる場合とでは大きく差が出ます。
プロジェクトの序盤で分かっている場合、
実装するには追加費用や期間が必要であることを
あらかじめ伝えて記録しておけば、
プロジェクト後半でモメても
少なくとも交渉材料にはなるでしょう。
そういった機能は次回開発にまわす、というような
交渉もできるかもしれません。
まとめ
この記事では以下の解説しました。
- 仕様変更が多いプロジェクトの特徴
→システム導入の目的と達成基準を決めていない。 - システム導入の目的と達成基準
→お客さんヒアリングで決めておくことが大切 - システム導入の目的と達成基準を決めるには
→論理思考という思考法が有効
いかがでしたでしょうか。
仕様変更を防ぐにはITスキルよりも
今回紹介したような論理思考などの
ビジネススキルが重要になってきます。
仕様変更をとめられるようなビジネススキルを持った
SEはとても貴重です。
論理思考を身につけて実践することで
仕事がデキるSE、そして・・・
高給取りのSEになりましょう！
それでは！！
最後に（おまけ）
ボクは新人の頃、部署内でも有名なポンコツエンジニアでした^^;
プログラミングなど、ITに関するスキルが壊滅的だったのです。
ですが、今となっては社内で最短昇格を達成し、ボーナスも6回連続最高評価を達成しました。
こう言うと、なかなかの怪しさですよね（苦笑）
ということで、やまさんのエンジニア人生をプロフィールとしてまとめてみました。
ITスキル壊滅だったボクがどうやってエンジニアとしての活路を見つけたのか、気になる人は見てみてくださいね^^
プロフィールを読んでもらえれば察してもらえると思いますが、ボクはITスキル平凡な凡人SE。
めちゃくちゃプログラミングができるなど、特別なITスキルは持っていないです。
そのためか、昔は
- エンジニアになったはいいものの、IT技術に関して興味を持てない…
- 平凡なITスキルしかもってないのにエンジニアとしてやっていけるのだろうか…
- IT技術を身につけていくだけでエンジニアとして食べていけるのかな…
- 移り変わりの早いITの世界で永遠とIT技術の勉強を続けられる自信が…
このような悩みを抱えていました。
おかげさまで、プロフィールに書いたあるきっかけから↑のような悩みは解決してます。
ですが、実はバリバリのエンジニアの方でも「ITの勉強しない→エンジニア失格」という空気感にしんどさを感じてる人は多いみたいなんですよ…
というのも、「勉強しない→エンジニア失格」の空気感について、こちらの記事でまとめてみたところ、かなり人気なんですよね。
このブログの中でも人気の記事なので、気になった方は一度見てみてください^^
最後まで読んでいただきありがとうございました！！
