2 月のネクストスキルの週次ゼミのまとめです。

2 月は主に、プロジェクトマネジメント、アジャイル開発、見積もりについて学びました。

いつものように、メモと、感想をつらつらと書きます。

2 月に学んだこと

第 1 週

プロジェクトマネジメントの基本を学びました。

• プロジェクトマネジメントとは
  • 教科書なプロジェクトマネジメント(PMBOK ガイド)に沿ってみていく
  • プロジェクトとは？
    • 新しい独自の目標を設定して、期限を設けてそれを達成させる一連の活動。
  • 定常業務（ルーチンワーク）
  • プロジェクトマネジメントとは？
    • プロジェクトの要求事項を満たすため、知識、スキル、ツールおよび技法をプロジェクト活動へ適用すること。
    • プロジェクトマネジメントにおけるマネジメントは、管理より運営の意味が近い
    • プロジェクト内のタスクをどう進めるか管理する
  • システム開発のポジション
    • プロジェクトマネージャー
      • 目標に向けてどう進めるか
    • PdM
      • なぜ、何を作るのか
    • プロダクトオーナー（アジャイル）
      • 開発の優先順位付け
    • スクラムマスター（アジャイル）
    • エンジニア
    • デザイナー
    • プロジェクトリーダー
  • プロジェクトマネジメントの要素
    • 5 つのプロセス
      • 立ち上げ、計画、実行、監視・コントロール、集結
    • 10 の知識エリア(xx マネジメント)
      • 統合(バランス、QCD)
      • スコープ
      • スケジュール
      • コスト
      • 品質
      • 資源(人的)
      • コミュニケーション
      • リスク(脅威、好機)
      • 調達
      • ステークホルダー
• ウォータフォール開発の基本
  • 企画 -> 要件定義 -> 設計 -> 実装 -> テスト -> 運用保守
  • この流れを円滑に進める仕事がプロジェクトマネジメント
  • 要件定義はプロジェクトマネジメントの知識だけでは不可能
    • PM は実際には要件定義のスキルが必要（教科書的には不要らしい）
    • 要件定義は、データの流れなどを考えていくので、エンジニアじゃないとできない。
    • IPA の要件定義
• プロジェクトマネジメントのツールやコツ
  • タスクの分割・スケジューリング
    • WBS(Work Brakedown Structure)
      • 要件定義、設計、実装などをブレイクダウンしたもの
      • 作るものに合わせて、管理しやすくする
    • ガントチャート(スケジュール)
    • スケジュールを立てることの意味
      • 予測
      • メンバーの位置付けの理解
      • 的確な質問や疑問が出てくる
    • 進捗率のパーセント表示などは NG。管理するなら未着手、着手、完了ぐらい。
  • QCD（クオリティ、コスト、デリバリー）
    • トレードオフ
    • これを崩そうとすると、結局うまくいかない
    • PM はこれをちゃんと言えるかどうかが、重要なスキル
    • スケジュールを管理するためにプロジェクトがあるわけではない
  • Tips
    • xx 管理表（課題管理、リスク管理）
    • ファシリテーション
      • 事前準備がほぼ全て
        • アジェンダ、質疑のパターンの洗い出し、ネゴって結論を握っておく etc
      • 空中戦をしない
        • 集中力、考えやすさ、心理的な問題に有用

PM が何の役割なのかは、なんとなくわかってたつもりでした。それが整理されすっきりしました。PM というと何でも屋になりがちですが、本来的にはプロジェクトマネジメント(まんまなんだが)に注力すべきで、そのためにはチームで協力し合うという姿勢は大事だなと感じました。

よく開発の現場では、「要件定義が決まってないから進められない。PM 決めてください」みたいな会話や行動が見られると思いますが、あまり良くないですね。

また、QCD は一見当たり前で当然のように感じますが、プレッシャーがかかった状態だと正常な判断ができない場合があるので、常に頭に置いておきたい内容でした。

その場しのぎだと、見えないコストを支払うことになって結局マイナスになるので、自分の首を絞めないためにも、伝えづらいことでもしっかり言った方がいいと思いました。その伝え方、交渉力も重要なスキルだと思いました。（まぁこれが難しいんですが）

