のりのりにっき

ただの雑談です

要件定義について勉強してきました

ブログ始めてから、だらだらと仕事と関係のないことばかり書いてきましたが、
今回は真面目にエンジニア勉強会のおはなしです。

昨日の4月11日に楽天タワーにおじゃまして、すごく久しぶりにエンジニア向けの勉強会に参加しました。
楽天タワーの1Fから13Fまでが楽天のオフィス。すごーいっ!!!(@@)
楽天オフィスのお話はそこそこにして、今回のタイトルはこちらです。じゃん。

「はじめよう!要件定義」ではじめる、すらすらと手が動くようになる楽々要件定義レッスン

「はじめよう!要件定義」の著者、羽生章洋(@ahabu)さんによる要件定義ワークショップです。

はじめよう!  要件定義 ~ビギナーからベテランまで

はじめよう! 要件定義 ~ビギナーからベテランまで

「はじめよう!要件定義」の本は今年の2月の終わりに出ました。 エンジニアさんを中心に売れていて、Amazonのシステム管理・監査部門で1位になっています。

参加して初めて分かったことですが、羽生さんの本はなんと10年前にお世話になっていました。(@@)

ちょうど10年前に新人プログラマーとして小さなSI系の会社に就職した時、SQLを勉強しろと言われて、何かいい本はないかと探していたら、新しく発売されたこの本を見つけて購入。

すらすらと手が動くようになるSQL書き方ドリル

すらすらと手が動くようになるSQL書き方ドリル

SQLの書き込み式ドリルは当時としては画期的で、SQLの基礎を学ぶのにすごく役に立っていました。
書き込み式ドリルはその後も改訂されて新しくなりました。SQLが苦手な新人エンジニアさんにもオススメしています。

改訂新版 反復学習ソフト付き SQL書き方ドリル (WEB+DB PRESS plusシリーズ)

改訂新版 反復学習ソフト付き SQL書き方ドリル (WEB+DB PRESS plusシリーズ)

SQLを勉強したい人、ぜひぜひ購入してたくさんSQLを書いてください。(^^)

少し脱線してしまいましたが、本題に入る前に、要件定義ってなんじゃらほーいというところから説明です。

ウォーターフォールという大規模なシステム開発で昔からある最も有名な開発モデルがあります。
川のように上流から下流に流れるイメージ。

要件定義

外部設計(概要設計)  ↑上流工程
↓-------------------------------------------------------------
内部設計(詳細設計)  ↓下流工程

開発(プログラミング)

テスト

運用

最近は作っては壊すアジャイル開発を採用しているところも出てきており、古い古いと言われている開発モデルですが、現在もSI企業を中心に採用されています。

要件定義〜外部設計が上流工程、内部設計〜運用が下流工程です。

発注側の会社が上流工程を担当して、下請けの会社に下流工程を任せるというパターンは昔から多く見られ、最近は下流工程の部分を下請けの会社ではなくて、オフショア開発といって、外国人エンジニアさんに全部丸投げ〜というパターンも出てきました。

要件定義は最も最初の部分。なにを作るかを決めていくところです。
エンジニアさんにこんなシステム作ってほしいとお願いするときに、こんなのにしましょうとすり合わせをしていく工程です。

この部分がしっかりしていないと、どんなことが起こるかというと。。。

(発注側)作らせてみたけど、思ったものとなんか違うなー。
(開発側)よしっ!作ろう!うん?あれ?ここどうするんだっけ?
       ↓
納得がいかないので、もう1度なにを作るか話し合うことにした
       ↓
(発注側)作り直してもらったけど、なんかいまいちだなー。
(開発側)おまえ、何が作りたいのかはっきりしろーっ!
(発注側)他のシステム会社に頼むかー。
       ↓
それぞれの立場でもっともらしいことを言って、
開発期間が長期化してぐだぐだに。。。。


要件定義は後に続く工程がスムーズにいくための重要なお仕事。

今までの上流工程の本は頭が痛くなるくらい小難しい内容で分厚いものばかりでしたが、
今回の羽生さんの本はページはそれほど多くなく、イラストとわかりやすい文章でとても親しみやすい内容になっています。

今回のワークショップは、SI系のエンジニアさん、Webサービスを作るエンジニアさん、スマートフォンアプリを作るエンジニアさん、今回の要件定義と関係がなさそうなWeb系のデザイナーさんといろいろな立場の人たちが30人くらい集まりました。

まずは羽生さんが1時間くらいお話をされました。

1.前提条件について

まずは、はじめよう!要件定義の本は以下の前提条件の上に成り立っていること。
要件定義がうまくいっても以下の前提条件が欠けているとうまくいきません。

プログラミングができる
プロジェクト・マネジメントができる
DB設計ができる、 ERDも書ける。
組織設計、業務設計ができる
ヒアリングスキルと接客能力がある

