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