現代的システム開発概論

by Recruit

Slide 1

Slide 1 text

現代的システム開発概論 2023 株式会社ウルフチーフ川島義隆

Slide 2

Slide 2 text

この講座で学んでほしいこと ● SIerでは研修および業務で学べるような「ソフトウェアエンジニアリング」のエッセンスを身につける ● プロジェクトマネジメントのうち、特にプランニングはソフトウェアの設計と結び付きが強く、相互に影響を与えるので、両方おさえておかなければならない

Slide 3

Slide 3 text

ソフトウェア工学 ● 要求 ● アーキテクチャ ● 設計 ● 構築 ● テスト ● 運用 ● 保守 ● 構成管理 ● マネジメント ● プロセス ● モデル・手法 ● 品質 ● セキュリティ ● プロフェッショナル実践 ● 計算基礎 ● 数学・エンジニアリング基礎 ● アジャイル / DevOps SWEBOK 4

Slide 4

Slide 4 text

プロジェクトとは何か? プロジェクトとは、独自のプロダクト、サービス、所産を創造するために実施する有期性のある業務 ● 特定の成果を達成するための組織 ● 期限が限定されている(有期性) ● 同じものはない(独自性) ● 相互に関連する作業の調整がなされる(相互関連性) PMBOK 4

Slide 5

Slide 5 text

Planning

Slide 6

Slide 6 text

プロジェクト計画計画の「変数」を予測、コントロールの方針を立てる ● 開発手法 ● 成果物 ● 組織の要求事項 ● 市場の状況 ● 法律または規制による制限 ● デリバリー ● 見積 ● スケジュール ● 予算 PMBOK 7

Slide 7

Slide 7 text

計画不確実性を減らす、明らかにする、局所化する In preparing for battle I have always found that plans are useless, but planning is indispensable. ー Dwight D. Eisenhower

Slide 8

Slide 8 text

プロジェクトピラミッド https://scrapbox.io/kawasima/プロジェクトの変数コントロール

Slide 9

Slide 9 text

時間とコストのトレードオフ最適ポイントを超えて、時間を短縮しようとするとコストが跳ね上がる。 Project Planning, Scheduling, and Control, Sixth Edition

Slide 10

Slide 10 text

Delivery(リリース基準) プロジェクトにとって重要なことは何か? ● リリースの日程 ● 機能セット ● 欠陥の少なさ ● 品質特性など、これらを満たしたらリリース可能といえる基準を決めておく。

Slide 11

Slide 11 text

開発ライフサイクル種類ライフサイクルの例長所および成功に必要な条件逐次型ウォーターフォールフェーズゲート ● コストのリスクを管理できる ● 既知かつ合意済みの要件 ● アーキテクチャをよく理解できている ● プロジェクトの過程で要件が変更されない反復型スパイラル進化的プロトタイピング ● 技術的リスクを管理できる ● 要件が進化し続ける漸進型スケジュールに応じた設計、段階的納品 ● スケジュールのリスクを管理できる反復漸進型 (適応型) アジャイル ● スケジュールと技術的の両方のリスクを管理できる ● 全てのメンバが同一サイトで作業を行える ● 統合チーム以外では円滑な進行が難しい場当たり型 Code and Fix Manage It! 3.2 ライフサイクルの概要

Slide 12

Slide 12 text

逐次型作るものが予測可能 (不確実性は含む)であることを前提とする不確実性をコスト/時間に転化するプロジェクト計画時点では、不確実性のボリュームを想定し、 Negativeな方に現実化された時の対処費用と対応時間を算出しバッファとして積んでおく

Slide 13

Slide 13 text

反復型と漸進型の違い PMBOK ７

Slide 14

Slide 14 text

https://martinfowler.com/bliki/WaterfallProcess.html Waterfall 予測型計画反復型適応型計画アジャイルアジャイルプロセスは適応型計画でなければならない反復型でも機能固定でやる場合は、予測型計画

Slide 15

Slide 15 text

