【勉強会メモ】Osaka Mix Leap Study #23 - React Native勉強会
- 日時：2018/09/19(水) 19:00 〜 21:30
- 場所：ヤフー株式会社 大阪グランフロントオフィス
ヤフーさん主催のMix Leapにはよくお世話になっていますが、今回は私が参加したことがある中でも参加者がかなり多く、React Nativeというテーマの関心の高さが伺えました。まだまだアップデートが頻繁に行われていてメンテナンスに手がかかるるなど、本格的に扱ううえでの課題はありそうですが、フレームワークとして熟れてきているのは感じました。
※メモの都合上Ract NativeをRNと略して表現してあります。RNと略すのが一般的かどうかはよくわかっていませんが。。
React Nativeでモバイルアプリ開発をはじめよう！
藤本 卓哉（株式会社Gemcook）さん
遅刻してしまって途中から聞いたのでざっくりまとめます。
課題
- バージョンを1つ上げただけでこける
メリット
デメリット
- ネイティブ側のビルドでコケたらデバッグが大変
- ネイティブで新しい機能が出た時にRNの対応待ちになる
- ブリッジ機能でネイティブコードを書けば動く
AirbnbのRN撤退宣言
⇒マイナス的な撤退ではない
- 当初は最高の選択肢だった
- 今はAirbnbの拡大がRNの成長を上回っただけ
まとめ
WebエンジニアがReact Nativeで開発した気づき
言上 和也（ヤフー株式会社）さん
※参考記事
プロダクト導入の経緯
困ったこと
リーダーに相談
- React Nattiveが流行っている
最初の感想
- 聞いた時⇒クロスプラットフォームって遅いんじゃない？
- React⇒書き方違うのでは？
採用の決め手
- learn once, write anywhereの体現
- 他のクロスプラットフォームに比べてパフォーマンスが良い
開発の実績
実装できた理由
- lean once, write anywhereの体現
- Web開発の知見がいかせた
- npmによるパッケージ管理
- Cocoapodsとかgradleとか不要
- スライリングがCSSライク、レイアウトがflexbox
- npmによるパッケージ管理
- OSSを使うことの開発効率の向上
- RNの足りない部分や簡単に使えるようにしてくれるライブラリが豊富
- コードの共通化
- 体感的に7〜8割程度共通化
Webエンジニアから見たRN
良い点
- Reactを経験しているとスムーズ
- Web開発の知見が活かせる
- 想像以上にコード共通化
- ホットリロード地味に便利
辛かった点
実装周りの辛かった点
- 凝った開発をしよう思うとネイティブのカスタマイズが必要
- version upの波が早い（2週間に一度）
- OSSの更新が止まるリスク
- iOSかAndroidかどちらかだけOSSがうまく出来ないリスク
- deployまわりが辛い
環境周りの辛かった点
- RNのアップグレード
- ドキュメントがほぼ英語
- ナレッジが少なくエラーログで検索しても出てこない
- ある程度仕様をコントロールできないと詰む
- FBにロックイン
RNに合う組織
- Webエンジニアが強い
- 専門チームを持つほど組織が大きくない
- Reactの実績がある
- 仕様のコントロールができる（自社サービスなど）
合うプロダクト
Gemcookで使うReact Nativeで絶対使えるライブラリ
西野 竣亮（株式会社Gemcook）さん
RNのライブラリ
ルーティング - React Navigation - Stack Navigator - Tab Navigator - DrawerNabvigator （開発途中で安定しない） - Fluid Transitions for React Navigation - かっこいい - react-native-router-flux - とりあえず試すならこれ - ネイティブ機能型 - react-native-splash-screen - React Native Camera - カメラはこれ一択 - react-native-maps - うまく動かずハマっている事例は多い - UI系 - NativeBase - Webで言うBootstrap的な立ち位置 - react-native-vector-icons - Font Awesome的なもの - react-native-lightbox - Lottie for React Native - Adobe After Effectsのプラグインで素材を作ってLottieに読み込ませる - react-native-app-intro - オンボーディング
自社のOSS紹介
- eslint-config-gemcook
- ESLintの初期設定
- とりあえずESLintを動かせる
- @gemcook/table
- テーブルの実装
- @gemcook/pagenation
- ページネーション
LT
ReactでToDoリストアプリを作ってみた
山崎 好洋（ヤフー株式会社）さん
Jetbrains製の kotlin-reactで ToDoアプリを作ってみよう
ToDoアプリは以下を参考
（コードの解説は割愛）
- 無理やり感はない
- Kotlinのモダンな言語仕様を利用してフロントが書ける
- TypeSafeにフロントをかけるのはよい
- サーバサイドも同じ言語で書けるようになる
- 反対にKotlinでReactの部分を書けるかも
VisualStudio2017でReactを使ってみる
つるまき さん
VSでReactが動くまで
- VS2015
- Marketplaceでテンプレ入手
- あとであれこれ入れるのが必要
- 個別にインストール
- 手順が大変
- Marketplaceでテンプレ入手
- VS2017
- 辛い環境変わらず
- 5ヶ月後にテンプレ更新
- 簡単に動くようになる
- Node.js入れてよというエラー
- Nodeのバージョンが古い
- Nodeだけ手動で入れ直すと動く
（DEMO割愛）
React Native x スマートスピーカー
がおまる さん
RN所感
ゼロカロリー理論を登録するReactアプリを作る
- キーワードを登録（例：ドーナツ）
- ゼロカロリー理論を登録（例：形が”0"を(ry ）
スマートスピーカー（Clova）にゼロカロリー理論を喋らせる
- Clovaに向かってキーワードを言う
- Clovaがゼロカロリー理論を返す
（DEMO割愛）
Reduxに疲れたのでUnduxを素振りなどした
田路 さん
undux
↓このへんの話
- storeをまるごとコンポーネントにつっこむ
- view側に責務がいろいろやってくる
⇒魔改造
mapPropsでreact-reduxのmapStateToPropsに近いことをやってた
まとめ
- Reduxに疲れてなかったと気づいた
【読書メモ】これだけ！PDCA
- 作者: 川原慎也
- 出版社/メーカー: すばる舎
- 発売日: 2012/07/18
- メディア: 単行本
- 購入: 3人 クリック: 38回
- この商品を含むブログ (4件) を見る
副題に「必ず結果を出すリーダーのマネジメント4ステップ」とあるとおり、本書は現場のリーダーが組織としての成果を出すためにPDCAを回す方法が説明されている。前回読んだ本（ 【読書メモ】最短で目標を達成する！PDCAノート - radioc@? ）がフレームワークやその使い方を中心に説明された本だったのに対して、この本はリーダーが組織的にPDCAを回すためのアプローチやマインドに重きが置かれている。現場のリーダーやマネジメントに携わる人は一度読んでおくべき本と思います。
PDCAがうまくいかない理由
そもそもPに問題アリ
- 計画を作るタイミング
- 計画策定に割く時間がない
- 組織構造
- 上層部で「計画」のみの是非が問われ、現場レベルの細かいチェクが行き届かない＝実現の可能性が低い計画が出来上がる
成果主義的な評価制度の弊害
- 低い目標設定
- 目標の達成度合いが評価に直結するため、容易に達成できそうなことしか計画しない
- 長期スパンの事業の回避
- 成果を出すまでに時間がかかるものは、そもそも計画に入れないようにしてしまう
- 非協力的な空気
- 部門ごと、個人ごとの評価では、それぞれの枠を超えて連携・協力が必要なものは評価してもらいにくいため、計画しない
目的と目標の違い
- 目的とは、ずっと追いかけ続けるもの
- 目標は明確なゴール
- 1つの目標を達成したら、また次なる目標が立てられ、その目標に向かって頑張り続ける
- 目標を達成することが目的ではない
鷹の目と蟻の目
- 鷹の目
- 経営者的な目線
- 上からふかんで物事を見る目
- 蟻の目
- 現場の視点
- 当事者の視点で物事を見る目
※メモ
最近は虫の目、鳥の目、魚の目というのもある。虫の目は蟻の目、鳥の目は鷹の目とほぼ同義で、魚の目はビジネスの潮目を読むという意味で使われる。
Plan
- 手段を目的化しない
- そもそもの目的を見失うと計画が無意味になる
- 何のための目標か、何のための計画かを問い続ける
- お客様との約束
- 現場のリーダーが中心となって議論できるテーマ
- お客様との約束＝顧客満足を上げることで会社の利益も上がり企業の強みになる
Planの5つのステップ
1) 現状の振り返りからスタート
- 計画通りに実行するえば必ず目標が達成できる現実的なレベルでの計画を策定する
- 通常業務がある前提で計画を立てる
2) 正しい事実を把握する
- 根本の原因を見つける意識をもつ
- なぜなぜ分析（”なぜ”を5回繰り返す）
3) 事実を認識するプロセスを欠かさない
- そもそも問題なのか、どの程度の問題なのか
- 把握した事実をどう認識して実行すべき方策を見つけるか
4) 勝てるイメージの計画
- ほぼ達成できる見込み数値を決める
- 目標数値と見込み数値とのギャップを把握する
- ギャップを埋めるための方策を洗い出す
- 方策ごとの見込み数値を予測する
- 見込み数値の合計が150%になるまで方策を追加する
- 阻害要因を洗い出す
- 阻害要因を克服する対策を事前に練り込む
5) 実行に値する計画か検証する
- 何を、いつまでに、誰が、どうやってが表現されているか
- 中間目標を設定することで成功率を上げる
Do
実行を妨げる3つの特性
- 学生症候群
- 後回ししてしまうクセ
- 必要以上の時間設定
- 余裕を持ったスケジュールを見積もって目一杯時間をかけてしまう
- 掛け持ち
- 複数の業務を毎日少しずつ進めると、余計に時間がかかる（コンテキストスイッチの話）
「5S」の徹底
5Sを徹底することでコミュニケーション、問題意識の共有、思いやりベースの協力が鍛えられてチームの実行力が上がる。
- 整理
- 整頓
- 清掃
- 清潔
- 躾
※参考
トヨタ式カイゼンでもリーダーはチームに5Sを徹底させるマインドが求められている。
フロー理論
揺らがず、とらわれず、気分の良い状態＝普段どおりのパフォーマンスができる
現在のリーダーは スキル と 心の状態 、両面に配慮することを求められており、それができなければ、チームのパフォーマンスを発揮することができない
※参考
本書ではスポーツドクターの辻秀一氏が提唱する理論が取り上げられている。
フロー理論は辻氏も言っているように元々はチクセントミハイ博士が提唱している理論である。
Check
計画の作り込みさえできていれば、「評価すべきこと」は明確になっている
Checkの4つのステップ
1) 現状の正しい把握
- 事実を正しく認識する
2) 早めのタイミングで改善の手を打つ
- スピード感のない改善では成果が出にくい
- 例）年間計画の1ヶ月目の結果が目標の90%⇒3ヶ月単位で考え、残り2ヶ月で5%ずつ上積みする方法を考える
3) 目標にピッタリのKPIを見つける
- 成果の状態を最初に確認すべき指標
- うまくいかない理由・改善すべきポイントを早い段階で見極められる
- 原因究明のルートをスピーディーに絞り込んでいける
4) 成果に直結するKPIを見つける
- ビジネスのキモを押さえる
- 他の部門から見ても評価できるものなのか、コミュニケーションをとりながら決定する
Action
人を縛る4つのしがらみ
4つのしがらみを意識して何が改善を妨げているのかを見極める。
- 評価制度
- 組織構造
- 習慣
- 考え方
会議5悪
- 会せず⇒メンバーがきちんと集まらない
- 会して議ぜず⇒議論をすることなく、一方的な通達のみの状態
- 議して決せず⇒議論はするが、結論が出ない
- 決して実行せず⇒出た結論を実行しない
- 実行して責を取らず⇒「とりあえずやればいい」という意識で、責任が伴わない
新たなPを始める
- 改善で終わりではない
- リーダーはチームの基礎力＝当たり前レベルを上げる
- 形状記憶組織から脱却する
- 成果が出なければすぐに元に戻ってしまう
- 早い段階での成果を意識する
PDCAマネジメントがうまく回っている状態とは
継続的に改善し続ける動きを ”当たり前” のこととして続ける
参考サイト
【読書メモ】最短で目標を達成する！PDCAノート
- 作者: 岡村拓朗
- 出版社/メーカー: フォレスト出版
- 発売日: 2018/01/20
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
「自分を劇的に成長させる！PDCAノート」に続くシリーズ2冊目。1冊目は日々の生活の中でPDCAをどうやって習慣づけていくかという点にフォーカスしていたが、この2冊目ではどうやって長期的な目標を設定して日々の行動に落とし込むかという点にフォーカスしてその作業を7つのフレームにしたものが紹介されている。個人の目標だけでなく仕事で設定する目標の立て方や日々の業務へのつなげ方のヒントにもつながる内容だと感じた。
7つのフレームは作者の考案したオリジナルなものだが、それぞれのフレームには一般的に紹介されている理論や知識が盛り込まれているので解説を読むだけでも参考になる。7つのフレームの詳細は書籍の本編参照。それらの解説の中で紹介されている理論や知識をまとめておく。
7つのフレーム
以下の7つをノートに書いて実践する。後半にいくほど日々のアクションに落とし込まれる。
目標達成の3つの条件
- 見える化
- 仕組み化
- 習慣化
仕事のGPS
高橋政史氏が提唱しているフレームワーク。
- G（Goal）：目標
- P（Points）：目標達成のためのポイント
- S（Steps）：どんな手順（ステップ）で実現するか
1ゴール、3ポイント、3ステップ を作って仕事を計画する。
※参考
- 作者: 高橋政史
- 出版社/メーカー: クロスメディア・パブリッシング(インプレス)
- 発売日: 2013/04/15
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
ウィルパワー（意志の力）
- 心理学者ロイ・パウマイスター氏が提唱
- 目標を成し遂げる集中力を生み出す力
- 小さな意思決定を繰り返すことで徐々に消耗する
※参考 toyokeizai.net
情熱大陸メソッド
- ゴールに臨場感を持ってイメージできるビジョンを描く
- TVの「情熱大陸」に取り上げられた自分をイメージしてみる
SMART基準
目標設定は以下を意識する。
- Specific（具体的であること）
- Measuradle（測定可能であること）
- Achievable（達成可能であること）
- Relevant（関連性があること）
- Time-bound（期限があること）
※参考
行動4原則
改善策をつくる時には「行動4原則」を意識する。上から順番に考えることでやることを無駄に増やさないようにする。
- やめる： 無駄を削り、シンプルにする
- 変える：別のアクションに置き換える
- 続ける：継続する
- 始める：新しい施策・プランに取り組む
環境4要素
習慣化する秘訣は「環境４要素」を考えて適切な環境に変えてみる。
- 時間：朝の5分で1日をデザイン
- 場所：デスク以外にお気に入りの場所を見つける
- 人：仲間を作る
- 道具：快適な道具を使う
ウィークリーレビューでは行動4原則と環境4要素のマトリクスで改善策を洗い出す。
1万時間の法則
スペシャリストになるために必要な時間
※参考
パレートの法則
仕事の成果の8割は、費やした時間全体のうちの2割の時間で生み出している
- 要点を抑えた20%思考の視点が重要
- 完璧を目指すよりまず終わらせる、得意な土俵に仕事を投入する
※参考
【勉強会メモ】Mobile Act OSAKA #6
- 日時：2018/08/20(月) 18:45 〜 21:30
- 場所：Osaka Innovation Hub (大阪イノベーションハブ)
今回はiOSのテーマが多めでした。またAI系のテーマも2つあって注目度の高さが伺えました。AIに関しては私も以前ML Kitについて別の勉強会で LT したことがありますが、モバイルでの活用がしやすいAPIなどの仕組みが充実してきていると感じています。 ちなみに今回は登壇もさせていただきました。何度も参加させてもらっている勉強会なので発表側で参加できてよかったです。 また、余談ですが懇親会のビールのチョイスが最高でビール好きにはたまりません。
これからはじめるDynamicType
itok さん
- iOS12がそろそろ
- iOS10サポートやめてiOS11のAPIが使える
Dynamic Type
- フォントのサイズをシステムレベルで変える
※メモ
Label間のマージンを自動調整
constraintEqualToSystemSpacingBelow- iOS11から
レイアウトを動的に変更
- 自分で書くしかない
画像も自動調整
UIImageViewのadjustsImageSizeForAccessibilityCOntentSizeCategoryを使う- 画像のサイズが大きくなる
まとめ
- WWDC17の動画参照
- iOS10サポートを終わらせてiOS11の機能をフルに使おう
Create MLで犬と猫の肉球を見分ける
hokuron さん
Create ML
- 転送学習
準備
- MacOSをMojaveにする
- Xcode10
デモ中心だったので割愛。ラベル付けされた犬と猫の肉球の画像をフォルダに準備してDrag&Dropするだけで学習とテストができてどちらかを予測できるようになりました。
※参考
Webアプリのようにモバイルアプリを作りたい
僭越ながら発表させていただきました。
RxSwiftのスケジューラ
usami-k さん
RxSwift
- 非同期イベントを受け取るための枠組み
非同期イベントとスレッド
- 非同期イベント＝同期的でない＝別スレッドで発生する
スケジューラ
- Rxでスレッドに当たる概念
Rxの三要素
- Observable
- Operator
- Scheduler
スレッド制御
subscribeOn- イベント発生元のスケジューラ指定
- WebAPI実行スレッドの指定
- データベースアクセススレッドの指定
observeOn- イベント処理のスケジューラ指定
- UIスレッドのスレッド指定
Hot と Cold
- subscribeOnがきかない
- Hotなobservableの場合は切り替えできない
Observableの分類・Hot/Cold
- HotはSubscribeしなくてもストリームが流れる
- Coldはsubscribeしたらストリームが流れる
どれがHotでどれがColdか
- Hot
- SubjectやRelay
- Rxの外側
- Cold
- 上記以外はだいたいCold
- Rxの制御下
まとめ
- スケジューラ
- 切り替える方法
- HotとCold
- Hotは切り替えできない
モバイル通信を覗いて見た
NakaHiro さん
スニファを使用
iOS Vision framework 顔認識アプリ開発してみた
TK さん
Vision Framework
- iOS11から利用できる画像解析API
- 顔、モノ、バーコードなどを検出できる
※メモ
Vision | Apple Developer Documentation
- 人間以外の人形やお札も識別
実装
VNImageRequestHandlerでハンドラを作る
パフォーマンス
- アプリ起動後、初回検出完了まで約3秒
- 動画で処理可能なフレーム：約8枚／秒
苦手なこと
- 傾いている顔（だいたい45度まで）
- マスクを付けた人
- 濃い影
まとめ
- 簡単に高精度の顔認識が可能
- 実装は座標の扱いに注意
- 苦手なこともある
【読書メモ】熊とワルツを
- 作者: トム・デマルコ,ティモシー・リスター,伊豆原弓
- 出版社/メーカー: 日経BP社
- 発売日: 2003/12/23
- メディア: 単行本
- 購入: 7人 クリック: 110回
- この商品を含むブログ (149件) を見る
ソフトウェア工学界の巨匠トム・デマルコ氏とティモシー・リスター氏によるリスク管理の名著。古典と書こうとしたが2003年とのことで古典というほど古くはない。とはいえ、ソフトウェア開発の書籍でこれだけリスク管理にスポットを当てた本はあまり無いのでいずれ古典的名著と呼ばれる日が来るのは間違いないだろう。ソフトウェア開発をマネジメントするうえでは必読書と言って良いのではないかと思う。
本書の後半ではリスク軽減の方法としてインクリメンタルな開発の重要性を挙げており、その思想はアジャイル開発の手法に受け継がれているようにも感じる。言い換えればリスク管理の側面でアジャイル開発のルーツの1つとも言えるかもしれない。個人的にはじっくり読むには非常に良いタイミングでした。
なぜリスクを管理するのか
リスクのないプロジェクトには手をつけるな
リスクと利益は切っても切れない関係にあるので、リスクのないプロジェクトに手を出しても何も得るものはない。
リスクとは
- 将来起こりうる出来事で、望まない結果を生むもの。
- 望まない結果そのもの。
リスク管理とは1を管理すること。
問題とは
既に発生したリスク。リスク管理の反対を「危機管理」といい、問題が発生した後に何をすべきかを考える。
リスク移行
リスクが問題になることを「リスク移行」といい、リスクが「実現」したという。
リスク管理の各要素
- リスク発見
- まずリスクにかんするブレーンストーミングを行い、次にリスクを選別する。さらに、プロセスを継続するしくみを導入する。
- エクスポージャー分析
- それぞれのリスクが実現する確率と、それによる影響を数値化する。
- 危機対応計画
- リスクが実現した場合に何をすべきか計画する。
- 軽減
- 計画した危機対応措置が必要な時に実行でき、効力をもつように、移行前にとるべき対策をとる。
- 継続的な移行監視
- 管理するリスクを追跡し、実現しないかどうかを監視する。
デンバー国際空港再考
1993年に開港する予定だったデンバー国際空港（DIA）の自動手荷物処理システムが完成せず、莫大な遅延コストが発生したというソフトウェア開発の失敗事例。
※参考
プロジェクトが失敗した原因は、DIAのリスク管理の方法にあるのではない。リスク管理の努力がまったくされなかったことにある。
リスクを管理すべき理由
- 積極的にリスクをとれるようにする
- 不意打ちを防ぐ
- 成功するプロジェクトを作る
- 不確定要素を限りあるものにする
- 最小限のコストによる保険である
- 目に見えない責任転嫁を防ぐ
- 一部が失敗したプロジェクトを救える
- 人材の成長機会を高める
- 管理者への不意打ちを防ぐ
- 注意すべきところに注意を向ける
リスク管理の方法
不確実性を数量化する
プロジェクトの完了について、縦軸に確率、横軸に時間をとったとき以下の3点を曲線で結んだ図を「リスク図」という。
- 可能性は極めて低いが最も早く完了する日
- 可能性が最も高い日
- 可能性は極めて低いが最も遅く完了する日
1をナノパーセント日と呼ぶ。
ソフトウェア業界全体でみると、不確定幅はNまでの期間の150から200パーセントである。
※参考
http://pcmdays.cocolog-nifty.com/blog/2006/09/post_5a24.html
リスク管理のしくみ
きのうの問題は今日のリスクである
過去に起きた問題を元に新しいプロジェクトのリスク・リストを作る。
リスクについてできること
- 避ける
- 抑制する
- 軽減する
- かわす
「かわす」は何もしなかったがリスクが実現しなかったこと。
リスク管理は、プロジェクトについて心配することとは違う
リスク・エクスポージャー
リスクの抑制コストの期待値。
コストのかわりに時間的なリスクにも使える。例えばプロジェクトが5ヶ月遅れるリスクが20%の場合はリスク・エクスポージャーは1ヶ月。
ショートストッパー
発生すると何もかも犠牲になって進めなくなるような自分では手に負えないリスク。リスクを監視する必要はあるが、自分が管理するのではなく上司や会社の上層部が管理するように正式な儀式を行って託す。
リスク管理の手順
9つのステップを実施する
- リスク発見プロセスによってリスクを調査する
- ソフトウェア・プロジェクトのコア・リスクが調査に含まれていることを確認する
- 個々のリスクごとに次の作業を行う
- リスクに名前と番号をつける
- ブレーンストーミングによって、そのリスクの移行指標を特定する
- リスクが実現した場合にコストとスケジュールに与える影響を推定する
- リスクが実現する確率を推定する
- そのリスクの時間的、資金的なエクスポージャを計算する
- 移行が始まった時にとるべき危機対応措置を事前に決めておく
- 選択した危機対応措置を実行できるように、移行の前にとるべき軽減措置を決める
- 全体的なプロジェクト計画に軽減措置を追加する
- ドキュメント化する
- ショートストッパーをプロジェクトの仮定条件として指定し、上層部に引き渡す儀式を実行する
- リスクがいっさい実現しないものと仮定して、最初のスケジュール見積もりを作成し、ナノパーセント日を決定する
- 社内と業界全体の不確定要素を使って、Nから始まるリスク図を作成する
- リスク図を使って約束を発注者に伝える
- リスクが実現したり終了したりしないか監視し、実現したときには危機対応計画を実行する
- プロジェクトの期間中、あとから出現したリスクに対応するためリスク発見プロセスを継続する
RISKOLOGY
リスク評価のツール
※メモ
Rで実装
リスク発見プロセス
- 破壊的結果のブレーンストーミング
- 悪夢に絞って考える
- 水晶玉を使う
- 視点を変える
- 誰も責任のない不幸
- 非難すべき失敗
- 部分的な失敗
- シナリオの構築
- 根本原因の分析
共存共栄モデル
- 利害関係と特定し勝利条件の対立や緊張を探る
ソフトウェア・プロジェクトのコア・リスク
- 内在的なスケジュールの欠陥
- 要求の増大
- 人員の離脱
- 仕様の崩壊
- 生産性の低迷
リスク管理の力学
天罰期
- リスクが問題として顕在化し問題を認識するプロジェクトの中盤ごろ
進捗メトリック
- 境界要素の決定
- データの流れからシステムの境界を明確化する
- 仕様の崩壊のコア・リスクを防ぐ
- EVR（現在稼得価値）
- 実質的な進捗状況を表す指標（完成度％）
- 仕様の崩壊意外の4つのコア・リスクの影響を追跡する
インクリメンタル開発
- 設計をほぼ完全に行い、サブセットごとにインクリメンタルな開発を行う
- 進捗メトリックの重要な拠り所
- EVRをメトリクスに使う
インクリメンタル開発計画
- 詳細設計図
- 作業分解図（WBS）
- バージョン受入検査表
究極のリスク軽減戦略
究極のリスク低減は少しでも早く着手すること
数量化の方法
リスクのことだけを考えると、リスクをどこまでとるべきか、理由を示して説明できない。
コストと効果は同じ精度であらわす必要がある
