インターンシップを実施しました（1週目）
こんにちは。イーアールアイの澤村です。
8/22~9/2でインターンシップを実施しましたので、どのような内容を実施したのかについて紹介させて頂きます。
今年は、8/22~8/26と8/29~9/2で分けて、1週間ごとにそれぞれ別の課題に取り組んでいただきました。
本記事では、8/22~8/26に取り組んだ内容についてお話していきたいと思います。
要件定義書を作ろう
8/22~8/26の1週間では、要件定義書の作成を行っていただきました。
要件定義書とは、クライアント（顧客）がそのシステムで何をしたいのか、なぜそのシステムが必要なのかを明確にし、その実現のために必要な「機能」や「性能」を洗い出したものです。
機能要件や非機能要件、システムの構成などが記載されます。
このインターンシップでは、弊社の管理部の黒沢さんが顧客となって要望を出してもらい、その要望をもとに学生さんが要件定義書を作成してみる、といったことを行いました。
購買ワークフローシステムの要件定義書を作ろう、というのが実際の課題内容です。
弊社では物品購入などの際に、専用の用紙とハンコを使って申請のやり取りを行っているのですが、
- 申請・承認のために人が書類をもって行き来しなければならない
- 申請者・承認者・経理担当者が不在のとき(出張/在宅勤務時など)に処理が滞る
- 見積書や物品購入申請書など、紙に書かれたことを発注管理台帳に転記するのが管理部の手間になっている
- ワークフローの進み具合が分からない
といった困りごとがありました。
上記を解決するためのシステムを考えてほしい、というのが依頼内容になります。
5人の学生さんがいたので、それぞれグループに振り分け、
- 顧客の要求を整理する
- 要件を定義する
- 要件定義書にまとめる
といった作業を行ってもらい、要件定義書に書き起こしていただきました。
黒沢さんと学生さんで対話して要件の整理を行って要件定義書を作成し、私ともう一人の指導員で要件定義書のレビューを行いました。
それが本当にお客さんが望んでいるものか
クライアントからの要求と、実際に望んでいるものが必ずしも一致するとは限りません。
「顧客が本当に必要だったもの」と言われる例があります。
この図は、システム開発プロジェクトの姿を風刺した複数の絵の中の一つです。
「顧客が説明した要件」と「顧客が本当に必要だったもの」の絵を見比べると分かる通り、顧客が説明した要件と、顧客が本当に必要だった物が必ずしも一致しない、ということが往々にしてあります。
そのギャップを埋めるためには、誰が、いつ、どこで、どうやってそのシステムを使うのかといった情報をヒアリングします。場合によっては「本当はこういう機能のほうが適切・必要ではないですか？」と提案することも大切です。そういったヒアリングや提案を繰り返して要件の整理を行います。
学生さんが実際に書いた要件定義書の内容を確認すると、「顧客から要望があった内容ではないが、こういう機能があったら便利ではないか」という理由でいくつか機能を追加していることがありました。
ところが、顧客側に内容を確認してみたら「その機能をいれても手間がかかるので使わないだろう」と回答をうけ、要件定義書から削除することがほとんどでした。
要件定義の段階で発覚できることで、実際に開発開始してから発覚するよりも時間や工数のロスを大幅に減らすことができます。
たとえ提案した機能が不要だと言われても、その理由を聞くことによって、顧客が欲しいシステムのイメージがより掴みやすくなります。
「相手が本当に望んでいること・ものは何か」を聞き出す力は、要件定義書に限らず、普段のコミュニケーションでも役に立つことが多いです。
資料の作り方も大切
レビューでは要件定義書としてこの内容が必要・不要だ、という話の他に、強くアドバイスした内容があります。
それが資料の作り方です。
学生さんが最初に見せてくれた資料は、ほとんど文章だけで見出しも図も無く、読む側の負荷が高い資料になっていました。内容を詳細に書こうとした結果、すべて文章として書き起こしているような印象でした。
自分が整理するための資料ではなく、見せる相手がいる資料なので、相手にストレスを感じさせない・理解しやすいようにしたいです。
実際の業務でこういった資料を作るとき、
- 箇条書きに置き換える
- システム構成は図で表現する
- 処理の流れにはシーケンス図を使う
- 表に置き換える
というように図や表で表現できるものはすべて置き換えます。
文章だと読み手によって齟齬が起きることがあるので、できるだけ文字を減らす工夫を行います。
これは要件定義書だけでなく、他の資料作りでも役に立つ知識なので、いろいろな場面で少しずつ磨いていって欲しいです。
まとめ
要件定義書を作ってみる、という課題でしたが、お客様からの要望・要件をいただき、一緒に仕様をつくっていくことが多い弊社ならではの課題を用意することができたかなと思います。
私もなかなか要件定義書を書く経験が多いわけではないので、改めて勉強になりました。
どうしても要件定義の段階だと、顧客も開発者側どちらもあれもこれも…といろんな機能を入れたくなることが多いので、本当に必要なのか？何故必要なのか？を協議して整理し、あるべき形へ近づけて行きたいです。