予測型と適応型プロセスの違い(イメージ図) 目標が定まっている不確実性はバッファでコントロールする目標と実績のズレを検知し対策を打つ目標が動き続けるので、 (大きな方針はある) 不確実性を目標を近くに置くことで減らす

Slide 16

Slide 16 text

不確実性「わからない」のレベル The Five Orders of Ignorance ● 0OI: 全部分かっている ○ 「答え」を持っている。あとは実装するだけで完成する。 ● 1OI: 分からないことが分かっている ○ 答えを得るための「質問」を持っている。 ● 2OI: 分からないことが分からない ○ 「質問」を持たない状態。決定的な答えを引き出すための「質問」ができない。 ● 3OI: 分からないことが分からない状況を何とかする術を知らない ○ 2OI→1OI→0OIと進んでいくためのプロセスがない状態。 ● 4OI: 無知にレベルがあることを知らない

Slide 17

Slide 17 text

Cynefin Framework 予測型適応型予測型でも良いが…

Slide 18

Slide 18 text

予測型計画でもリスクを減らす方法逐次型の代表的な開発手法、だがこれといった定義があるわけではない ● 小さな機能を切り出し、一通りの開発パイロット開発をやり、本開発の不確実性を減らす [Royce 1970] ● 一度に全てを詳細化しスケジュールを作ってしまうと、開発直後からリスケばかり発生し、マネージャの労力はそこに裂かれてしまう。ローリングウェーブ計画法にしたがい、詳細なスケジュールを立てるのは直近のみにする。[Manage It!]

Slide 19

Slide 19 text

ローリングウェーブ計画法 ● 遠い未来はざっくり計画しておいて、近い未来は詳細に計画する ● 必然的に、時間の経過にともなって計画の詳細化を繰り返す計画計画 Now

Slide 20

Slide 20 text

不確実性の管理 https://www.linkedin.com/pulse/issue-risk-what-difference-sanjeev-kulkarni/ Risk Issue 未来にフォーカス現在・過去にフォーカスプロジェクト期間中に、主要なリソースがいなくなるかもしれない。チームメンバが離任する。最終日はxxなので、引き継ぎを計画するチームメンバがプロジェクトの大事な期間に休暇をとるかもしれない。チームメンバが休暇をとった時、他の誰も対処できないことがある。予期せぬ要求の変更があるかもしれないプロジェクトのスコープに追加するべき機能が見つかった影響分析すると、プロジェクトのスケジュールを遅延させる問題が見つかるかもしれない影響分析の結果、プロジェクトを一週間後ろ倒ししそうな新たな問題が2つ見つかったマトリックス型の組織でプロジェクトを進めると、現場が混乱し生産性が低下するかもしれない我々の組織はマトリックス型なので、PMの権限と説明責任について混乱を減らすために、それを明記した文書を作成する必要がある

Slide 21

Slide 21 text

IssueとRiskの役割の違い ● Issue ○ 顕在化した不確実性要素の内部シェア ○ タスク化してバックログに積む ● Risk ○ 対処予算の確保 ○ エグゼクティブラインを動かす

Slide 22

Slide 22 text

リスク対応戦略リスク発生の際の損害の大きさ(影響度) リスクの発生可能性脅威 × 脆弱性 (情報資産の価値) リスク保有リスク低減リスク移転リスク回避リスク回避高低大小

Slide 23

Slide 23 text

スコープを決める主要な成果物と各成果物の受け入れ基準を特定する

Slide 24

Slide 24 text

WBS プロジェクトを進めるに当たって、必要なものを洗い出さないと計画を立てることができないので、階層構造として洗い出す。基本的には予測型計画向き。 ● 100％ルール (いわゆるMECEというヤツ) ● 基本的には成果物ベースでブレイクダウン (NOT タスクベース) ● 実行順序や実行時間はWBSには含めない (複雑さが増すため)

Slide 25

Slide 25 text

演習問題: WBSを作ってみよう完全受注生産のECサイトを作ります。ユーザは商品を検索し、カートに積み予約注文します。商品手配できたら、ユーザに手配完了メールを送信し、ユーザは決済し、配送先住所を入力します。配送は別システムなので、受注リストを出力して完了です。

