【読書】Amazon Web Services 基礎からのネットワーク＆サーバー構築 改訂版
やったことをざっと整理
VPCを作る
パブリックサブネットを作る
インターネットゲートウェイを作る
パブリックルートテーブルにインターネットゲートウェイを追加する
パブリックサブネットのルートテーブルにパブリックルートテーブルを設定する
WEBサーバを作る
EC2インスタンスを作成する
作成したVPC、パブリックサブネットを設定する
新規のセキュリティグループを設定する
新規のキーペアを作成する
SSHで接続する
WEBサーバソフトをインストール
Apacheをインストール
自動起動設定
セキュリティグループのインバウンドに80を追加する
nslookupで名前解決を確認
WEBサーバにGETとPOSTに返信するnode.jsを配置
node.jsをインストール
パスを設定
セキュリティグループのインバウンドに8080を追加する
telnetでレスポンスを確認
プラーベートサブネットを作る
プラーベートサブネットにサーバを作成する
EC2インスタンスを作成する
作成したVPC、プラーベートサブネットを設定する
新規のセキュリティグループを設定する
セキュリティグループのインバウンドにICMPを追加する
WEBサーバからPINGが通ることを確認
WEBサーバにSSHで接続した上で、プライベートサーバにSSHで接続
NATゲートウェイを構築
プラーベートサブネットのテーブルにNATを追加する
プライベートサーバから外部への接続をcurlで確認
DBサーバにMysqlをインストール
WEBサーバにWordpressをインストール
【読書】アジャイルサムライ 達人開発者への道 / Jonathan Rasmusson
入門
「価値ある成果を毎週届ける」
大きな問題は小さく
本当に大事なことに集中して、それ以外のことは忘れる
ちゃんと動くソフトウェアを届ける
フィードバックを求める
必要とあらば進路を変える
成果責任を果たす（＋期待をマネジメントする）
「マスターストーリーリスト(TODOリスト)」
概要、優先順位、見積 → 土台
ベロシティ（１回のイテレーションでの量）を実測
スコープを柔軟にしておく（開発者は顧客にありのままを伝える）
「完了」の定義
リリースに関するあらゆる作業を完了させる
「３つ」の真実
プロジェクトの開始時に全ての要求を集めることはできない
集めたところで、要求はどれも必ずといっていいほど変わる
やるべきことはいつだって、与えられた時間と資金よりも多い
「やり方はたった１つではない」
原理原則、プラクティス＋自分の頭で考えること
「アジャイルなチーム」
役割分担はない（全員が何でもやる）
開発工程が連続的
同じロケーション
顧客に積極的に参加してもらう（アジャイルな顧客）
自己組織化（当事者意識、肩書きや役割を気にしない、自分から動く）
チームメンバー（ゼネラリスト、曖昧な状況に抵抗がない、我を張らない）
方向付け
「プロジェクトがダメにならないために」
ゴールやビジョン、プロジェクトの状況や背景など話し合っておく
ステークホルダーにプロジェクトを続けるかどうか判断するための情報を提供する
「インセプションデッキ」
我々はなぜここにいるのか？（顧客は？プロジェクトが始まった理由は？）
エレベーターピッチを考える（３０秒以内、２センテンスでプロジェクトを）
パッケージデザインを作る
やらないリストを作る
ご近所さんを探す
解決案を描く（概要レベルのアーキテクチャ設計図）
夜も眠れなくなるような問題は？（どう最悪の事態を避けるか、被害を抑えるか）
期間を見極める
何を諦めるのかはっきりさせる（期間、スコープ、予算、品質）
何がどれだけ必要か？
計画
「文書化」の難しさ
変化に対処できない
顧客の欲しいものではなく、仕様に合わせて作ることになる
下手な推測や誤った前提を招き寄せる
多くの時間を無駄にする
「ユーザーストーリー」
あらゆる詳細を聞き出すこと＜本質を捉えること
顧客にとって何かしらの価値が書かれていること
「よくできているユーザーストーリー」とは？
お客さんがワクワクするようなストーリー
独立している
交渉の余地
テストできる
小さい（見積れる）
誰のため 何をしたいのか？ なぜしたいのか？
「ストーリー収集ワークショップ」
大きくて見通しの良い部屋
図をたくさん描く
ユーザーストーリーをたくさん書く
その他もろもろをブレインストーミング
リストを磨き上げる
「アジャイルな計画」
顧客にとって価値ある成果を届けられる計画
分かりやすくありのままを伝える、誠実な計画
約束したことを守り続けられる計画
必要に応じて変更できる計画
開発速度を計測し、完了時期を見通せる
「計画づくり」
マスターストーリーリストを作る
プロジェクト規模を見極める
優先順位
チームのベロシティを見積もる
期日を仮決め
運営
「イテレーション」の進め方
必要な分を必要なときに分析する
必要な分だけ、必要なときに掘り下げて分析する（フローチャート、ペルソナ、ペーパープロト）
開発（ソースコード管理、ビルド自動化、開発環境テスト環境）
テスト（だいたい動いていることを確認、できる限り自動化）
「イテレーション」でやるべきこと
今回のストーリー計画ミーティング
ショーケース（→フェードバック）
次回のイテレーション計画ミーティング
ミニ振り返り
デイリースタンドアップ
プログラミング
アジャイルソフトウェア開発の１２の原則
１ 顧客満足最優先、価値のあるものを早く継続的に提供
２ 要求の変化は歓迎、変化を味方につけてお客さんの競争力を引き上げる
３ 動くソフトウェアを２−３週間の短い時間間隔で
４ ビジネス側の人と開発者は日々一緒に
５ 意欲に満ちた人を集め、環境と支援を与え、無地終わるまで信頼
６ フェイストウフェイス
７ 動くソフトウェアこそが進捗の最も重要な尺度
８ 持続可能、一定のペースで継続的に
９ 技術的卓越性と優れた設計に対する不断の注意で機敏さを高める
１０ シンプルさ（無駄なく作れる量を最大限にすること）
１１ 最良のアーキテクチャ、要求、設計は自己組織的なチームから
１２ 定期的に振り返り、自分たちのやり方を最適に調整
2018 PMI日本フォーラム 参加してみて
M1.プロジェクトマネジメントの未来 / マーク・ラングレー
破壊は世界中で起きている
ベスト・プラクティスからネクスト・プラクティスへ / アジリティ,DevOps
PMI タレント・トライアングル / テクニカル,リーダーシップ,ストラテジ
M2破壊的イノベーションとPMロールの変化 / Hirotoshi Kamba
「勝つか負けるか」ではなく「生きるか死ぬか」/ 覚悟
デジタル化の進展により既存のビジネスが破壊的な影響 / 顧客の行動が変化
業種、業界の壁が崩れ、巨大商圏を中小ベンチャー (Ankle Biter)が食い散らかす
タレント・トライアングル 新しいPMロールモデルの提案
行動とは死人にはできない活動のこと / 自分の外側に対して、能動的に何かを行うこと
Reflection (内省)
1. 自分を振り返る時間を得る
2. 自分の役割と責任を書き出す
3. それを受け入れる覚悟がある かを自問自答する
Action / Behavior (行動)
1. 自覚した自分のロール・モデ ルにふさわしい行動をとろう と努力する
2. 適切であったかどうか、行動 結果を振り返る
M4.人生100年時代に 求められる学び力とは? / 清水久三子
ライフプランの変化 /人生100年時代の到来
ビジネスパーソンの学びの成功要因
(与えられるのではなく、多くの機会に接することで自ら気付き、成長を図る)
Career 学びの目的がキャリアと直結している
Open “黙って闇練”ではなく 周囲にオープンにし、 期待や機会に触れる
Output 多くのアウトプットの場があり適切なフィードバックが得られる
キャリアデザインの変化 山登り型からフィールド型へ
(個人のキャリアの8割は 予想しない偶発的なことによって決定される)
1「好奇心」 絶えず新しい学習の機会を模索し続ける
2「持続性」 失敗に屈せず、努力し続ける
3「楽観性」 機会は必ず実現する、可能になるとポジティブに考える
4「柔軟性」 こだわりを捨て、信念、固定概念、態度、行動を変える
5「冒険心」 結果が不確実でも、リスクを取って行動を起こすこと
自分戦略の考え方 個人 = 法人
1 経営戦略 / ありたい姿、目指すキャリア
2 マーケティング / セグメント、ターゲット、ポジショ ニング、ブランディング
3 商品・サービス開発 /提供する価値、ケイパビリティ
4 営業・チャネル戦略 / どうやって自分の価値を示す
5 組織戦略 / 価値を生み出す
6 オペレーション戦略 / 生産性の高い働き方
7 財務戦略 / 収入、資産、収益、キャッシュフロー
＊スキル x 知識 x マインド x ケイパビリティ → 提供価値
学びのソース 検索→探索→模索
＊既存ジャンルではなく点をつなぐ
＊学びジプシーにならない
＊勝負のフィールドに出る
学びにおける2つの視点
段階的視点
覚える→構造化する→試行する→達成する
社会的視点
1 適切なフィードバックを得て到達レベルを認識する
2 実戦に向けて形にする訓練
3 周囲へのアピールによる情報・期待・機会の獲得
M7.会う人すべてがあなたのファンになる 一流の魅せ方 / 鈴鹿久美子
勝つ人の共通項
・客観的な自分の姿が見えている
・素直な努力家である
・一流の3要素（清潔感、信頼感、安定感）を持っている
成功体験だけでなく、失敗談を披露する
勝つための５ステップ
1.敵=欲しいもの=目標を定める
2.素の自分自身=スペック=を知る
3.理想の自分の姿を決める
4.素と理想の自分の間の溝を埋める
5.答えが見つかったらそれを固定化する
魅せたい印象を作る
・３種の笑顔
・コアスタイル コアカラー
・話すスピード
M10.ジョブ理論によるイノベーションプロセス / 白井和康
企業の目的 = 顧客の創造 x イノベーション x マーケティング
イノベーションプロセスに対する 3つのインプット
低 技術や アイディア
中 プロダクト/サービスに関する顧客の声
高 顧客のジョブに関する深い理解と洞察
顧客が成し遂げようとしているジョブ
・履行しようとしている仕事や用事
・実現しようとしているゴールや目標
・解決しようとしている問題や課題
優れたイノベーションプロセスの4つの特長
・予測可能 / 持続可能 / 拡大可能 / 再現可能
イノベーションプロセスの4つのステージ
・定義する→理解する→発見する→想像する
市場の魅力度の推定
・ジョブ履行者が多く存在する
・そのジョブを頻繁に履行する
・そのジョブ履行に関する多くの望ましい成果(ニーズ)が 満たされていない
・そのジョブを完璧に成し遂げるために四苦八苦をしている
・そのジョブを成し遂げるために多くのお金と時間を費やしている
・長期間にわたってそのジョブが履行される
ジョブステートメント
背景 - 状況
背景 - トリガー
機能的ジョブ - 行動の対象
機能的ジョブ - 行動の内容
中核となる機能的ジョブの分解
計画する→収集する→準備する→確認する→開始する→監視する→修正する→完了する
中核となる機能的ジョブに付随するジョブの収集
・感情的ジョブ
・社会的ジョブ
・関連するジョブ
・台頭するジョブ
各々のジョブステップにおける 望ましい成果(ニーズ)の収集
統制の対象 x 測定の単位 x 改善の方向性
望ましい成果の実現を阻む 障壁や制約(課題)の特定
スピード：時間の浪費 遅延 実行の困難性
安定性：不安定 予測不可能 脱線
アウトプット：間違い 無駄 コスト増
望ましい成果の優先付け
機会スコア = { 重要度 + max ( 重要度 - 満足度, 0 ) }*10
成果ベースのセグメンテーション
因子分析 x クラスタリング分析 x ペルソナ分析
プロダクト/サービス戦略の方向づけ
破壊戦略 / 支配戦略 / 持続戦略 / 分離戦略 / 差別戦略
ジョブ全体にわたるコンセプトに関するヒント
・ジョブが履行される背景(状況やトリガー)を事前 に知る方法はないか?
・ジョブの履行パターンを学習して、最も有効な履行 方法に関する情報を提供してあげることはできない か?
・ジョブ全体または一部に関する履行を高速化または 自動化してあげることはできない?
・複数のジョブステップをまとめてあげたり、特定の ジョブステップを無くてあげたりすることはできな い?
・現在使っている複数のプロダクト/サービスをワン ストップで提供してあげることはできないか?
ニーズ/課題とソリューションのフィット検証
価値マップ x 顧客プロファイル
【読書】やり抜く人の９つの習慣 コロンビア大学の成功の科学
はじめに
目標を達成できるかどうか
＝ 目標を達成できる人の思考や行動（９つの習慣）を持っているかどうか
「あたりまえで簡単に実行できること」だが「あたりまえに実行されていないこと」
第１章 目標に具体性を与える
どうなったら成功なのか？成功の状態を明確にする
「目標を達成した時の感情」「そのときの様子や状況」「そこまでの障害」をイメージ
今との差（コントラスト）を明確にする
目標達成のために「やるべきこと」を具体化する
まとめ
１．目標を紙に書く 2．どうなったら「目標達成か」考える ３．目標を書き直す
第２章 目標達成への行動計画をつくる
着実に実行するため「いつ何をやるか」を予定表に入れておく
if-then(もしこうなったら、こうする)をはっきり決めておく
まとめ
１．すべきことを明確にする ２．「いつ」「どんな時に」行動に移すか考える
３．if-thenプランニングに落とし込む ４．何が障害になるか考える
５．障害への対処を考える ６．もう一度if-thenプランニングを考える
第３章 目標達成までの距離を意識する
日々どれだけ進んだのかを意識する
そのために定期的にフィードバックを得て目標に正しく向かっているか確認する
「これまで思考（どこまでやったか）」と「これから思考（あとどれだけやらないといけないか）」の２つの視点のうち、後者を重視したほうがモチベーションを上げやすい
まとめ
１．どの程度の頻度でフィードバックを得るか ２．フィードバックの予定を立てる
３．「これから思考」で目標までの距離を考える
第４章 現実的楽観主義者になる
目標は達成できると信じることは大切だが、簡単に達成できると考えてはいけない
「現実的な楽観主義者」とは「成功を望み、それに相応しい努力をする人」
覚悟を決め、詳細なプランを立て、正しい戦略を練って、成功を掴むまで努力
「不安」に思い成功への「障害」を探すことは成功への大切なステップ
自分の前にある課題や困難から逃げず、しっかり見つめること
成功するまでのステップと取るべき行動をビジュアリゼーションすること
第５章 「成長すること」に集中する
能力は努力次第で伸ばせる
「今、何ができるか」ではなく「これから、何ができるようになりたいか」
「失敗してもいい」と開き直る
「証明ゴール（今できること）」より「成長ゴール（できるようにする）」
「興味をもつ」ことが大事
まとめ
１．焦らない、完璧主義にならない ２．助けを求める ３．他人と比べない
第６章「やる抜く力」を持つ
能力は経験や努力を重ねることで高めることができる（拡張的知能観）
失敗は「努力不足」「戦略を間違えた」「プラン不足」など努力や行動が原因
まとめ
１．苦手とすることを振り返る ２．自分の思い込みを注意深く観察
第７章 筋肉を鍛えるように意志力を鍛える
気の進まないことをして、意志力を鍛える
取り組む価値があると思い続ける
挑戦するには「誘惑に打ち勝つ」必要がある
今すぐ意志力を回復させたい場合は「意志力が強い人」を思い浮かべる
意志力が弱まったら自分にご褒美をあげる
定期的に刺激を与えることでどんどん意志力が強くなる
まとめ
１．意志力は有限 ２．意志力を特効薬で回復 ３．意志力を日々の訓練で鍛える
第８章 自分を追い込まない
２つの困難な目標に同時に取り組まない
どんな目標でもできるだけ簡単な方法を見つける
自分の意志力を過大評価しない
まとめ
１．誘惑と会う場所と時間を把握 ２．大きな目標は１つ ３．やめるなら一気に
第９章 「やめるべきこと」よりも「やるべきこと」に集中する
行動を変えたいなら「やめたいこと」ではなく「やりたいこと」「やるべきこと」
「好ましくない行動」を防ぐには具体的な「代替行動」を目標にする
まとめ
１．「〜しない」という目標を「〜する」に変える
２．「〜する」という目標をif-thenプランする
【読書】SOFT SKILLS ソフトウェア開発者の人生マニュアル
充実した人生のために必要なのはこの７つ
キャリア、自己アピール、学習法、生産性、お金、体、心
第１章 キャリアを築こう
- 大きな目標地点を決めてから動き出すこと
- 専門領域を決めること
- 多彩で柔軟なスキルも身に付けること
- プロであること（いい習慣、正しいことを選択、品質の追求、自己研鑽）
- やり遂げるまではできたふりをして実践に移す
第２章 自分を売り込め！
- ブログをやる
- 他人の役に立つような情報を提供する
- バカにされるのを恐れない
第３章 学ぶことを学ぶ
学習のための１０ステップ
STEP1〜6 準備
1.基本的な調査で全体像を掴む
2.学びたいもののスコープを決める。絞る。大きすぎる場合分割する
3.学習活動の成功を定義する明確で簡潔な文を作る。目標を達成したらできること。
4.参考資料をできるだけたくさん見つける
5.学習プラン（自分がそのテーマについて本を書く場合のあらすじ）を書く
6.何を学ぶか、どのような順序で学ぶかが決まったらどの参考資料を使うか決める
STEP7〜10 実践
7.使い始められるようにする方法を学ぶ（浅すぎず、深すぎず）
8.遊び回る（実際に始めることが大切）疑問が浮かぶ
9.役に立つところまで学ぶ（本を最初から最後まで綺麗に読む必要はない）好奇心
10.教える（人に説明する）
第４章 生産性を高めよう
- 週ごとに小さなタスクの計画
- 四半期ごとに達成したいこと（月次計画、週次計画、日次計画）
- テレビを止める
- 習慣（キュー、ルーチン、褒美）をもつ
- ブレイクダウンして先延ばしを防ぐ
【読書】システムを「外注」するときに読む本
第1章 システム作りは業務フローから〜「本当に役に立つシステム」を作るために、まずやるべきこと
ワクワクするか？何がうれしいか？
第2章 発注者に最低限必要な知識〜自社の業務を「正確に」知っているか?
要件は必要かつ十分か？
要件は十分に詳細化されているか？
業務の例外や異常を考慮しているか？
要件が正しく管理されているか？
体裁・文言は適切か？
第3章 失敗しないベンダ選びのポイント〜プロジェクト管理能力の見極め方
プロジェクト計画
・概要
・ライフサイクル
・体制役割
・マスタスケジュール
・WBS
・要員計画スキルアップ計画
・成果物一覧
・会議体計画
プロジェクト管理計画
・進捗管理計画
・コスト管理計画
・変更管理計画
・リスク管理計画
・課題管理計画
・欠陥管理計画
・構成管理計画
・品質計画
第4章 社内の協力を得るために〜みんながシステム担当者に協力するしくみ作り
システム全体の目的と意義を社員全体が認識すること
システム開発も本業であるという意識づけと仕組みの改革
第5章 リスク管理で大切なこと〜「ベンダ側のリスク」の引き出し方
要件定義時チェックポイント
・合目的性
・網羅性 妥当性 整合性
・採否 変更
プロジェクト計画時チェックポイント
・スケジュール
・コスト費用
・体制要員
・エンドユーザの参画
・開始完了条件
・パッケージ外部サービス
プロジェクト実施中のチェックポイント
・要件の詳細化と変更
・品質
・コスト
・リスク 課題
・要員 体制
・本稼働準備
第6章 ベンダとの適切な役割分担〜発注者はどこまで「ワガママ」でいられるのか?
「してやってる」と思えるくらい責任のある行動（７：３で自分たちが損をしている）
第7章 情報漏えいを起こしてしまったら〜ダメージを最小限に抑える対応法
どうやって自然と勉強する仕組み作りをするか？
TODOを管理する
https://todo.microsoft.com/ja-jp/
実績を管理する
情報を収集する
サイト
ブログ
上記をスマホのすぐ目につくところに置いておく
心構え
・すぐ結果を求めない。時間をかけて学習する
・毎日こつこつ。1日4hだと1年365日1460h
・何をどのくらいやるか配分をなんとなく決める