PM という役割をかじっていたり、プロジェクトを経験していると、頷くことが多く、確かになという印象が強かったです。

第 2 週

アジャイル開発について学びました。

• アジャイル開発の概要
  • ウォーターフォール開発
    • 1 回だけ行う。手戻りは無し
  • ウォーターフォール開発の問題点
    • 正確な要件定義は難しい
      • プロジェクトの初期に完璧に作るのは不可能
      • 設計、実装、テストをしてみないとわからない
      • 動くもの無しに、何が足りないとか違うとかわからない
    • 変化が早く、予測が難しい時代にあっていない
      • リリース直前に不要になっている
      • 時間かけて作ったのに、全然違った
  • アジャイル（機敏な）開発
    • 要件定義 -> 設計 -> 実装 -> テストのサイクルを短くして、何度も繰り返す
    • 1 サイクル = スプリント、イテレーション
    • サイクルの間でリリースすることがある
    • アジャイルソフトウェア開発宣言
      • マインドセット
      • 本質的に価値のあるものを作ることに重きを置いている
    • モダンアジャイル
• アジャイル開発の誤解
  • アジャイルなら要件定義不要
  • アジャイルではドキュメントを作らない
  • アジャイルなら仕様変更は自由
  • アジャイルは計画がいらない
• アジャイルの手法
  • XP(エクストリーム・プログラミング)
  • スクラム開発
    • アジャイル開発のフレームワーク
    • 具体的なアジャイルの実現手法
• アジャイルなチームと計画づくり（スクラム開発）
  • チーム作り
    • 「チーム結成、計画、スプリントを回す」という流れ
    • スクラム特有のポジション
      • プロダクトオーナー
        • 作る製品の責任者
        • プロダクトバックログ(やりたいことリスト)の優先順位付けをする
      • スクラムマスター
        • スクラムが正しく適用されていることを保証する役割
        • ロボット掃除機が家に来た時に、最初にやること（開発の障害を取り除く）
      • 開発者（デザイナーなど含む）
    • インセプションデッキ（最初の山札）
      • チームビルディング
      • チームで 10 の質問に答え、目的を合わせる
  • 計画作り
    • プロダクトバックログ
      • 優先順位を設定したリスト
      • これの形式の一つがユーザーストーリー(書き方が決まっている。その一種)
      • ＜ユーザー＞として、＜機能＞が欲しい。それは＜ビジネス価値＞のためだ
      • 作成したものをユーザーストーリーマップという
  • 見積もり
    • WBS の問題点
      • 人月に意味がない場合がある
        • スキルの差、実装の工数は設計次第など
    • ストーリーポイント
      • ユーザーストーリーに相対的なポイントをつける
      • プランニングポーカー
      • 人によってずれるのがポイント。ずれたらそこで相談できる
      • 数字が大きいと、そのままだと難しいタスク
      • チープスプリントを開始して、1 スプリントみれば計画が立てられる
      • だんだん計画が正確になる
• アジャイルなプロジェクトの進行
  • チーム結成 -> 計画 -> スプリント 1 -> スプリント 2 -> スプリント 3 -> ...
  • 1 スプリントは 1 週間〜4 週間にする
  • スプリントの中をみる
    • スプリントプランニング
    • 日々の作業
      • デイリースクラム(デイリースタンドアップ)
    • スプリントレビュー
    • スプリントレトロスペクティブ（振り返り）
  • CI/CD などの準備は、スプリント 0 を設けたりする
  • カンバン
    • スプリントの中でのタスク管理
    • チームタスクの進め方の可視化
    • ツールは、模造紙、Github project、Trello など。
  • アジャイルでは設計もインクリメンタルに実施
    • TDD、リファクタリング、ペアプロ、CI/CD

なんとなくアジャイルというものについて知っていたつもりでしたが、かなりクリアになりました。まずはアジャイルザムライを手始めに、より学習していこうと思います。

