現代的システム開発概論

2023年度リクルート エンジニアコース新人研修の講義資料です

Transcript

1. 現代的システム開発概論 2023 株式会社ウルフチーフ 川島義隆
2. この講座で学んでほしいこと • SIerでは研修および業務で学べるような「ソフトウェアエンジニアリング」 のエッセンスを身につける • プロジェクトマネジメントのうち、特にプランニングはソフトウェアの設計 と結び付きが強く、相互に影響を与えるので、両方おさえておかなければな らない
3. ソフトウェア工学 • 要求 • アーキテクチャ • 設計 • 構築 • テスト • 運用 • 保守 • 構成管理 • マネジメント • プロセス • モデル・手法 • 品質 • セキュリティ • プロフェッショナル実践 • 計算基礎 • 数学・エンジニアリング基礎 • アジャイル / DevOps SWEBOK 4
4. プロジェクトとは何か? プロジェクトとは、独自のプロダクト、サービス、所産を創造するために実施す る有期性のある業務 • 特定の成果を達成するための組織 • 期限が限定されている(有期性) • 同じものはない(独自性) • 相互に関連する作業の調整がなされる(相互関連性) PMBOK 4
5. Planning
6. プロジェクト計画 計画の「変数」を予測、コントロールの方針を立てる • 開発手法 • 成果物 • 組織の要求事項 • 市場の状況 • 法律または規制による制限 • デリバリー • 見積 • スケジュール • 予算 PMBOK 7
7. 計画 不確実性を減らす、明らかにする、局所化する In preparing for battle I have always found that plans are useless, but planning is indispensable. ー Dwight D. Eisenhower
8. プロジェクトピラミッド https://scrapbox.io/kawasima/プロジェクトの変数コントロール
9. 時間とコストのトレードオフ 最適ポイントを超えて、時間を短 縮しようとするとコストが跳ね上 がる。 Project Planning, Scheduling, and Control, Sixth Edition
10. Delivery(リリース基準) プロジェクトにとって重要なことは何か? • リリースの日程 • 機能セット • 欠陥の少なさ • 品質特性 など、これらを満たしたらリリース可能といえる基準を決めておく。
11. 開発ライフサイクル 種類 ライフサイクルの例 長所および成功に必要な条件 逐次型 ウォーターフォール フェーズゲート • コストのリスクを管理できる • 既知かつ合意済みの要件 • アーキテクチャをよく理解できている • プロジェクトの過程で要件が変更されない 反復型 スパイラル 進化的プロトタイピング • 技術的リスクを管理できる • 要件が進化し続ける 漸進型 スケジュールに応じた設計、段階的 納品 • スケジュールのリスクを管理できる 反復漸進型 (適応型) アジャイル • スケジュールと技術的の両方のリスクを管理できる • 全てのメンバが同一サイトで作業を行える • 統合チーム以外では円滑な進行が難しい 場当たり型 Code and Fix Manage It! 3.2 ライフサイクルの概要
12. 逐次型 作るものが予測可能 (不確実性は含む)であることを前提とする 不確実性をコスト/時間に転化する プロジェクト計画時点では、不確実性のボリュームを想定し、 Negativeな方に現実化された時の対処費用と対応時間を算出しバッ ファとして積んでおく
13. 反復型と漸進型の違い PMBOK ７
14. https://martinfowler.com/bliki/WaterfallProcess.html Waterfall 予測型計画 反復型 適応型計画 アジャイル アジャイルプロセスは適応 型計画でなければならない 反復型でも機能固定でやる 場合は、予測型計画
15. 予測型と適応型プロセスの違い(イメージ図) 目標が定まっている 不確実性はバッファでコントロールする 目標と実績のズレを検知し対策を打つ 目標が動き続けるので、 (大きな方針はある) 不確実性を目標を近くに置くことで減らす
16. 不確実性 「わからない」のレベル The Five Orders of Ignorance • 0OI: 全部分かっている ◦ 「答え」を持っている。あとは実装するだけで完成する。 • 1OI: 分からないことが分かっている ◦ 答えを得るための「質問」を持っている。 • 2OI: 分からないことが分からない ◦ 「質問」を持たない状態。決定的な答えを引き出すための「質問」ができない。 • 3OI: 分からないことが分からない状況を何とかする術を知らない ◦ 2OI→1OI→0OIと進んでいくためのプロセスがない状態。 • 4OI: 無知にレベルがあることを知らない
17. Cynefin Framework 予測型 適応型 予測型でも 良いが…
18. 予測型計画でもリスクを減らす方法 逐次型の代表的な開発手法、だがこれといった定義があるわけではない • 小さな機能を切り出し、一通りの開発パイロット開発をやり、本開発の不確 実性を減らす [Royce 1970] • 一度に全てを詳細化しスケジュールを作ってしまうと、開発直後からリスケ ばかり発生し、マネージャの労力はそこに裂かれてしまう。 ローリングウェーブ計画法にしたがい、詳細なスケジュールを立てるのは直 近のみにする。[Manage It!]
19. ローリングウェーブ計画法 • 遠い未来はざっくり計画しておいて、近い未来は詳細に計画する • 必然的に、時間の経過にともなって計画の詳細化を繰り返す 計画 計画 Now
20. 不確実性の管理 https://www.linkedin.com/pulse/issue-risk-what-difference-sanjeev-kulkarni/ Risk Issue 未来にフォーカス 現在・過去にフォーカス プロジェクト期間中に、主要なリソースがいなく なるかもしれない。 チームメンバが離任する。最終日はxxなので、引 き継ぎを計画する チームメンバがプロジェクトの大事な期間に休暇 をとるかもしれない。 チームメンバが休暇をとった時、他の誰も対処で きないことがある。 予期せぬ要求の変更があるかもしれない プロジェクトのスコープに追加するべき機能が見 つかった 影響分析すると、プロジェクトのスケジュールを 遅延させる問題が見つかるかもしれない 影響分析の結果、プロジェクトを一週間後ろ倒し しそうな新たな問題が2つ見つかった マトリックス型の組織でプロジェクトを進める と、現場が混乱し生産性が低下するかもしれない 我々の組織はマトリックス型なので、PMの権限と 説明責任について混乱を減らすために、それを明 記した文書を作成する必要がある
21. IssueとRiskの役割の違い • Issue ◦ 顕在化した不確実性要素の内部シェア ◦ タスク化してバックログに積む • Risk ◦ 対処予算の確保 ◦ エグゼクティブラインを動かす
22. リスク対応戦略 リスク発生の際の損害の大きさ(影響度) リ ス ク の 発 生 可 能 性 脅 威 × 脆 弱 性 (情報資産の価値) リスク保有 リスク低減 リスク移転 リスク回避 リスク回避 高 低 大 小
23. スコープを決める 主要な成果物と各成果物の受け入れ基準を特定する
24. WBS プロジェクトを進めるに当たって、必要なものを洗い出さないと計画を立てるこ とができないので、階層構造として洗い出す。基本的には予測型計画向き。 • 100％ルール (いわゆるMECEというヤツ) • 基本的には成果物ベースでブレイクダウン (NOT タスクベース) • 実行順序や実行時間はWBSには含めない (複雑さが増すため)
25. 演習問題: WBSを作ってみよう 完全受注生産のECサイトを作ります。 ユーザは商品を検索し、カートに積み予約注文します。 商品手配できたら、ユーザに手配完了メールを送信し、ユーザは決済し、配送先 住所を入力します。 配送は別システムなので、受注リストを出力して完了です。
26. プロジェクトが予測可能でない場合 https://www.atlassian.com/ja/agile/project-management/epics-stories-themes Initiative Epic Story/Task 予測可能でない前提をおくので、 • WBSの100％ルールは適用しない • 必要な範囲だけ詳細化(ブレイクダウン)する
27. User Story ユーザーストーリーは、システムやソフトウェアのユーザや購入者にとって価値 のある機能を説明するもの • (理想)Storyは互いに独立している。Storyはどのような順序でも開発できる ように記述する。 • ストーリーの詳細は、ユーザーと開発者の間で交渉される。 • ストーリーは、ユーザまたは顧客に対する価値が明確になるように書く • ストーリーに注釈を付ける最も良い方法の1つは、ストーリーのテストケース を書くことである。 • ストーリーはテスト可能でなければならない。 User Stories Applied
28. スコープに関する注意 • doneドリフト ◦ 適応型計画の元では、プロジェクトのdoneの定義が動き続ける。 ◦ イテレーション毎のストーリーはdoneをドリフトさせないようにコントロールしなければな らない。 • スコープクリープ ◦ 予測型計画の元では、対応するスケジュール、予算、リソースの必要性を調整することな く、追加のスコープや要件を受け入れてしまうことがある。 ◦ 受け入れる前に、必ず変更管理を行い、必ず時間バッファ、予算バッファへの影響を見積も り評価する。 PMBOK 7
29. 見積 プロジェクトのコスト、リソース、労力、期間を定量的に評価する 何のために? • プロジェクトに関するサイズ/コスト/日付の「桁」がどれくらいかを 把握する。 • もうすぐ終わるから、いつ終わるか知りたい。 • ある程度の期間、お金や人のチームを割り当てる必要がある。 • 誰が、誰を責任を求めるべきか知りたい。 https://www.amazon.co.jp/dp/1943487006
30. 見積: 絶対見積と相対見積 • 絶対見積 ◦ 具体的な時間、コストを割り当てる ◦ 誰がやるかによって変動性が少ないなら、これでも良いが… • 相対見積 ◦ 基準タスクとのサイズの違いを相対的に割り当てる
31. SWAGとプランニングポーカー 経験に基づき見積ができない場合は、SWAG(科学的な野蛮な推測)を使う。 • 実際タスクを実行するチームメンバで見積もりをおこなう。 • 楽観的、可能性が最も高い、悲観的の3点見積を使うこともある。 • または、プランニングポーカーを使い、チームの合意する数値を導く。 ◦ プランニングポーカーにはメンバ間のストーリー、タスクに関する認識のずれを検出する目 的もある。 プランニングポーカー https://en.wikipedia.org/wiki/Planning_poker
32. 見積: DeterministicかProbabilisticか? • Deterministic (決定論的) ◦ コミットメントに使う ◦ 不確実性分のバッファを含める • Probabilistic (確率的) ◦ 計画に使う https://qiita.com/miyarappo/items/e27f6e8774bdb587e00d
33. 見積: AccuracyとPrecision • PrecisionよりもAccuracyが優先 • Accuracyを上げるためにできること ◦ インチペブル ▪ 見積もりたいタスク群に似たサイズの小さなタスクを1日〜2日で実際に実行してみる ◦ Yesterday's Weather ▪ 過去のタスク実績を記録しておいて、見積りたいタスクに類似の記録を探し、その実績 値を見積とする
34. 3点見積 • 楽観的見積: 最も良好な条件下での最小の見積 (Optimistic) • 最も可能性の高い見積: 最もありえそうな見積 (Most Likely) • 悲観的見積: 最も好ましくない条件下での見積 (Pessimistic) Optimistic Most Likely Pessimistic Optimistic + 4×Most Likely + Pessimistic 6
35. 不確実性のコーン • 見積は「推測」であり不 確実性を多分に含む • プロジェクトの初期段階 であればあるほど、不確 実性は大きい Reducing estimation uncertainty with continuous assessment: tracking the "cone of uncertainty"
36. スケジューリング 予測型手法でのスケジューリング 1. 具体的なタスクに分解する。(See. WBS) 2. 関連するタスクを順番に並べる。 3. タスクを完了するために必要な労力、期間、人、物理的リソースを見積も る。(See. 見積) 4. 利用可能性に基づいて、人員と資源を活動に割り当てる。 5. 合意されたスケジュールが達成されるまで、順序、見積もり、リソースを調 整する。 PMBOK 7
37. タスク間の関係性 Task A Task B Task A Task B Task A Task B Start-to-Start Finish-to-Start Finish-to-Finish
38. 実はFinish-to-Startでないもの 機能A 実装 機能A テスト 機能A 実装 機能A テスト 完了基準となるタスクはFinish-to-Finishでスケ ジューリングする。 見積が変わらない限り、スケジュール短縮されるものではないが、手戻りによ るリスケを減らせる
39. 演習問題: スケジューリングとタスクの分解 A B 以下のスケジュールを短縮できるでしょうか? C D A: 認証モジュールを作る (見積: 3日) B: 認証モジュールをテストする (見積: 2日) C: 認証ライブラリが返すユーザオブジェクトを使って、検索するプ ログラムを作る (見積: 3日) D: 検索機能をテストする (見積: 2日)
40. 解答例 A B C D A’ A: 認証モジュールインタフェースを作る (見積: 1日) A’: 認証モジュールを作る(見積: 2日) B: 認証モジュールをテストする (見積: 2日) C: 認証ライブラリが返すユーザオブジェクトを使って、 　検索するプログラムを作る (見積: 3日) D: 検索機能をテストする (見積: 2日)
41. スケジュールの圧縮 • Crashing ◦ 重要なタスクにリソースを追加する • Fast Tracking ◦ クリティカルパス上の作業をオーバーラップさせる どちらも危険な香りがプンプンするが、元々の計画 が甘ければ上手くいくこともある…
42. 見積、スケジュールから予算への変換 Task 1 Task 2 2人で5日 1人で3日 山積み表 Aさん Bさん 集計した費用 Σ 不確実性分の バッファ
43. 設計がスケジューリングに大きな影響を与える • 抽象レイヤを見出し、タスクを分解する ◦ 結果、並行開発可能性が上がる • 2つのタスクが本当にFinnish-to-Startかどうかを考える • リソースまたは人員に余裕があればタスクを割り当てて 工期を短縮できる。
44. 設計が見積に大きな影響を与える • 業務で定義される振る舞いに着目し、異なる振る舞いをするものを見 つけ出す。 • ざっくりした振る舞いの理解に基づいたデータ型定義だけでは、複雑 さを見逃す。 ◦ 参照: なぜデータモデリングが重要なのか? ◦ 参照: Domain Modeling Made Functional
45. リソース効率とフロー効率 • リソース効率 ◦ 各人の稼働率をあげることを目的にする • フロー効率 ◦ タスクのリードタイムを短くすることを目的にする Create Your Successful Agile Project && https://www.slideshare.net/i2key/xpjug
46. デリバリとデプロイ • デリバリ ◦ 本番リリース一歩手前まで持っていくこと(ビジネスサイドにデプロイ判断は委ねる) • デプロイ ◦ 本番リリースする https://www.atlassian.com/continuous-delivery/principles/continuous-integration-vs-delivery-vs-deployment
47. リソース効率に潜む問題 • コンテキストスイッチによって • 1人1タスク以上持つことが多いので、必然的にチーム内のコラボレーション が発生しにくくなる • タスク割当のための労力が大きい (マネジメントの工数が大きくなる)
48. WIP(Work In Progress) フロー効率においては、チームが一度にどれだけのタスクを扱うか? が重要。 → WIPが多すぎると、フロー効率が下がる アジャイル(というかリーン)におけるマネジメントのベースは、 WIPの上限を定めて、デリバリを安定させること
49. 大きすぎるWIPの問題 Software Development Metrics WIPが大きい 稼働率が 高すぎる コラボレーション が減る 詳細に目が 行きすぎる 詳細に目が 行きすぎる ミス、エラー が増える コンテキスト スイッチが多い サイクル タイムが長い 納期に追われる ストレス 疲労困憊 残業過多 他人を助ける 余裕がない 注意力 散漫 焦り
50. Steering
51. 予測型手法 適応型手法 開発 作業 メトリクス 計測 メトリクス 計測 開発 作業 動く目標値に対して、計測したメトリクスを 元にイテレーション計画を調整する プロセス改善 プロセス改善 目標と実績のズレを計測しプロセス改善する
52. スコープ完了率 見積時間orストーリーポイン トがどれだけ完了したかを時 系列でトラッキングする。 トレンドラインを見れば、着 地点を推測できるので、対策 を打つ。
53. バッファ燃焼率 バッファを使い切らなければ、デリ バリの遅れ、計画コストの超過は免 れる。 「Software Development Metrics」 イエロー ゾーン レッドゾーン イエロー ゾーン グリーン ゾーン
54. テスト実施済み(本番投入可能)機能 適応型プロセスにおいて、本番投 入可能な機能をイテレーション毎 に作れているかを検証する。 テストは回帰的に実行するので、 あるフィーチャーの実装で、本番 投入可能なものを壊してしまった ことも検出する。
55. ベロシティ タイムボックスを使うプロジェクトに おいて、次のタイムボックスの出来高 を推測するのに使う。 ベロシティを目標設定に使ったり、 チーム間の生産性比較に使ったりして はならない。
56. Ramp up ベロシティは開発の初めの数イテレーションは最大値が出ない。 これを踏まえて計画する。 このRamp up期間は予測型開発においても同じ。 スケジューリングの際に考慮する。
57. 累積フロー どの作業にどれくらい時間がかかって いるか? ボトルネックを探すために使う。
58. Activity
59. 要件定義 • 本当の問題を見つける • エッジケースを探す • 抽象化と視座の上げ下げ
60. 本当の問題を見つける 解の質 イシュー度 ①「イシュー」 の見極め ②「解」の徹底 した磨き込み
61. 例題: 安心できないマーケットプレイス マーケットプレイスを運用するA社は、出店している店舗の質低下に悩まされている。 発送したが届かない、違うものが届くなどが相次ぎクレーム対応におわれることになっ た。 この出店店舗の質低下に対して、どういう対策が考えられるだろうか…?
62. 解答例: エスクロー ① 購入意思表示 ② 支払い ③ 支払い通知 ⑥ 支払い A社 問題を「カスタマが安心して買える(カスタマ不利益をもたらさない)こと」と考える ④ 配送 ⑤ 受取通知
63. 例題: 混雑するエレベータ • 73階建てのオフィスビルは、いつもエレベータが混雑している。 • このビルの入居企業はだいたい平日9:00〜17:00が定時である。 • だいたいが金融関係の企業である。 • 入居者たちはほぼ均等に73フロアに分散している。 • ビルのオーナーは空いているオフィススペースを埋めるために、多額の借金 をして広告をうった。 • 狭い金融業界では、エレベータの混雑具合について落胆の声が広がってい る。
64. 解: エレベータホールに鏡を設置 問題は「待ち時間が長いこと」ではなく「利用者がエレベータの待ち時間にフラ ストレーションを溜めること」
65. エッジケースを探す • 要求を分類し、どこまでが同じで、どこからが違うかの境界を作る。 • 「曖昧な」言葉が含まれていないか? • エラーケースが考慮されているか? エッジケースの探索は、たぶんに設計に踏み込むことがあるが、後 の見積漏れを防ぐためには甚だ重要なことである。
66. 演習問題: 送料無料サービス とある書籍のECサイトで、 5,000円以上の全ての注文で送料は無料にする という旨の要求を聞いた。追加で確認しておかなくてはならないことは 何だろうか?
67. 解答例 • 5,000円に税金は含まれますか? • 5,000円に現在の送料が含まれますか? • 5,000円に含むのは紙の本だけですか? 同じ注文の電子書籍も含まれますか? • どのような配送手段がありますか? 優先順位は? • 国際注文の場合はどうなりますか? • 5,000円の制限は将来どれくらい変わりそうですか? https://www.amazon.co.jp/dp/0135957052
68. 演習問題: オンラインコミック オンラインコミックのサイトを作ります。紙と連動していて、連載が載る雑誌とその後 発刊される単行本のそれぞれが、購入できてオンラインで閲覧できます。 以下のような料金体系や割引サービスを考えていて、今後も様々なキャンペーンと割引 サービスを計画していきたいと考えています。 • 定期購読 • 読み放題サブスクリプション • 学割 • 誕生月割 • 提携先からの登録割引 この要求に対して、どのようなコンセプトで料金体系と割引サービスを設計し、柔軟性 を確保しますか?
69. 抽象化と視座の上げ下げ
70. 視点・視野・視座と意思決定構造の関係性 視点 どこに着目するか 代替案の評価・選択 センス (論理性) 視野 見えている範囲 代替案をどれだけ出せ るか 経験 視座 見ているものの抽象度 コンテキストを適切に 捉えているか? 職位 影響する箇所 必要な要素
71. 垂直思考と水平思考 • 垂直思考 ◦ いわゆるロジカルシンキング ◦ 代替案をMECEに検討し、思考を掘り下げる • 水平思考 ◦ 思考の幅をひろげ、本質を考える ◦ 「抽象化」と「常識を疑うこと」が鍵
72. ダイアログマッピングで考える https://scrapbox.io/kawasima/厄介な問題
73. 演習問題: サイネージ広告の掲載 A社はサイネージ広告プラットフォームを提供しています。 広告は1ヶ月契約で、時間枠を購入し、その分だけ広告原稿を制作して入稿します。 • 毎月、翌月の購入枠数を3営業日前までに、クライアントは入稿します。 ◦ 広告の事前審査を行うためのリードタイムです。 • 広告は当月のものと同じものを流用して入稿することができます。 • A社の担当者は、広告枠に穴がでないように、クライアントへ入稿を 催促したり、月途中で契約落ちの穴埋めを売り込んで、代替原稿を 入稿してもらったりします。 A社にとって業務がなるべく楽にまわせるよう、必要な仕組みを 設計してみましょう。
74. 次月の広告枠購入 広告原稿作成 審査 催促 枠数充足チェック 掲載
75. 担当者目線を外して、もっと高い視座で考えてみる • 顧客は毎月広告を入稿したい訳ではない。 (毎月入稿してもらうのはA社の売り方の都合) • A社は広告枠に穴がでると売上が下がるので、できるだけ多くの売上の見込める原稿ス トックを持っておきたい。 • 月末に向けてのやりとりを減らすには、できるだけ多くの審査済みの原稿をストック しておければよい。
76. Wrap up ソフトウェアエンジニアリング全般(設計もマネジメントも) 不確実性と複雑さ をどう認識し扱うかについてである、と考えておくと良い。