GMOアドマーケティングのKMです。
前回、エンジニアの職種について記載しましたが、
今回はどの職種にも当てはまる作業工程について書いて行きますね。
はじめに
システム開発は、アジャイル開発などの開発手法がありますが、弊社ではプロダクトにより使い分けております。
私の携わっているプロダクトの基本的な流れは下記ですが、各フェーズ毎に落とし穴●があるので、最後までナイスイーン（落とし穴に落下）せずにゴールする為の経験則を駆け足でご紹介して行きます。
「要件定義」～「設計」～「開発」～「テスト」～「リリース」～「運用」～ 😛
要望があり「要件定義」を行った後、システムの「設計」を行いますが、伝言ゲームのように
最初の方（工程）で間違えると、以降が「無駄」～になってしまうので失敗しない事が重要です！
工程の流れと、落とし穴●について記載します。
「要件定義」
１．ヒヤリングシートの作成 💡
●想定と違うシステムになってしまう事にならないように、ヒヤリング漏れや、具体的な要件が聞けるようにヒヤリング項目を整理しておきましょう。
２．ヒヤリング 💡
●要求者の思惑違いや知らない事により開発不要だったという事にならないように、目的や背景、要求者の理解度に併せて、どのように上手くワークしていくかなど、敬意や賛同の心を持って聞く一方、レビューするつもりでヒヤリングしきましょう。
３．現実性の検討 😎
●ヒヤリング内容や機能が素晴しくても、以下のように使われないシステムにならないよう、
持てる力や感性と関係者や人脈を駆使してチェックしましょう。
😕 運用できない（要望元が運用者でない場合）
😥 ユーザーの事を考えていない（逆の立場になれない人がリサーチもせず要望した場合）
👿 宣伝（マーケティング）を考えていない（スケールする戦略が計画されていない場合）
😡 ステークホルダーの利害が不一致（先方が動く条件を事前に取り付けていない場合）
🙁 代替ツールや、競合他社より劣ってしまった（知識不足や情報収集を怠った場合）
🙁 システムが依存関係にある場合（依存元の決定次第で全ての価値を失う場合）
４．フェーズ分け 😎
要求時にディテールをこだわる発想は大事ですし素晴らしい事ですが、細かい機能を時間をかけて作るのではなく、昨今のビジネス環境においては「スピード」という新たな「質」を上げる事がとても大事な為、先ず、どこまで開発してリリースするかのフェーズを分ける事が重要です。
細かい要望が多く困っている方は、要望元に是非、以下を見せて、納得頂いてください（汗）
「神は細部に宿る」は正しく使おう －「言葉」の持つ誤ったことを正当化してしまう怖さ－
http://sh0tk.blogspot.jp/2012/02/blog-post_23.html
●逆にリスクがある場合は、フェーズを分けて後回しにしない事も重要です。
５．状況判断と優先度調整 😎
ネット業界は日々優先度が代わりますので、市場優位性や、関係する事業や人への影響から判断し、売上影響が小さい要件は後のフェーズにする等、各要件の優先度を調整します。
●開発リソースは有限の為、優先度を間違うと暫く他の開発が進まないので、緊急案件以外本当に今必要か？最終確認し、事業責任者が意思決定を行い、関係者に目的と予定を伝えておくと、現場の指揮や次のアクションに繋がります。
６．他システムとの優先度調整
他システムとの連携は必要性をヒヤリングしたり、逆に必要性を訴えつつ、足並みが揃うようスケジュール調整を行います。
時どきあるのが、他システム側で開発すべきだがリソース不足の為、
●代わりにシステム開発して欲しい要件ですが、一時的にしか使われないシステムの場合、重要度と工数次第で開発しない調整も、 😳 エンジニアのモチベーション低下を防ぐ為に必要です。
「設計」
７．イメージ打法 😳 ➡ 💡 （歌や曲を作る時と一緒で想像する、妄想する（笑））
イチローや五郎丸がルーティーンの時に何を考えているかは知らず、私自身、どんな顔で考えているのかわかりませんが、空に絵を書くようにイメージしています。
●要件が、複雑だったりブレストが必要な場合、自分の頭の中だけでは整理できずに設計が進まない場合があるので、紙やホワイトボードを使いましょう。
８．設計に行き詰まったら
●一人では手に負えないのに無理すると設計を失敗するので、１．の段階で、その分野の識者や関係者を招集してホワイトボードを囲みMTGしましょう。
GMOのスピリットベンチャー宣言に、
相談されたら、わかることは一言でも教えよう。とありますし、仲間です。助け合いです。
先日、某社長とお話する機会がありましたが、設計段階で何か良い戦略はありますか？
とおっしゃれていました。設計にも戦略という言葉を用いられるのは、常日頃から、
要件から戦略を考えられていると思い関心しました。戦略を実現する為の設計は重要です。
９．仕様書や出力内容 💡
仕様書をまず記載し、続いて出力内容（モックアップなど）ですが、微修正を除き期待するアウトプットを要望者、仕様作成者、開発者の３者間で、●認識違いを防ぐ為に手書きでも良いので、正しく伝わるレベルの仕様書を残しましょう。
９番ホールまで、違う穴を説明したので、一旦ここで休憩します。 😛
最後に
今回は、「要件定義」～「設計」について紹介しました。弊社では、同じ失敗をしないよう日々改善を行ない、エンジニアもチームで変化を乗り越えながら楽しんでいます。
次回は、「開発」以降のフェーズを書いて行きますね。