また、実践するにはチームの理解なども必要なので、「アジャイルやります」とかで始めると、いきなり導入するのは難しそうだと感じました。いかに導入していくか、有用性をわかってもらうかなど、うまく浸透させるためのプラクティスを知りたいなと思いました。これもアジャイルと言わずにやってみるとか、既に成功してるプロジェクトを引き合いに出すとかがいいんでしょうか。

第 3 週

システム開発の見積りについて学びました。

• システム開発の見積もりに必要な前提知識や基本的な法則
  • 必要な要素
    • 時間、人数、お金
  • 体制、スケジュール、予算
  • 最初の段階で完璧に見積もるのは困難
  • 見積もりに失敗すると...
    • デスマーチ
    • 赤字
    • 信用がなくなる
  • システム開発の見積の法則
    • 不確実性コーン
      • 初期ほどずれやすい
      • 見積もりに幅をもたせる
      • 要件定義や設計が終わっているのか
    • 人月
      • 生産性が同じという前提
      • 単純に人を増やすという選択肢？
      • 1 ヶ月ヘルプが入ると早くなる？
      • コミュケーションコスト、教育コスト、採用コスト
      • ブルックスの法則
• システム開発の時間の見積もり
  • まず見積もりして実行
    • 見積もりと実績を記録し、分析。次の見積に活かす
  • 大きなタスクは分割すべし
  • 実装だけで見積もらない
    • 要件定義、設計、実装、テスト、検証など全部考慮するともっと正確になる
  • 感情・政治を入れない
    • ちゃんと言わないと後でツケを払うことになる
  • 見積もれない場合は、要件定義ができてない可能性大
  • 見積もりは必ず出す。幅で見積もるのもあり。
• 見積の手法
  • KKD 法（おすすめしない）
  • 積み上げ法（定番）
  • ファンクションポイント法
  • ストーリーポイント（アジャイル的）
• 見積のポイント
  • 実装だけで見積もらない
  • バッファを入れる
  • 最初から完璧に見積もらない
  • 工数とリードタイムを分けて見積もる
• システム開発のお金の見積もり
  • 作るもの、作る人によって全然違う。目安はない
  • 請負契約 or 準委任契約
  • 開発の進め方と契約方法の組み合わせには注意
  • 人的コスト
    • なるべく作らないという選択肢を持っておく

注意点として、個人の意見や経験多めと言っていましたが、ざっくりでも流れを知ることができてよかったと思いました。見積もりは難しい前提で、見積もりをどう考えるべきかということを学習することができました。

タスクの分解についてはその通りだなと感じました。いきなり解決できそうにない問題も、独立した問題に分割していったり、まず調査タスクなどにすると、意外と次に進むことができたりするので、どんな仕事する上で必須だなと思ってます。

第 4 週

受講生のアンケートへの回答の講義でした。

• プロキシやリバースプロキシの役割
  • フォワードプロキシ
  • リバースプロキシ
• クリーンアーキテクチャと依存性逆転の原則
  • アプリケーションアーキテクチャ
  • 3 層アーキテクチャ
    • プレゼンテーション、ビジネスロジック、データアクセス
  • レイヤードアーキテクチャ
    • ドメイン層の追加
  • ヘキサゴナル、オニオン、クリーンアーキテクチャ
    • ドメイン層を中心に考える
    • 外から中に依存するようにする
    • クリーンアーキテクチャは思想
    • そもそも依存とは
    • 抽象に依存せよ（依存性逆転）
    • DI（Dependency Injection）とは
• シェルスクリプトの入門
  • Bash
  • リダイレクト
  • パイプ
  • あまり複雑だと、スクリプト言語を使うべきかも
• プログラミング言語はどう動いているのか
  • コンパイラとインタプリタ
  • プログラムの動かし方
    • 機械語に変換
    • 文字列を解釈して動くプログラム（インタプリタ）

今月は自分はリクエストしておらず、知っていることが多かったんですが、それぞれより深掘りして学習したいなと思いました。

まとめ

2 月は、プロジェクトの進め方に関するもので、自分が体系的に学習していない分野が多かったので、満足度高めでした。これを参考に、それぞれ学習を進めようと思います！

いよいよ来月が最終の月になりますが、引き続きがんばります。