現代的システム開発概論

 現代的システム開発概論

2019年度リクルート新人ブートキャンプ エンジニアコースの講義資料です

Eea9a05e6e222a3d50c73f54a49fadf4?s=128

Recruit Technologies

June 24, 2019
Tweet

Transcript

  1. 6.

    計画 Plans are useless, but planning is indispensable. – Eisenhower

    計画そのものは刻一刻と状況が変わりゆくプロ ジェクトにおいては役に立たない。 どんなライフサイクルを採用しようとも、再計 画を想定しておかなければならない
  2. 7.

    プロジェクト計画 だいたい次のようなことを書く • プロダクトの目的 • 履歴 • リリース基準 • プロジェクトの目標

    • プロジェクトの編成 • スケジュールの概要 • プロジェクトの人員配置(人員配置の計画) • スケジュール案 • リスク一覧
  3. 11.

    リリース基準の書き方はSMARTに • 具体的 (Specific) • 計測可能 (Measurable) • 達成可能 (Attainable)

    • 現実的 (Relevant) • 追跡可能 (Trackable) Time Boundとされることが多 いが、Manage It!で使われてい るTrackableの方が意味合いが ハッキリする
  4. 12.

    RiskとIssueの違い Risk Issue 未来にフォーカス 現在・過去にフォーカス プロジェクト期間中に、主要なリ ソースが居なくなるかもしれない チームメンバが離任する。最終日 は✕✕なので、引き継ぎを… チームメンバがプロジェクトの大事

    な期間に休暇をとるかもしれない。 チームメンバが休暇を取ったと き、他の誰も対処できないことが ある。 予期せぬ要求の変更があるかもしれ ない プロジェクトのスコープに追加す べき機能が見つかった 影響分析すると、プロジェクトのス ケジュールを遅延させる問題が見つ かるかもしれない。 影響分析の結果、プロジェクトを1 週間後ろ倒ししそうな新たな問題 が2つ見つかった。 マトリックス型の組織でプロジェク トを進めると、現場が混乱し生産性 が低下するかもしれない。 我々の組織はマトリックス型なの で、PMの権限と説明責任について 混乱を減らすために、それを明記 した文書を作成する必要がある。 https://www.linkedin.com/pulse/issue-risk-what-difference-sanjeev-kulkarni/
  5. 20.

    失敗を避けるのではなく 失敗を前提としてシステムを設計する Availability := MTTF MTTF + MTTR https://www.slideshare.net/ufried/patterns-of-resilience Werner

    Vogels(Amazon CTO): “Everything fails all the time” MTTFを長くする → Robust MTTRを短くする → Resilient
  6. 30.

    トライアドのフレームワーク 特になにもしない 業務に関係ないも のも、アレコレつ まみ食いする 業務で必要なもの を勉強する Antifragile Robust Fragile

    世の中の事象を、Fragile/Robust/Antifragile の3つ組(トライアド)に沿って考えると面白 い。 エンジニアの技術学習のトライアド
  7. 31.

    Netflix Chaosシリーズ 意図的に本番障害を起こし、何が起きるかをモニタリングする Chaos Monkey: EC2インスタンス単位で落とす Chaos Gorilla: AZ単位で落とす Chaos

    Kong: リージョン単位で落とす Latency Monkey: 1Microserviceのレスポンスを遅延させる https://www.slideshare.net/JoshEvans2/embracing-failure-reinvent-2014
  8. 33.

    WBS

  9. 37.

    タスクの依存関係 A B Finish to Start Start to Start Finish

    to Finish Start to Finish A B A B A B Bが終わるまでAが 完了にならない Aが完了しないとB が始められない Aを始めるまでBが 始められない Aを始めないとBが 完了できない
  10. 41.

    問題 A B C D A:認証モジュール作る (3d) B:認証モジュールをテストする (2d) C:認証ライブラリが返すユーザオブジェクトを使って、検索す

    るプログラムを作る (3d) D:検索機能をテストする (2d) 以下のスケジュールを短縮することができるでしょうか?
  11. 44.

    スケジューリングの技法 • トップダウンスケジューリング – まずマイルストーンを置き、それを支えるタスクをひねり出す • ボトムアップスケジューリング – 特定のタスクから始め、それに連なるタスクを洗い出しマイルストーンをひねり出す。 –

    漸進型ライフサイクルで有用 • インサイドアウト – 自分(たち)の分かっていることをマインドマップに書き出し、そこからタスクとマイルス トーンを作る • ハドソン・ベイスタート – まず小さくプロジェクトを始めてみて、そこでの理解をもとにタスクやマイルストーンを 作る
  12. 45.

    計画の種類 • フェーズベースの計画 – 特定の部門の人たちからなるチームが、プロジェク トの各部の責任を追う。 – 責任を負う人たちが「終了」と宣言すれば、その フェーズが完了 •

    成果物ベースの計画 – 成果物に基づいたマイルストーンを置く – 成果物の完成に各チームが集中できるようになる一 方、マイルストーンが守られずグダグダになるリス クがある。
  13. 51.

    Five Orders of Ignorance 0OI: 全部分かっている 「答え」を持っている。あとは書き写すだけで完成する。 1OI: 分からないことが分かっている 答えを得るための「質問」を持っている。

    2OI: 分からないことが分からない 「質問」を持たない状態。決定的な答えを引き出すための「質問」がで きない。 3OI: 分からないことが分からない状況を何とかする術を知 らない 2OI→1OI→0OIと進んでいくためのプロセスがない状態です。 4OI: 無知にレベルがあることを知らない http://qiita.com/seki_uk/items/4001423b3cd3db0dada7
  14. 55.

    開発ライフサイクル 種類 ライフサイク ルの例 長所および成功に必要な条件 プロジェクトの 優先順位 逐次型 ウォーターフォール、 フェーズゲート

    • コストのリスクを管理できる (経営陣がフェーズゲートを使用する場合) • システムアーキテクチャをよく理解できている • プロジェクトの過程で要件が変動しない 1.機能セット 2.欠陥の軽減 3.リリース期日 反復型 スパイラル、進化的プ ロトタイピング、RUP • 技術的リスクを管理できる • 要件が進化し続ける 1.機能セット 2.欠陥の低減 3.リリース期日 漸進型 スケジュールに応じた 設計、段階的納品 • スケジュールのリスクを管理できる • 多少の要件の変更を吸収できるが、アーキテク チャに影響を与える変化には十分対応できない 1.リリース期日 2.欠陥の低減 3.機能セット 反復漸進型 アジャイル • スケジュールのリスクと技術的リスクの両方を管 理できる • すべてのメンバが同一サイトで作業を行える • 統合チーム以外では円滑な進行が難しい 1.リリース期日 2.機能セット 3.欠陥の低減 場当たり型 Code and Fix なし 1.リリース期日 2.機能セット 3.欠陥の低減
  15. 56.
  16. 67.
  17. 71.

    品質特性シナリオ 成果物 (Artifact) 環境 (Environment) レスポンス (Response) レスポンス計測 (Response Measure)

    刺激発生源 (Source of Stimulus) 刺激 (Stimulus) Software Architecture in Practice より
  18. 74.

    可用性の戦術 Availability Tactics 異常の検知 異常状態からのリカバリ 異常状態の防止 切り離し トランザクション 予測モデル 例外防止

    再起動 準備と修復 縮退 スペア 例外 ハンドリング ロールバック リトライ デグラデーション シャドウモード 再同期 再起動レベル グレイスフル リスタート ping/echo 監視 ハートビート 例外検知 自己診断
  19. 75.

    性能の戦術 Performance Tactics リソース要求のコントロール リソースの管理 リソースを増やす 並列化する 計算リソースの複数コピーをもつ データの複数コピーをもつ キューサイズを制限する

    リソースをスケジューリングする サンプリングレートを コントロールする イベントレスポンスを 制限する イベントに優先度をつける オーバーヘッドを減らす 実行時間を制限する リソース効率をあげる
  20. 76.

    品質特性間のトレードオフ 可 用 効 率 柔 軟 完 全 相

    互 運 用 保 守 移 植 信 頼 再 利 用 堅 牢 テ ス ト 使 い 勝 手 可用 + + 効率 ➖ ➖ ➖ ➖ ➖ ➖ ➖ ➖ 柔軟 ➖ ➖ + + + + 完全 ➖ ➖ ➖ ➖ ➖ 相互運用 ➖ + ➖ + 保守 + ➖ + + + 移植 ➖ + + ➖ + + ➖ 信頼 + ➖ + + + + + 再利用 ➖ + ➖ ➖ + 堅牢さ + ➖ + + テスト + ➖ + + + + 使い勝手 ➖ + https://msdn.microsoft.com/en-us/library/bb402962.aspx
  21. 93.
  22. 94.

    簡略化して仕様を書き下す • クーポンを持っておらず、休日である → 割引 なし • クーポンを持っていて、休日で、16歳以上であ る →

    10%OFF • 休日で、15歳以下である → 20%OFF • 平日で65歳未満である → 30%OFF • 平日で65歳以上である → 50%OFF
  23. 97.
  24. 98.

    ETC割引のルール ETC割引の計算ロジックを実装します。 • 平日朝夕割引 – 平日「朝:6時〜9時」、「夕:17時〜20時」 – 地方部 – 当月の利用回数が5回〜9回

    30%割引、10回以上 50%割引 • 休日割引 – 普通車、軽自動車等(二輪車)限定 – 土曜・日曜・祝日 – 地方部 – 30%割引 • 深夜割引 – すべての車種 – 毎日0〜4時 – 30%割引
  25. 99.

    ワークショップ4: ETC割引のルール実装 上記の業務ルールにしたがい、割引率を計算するインタフェー スDiscountServiceを実装して下さい。 public interface DisountService { public long

    calc(HighwayDrive drive); } 走行記録はHighwayDriveクラスで表現さ れ、DiscountService#calcに渡されるものとします。 ま た、割引率はパーセンテージの正の整数で表現されます。
  26. 102.

    シンプルな設計を目指すために Simple Made Easy • Easy – 慣れている – すぐに使い始められ

    る – 似たようなものをす でに知ってて、身近 だ – 今の自分の能力の範 疇内だ • Simple – ひとつの役割 – ひとつのタスク – ひとつの概念 – ひとつの次元
  27. 103.

    対象 何がコンプレクトしている? 状態(state) 状態を変更するすべてのもの オブジェクト 状態と一意性と値 メソッド 関数と状態と名前空間 継承 複数の型

    変数 状態と時間 アクター 「何を」と「誰が」 switch文/match文 「何を」と「誰が」とのペアが複数個混 ざっている
  28. 105.