2. Gレコを見よ!

羽生さんはガンダムが大好きで、ガンダムGのレコンギスタ(通称:Gレコ)の話が盛りだくさん。Gレコには要件定義の秘訣が満載。ガンダム50年の歴史を1つの作品にうまくまとめている、これからの時代を生きることを考えるときに重要なヒントをくれる作品なのだそう。

アニメも要件定義の材料になるのですか!!!(@@)
ガンダムおたくさんにとってはとても嬉しいお話。エンジニアさんでガンダム好きの人が多いです。
しかし、私はガンダム全然知りませーん!!!きゃーっ!たすけてーっ!!(><)

3. 引き寄せの法則

システムのお話で引き寄せの法則の話が出てくるとは。。。
発注側も開発側もどういう結果を得たいのかを明確にすること。曖昧な結果をイメージでは実現しません。
システムに限った話ではありません。

4. 実力をつけるためには?

材料
道具   →  活動(プログラミング) → 成果
手順       ↑
        実力

システムを作るには、材料、道具、手順が必要。しかし、これらがそろっても実力がないと成果につながりません。

(1)実力をつけるためには、


・実行するスキルを高める
・知見のボキャブラリーを増やす

実行するスキルはプログラミングなどもの作るために必要なものですね。
それに加えて、知見のボキャブラリーを増やすことで臨機応変に対応できるようになるのだそう。
私もいろいろな人にお会いして知見を増やす活動をしてきましたが、今日はGレコとこの後のワークショップで見知らぬ世界へ。。。
まだまだ私の知らない世界がたくさんあるなーと。。。(^^;;;;;

(2)実力ってなんだ

Step0: 何も知らないから何もやれない
Step1:知っている
( いっぱい勉強して知識は豊富だが実際はやっていないのでスキルがつかない)
Step2:やっている
(最初は失敗するがやっているうちにできるようになっていく)

Step3:理解している
(自分がなぜできるのか他人に説明できる)

プロとアマの境界線がStep2とStep3の間。
まずはできるようになること、やらないとダメ。
システムに限らず、どの分野でも同じですね。はい。

5. ワークショップ開始

ということで、あとはひたすら実践です。
A3用紙と付箋と黒いペンと赤いペンが渡され、4人1組、2人1組、そして1人。
合計3回。画面設計をまとめていきます。

まずは、共通のテーマ。ねこあつめ。
HitPointさんから出ている「ねこあつめ」というスマートフォンアプリ。
最近始めましたが、すっかりハマっています。

f:id:norinori2222:20150412221845j:plain

-ねこあつめ-

-ねこあつめ-

  • Hit-Point Co., Ltd.
  • ゲーム
  • 無料

ねこあつめのアプリを見ながら、4人1組で画面設計を書き起こしていきます。このように、実際に動いているシステムから設計を書き起こす作業を「リバース作業」と呼びます。過去の案件で既に出来上がったシステムを見て設計書の書き起こし作業をしたことがあり、懐かしさに浸りながら作業です。

私がいるチームで作ったものはこんな感じ。

f:id:norinori2222:20150412213346j:plain


そして、他のチームで作ったものを全員で確認していきます。
出来上がったものはチームによってバラバラ!

他のチームの画面設計を見て、よかったところ、
ここが参考になったというところを盗んでさらに画面設計図を書いていきます。

次は2人1組。そして最後は一人でアプリのサービスを選んで画面設計を作る作業です。途中までですが、こんな感じで作りました。いつも使っているアプリの1つ。
Evernote Foodを取り上げて作ってみました。

f:id:norinori2222:20150412213919j:plain

プログラミングやDB設計する前に画面設計を実際に書いていくとページでどの項目が抜けているのか、DB設計で必要な項目も見えてきます。
このような画面設計図はきちんと書いたことはなかったので、とてもいい勉強になりました。

Web系の会社に勤務してからは、アジャイルアジャイル、あじゃじゃしたーな環境にいて、
企画が渡されると同時に、DB設計したり、考えながらプログラムを書いていましたが、このように画面設計を書いていくと後々楽になると思いました。パソコンがない時でもスマートフォンやノートで手書きでまとめることもできますね。

要件定義はSI企業の上流エンジニアさんがお客さんと何を作るか決めていかないといけない場面だけではなく、1人で何かを企画して作る、エンジニアの仕事をしていなくても、何かシステムを作りたくてエンジニアさんに依頼しないといけない立場の人にも参考になるのではないかと思いました。

ワークショップの講師をつとめた羽生さん、一緒にワークショップをしたエンジニアのみなさん、会場を貸してくれた楽天の社員のみなさん、主催のNEKOGET(@NEKOGET)さん、本当にありがとうございました!!!m(_ _)m

f:id:norinori2222:20150412214014j:plain


(おまけ)
Gレコ、録画予約しました。

おしまーい。