Slide 26

Slide 26 text

プロジェクトが予測可能でない場合 https://www.atlassian.com/ja/agile/project-management/epics-stories-themes Initiative Epic Story/Task 予測可能でない前提をおくので、 ● WBSの100％ルールは適用しない ● 必要な範囲だけ詳細化(ブレイクダウン)する

Slide 27

Slide 27 text

User Story ユーザーストーリーは、システムやソフトウェアのユーザや購入者にとって価値のある機能を説明するもの ● (理想)Storyは互いに独立している。Storyはどのような順序でも開発できるように記述する。 ● ストーリーの詳細は、ユーザーと開発者の間で交渉される。 ● ストーリーは、ユーザまたは顧客に対する価値が明確になるように書く ● ストーリーに注釈を付ける最も良い方法の1つは、ストーリーのテストケースを書くことである。 ● ストーリーはテスト可能でなければならない。 User Stories Applied

Slide 28

Slide 28 text

スコープに関する注意 ● doneドリフト ○ 適応型計画の元では、プロジェクトのdoneの定義が動き続ける。 ○ イテレーション毎のストーリーはdoneをドリフトさせないようにコントロールしなければならない。 ● スコープクリープ ○ 予測型計画の元では、対応するスケジュール、予算、リソースの必要性を調整することなく、追加のスコープや要件を受け入れてしまうことがある。 ○ 受け入れる前に、必ず変更管理を行い、必ず時間バッファ、予算バッファへの影響を見積もり評価する。 PMBOK 7

Slide 29

Slide 29 text

見積プロジェクトのコスト、リソース、労力、期間を定量的に評価する何のために? ● プロジェクトに関するサイズ/コスト/日付の「桁」がどれくらいかを把握する。 ● もうすぐ終わるから、いつ終わるか知りたい。 ● ある程度の期間、お金や人のチームを割り当てる必要がある。 ● 誰が、誰を責任を求めるべきか知りたい。 https://www.amazon.co.jp/dp/1943487006

Slide 30

Slide 30 text

見積: 絶対見積と相対見積 ● 絶対見積 ○ 具体的な時間、コストを割り当てる ○ 誰がやるかによって変動性が少ないなら、これでも良いが… ● 相対見積 ○ 基準タスクとのサイズの違いを相対的に割り当てる

Slide 31

Slide 31 text

SWAGとプランニングポーカー経験に基づき見積ができない場合は、SWAG(科学的な野蛮な推測)を使う。 ● 実際タスクを実行するチームメンバで見積もりをおこなう。 ● 楽観的、可能性が最も高い、悲観的の3点見積を使うこともある。 ● または、プランニングポーカーを使い、チームの合意する数値を導く。 ○ プランニングポーカーにはメンバ間のストーリー、タスクに関する認識のずれを検出する目的もある。プランニングポーカー https://en.wikipedia.org/wiki/Planning_poker

Slide 32

Slide 32 text

見積: DeterministicかProbabilisticか? ● Deterministic (決定論的) ○ コミットメントに使う ○ 不確実性分のバッファを含める ● Probabilistic (確率的) ○ 計画に使う https://qiita.com/miyarappo/items/e27f6e8774bdb587e00d

Slide 33

Slide 33 text

見積: AccuracyとPrecision ● PrecisionよりもAccuracyが優先 ● Accuracyを上げるためにできること ○ インチペブル ■ 見積もりたいタスク群に似たサイズの小さなタスクを1日〜2日で実際に実行してみる ○ Yesterday's Weather ■ 過去のタスク実績を記録しておいて、見積りたいタスクに類似の記録を探し、その実績値を見積とする

Slide 34

Slide 34 text

3点見積 ● 楽観的見積: 最も良好な条件下での最小の見積 (Optimistic) ● 最も可能性の高い見積: 最もありえそうな見積 (Most Likely) ● 悲観的見積: 最も好ましくない条件下での見積 (Pessimistic) Optimistic Most Likely Pessimistic Optimistic + 4×Most Likely + Pessimistic 6

