こんにちは!
システムインテグレーション事業部(以下、SI)のドンフンです。

現在、私は開発業務よりも、要件定義や設計、ソースコードのレビュー、サーバの管理をメインに担当しています。
要件定義と設計を行ううえで、コミュニケーションが非常に重要であることを改めて感じるようになりました。

今回の記事では、なぜそのように思うようになったのかについてお話をしたいと思います。

先ずは開発フローの確認から

開発プロジェクトの流れを簡単に確認してから本題に入りたいと思います。

一般的に、開発プロジェクトは上記の画像に記載された過程を経て進みます。

私が今回話したい内容は、要望のヒアリングから開発の部分になります。

お客様が本当に欲しがっているものを把握しよう

とあるプロジェクトでのお話です。

お客様より、会員登録したユーザーが自身のスケジュールを登録し、決まったルールによってそのスケジュールを自動管理するアプリを作りたいと要望がありました。

私はその要望を聞いた後、画面設計と機能の洗い出しを行い、お客様に作成したドキュメントを見せながら説明をしましたが、その際お客様の希望と少し認識がズレていることが発覚しました。

後に要望についてもっとお話を伺ったところ、会員のスケジュール管理よりも、会員が本人の個人データをどのように保存し、管理していくのかがお客様にとってより重要だったのです。

お客様が一番大事だと考えていた機能の要望を勘違いし、私が考えた設計ではその要望が実現できない状況でした。

ズレが発覚した当時はまだ要件定義の段階でしたので、早く気付けて良かったですが、それでも書いたドキュメントを全部修正することになったため無駄に工数がかかってしまいました。

それ以降、要望をお伺いする際は「お客様が作りたいというサイトは何なのか」を聞くよりも、「なぜそのサイトを作りたいのか」その意図を聞いて要望の本質を理解することが何より重要だと感じました。

私に限らず、お客様の意図を理解せず、言われたまま作ってしまうと実はお客様が想像していたものと全く違うサイトができてしまうこともありますので、今後は気をつけたいと思います。

設計・開発もコミュニケーションから

要望のヒアリングと要件定義がお客様とのコミュニケーションだとすると、設計・開発は開発者とのコミュニケーションから始まります。

サイトの目的やその機能が必要な理由を開発者に伝えないと、意図したサイトが開発されない場合があります。

例えば、APIの開発において、権限設定を行う機能の設計書があります。
Adminと一般のユーザーが分かれる状況で、その一般のユーザーの中でも細かく権限を分けることができます。

その開発では、「Adminの役割はどのようなものなのか」という説明が足りなかったため、一般のユーザーがAdminになることを想定して作られていました。
(※実際はAdminと一般ユーザーは全く役割が異なり、一般ユーザーがAdminになることはないとのことでした。)

※当時作成した設計書の一部

このような事例があった後は、開発者に設計書だけではなく、詳しい要件やお客様の意図、各機能の動きなどを共有するようになりました。

それからは、意図していた通りに開発が行われるようになると同時に、開発者からのアイデアも数多くいただき、これまでよりも良いサイトが作られるようになりました。

最後に

今まで複数のプロジェクトを進めてみて一番強く感じたことは、やはりコミュニケーションが重要だということです。

他にも仕事の分担とか、開発手法、スケジューリングの方法など重要な点はいくつもありますが、「全てのことはコミュニケーションから始まり、コミュニケーションで終わる」ということを改めて感じるようになりました。

今後も、より円滑に開発が進む方法について調査し、トライし続けていきます。

以上、SI事業部のドンフンでした。