トップ > 2014年6月25日要件定義

2014年6月25日要件定義

今日は「要件定義」についてミニ講義でした。

今までやってきたのは、「要求開発」「要求獲得」の部分にあたります。

それをシステムに近づけていくのが要件定義。

気をつけて欲しいのは、
あくまでも、ユーザーの立場で考えるシステムであるということ。

エンジニアは、ついつい、システムありき、で考えがちですが、
せっかくここまでユーザー志向で来たので、
要件定義でも、ユーザー視点を忘れないでくださいね。

どんな機能があればいいのか、
ユーザーは何をしたいのか。

そこをしっかり議論してもらいます。

チームによっては、もういちど、解くべき課題の具体化まで戻って、
考えなおしているチームもあるようです。

そうやって行きつ戻りつしながら、議論をする。
それがPBLでの学びになります。

議論の中で、「コミュニケーション」の難しさについても、
実感しているんじゃないでしょうか。
それぞれの人によって専門分野、学んできた領域、そして、人生の経験が違います。
ですから、当たり前というのは通じません。
また、基礎になるスキルもまちまちです。

人間関係の成長モデルで説明したように、
お互いを知り、協力しあい、さらにお互いを知ります。
「知る」ことには、
相手が使う言葉の意味も含まれます。

ちょっと大変かもしれませんが、
とてもいい学びになっていると思いますよ。

とはいえ、6月ももうすぐ終わります。
ユーザー課題を要件定義に出来れば、
システムとしての機能の検討をし、
そして実装範囲・実装方法の検討と進みます。

先を睨みつつ、がんばっていきましょう。

余談になりますが、
ときどき、
「コミュニケーションがいい」
「コミュニケーションが悪い」
というのを耳にします。

でも、実は、これはどんな状態なのかが曖昧なので、
対応のしようがないのです。

コミュニケーションというのは双方向のやりとり、という意味です。
それ以上でもそれ以下でも（本来は）無いのです。

例えば、コミュニケーションが悪いといっても、
雑談を気軽に出来ない雰囲気だとか、
ホウレンソウが出来ていなくて、連絡漏れがいつも発生するとか、
誰かメンバーがミーティングに欠席したら内容が伝わらないとか、

要求分析をしている過程でも、「具体的に」しましょう、と
何回か言いましたが、
コミュニケーションという問題も同じく、
解決したい事象、問題は何なのかを具体的にしないと、
手が打てないのです。

もし、今、チームでコミュニケーションの問題があるな、と感じたら、
「どんな状態で、どうなっていることが問題なのか」を、
言葉にしてみてください。

それが出来れば、解決策を考えることができますよ。

PBL2014

2014年6月25日 要件定義

2014年6月25日要件定義