Slide 35

Slide 35 text

不確実性のコーン ● 見積は「推測」であり不確実性を多分に含む ● プロジェクトの初期段階であればあるほど、不確実性は大きい Reducing estimation uncertainty with continuous assessment: tracking the "cone of uncertainty"

Slide 36

Slide 36 text

スケジューリング予測型手法でのスケジューリング 1. 具体的なタスクに分解する。(See. WBS) 2. 関連するタスクを順番に並べる。 3. タスクを完了するために必要な労力、期間、人、物理的リソースを見積もる。(See. 見積) 4. 利用可能性に基づいて、人員と資源を活動に割り当てる。 5. 合意されたスケジュールが達成されるまで、順序、見積もり、リソースを調整する。 PMBOK 7

Slide 37

Slide 37 text

タスク間の関係性 Task A Task B Task A Task B Task A Task B Start-to-Start Finish-to-Start Finish-to-Finish

Slide 38

Slide 38 text

実はFinish-to-Startでないもの機能A 実装機能A テスト機能A 実装機能A テスト完了基準となるタスクはFinish-to-Finishでスケジューリングする。見積が変わらない限り、スケジュール短縮されるものではないが、手戻りによるリスケを減らせる

Slide 39

Slide 39 text

演習問題: スケジューリングとタスクの分解 A B 以下のスケジュールを短縮できるでしょうか? C D A: 認証モジュールを作る (見積: 3日) B: 認証モジュールをテストする (見積: 2日) C: 認証ライブラリが返すユーザオブジェクトを使って、検索するプログラムを作る (見積: 3日) D: 検索機能をテストする (見積: 2日)

Slide 40

Slide 40 text

解答例 A B C D A’ A: 認証モジュールインタフェースを作る (見積: 1日) A’: 認証モジュールを作る(見積: 2日) B: 認証モジュールをテストする (見積: 2日) C: 認証ライブラリが返すユーザオブジェクトを使って、　検索するプログラムを作る (見積: 3日) D: 検索機能をテストする (見積: 2日)

Slide 41

Slide 41 text

スケジュールの圧縮 ● Crashing ○ 重要なタスクにリソースを追加する ● Fast Tracking ○ クリティカルパス上の作業をオーバーラップさせるどちらも危険な香りがプンプンするが、元々の計画が甘ければ上手くいくこともある…

Slide 42

Slide 42 text

見積、スケジュールから予算への変換 Task 1 Task 2 2人で5日 1人で3日山積み表 Aさん Bさん集計した費用 Σ 不確実性分のバッファ

Slide 43

Slide 43 text

設計がスケジューリングに大きな影響を与える ● 抽象レイヤを見出し、タスクを分解する ○ 結果、並行開発可能性が上がる ● 2つのタスクが本当にFinnish-to-Startかどうかを考える ● リソースまたは人員に余裕があればタスクを割り当てて工期を短縮できる。

Slide 44

Slide 44 text

設計が見積に大きな影響を与える ● 業務で定義される振る舞いに着目し、異なる振る舞いをするものを見つけ出す。 ● ざっくりした振る舞いの理解に基づいたデータ型定義だけでは、複雑さを見逃す。 ○ 参照: なぜデータモデリングが重要なのか? ○ 参照: Domain Modeling Made Functional

Slide 45

Slide 45 text

リソース効率とフロー効率 ● リソース効率 ○ 各人の稼働率をあげることを目的にする ● フロー効率 ○ タスクのリードタイムを短くすることを目的にする Create Your Successful Agile Project && https://www.slideshare.net/i2key/xpjug

Slide 46

Slide 46 text

デリバリとデプロイ ● デリバリ ○ 本番リリース一歩手前まで持っていくこと(ビジネスサイドにデプロイ判断は委ねる) ● デプロイ ○ 本番リリースする https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment

Slide 47

Slide 47 text

リソース効率に潜む問題 ● コンテキストスイッチによって ● 1人1タスク以上持つことが多いので、必然的にチーム内のコラボレーションが発生しにくくなる ● タスク割当のための労力が大きい (マネジメントの工数が大きくなる)

