ソフトウェア開発って なにか？を学ぶ勉強会

ホロラボの社内勉強会で話した資料です。

Transcript

1. アジャイルにものをつくる とはどういうことか？ ソフトウェア開発って なにか？を学ぶ勉強会
2. システムを作る
3. 証券取引所 証券会社
4. 現在の株価を見 たい。
5. ネットワークにつなぐ
6. = 5000円
7. = 5000円 = 5000円
8. 株式には いろいろある
9. https://www.jpx.co.jp/listing/co/index.html
10. 3825種類
11. 自分の知りたい 株価だけ見たい
15. 6501 [Enter]
16. 6501 [Enter] 日立 5870 +68 (+1.17)
17. https://www.hitachihyoron.com/jp/pdf/1974/08/1974_08_05.pdf
18. https://www.hitachihyoron.com/jp/pdf/1974/08/1974_08_05.pdf
19. https://museum.ipsj.or.jp/computer/main/0026.html
20. 日立 5870 +68 (+1.17) https://www.jpx.co.jp/corporate/ about-jpx/history/01-02.html 証券取引所 相場報道回線
21. でも株価って 動くんですよね。
22. https://www.hitachihyoron.com/jp/ pdf/1988/03/1988_03_11.pdf
23. https://www.jpx.co.jp/corporate/ about-jpx/history/01-02.html 証券取引所 相場報道回線 日立 5870 +68 (+1.17) 160 自動 更新
24. 値動きも 見たいよね。
25. https://www.jpx.co.jp/corporate/ about-jpx/history/01-02.html 証券取引所 相場報道回線 時系列方向に拡張
26. グラフで 見たいよね。
27. https://www.jpx.co.jp/corporate/ about-jpx/history/01-02.html 証券取引所 パソコンの普及 グラフ 描画
28. 回線料 安くしたい
29. 建物内 LAN 広域網 データ センター エッジサーバ
30. ちょっ、何の話
31. 30年の変遷
32. https://www.juse.or.jp/ departmental/point02/08.html 狩野 紀昭先生 東京理科大学名誉教授、工学博士 KANOモデル
33. 狩野モデル ないと話にならない。 あればあるほどよい。 なくても困らないけど、 好き。持っていたい。 当たり前品質 一元的品質 魅力的品質 業界の競争の基準が変わる
34. 例えば自動車の歴史 走る。曲がる。 より速く。より遠く。 エアバッグやABSで 安全。安心。 当たり前品質 一元的品質 魅力的品質 ３０年の変遷
35. https://hbr.org/1986/01/the-new- new-product-development-game 新製品開発におけるゲームのルールは 変わりつつあります。多くの企業が、 今日の競争市場で優位に立つためには、 高品質、低コスト、差別化という 基本的な要素だけでは不十分であることに 気づいています。また、スピードと 柔軟性も必要です。 (野中、竹内 1986年)
36. また、物理的な世界に存在すると考 えられている産業のバリューチェー ンの多くをソフトウェアが担ってい ます。今日の自動車では、ソフト ウェアがエンジンを動かし、安全機 能を制御し、乗客を楽しませ、ドラ イバーを目的地に案内し、各車をモ バイル、衛星、GPSネットワークに 接続しています。車好きの人が自分 で車を修理できた時代ははるか昔の ことですが、それは主にソフトウェ アの内容が充実しているからです。 ソフトウェアが 世界を食べている https://www.wsj.com/articles/SB10001424053111903480904576512250915629460 2011年マーク・アンドリーセン
37. 個体発生は 系統発生を 繰り返す https://ja.wikipedia.org/wiki/エルンスト・ヘッケル
38. 狩野モデルは新製品開発にも適用できる ないと話にならない。 あればあるほどよい。 なくても困らないけど、 好き。持っていたい。 当たり前品質 一元的品質 魅力的品質 順に必要な品質を備えていく 機能 機能 機能 機能 機能 機能 機能
39. 狩野モデルは新製品開発にも適用できる ないと話にならない。 あればあるほどよい。 なくても困らないけど、 好き。持っていたい。 当たり前品質 一元的品質 魅力的品質 順に必要な品質を備えていく 機能 機能 機能 機能 機能 機能 機能 ここを 狙いたい
40. 狩野モデルは新製品開発にも適用できる ないと話にならない。 あればあるほどよい。 なくても困らないけど、 好き。持っていたい。 当たり前品質 一元的品質 魅力的品質 順に必要な品質を備えていく 機能 機能 機能 機能 機能 機能 機能 ここを 狙いたい でも、 ここは 無視でき ない
41. 狩野モデルは新製品開発にも適用できる ないと話にならない。 あればあるほどよい。 なくても困らないけど、 好き。持っていたい。 当たり前品質 一元的品質 魅力的品質 順に必要な品質を備えていく 機能 機能 機能 機能 機能 機能 機能 MVP 生き残れる 最低限の機能 (の仮説)
42. ユーサーストーリーマッピング 利用者の行動(フロー)を分析する
43. ユーサーストーリーマッピング 必要な機能が 少ない方が リリースの 確実性が高い リリースごとに 一貫して 利用できること
44. 最小限の機能で、 最大の成果を 機能を洗い出す だけでなく、 できるだけ 絞ることが重要
45. https://kawaguti.hateblo.jp/entry/20111030/1319926043 作る都合 = インクリメンタル 確かめる都合 = イテレーティブ
46. https://kawaguti.hateblo.jp/entry/20111030/1319926043 作る都合 = インクリメンタル 確かめる都合 = イテレーティブ まず全体を洗い出して、 順に、手戻りなく 作っていくと効率がよい …のでちゃんと先に 調べて設計してほしい
47. https://kawaguti.hateblo.jp/entry/20111030/1319926043 作る都合 = インクリメンタル 確かめる都合 = イテレーティブ まず全体を洗い出して、 順に、手戻りなく 作っていくと効率がよい …のでちゃんと先に 調べて設計してほしい カタチにしてみないと、 本当にそれでいいのか わからないので、 全体像を描いてみて、 徐々に調整したい
48. 囲碁の目標 = なるべく多くの 陣地を囲む • 大きく囲もうとすると 裏を取られる。 • 小さく着実に進みすぎ ると大きく囲めない。
49. チームで一歩ずつ着実に進む = スクラム 機能 機能 機能 機能 機能 作業 作業 作業 作業 実装 デモ / レビュー (企画書ではなく 動くソフトウェアを見せて、 早期にフィードバック をもらう) 自分たちで考え、集中して作業を進める
50. チームで一歩ずつ着実に進む = スクラム 機能 機能 機能 機能 機能 作業 作業 作業 作業 実装 デモ / レビュー (企画書ではなく 動くソフトウェアを見せて、 早期にフィードバック をもらう) 自分たちで考え、集中して作業を進める
51. 集中してチームとして仕事を進める 作業 作業 作業 作業 実装 自分たちで考え、集中して作業を進める
52. https://hbr.org/1986/01/the-new- new-product-development-game ラグビー・アプローチでは、 選び抜かれた多分野のチームメンバーが、 最初から最後まで一緒に仕事をすることで、 製品開発プロセスが生まれます。 製品開発プロセスは、 高度に構造化された段階を踏むのではなく、 チームメンバーの相互作用から生まれます。 (野中、竹内 1986年) 新製品開発の新たなゲーム
53. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ 竹内野中論文(1986)が示した マネジメントスタイル • Type A NASAのウォーターフォール型 • 要求、分析、設計、実装、試験と、 順に次の工程の部署に引き渡される • Type B 富士ゼロックスのサシミ型 • 前工程と後工程が同席する • Type C ホンダのスクラム型 • 一時は全工程が同席する Jeff SutherlandはこのType Cから、 自らのフレームワークの名前を とった。
54. オリジナルのスライド https://www.infoq.com/presentations/The-Roots-of-Scrum/ ラグビーのスクラム
55. 単純作業であれば、 作業分担が 機能しやすい。 複雑な作業は、 相互に連携して 進める必要がある。 水を汲む専門家 水を運ぶ専門家 水をかける専門家 全員が同じ情報を見て、できることをする
56. 単純作業であれば、 作業分担が 機能しやすい。 複雑な作業は、 相互に連携して 進める必要がある。 水を汲む専門家 水を運ぶ専門家 水をかける専門家 全員が同じ情報を見て、できることをする リソース効率を重視 (全員が働いている) フロー効率を重視 (目標に速く到達)
57. 最初のスクラムは、 まずガントチャートを 廃止するところから始まった。 必要なスキルを 持った人が都合よく 割り当てられるか？ 水を汲む専門家 水を運ぶ専門家 水をかける専門家
58. 問題が起きたら、 全員で対策にあたる 最初からわかってい る情報が少ない。 探索的に進めたい。
59. チームで一歩ずつ着実に進む = スクラム 機能 機能 機能 機能 機能 作業 作業 作業 作業 実装 デモ / レビュー (企画書ではなく 動くソフトウェアを見せて、 早期にフィードバック をもらう) 自分たちで考え、集中して作業を進める
60. 最小限の機能(努力)で、最大の成果を 機能 機能 機能 機能 機能 作業 作業 作業 作業 実装 自分たちで考え、集中して作業を進める
61. チームで一歩ずつ着実に進む = スクラム 機能 機能 機能 機能 機能 作業 作業 作業 作業 実装 デモ / レビュー (企画書ではなく 動くソフトウェアを見せて、 早期にフィードバック をもらう) 自分たちで考え、集中して作業を進める
62. 作ったら素早くリリースする仕組みづくり 機能 機能 機能 機能 機能 作業 作業 作業 作業 実装 デモ / レビュー (企画書ではなく 動くソフトウェアを見せて、 早期にフィードバック をもらう) 自分たちで考え、集中して作業を進める
63. チームで一歩ずつ着実に進む = スクラム 機能 機能 機能 機能 機能 作業 作業 作業 作業 実装 デモ / レビュー (企画書ではなく 動くソフトウェアを見せて、 早期にフィードバック をもらう) 自分たちで考え、集中して作業を進める
64. ソフトウェアはコピーできる つまり、新しく作る、 ということは、 世の中にないから 作るということになる。 それゆえ、不確実性が高く。常に学ぶ必要がある。
65. 作れる人はコピーできない 内容を理解した人を 他の人に簡単に 「引き継ぐ」ことは できない。 レシピは渡せても、 スキルは引き継げない。 それゆえ、うまくいくチームを維持する必要がある
66. https://simplearchitect.hatenablog.com/entry/2016/06/20/080807
67. チームで一歩ずつ着実に進む = スクラム 機能 機能 機能 機能 機能 作業 作業 作業 作業 実装 デモ / レビュー (企画書ではなく 動くソフトウェアを見せて、 早期にフィードバック をもらう) 自分たちで考え、集中して作業を進める
68. 動くソフトウェアを 生み出すチームの活 動を通じて、一つ一 つ課題に対応し、 信頼を積み上げます。