2019年度リクルート新人ブートキャンプ エンジニアコースの講義資料です
現代的システム開発概論 (v1.0)株式会社ウルフチーフ川島 義隆
View Slide
プロジェクトを進める上での基礎知識
プロジェクトとは何か?プロジェクトとは、独自のプロダクト、サービス、所産を創造するために実施する有期性のある業務 (PMBOKの定義)●特定の成果を達成するための組織● 期限が限定されている (有期性)● 同じものはない (独自性)● 相互に関連する作業の調整がなされる(相互関連性)
マネジメントのことが好きじゃない/苦手でも、プロジェクトマネージャと対等に話するためにPMBOKの内容くらいは学んでおいたほうが良い…が、退屈な内容であることは変わりない私はこの本で分かった気になった
マネジメントライフサイクル● 計画: QCDSを決める● 実行: 計画にしたがって作業をする● 監視: 計画と実績のズレを測る● コントロール: ズレに対応する
計画Plans are useless, but planningis indispensable. – Eisenhower計画そのものは刻一刻と状況が変わりゆくプロジェクトにおいては役に立たない。どんなライフサイクルを採用しようとも、再計画を想定しておかなければならない
プロジェクト計画だいたい次のようなことを書く●プロダクトの目的●履歴●リリース基準●プロジェクトの目標●プロジェクトの編成●スケジュールの概要● プロジェクトの人員配置(人員配置の計画)●スケジュール案●リスク一覧
ローリングウェーブ計画法●段階的に詳細化する、計画策定の方法。●直近の作業は詳細に、先の作業はおおざっぱに計画する。●初期段階では、ワーク・パッケージの要素分解はマイルストーン・レベル。●プロジェクトが進行し、詳細が判明するにつれて、ワーク・パッケージはアクティビティに分解される。
リリース基準プロジェクトにとって重要なことは何か?– リリースの日程– 機能セット– 欠陥の少なさ– 品質特性など、これを満たしたらリリース可能という基準を定める。
トレードオフ・スライダーを使って会話するとよい
リリース基準の書き方はSMARTに● 具体的 (Specific)● 計測可能 (Measurable)● 達成可能 (Attainable)● 現実的 (Relevant)● 追跡可能 (Trackable)Time Boundとされることが多いが、Manage It!で使われているTrackableの方が意味合いがハッキリする
RiskとIssueの違いRisk Issue未来にフォーカス 現在・過去にフォーカスプロジェクト期間中に、主要なリソースが居なくなるかもしれないチームメンバが離任する。最終日は✕✕なので、引き継ぎを…チームメンバがプロジェクトの大事な期間に休暇をとるかもしれない。チームメンバが休暇を取ったとき、他の誰も対処できないことがある。予期せぬ要求の変更があるかもしれないプロジェクトのスコープに追加すべき機能が見つかった影響分析すると、プロジェクトのスケジュールを遅延させる問題が見つかるかもしれない。影響分析の結果、プロジェクトを1週間後ろ倒ししそうな新たな問題が2つ見つかった。マトリックス型の組織でプロジェクトを進めると、現場が混乱し生産性が低下するかもしれない。我々の組織はマトリックス型なので、PMの権限と説明責任について混乱を減らすために、それを明記した文書を作成する必要がある。https://www.linkedin.com/pulse/issue-risk-what-difference-sanjeev-kulkarni/
RiskはIssueとは使い方が違う。– 対処予算の確保– エグゼクティブラインを動かす
リスク対応戦略
リスクの主観的価値の非線形性質問1:あなたの目の前に、以下の二つの選択肢が提示されたものとする。選択肢A:100万円が無条件で手に入る。選択肢B:コインを投げ、表が出たら200万円が手に入るが、裏が出たら何も手に入らない。
質問2:あなたは200万円の負債を抱えているものとする。そのとき、同様に以下の二つの選択肢が提示されたものとする。選択肢A:無条件で負債が100万円減額され、負債総額が100万円となる。選択肢B:コインを投げ、表が出たら支払いが全額免除されるが、裏が出たら負債総額は変わらない。
プロスペクト理論
発生確率の主観評価の難しさブラックスワン1697年まではヨーロッパでは真実だった。「白鳥は白い」経験に基づく知識現在の知識の限界 → 分からないことが分からない
ブラックスワンの特徴●予測不能●非常に強いインパクトを持つ●実際に起こると後付けで説明がなされ、偶然ではなく、最初からわかっていたような気にさせられる (後知恵バイアス)
失敗を避けるのではなく失敗を前提としてシステムを設計するAvailability :=MTTFMTTF + MTTRhttps://www.slideshare.net/ufried/patterns-of-resilienceWerner Vogels(Amazon CTO): “Everythingfails all the time”MTTFを長くする → RobustMTTRを短くする → Resilient
ブラック・スワン提唱者のタレブ博士のその次の作品Antifragile(反脆弱性)は非常に面白いし、ソフトウェアの世界でも重要な概念になりつつあるので横道ですが話しておきます
プットオプションとリーマンショックhttp://www.jsda.or.jp/manabu/qa/derivative05.html
https://taylorpearson.cdnoptimus.com/wp-content/uploads/2013/05/Convexity-and-Concavity.png変動幅が大きいと儲かる(長期投資)変動幅が小さいと儲かる(短期投資)
Fragile変化に対して弱い・損失が大きい仕組み●後戻りの計画・その分の予算確保がないウォーターフォールのプロジェクト●プロビジョニングが十分でないシステム(ex. 30分 2000PVでダウンする図書館システム)●例外のハンドリングが雑なアプリケーション
Robust変化に対して、十分強い仕組み(フラジャイルの裏返し)●よく計画されたウォーターフォールの開発プロジェクト●急激なアクセス増や異常なデータファイルに対しても、安全に処理できるアプリケーション●例外を適切にハンドリング出来ているコード
Resilient大きな変化に対し、一時的にシステムのパフォーマンスを落としてもすぐに復旧できる仕組み
Antifragile変化が起これば起こるほどメリットがある仕組みストレスが増せば増すほど強くなる仕組みそんなことが可能なのでしょうか?
BenefitChangeCostAntifragileResilientRobustFragile
ダモクラス フェニックス ヒドラFragileRobust(Resilient)Antifragileちょっとしたことで上に吊るされた剣が落ちてきて死亡死んでも何度でも甦る1つ首を切ると、2つはえてくるイメージ図
トライアドのフレームワーク特になにもしない業務に関係ないものも、アレコレつまみ食いする業務で必要なものを勉強するAntifragileRobustFragile世の中の事象を、Fragile/Robust/Antifragileの3つ組(トライアド)に沿って考えると面白い。エンジニアの技術学習のトライアド
Netflix Chaosシリーズ意図的に本番障害を起こし、何が起きるかをモニタリングするChaos Monkey: EC2インスタンス単位で落とすChaos Gorilla: AZ単位で落とすChaos Kong: リージョン単位で落とすLatency Monkey: 1Microserviceのレスポンスを遅延させるhttps://www.slideshare.net/JoshEvans2/embracing-failure-reinvent-2014
https://www.youtube.com/watch?v=ZMbqbXxRthE&index=40&list=PLRsbF2sD7JVqk90s0ogP\_dcfM9T-y1DRm
WBS
WBS作成のうえで適用されるルール●100%ルール●8/80ルール●7×7ルールhttps://www.itmedia.co.jp/im/articles/1001/27/news103.html
スケジュールタスク スケジューリング 見積「Manage It!」での定義スケジュール
スケジューリングと見積の違い●スケジューリング– タスクの依存関係を明らかにし、順序付けを行うこと●見積– あるタスクが完了するのにどれくらい時間がかかるかを推定すること
タスクの依存関係A BFinish to Start Start to StartFinish to Finish Start to FinishA BA BA BBが終わるまでAが完了にならないAが完了しないとBが始められない Aを始めるまでBが始められないAを始めないとBが完了できない
Finish-to-StartA BA:認証ライブラリを作るB:認証ライブラリが返すユーザオブジェクトを使って、検索するプログラムを作る
Start-to-StartA BA:ユーザマニュアルを書くB:ユーザマニュアルをレビューする
Finish-to-FinishA BA:検索機能のテストを書くB:検索機能を作る
問題A B C DA:認証モジュール作る (3d)B:認証モジュールをテストする (2d)C:認証ライブラリが返すユーザオブジェクトを使って、検索するプログラムを作る (3d)D:検索機能をテストする (2d)以下のスケジュールを短縮することができるでしょうか?
回答例ACDA:認証モジュールインタフェース作る (1d)A’:認証モジュール実装作る(2d)B:認証モジュールをテスト作る (2d)C:認証ライブラリが返すユーザオブジェクトを使って、検索するプログラムを作る (3d)D:検索機能をテスト作る (2d)A’ B
ポイント●タスクを分解する– 抽象概念を作り出すのがポイント●2つのタスクが本当にFinish-to-Startかを考える●リソースに余裕があればタスクを割り当てて、工期を短縮できる (リソース効率を上げる)
スケジューリングの技法●トップダウンスケジューリング– まずマイルストーンを置き、それを支えるタスクをひねり出す●ボトムアップスケジューリング– 特定のタスクから始め、それに連なるタスクを洗い出しマイルストーンをひねり出す。– 漸進型ライフサイクルで有用●インサイドアウト– 自分(たち)の分かっていることをマインドマップに書き出し、そこからタスクとマイルストーンを作る●ハドソン・ベイスタート– まず小さくプロジェクトを始めてみて、そこでの理解をもとにタスクやマイルストーンを作る
計画の種類●フェーズベースの計画– 特定の部門の人たちからなるチームが、プロジェクトの各部の責任を追う。– 責任を負う人たちが「終了」と宣言すれば、そのフェーズが完了●成果物ベースの計画– 成果物に基づいたマイルストーンを置く– 成果物の完成に各チームが集中できるようになる一方、マイルストーンが守られずグダグダになるリスクがある。
https://www.slideshare.net/yusuke/itawsこれはあるあるだけれども、ウォータフォールが全てそうだというわけではなくフェーズベースの計画が適してないのに、そうしてしまったという場合の失敗
見積プロジェクトが大失敗する原因は2つある– 見積ミス– 仕様を凍結できない“見積の大部分は、非現実的で単なる希望にすぎない。さらに悪いことに、不正確な見積を改善するすべがないのだ”ソフトウエア開発 55の真実と10のウソより
見積の技法●経験ベース– 類推法– デルファイ法●アルゴリズムベース– Function Point– Use Case Point
見積の正確度と精度正確度(Accuracy) 精度(Precision)
未知の領域の見積タスクが大きいとだけ分かっていて、どれくらい大きいかを見積もる適切な方法が見当つかないスパイクタスクの情報を得るために作る小さなタイムボックス
Five Orders of Ignorance0OI: 全部分かっている「答え」を持っている。あとは書き写すだけで完成する。1OI: 分からないことが分かっている答えを得るための「質問」を持っている。2OI: 分からないことが分からない「質問」を持たない状態。決定的な答えを引き出すための「質問」ができない。3OI: 分からないことが分からない状況を何とかする術を知らない2OI→1OI→0OIと進んでいくためのプロセスがない状態です。4OI: 無知にレベルがあることを知らないhttp://qiita.com/seki_uk/items/4001423b3cd3db0dada7
ベルトとサスペンダー方式●見積の正確度をあげることができないことへの妥協策– a) 経験者の意見をベースにした見積– b) ある程度の正確度を期待できるアルゴリズムで算出した予測値の2つを使って予測する。
見積に関するおかしな真実●ソフトウェア開発の見積は、プロジェクトの開始に実施する場合が非常に多い。これだと要件定義が固まる前に見積ることになり意味がない。●プロジェクトが進むにしたがって見積を調整することはまずない。したがって不適切な時期に不適切な人間が実施した見積を修正することはほとんどない。●見積精度がいい加減だと、実際のプロジェクトが見積どおりに進まなくても、まったく気にならないはずだが、現実にはみんな気にする。
ソフトウェア開発ライフサイクル要件定義設計実装 コーディングテストデプロイ保守
開発ライフサイクル種類 ライフサイクルの例長所および成功に必要な条件 プロジェクトの優先順位逐次型 ウォーターフォール、フェーズゲート●コストのリスクを管理できる(経営陣がフェーズゲートを使用する場合)●システムアーキテクチャをよく理解できている●プロジェクトの過程で要件が変動しない1.機能セット2.欠陥の軽減3.リリース期日反復型 スパイラル、進化的プロトタイピング、RUP●技術的リスクを管理できる●要件が進化し続ける1.機能セット2.欠陥の低減3.リリース期日漸進型 スケジュールに応じた設計、段階的納品●スケジュールのリスクを管理できる●多少の要件の変更を吸収できるが、アーキテクチャに影響を与える変化には十分対応できない1.リリース期日2.欠陥の低減3.機能セット反復漸進型 アジャイル ●スケジュールのリスクと技術的リスクの両方を管理できる●すべてのメンバが同一サイトで作業を行える●統合チーム以外では円滑な進行が難しい1.リリース期日2.機能セット3.欠陥の低減場当たり型 Code and Fix なし 1.リリース期日2.機能セット3.欠陥の低減
逐次型ライフサイクル逐次型ライフサイクルを選択可能な条件●技術的リスクが小さい●スケジュールリスクが小さい●プロジェクトチームが安定している●要求変動リスクが小さい逐次型ライフサイクルで対処できるリスク●機能セット●何をいつ行うのかが分かる●コストのリスク
逐次型ライフサイクルの隠れたリスク●アーキテクチャ上のリスク– BDUFに陥る●テストのリスク●スケジュール上のリスクhttps://enterprisezine.jp/iti/detail/2392
反復型ライフサイクル●代表的なプロセス– スパイラル– 進化的プロトタイピング●反復型ライフサイクルによって対処されるリスク– 頻繁に変更される要件– 技術的なリスク
反復型ライフサイクルのリスク●スケジュールのリスク●コストのリスク– 製品の最も重要な部分でなく、製品の最もリスクを伴う部分を最初に実装することを前提としている。
反復型ライフサイクルとアジャイルの違いアジャイル 反復型イテレーション期間は一定 イテレーション期間に制限はないイテレーション終わりには機能を完成させるイテレーション終わりに必ずしも完成している必要はない
漸進型ライフサイクル顧客と頻繁にやり取りせず、機能毎に実装を行う機能チームを作れる場合に向いている。(日本の比較的大規模開発で独自進化を遂げている、五月雨式ウォータフォールはこれに近い)●漸進型ライフサイクルによって対処されるリスク– スケジュール上のリスク– プロジェクトチームの変更– 要件の変更
漸進型ライフサイクルのリスク●アーキテクチャ上のリスク– 機能の開発順序を見誤ると、後回しにした機能によってアーキテクチャを変更せざるを得ないことがでてくる●要件の変更– 以前に開発済みの機能を変更したくなった場合、チームの作業が増える
アジャイルライフサイクル●アジャイルライフサイクルによって対処されるリスク– スケジュール上のリスク– プロジェクトチームの変更– 要件の変更– コストのリスク
アジャイルライフサイクルのリスク●プロジェクトの優先順位を経営者が決定できない●要件について意思決定する必要のある人物が決定できない●プロジェクトのスタッフが固定化してしまう
プロジェクトの時間= 開発時間+ アーキテクチャとリスク削減時間+ やり直しの時間走り出すまでにどれくらい全体の設計を考えておくべきか?Making Software, How Much Architecting Is Enough?
V&V●Validation: 正しいシステムを作っているか?●Verification: システムを正しく作っているか?
V-Model要件定義外部設計コーディングシステムテスト内部設計 単体テスト結合テストValidationVerificationVerification
ソフトウェアの品質機能性 信頼性 使用性効率性 保守性 移植性アーキテクチャ設計非機能要求(NFR)品質特性アーキテクチャパターン
品質特性シナリオ成果物(Artifact)環境(Environment)レスポンス(Response)レスポンス計測(Response Measure)刺激発生源(Source of Stimulus)刺激(Stimulus)Software Architecture in Practice より
可用性のケース成果物環境レスポンスレスポンス計測刺激発生源刺激ヘルスチェックヘルスチェックサーバ無応答プロセス平常状態ダウンタイムなし運用が継続できる
品質特性シナリオの例平常状態において、ヘルスチェックが1回無応答状態になっても、そのサーバは適切に切り離されサービス全体としてはダウンタイムなしに処理継続されることEnvironment Source of StimulusStimulusArtifactResponse MeasureResponse
可用性の戦術Availability Tactics異常の検知 異常状態からのリカバリ 異常状態の防止切り離しトランザクション予測モデル例外防止再起動準備と修復縮退スペア例外ハンドリングロールバックリトライデグラデーションシャドウモード再同期再起動レベルグレイスフルリスタートping/echo監視ハートビート例外検知自己診断
性能の戦術Performance Tacticsリソース要求のコントロール リソースの管理リソースを増やす並列化する計算リソースの複数コピーをもつデータの複数コピーをもつキューサイズを制限するリソースをスケジューリングするサンプリングレートをコントロールするイベントレスポンスを制限するイベントに優先度をつけるオーバーヘッドを減らす実行時間を制限するリソース効率をあげる
品質特性間のトレードオフ可用効率柔軟完全相互運用保守移植信頼再利用堅牢テスト使い勝手可用 ＋ ＋効率 ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖柔軟 ➖ ➖ ＋ ＋ ＋ ＋完全 ➖ ➖ ➖ ➖ ➖相互運用 ➖ ＋ ➖ ＋保守 ＋ ➖ ＋ ＋ ＋移植 ➖ ＋ ＋ ➖ ＋ ＋ ➖信頼 ＋ ➖ ＋ ＋ ＋ ＋ ＋再利用 ➖ ＋ ➖ ➖ ＋堅牢さ ＋ ➖ ＋ ＋テスト ＋ ➖ ＋ ＋ ＋ ＋使い勝手 ➖ ＋https://msdn.microsoft.com/en-us/library/bb402962.aspx
第1部まとめプロジェクトマネジメントの最大誤謬ソフトウェア開発で最も重要なことは、プログラマが使うツールや技法ではなく、プログラマ自身の質である。
開発フェーズ毎の極意
ここから先は、ワークショップベースで各開発プロセスの極意を体験していきます
要件定義
「顧客が本当に望んだもの」とズレる要因顧客自身が必要なものを分かってないため、とよく言われるが●認知バイアス●誤謬などによって、言語化する際に少しずつ歪みが生じていく。
選択バイアス
合成の誤謬https://atarimae.biz/archives/6914
フィーチャークリープ
システム1だけで処理して終わり、にしないように。https://togetter.com/li/1253386
要件定義ワークショップ1クラウド型オーディオプレイヤーA社の演奏システムを作ります。A社から出された機能要求は以下のとおりです。●複数のアルバムとそれに含まれる曲が登録されています。●登録された曲およびアルバムを通常再生できます。●リピート機能とランダム再生機能をもちます。機能仕様を決めていくにあたって、A社にどういう点を確認しますか?
ワークショップ1のポイント●用語の使い方が定まっていない場合がある。●機能が動的に組み合わさった場合の挙動は、曖昧なままではシステムは作れない。●自分の経験・知識から組み立てるのは大事ではあるが、要求されている以上のことへは拡げないこと。
要件定義ワークショップ2:掲載管理クライアント毎に購入した枠数分(月次)だけ、記事掲載できます。●毎月、翌月分の枠数だけ載せる記事をクライアントに入稿してもらいます。●記事は当月分のものと同じものを流用して入稿することも可能です。● 記事は掲載前に内容の審査を行うため、3営業日前までにクライアントに入稿してもらう必要があります。必要な機能を設計してみましょう。
ワークショップ2のポイント● 結局のところ、実現したいことは何であるか?を追求する。●補助線を引くと、シンプルな解決策がみえることもある。
RequirementsとSpecificationshttps://softwareengineering.stackexchange.com/questions/121289/what-is-the-difference-between-requirements-and-specifications●Requirements– プログラムが何をすべきか●Specifications– プログラムをどう実現していくかのプラン現実には混同されてRequirementsにSpecificationsまで含まれている(ように受け取ってしまう)ことがあるので注意
ワークショップ3:健康ランドの割引率計算以下の割引計算のルールを洗い出してみましょう。● クーポン持参:10％OFF● 平日割引:30％OFF● 平日シニア割引（65歳以上）:50％OFF● 土日祝ジュニア割引（15歳以下）:20％OFF●2つ以上の割引サービスが重なった場合は，割引率が高い方が優先される
デシジョンテーブルで仕様を漏れなく記述する
簡略化
簡略化して仕様を書き下す●クーポンを持っておらず、休日である → 割引なし● クーポンを持っていて、休日で、16歳以上である → 10％OFF● 休日で、15歳以下である → 20%OFF● 平日で65歳未満である → 30%OFF● 平日で65歳以上である → 50%OFF
ワークショップ3のポイントデータパターンを漏れなく洗い出すのは、Specificationsを書き下すソフトウェアエンジニアの重要な仕事であるが、これをそのまま実装してはならない。
[閑話休題] 仕様調整で3案出す理由選んで欲しい案極端回避性により、竹案が選ばれやすい予算の面などであまり現実的ではない案技術的負債となりそうな案
設計
ETC割引のルールETC割引の計算ロジックを実装します。●平日朝夕割引– 平日「朝:6時〜9時」、「夕:17時〜20時」– 地方部– 当月の利用回数が5回〜9回 30%割引、10回以上 50%割引●休日割引– 普通車、軽自動車等(二輪車)限定– 土曜・日曜・祝日– 地方部– 30%割引●深夜割引– すべての車種– 毎日0〜４時– 30%割引
ワークショップ4: ETC割引のルール実装上記の業務ルールにしたがい、割引率を計算するインタフェースDiscountServiceを実装して下さい。public interface DisountService {public long calc(HighwayDrive drive);}走行記録はHighwayDriveクラスで表現され、DiscountService#calcに渡されるものとします。 また、割引率はパーセンテージの正の整数で表現されます。
ワークショップ5:様々な提携先システムとの連携あるECサイトでは、自前で在庫管理している商品もあれば、提携先の代理店を担っているものもあります。提携先の注文は、自テーブルにINSERTした後、提携先のAPIをコールし、注文処理を行います。現在のビジネスルール- 自社発送先の注文: Orderを保存して終了- 提携先A社への注文: Orderを保存したら、注文内容をemailでA社に送る。- 提携先B社への注文: Orderを保存したら、注文内容をB社のAPIを経由して送る。今後、提携先が増減することも考慮に入れて、設計を考えてみましょう
ワークショップ5のポイント提携先は今後増減していく可能性が高いので、追加・削除が簡単にできるように設計しておく。●コアの処理に、フックポイントを設ける。●提携先ごとに個別な処理はプラグインとして実装する。●プラグインを適切なフックポイントに登録する。
シンプルな設計を目指すためにSimple Made Easy●Easy– 慣れている– すぐに使い始められる– 似たようなものをすでに知ってて、身近だ– 今の自分の能力の範疇内だ●Simple– ひとつの役割– ひとつのタスク– ひとつの概念– ひとつの次元
対象 何がコンプレクトしている？状態(state) 状態を変更するすべてのものオブジェクト 状態と一意性と値メソッド 関数と状態と名前空間継承 複数の型変数 状態と時間アクター 「何を」と「誰が」switch文/match文 「何を」と「誰が」とのペアが複数個混ざっている
オブジェクトの捉え方の違い
テスト
ありがちなテスト計画単体テスト: 単一モジュールについて、ホワイトボックス観点でテストを行う機能内結合テスト: 同一機能内で複数モジュールをまたいだで、ブラックボックス観点でテストを行う。機能間結合テスト: 複数機能間をまたいで、テストを行う。特に外部システムとの連携ポイントをテストする。システムテスト: 業務シナリオに沿ってテストを行う。●どの要求・仕様をテストするのか、トレーサビリティが不明。●●工程の中で性質の異なるテストを組み合わせてやるので、品質指標が決めづらい。
工程と種別は違うhttps://qiita.com/kawasima/items/1fed574e7456edbad727
ワークショップ6①就活サイトのように大規模でかつオープン時にシステムへのアクセス集中が激しいサイトの開発について、工程にテスト種別をマッピングしてみましょう。②既存のPC向けサイトの一部機能をスマフォ専用サイトとして開発しました。工程にテスト種別をマッピングしてみましょう。
参考文献
rtechkouhou
miyake
goyoki
hayaosuzuki
mitsuaki96
lefred
cyberagentdevelopers
hankehly
microcms
.jpg){kind=avatar}
hiro_torii
nnstt1
nozomiito
matsujirushi
afnizarnur
skipperchong
moore
bkeepers
michaelherold
colly
orderedlist
tmm1
bermonpainter
pauljervisheath
aarron
hatefulcrawdad