Slide 48

Slide 48 text

WIP(Work In Progress) フロー効率においては、チームが一度にどれだけのタスクを扱うか? が重要。 → WIPが多すぎると、フロー効率が下がるアジャイル(というかリーン)におけるマネジメントのベースは、 WIPの上限を定めて、デリバリを安定させること

Slide 49

Slide 49 text

大きすぎるWIPの問題 Software Development Metrics WIPが大きい稼働率が高すぎるコラボレーションが減る詳細に目が行きすぎる詳細に目が行きすぎるミス、エラーが増えるコンテキストスイッチが多いサイクルタイムが長い納期に追われるストレス疲労困憊残業過多他人を助ける余裕がない注意力散漫焦り

Slide 50

Slide 50 text

Steering

Slide 51

Slide 51 text

予測型手法適応型手法開発作業メトリクス計測メトリクス計測開発作業動く目標値に対して、計測したメトリクスを元にイテレーション計画を調整するプロセス改善プロセス改善目標と実績のズレを計測しプロセス改善する

Slide 52

Slide 52 text

スコープ完了率見積時間orストーリーポイントがどれだけ完了したかを時系列でトラッキングする。トレンドラインを見れば、着地点を推測できるので、対策を打つ。

Slide 53

Slide 53 text

バッファ燃焼率バッファを使い切らなければ、デリバリの遅れ、計画コストの超過は免れる。「Software Development Metrics」イエローゾーンレッドゾーンイエローゾーングリーンゾーン

Slide 54

Slide 54 text

テスト実施済み(本番投入可能)機能適応型プロセスにおいて、本番投入可能な機能をイテレーション毎に作れているかを検証する。テストは回帰的に実行するので、あるフィーチャーの実装で、本番投入可能なものを壊してしまったことも検出する。

Slide 55

Slide 55 text

ベロシティタイムボックスを使うプロジェクトにおいて、次のタイムボックスの出来高を推測するのに使う。ベロシティを目標設定に使ったり、チーム間の生産性比較に使ったりしてはならない。

Slide 56

Slide 56 text

Ramp up ベロシティは開発の初めの数イテレーションは最大値が出ない。これを踏まえて計画する。このRamp up期間は予測型開発においても同じ。スケジューリングの際に考慮する。

Slide 57

Slide 57 text

累積フローどの作業にどれくらい時間がかかっているか? ボトルネックを探すために使う。

Slide 58

Slide 58 text

Activity

Slide 59

Slide 59 text

要件定義 ● 本当の問題を見つける ● エッジケースを探す ● 抽象化と視座の上げ下げ

Slide 60

Slide 60 text

本当の問題を見つける解の質イシュー度 ①「イシュー」の見極め ②「解」の徹底した磨き込み

Slide 61

Slide 61 text

例題: 安心できないマーケットプレイスマーケットプレイスを運用するA社は、出店している店舗の質低下に悩まされている。発送したが届かない、違うものが届くなどが相次ぎクレーム対応におわれることになった。この出店店舗の質低下に対して、どういう対策が考えられるだろうか…?

Slide 62

Slide 62 text

解答例: エスクロー ① 購入意思表示 ② 支払い ③ 支払い通知 ⑥ 支払い A社問題を「カスタマが安心して買える(カスタマ不利益をもたらさない)こと」と考える ④ 配送 ⑤ 受取通知

Slide 63

Slide 63 text

例題: 混雑するエレベータ ● 73階建てのオフィスビルは、いつもエレベータが混雑している。 ● このビルの入居企業はだいたい平日9:00〜17:00が定時である。 ● だいたいが金融関係の企業である。 ● 入居者たちはほぼ均等に73フロアに分散している。 ● ビルのオーナーは空いているオフィススペースを埋めるために、多額の借金をして広告をうった。 ● 狭い金融業界では、エレベータの混雑具合について落胆の声が広がっている。

Slide 64

Slide 64 text

解: エレベータホールに鏡を設置問題は「待ち時間が長いこと」ではなく「利用者がエレベータの待ち時間にフラストレーションを溜めること」

