ワークショップ演習・白書・アジャイル（グループワーク・感覚の数値化・データ白書の見方・アジャイル開発）
Z-4 外部環境・トレンド ＞ Z. その他（横断情報） 元資料: ワークショップ素材 WS0006 後半（19枚）
目的・概要
考え方・観点
グループワーク
（１）「感覚」を数値化する！
- あなたは淀屋橋の会社に勤務するOLです。毎日の楽しみは、何といっても同僚との話がはずむランチタイム。最近は、数件のお気に入りをローテーションで回る日々で、少々飽き気味です。
- ちょっと時間ができたので、お気に入りのお店をリストに整理して、ついでに新しいお店を開拓したいなと思いました。
- 【課題】
- ★リストアップに必要な 「お気に入りの観点」 と「評価データ」を考えてください。
- 【評価ポイント】
- ★同僚と、データをもとにしたお店の比較ができること
- 飲食店のお客さん：「 ランチタイムをもっと充実させたい 」
- 20分
- （＋共有20分）
「感覚」を数値化する／回答例
- 実際にオフィスからお店に行くまでのイメージを描きながら、どんな観点、気持ちで選んでいるかを考え、まずは量を洗い出す →その後にカテゴリわけ
- 「感覚値」は普段使っている言葉に近いものをまず置いてみる
- →無理に数値化せず、あとで重み付け、順位付けをしてもよい
- 総合ポイントで比較ができる形
（２）「視座」を変え深層を理解する！
- 2030年、あなたは淀屋橋界隈でイタリアンのお店を営むオーナーです。
- ディナーのお客さんを増やすべく、半年前からランチを始めましたが、客足が伸びず、このままではランチ営業をやめざるを得ません。
- 【課題】
- ★今現在、様々な機器から情報取得が可能になっていますが、お店の評判を上げ、売上を倍増させるための「データ」をどの機器から取得し、どんな「改善」に結びつけますか？
- 【評価ポイント】
- ★お客さんの反応と動線を考慮していること
- 飲食店のオーナー：「 ランチで評判のお店にしたい 」
- 20分
- （＋共有20分）
「視座」を変え深層を理解する！／回答例
- 店舗ウィンドウに埋め込まれた「通行量センサー」で、曜日ごとの昼時の通行量、男女比、年齢比、来る方向、歩く速度、店舗を見る人数、天候を取得
- → 曜日ごとのメニュー・金額の検討、看板デザイン（色、フォント）の改善
- 店内カメラの「表情センサー」と、テーブルの「声色センサー」により、運ばれたメニューに対する評価情報を獲得
- → メニュー、調理法の改善
- 近隣銀行の混雑状況と外に設置された「気温、雨滴センサー」の情報より、ランチ外出率を予測
- → 来店率の予測に生かし、材料の発注量を調整、コストを削減
ソフトウェア開発データ白書の見方、使い方
ざっくり言うと、白書の注目ポイントは２つ！
- コンセプト
- と
- バリュー
- 出典：IPA/SEC ソフトウェア開発データ白書2018-2019
- コンセプトをもとに
- データ間の関係性を
- 探ることで
- 得られるものがバリュー
コンセプトはこの1枚に集約！
- ソフトウェア開発における関係者の 「相場観」 ・・ピンクの枠
- ベンダ内部におけるソフトウェアの「評価軸」・・オレンジの枠
- 白書で明らかにしたかったこと・・
- コンセプト
- 出典：IPA/SEC ソフトウェア開発データ白書2018-2019
相場観を示すデータは解明！
- 「プロジェクト特性」×「要素間の関係」の分析により、相場観を測るための「二次データ」(計算値)が解明できた →白書 [A4.導出指標の名称と定義] を参照
- But, 見積りや品質の評価に使える「絶対的な指標」は示せなかった
- バリュー
- 白書DB
- 収集データ
- 現場プロジェクトの生データ
- 【組織やプロジェクトに関する
- 様々なデータ】
- 【プロジェクトに影響する
- 様々な環境要因】
- 社会情勢や他の業界の景気、技術や人材育成の動向など
- プロファイル
- （プロジェクト特性）
- 加味されていない
- 各社
- IPA/SEC
- 加味されていない
- 相場観
- を示す
- 主なデータは解明できた
- 環境や背景に関わる未取得データが多く、
- 生産性や品質の評価は
- できていない
- 要素間の関係
- 絞
- 世の中
- 成果
- 限界
- これらを参考に、各企業
- においてデータを蓄積～分析
- することで、システム開発の
- 精度を向上させるのがgood
- ここは環境要因や各企業の文化的特性、顧客特性とともに、より深い分析を行う
- 必要があるところ
- 白書としての
（参考）アジャイル型開発
アジャイル型開発を行う上での留意点
- プロジェクトとして当たり前に実施すべきことができていない場合は、アジャイルには手を出さない→より高度なマネジメント、エンジニアリングが求められるため
- アジャイル開発の特性（プロセスや役割、適合性など）を十分に理解する
- アジャイルの活用理由や目的（ねらい）が明らかでない場合は使わない
- アジャイルで効果が出る／出ない箇所（フェーズ、機能など）を切り分ける
アジャイル開発に関する記事
| 記事・ニュースのタイトル | URL | 簡単に概要 | ||
|---|---|---|---|---|
| アジャイル開発～顧客を巻き込みチーム一丸となってプロジェクトを推進する～ （前編） | http://www.nec-solutioninnovators.co.jp/column/01_agile.html | アジャイル開発の紹介、スクラムの紹介 | ||
| アジャイル開発～顧客を巻き込みチーム一丸となってプロジェクトを推進する～ （後編） | http://www.nec-solutioninnovators.co.jp/column/02_agile.html | スクラムの役割・事例・効果 | ||
| アジャイルとは何か？ ツールと開発手法「スクラム／XP」、ウォーターフォールとの違い | http://www.buildinsider.net/enterprise/agile/01 | 誕生背景・概要・よくある誤解・実際に組織／チームに適用する方法 | ||
| 開発手法を徹底比較！アジャイル vs ウォーターフォール | https://techacademy.jp/magazine/12072 | それぞれの開発手法でのメリット・デメリット | ||
| 現代のプロマネが知っておきたいアジャイル開発の基礎知識まとめ | http://www.atmarkit.co.jp/ait/articles/1412/05/news044.html | そもそも開発手法とは、アジャイルとは何か、他の開発手法との違い、アジャイル開発に向いているプロジェクト、スクラム／リーン | ||
| 知っておくべきアジャイル開発手法「スクラム」の特徴と開発の流れ | https://furien.jp/columns/98/#2 | スクラムの紹介・開発の流れ | ||
| アジャイル型開発の重要性とは？ | https://www.ves.co.jp/column/005/index.html | アジャイル開発の紹介・成功のポイント | ||
| ソフトウェアの新たな開発手法、「アジャイル開発」って？ | https://japan.zdnet.com/article/20248727/ | アジャイル開発の紹介・代表的な開発手法 | ||
| 「アジャイル開発」って何がいいの？--アジャイル開発を実案件に生かすための基礎知識 | https://japan.zdnet.com/article/35003090/ | アジャイル開発の紹介・モデル | ||
| アジャイルなソフトウェア開発とは | https://www.ogis-ri.co.jp/otc/hiroba/technical/IntroASDooSquare/chapter1/IntroASDooSquareApr2005.html | アジャイル開発の紹介・宣言・開発手法の分類 | ||
| いまさら聞けない“スクラム開発”ってどんなもの？ | https://geechs-magazine.com/tag/tech/20160212 | アジャイル開発の紹介・役割・流れ | ||
| アジャイルモデリングへの道 Vol.2：スクラム組んで開発しよう！ | http://www.ogis-ri.co.jp/pickup/agile/agileintro02.html | スクラムの紹介・進め方・事例 |
アジャイル型開発技法
- アジャイルとは『すばやい』『俊敏な』という意味で、反復 (イテレーション) と呼ばれる短い開発期間単位を採用することで、リスクを最小化しようとする開発手法の一つ。
- 出典：日立ソリューションズのサービス資料 より
- 出典：http://www.nec-solutioninnovators.co.jp/column/01_agile.html
アジャイル開発の方法論
- 出典：マイクロソフトもIBMもやっている！アジャイル開発の実践事例 より
アジャイル開発は手段
- 出典：日立ソリューションズのサービス資料 より
アジャイル開発の適用パターンは様々
- 出典：日立ソリューションズのサービス資料 より
スクラムの主なプロセス
- デイリースクラムは、毎朝チームメンバーで集まり、15分など短い時間を区切り、昨日やったこと、今日やること、障害となっていることを一人一人報告・共有します。このミーティングにより、チーム全員の状況、障害や問題の共有、今日どこまで完了するかの宣言を行い、プロジェクト全体の見える化を行います。
- リリースプランニングは、プロジェクト立ち上げ時に、どのようなプロダクトをどのような機能優先順で、どのくらいの期間で実施するかをチーム全員でプランニングします。万が一実態とのずれが大きくなってきた場合には、随時見直しを行います。プランニングを実施した結果は、『プロダクトバックログ』という名前の、機能優先順で並べた機能一覧により管理します。
- スプリントプランニングは、ひとつのイテレーション期間（1～4週間程度）で、全体のプロダクトバックログの中からどの範囲の機能を実現するかをチーム全員でプランニングします。プランニングした結果は、『スプリントバックログ』という名前の、機能優先順で並べた機能一覧により管理します。チームが毎スプリント内でどのくらいのタスクを消化できるかは、毎回計測し、精度を高めて行きます。
- スプリントは、実際のひとつのイテレーション期間の開発フェーズです。チームメンバーは、宣言通りにスプリント内で安定したプロダクトがリリースできるよう、最善を尽くします。基本的に、スプリント内の変更（機能の追加や変更、削除）は認められません。
- スプリントレビューは、ひとつのイテレーション期間で完成したプロダクトを、ステークホルダを集めデモを行います。このフェーズでは、チームメンバー達の作ったプロダクトが安定して動くことをアピールすると共に、要求の伝達ミスや漏れがないことを必ずチェックし、チームメンバー全員が正しい方向を向いてイテレーション開発を進めているかを確認します。
- ふりかえりは、基本的に毎スプリント終了時に行います。ふりかえりにはKPT法などが用いられます。今回のスプリントの良かったこと、問題点、挑戦したいことをメンバー全員で出し合い、次のスプリントでさらにチームメンバーが高い価値を生み出せるように、メンバー同士話し合いを行い、確認し合います。
- 出典：http://www.nec-solutioninnovators.co.jp/column/01_agile.html
スクラムの役割
- プロダクトオーナー
- 作成するプロダクトに対する、最終決定権と責任を持つ人です。
- プロダクト全体の機能優先順である『プロダクトバックログ』を常に最新の状態に管理する責任があります。
- 同時にプロダクトに対する情熱を持ち、スクラムチームと綿密な議論を交わし、プロダクトの価値を最大限にしようと常に努力します。
- スクラムマスター
- スクラムの理解と実践を推進し、プロジェクトを円滑に進めることに責任を持つ人です。
- スクラムをスクラムチーム全員が正しく理解した上で開発を実践していることを常にチェックします。
- また、チームの自律的な行動を引き出し、成果を最大限に引き出すことに注力します。
- チーム
- ウォーターフォール型開発では、概要設計者・詳細設計者・実装者・テスターなど役割が決まっていますが、スクラム開発では全ての開発に関わる人を『チーム』と呼びます。
- 役割として名前を分けず、『チーム』と呼ぶのは、チーム一丸となって最大の価値を提供する、ということに重点を置くためです。
- 出典：http://www.nec-solutioninnovators.co.jp/column/02_agile.html
イメージ図
手順・進め方
アジャイル開発の流れ
- 出典：日立ソリューションズのサービス資料 より