Slide 65

Slide 65 text

エッジケースを探す ● 要求を分類し、どこまでが同じで、どこからが違うかの境界を作る。 ● 「曖昧な」言葉が含まれていないか? ● エラーケースが考慮されているか? エッジケースの探索は、たぶんに設計に踏み込むことがあるが、後の見積漏れを防ぐためには甚だ重要なことである。

Slide 66

Slide 66 text

演習問題: 送料無料サービスとある書籍のECサイトで、 5,000円以上の全ての注文で送料は無料にするという旨の要求を聞いた。追加で確認しておかなくてはならないことは何だろうか?

Slide 67

Slide 67 text

解答例 ● 5,000円に税金は含まれますか? ● 5,000円に現在の送料が含まれますか? ● 5,000円に含むのは紙の本だけですか? 同じ注文の電子書籍も含まれますか? ● どのような配送手段がありますか? 優先順位は? ● 国際注文の場合はどうなりますか? ● 5,000円の制限は将来どれくらい変わりそうですか? https://www.amazon.co.jp/dp/0135957052

Slide 68

Slide 68 text

演習問題: オンラインコミックオンラインコミックのサイトを作ります。紙と連動していて、連載が載る雑誌とその後発刊される単行本のそれぞれが、購入できてオンラインで閲覧できます。以下のような料金体系や割引サービスを考えていて、今後も様々なキャンペーンと割引サービスを計画していきたいと考えています。 ● 定期購読 ● 読み放題サブスクリプション ● 学割 ● 誕生月割 ● 提携先からの登録割引この要求に対して、どのようなコンセプトで料金体系と割引サービスを設計し、柔軟性を確保しますか?

Slide 69

Slide 69 text

抽象化と視座の上げ下げ

Slide 70

Slide 70 text

視点・視野・視座と意思決定構造の関係性視点どこに着目するか代替案の評価・選択センス (論理性) 視野見えている範囲代替案をどれだけ出せるか経験視座見ているものの抽象度コンテキストを適切に捉えているか? 職位影響する箇所必要な要素

Slide 71

Slide 71 text

垂直思考と水平思考 ● 垂直思考 ○ いわゆるロジカルシンキング ○ 代替案をMECEに検討し、思考を掘り下げる ● 水平思考 ○ 思考の幅をひろげ、本質を考える ○ 「抽象化」と「常識を疑うこと」が鍵

Slide 72

Slide 72 text

ダイアログマッピングで考える https://scrapbox.io/kawasima/厄介な問題

Slide 73

Slide 73 text

演習問題: サイネージ広告の掲載 A社はサイネージ広告プラットフォームを提供しています。広告は1ヶ月契約で、時間枠を購入し、その分だけ広告原稿を制作して入稿します。 ● 毎月、翌月の購入枠数を3営業日前までに、クライアントは入稿します。 ○ 広告の事前審査を行うためのリードタイムです。 ● 広告は当月のものと同じものを流用して入稿することができます。 ● A社の担当者は、広告枠に穴がでないように、クライアントへ入稿を催促したり、月途中で契約落ちの穴埋めを売り込んで、代替原稿を入稿してもらったりします。 A社にとって業務がなるべく楽にまわせるよう、必要な仕組みを設計してみましょう。

Slide 74

Slide 74 text

次月の広告枠購入広告原稿作成審査催促枠数充足チェック掲載

Slide 75

Slide 75 text

担当者目線を外して、もっと高い視座で考えてみる ● 顧客は毎月広告を入稿したい訳ではない。 (毎月入稿してもらうのはA社の売り方の都合) ● A社は広告枠に穴がでると売上が下がるので、できるだけ多くの売上の見込める原稿ストックを持っておきたい。 ● 月末に向けてのやりとりを減らすには、できるだけ多くの審査済みの原稿をストックしておければよい。

Slide 76

Slide 76 text

Wrap up ソフトウェアエンジニアリング全般(設計もマネジメントも) 不確実性と複雑さをどう認識し扱うかについてである、と考えておくと良い。