DaisukeのITメモ

一人前になる為に。

ProductBacklogの優先順位の決め方_WSJF

目次

概要

ProductBacklogの優先順位を決める際の考え方やフレームワークはいくつか存在する。
そこで今回は、その中でも主流なWSJFについて纏める。

【復習】ProductBacklog（PBL）とは？

  • ScrumにおいてPOが作成,管理するモノ。
  • ProductBacklogItem（PBI）のリスト。
    • PBIには、ユーザーストーリー形式で要件が記載されている。

【大前提】なぜ優先順位を決める必要が有るのか？

  • プロダクトはユーザに使ってもらって始めて価値を発揮するため、てきとうな順番で機能を実現してユーザに届けるのではなく、より価値有るものがより先（早く）にユーザに届くように考える必要が有る。
    • 例えば、毎月300万円の価値が有るプロダクトのリリースを3ヶ月遅らせる事で生じる損失は、900万円（300万円 × 3ヶ月）。
    • 一方で、毎月50万円の価値が有るプロダクトの場合、150万円（150万円 × 3ヶ月）。
    • 上記の様な考え方をCoDと言う。
  • また、下記2つの観点で仮説度が大きいモノは、より早くリリースし、仮説検証を行う方が良い。
    1. 技術的実現性（フィージビリティ）
    2. ビジネス的需要性,収益性（ユーザに受け入れられるか？売れるか？）

CoD（Cost of Delay）とは？

  • デリバリーを遅らせたせいで損するコスト（実現できなかった価値）の事で、「遅延コスト」と呼ばれる。
  • 下記の3つの要素から成る。
    1. ユーザ,ビジネス価値
      • ユーザやビジネスに提供する価値。
      • ユーザに提供できる価値や、我々の収益に与える価値が大きなPBIは、なるべく早くリリースすべき。
    2. 緊急性（時間的制約）
      • ユーザ,ビジネス価値は、時間が経過すると小さくなる。
      • 決まったデッドラインが存在したり、競合との競争性が有るPBIは、なるべく早くリリースすべき。
    3. リスク低減
      • フィージビリティーリスク（技術的実現性）やユーザ,ビジネス価値リスク（本当に需要が有るのか等）を早期に発見,解決する為に、仮説性が高いPBIはなるべく早くリリースするべき。

純粋にCoDがより大きいモノから早くリリースすれば良いのか？

  • 答えは「No」。
  • Q：下記の様な場合において、どの様な順番で着手（実現）すべきか？
    1. 機能A
      • 価値（CoD）：5
      • 作業時間：5
    2. 機能B
      • 価値（CoD）：2
      • 作業時間：10
    3. 機能C
      • 価値（CoD）：10
      • 作業時間：500
  • A：１、２、３の順に着手（実現）するのが、トータルで得られる価値が1番大きい。
  • つまり、CoDだけではなく、作業時間（JobDuration）も考慮して、PBLの優先順位を決める必要が有る。

WSJF（Weighted Shortest Job First）とは？

  • SAFe(Scaled Agile framework)で用いられているフレームワーク。
  • 「重み付けされた最短の作業から着手する」という考え方。
    • 簡単に言うと、「コスパ良いタスクから着手しよう」という考え方。
  • PBI毎に下記式を計算し、値が大きい順に優先順位を付ける。
    • WSJF = CoD / JobDuration
  • CoDとJobDurationの見積もりには、相対見積もりを用いる。
    • どちらの概念も、定量的に見積もり,評価する事が難しいため。
    • Sprintをこなす毎に、相対見積もりの感覚値や考え方を振り返ってブラッシュアップしていく事が大切。

参考文献

所感

  • CoD3要素を相対見積りする際の考え方や基準が非常に重要そう、かつ、難しそうなので、既に優先順位付け,リリースしたPBIとそのビジネス的実績を基にFBを繰り返していく事が非常に重要と考える。

オブジェクト指向の三大要素について

目次

概要

社会人1年目のJava研修にて概念のWhat（何をする事なのか）は理解できたが、Why（何故やるのか、そのウマミ）までは腑に落ちなかったオブジェクト指向三大要素。
今更だが、Whyも基本的なレベルまで理解した気がするため、以下に纏める。
（成長させて頂けるので、マサカリ大歓迎です。）

オブジェクト指向の三大要素

カプセル化（隠蔽）

What（何をする事なのか）

  • クラスのメンバー（フィールドとメソッド）を宣言する際に下記アクセス修飾子（Javaの例）を付与する事で、他クラスからそのメンバーへのアクセス（取得,更新,実行）権限を制限する事。
    • private
    • protected
    • public
  • アクセスを制限したフィールドの取得と更新は、それ専用のメソッド（getter,setter）を使用して行う。

Why（何故やるのか、そのウマミ）

クラス提供者目線

外部から勝手にアクセスされたくないメンバーへのアクセスを遮断できる。

クラス利用者目線

利用して良いメンバーだけ明示的に公開されている事で、利用するクラスの仕様を気にする事なく利用しやすくなる。

継承

What（何をする事なのか）

  • クラス宣言時に既存クラスを継承（Javaならextends）し、既存クラスと親子関係を持つ事により、大きく下記2点の効果を得られる。
    • 親クラスが持っているメンバー（フィールドとメソッド）をそのまま引き継げる。
      • 子クラスのソースコード上には親クラスのメンバーの記述は無いため目には見えないが、ちゃんと引き継がれている。
    • クラスをグループ化する事ができる。

Why（何故やるのか、そのウマミ）

親クラス提供者目線

子クラスの仕様（メソッド名など）を統一させる事ができる。

子クラス作成者目線

  • 既存クラスと似ているが一部内容が違うというクラスを作成する際、継承を利用する事で下記 を実現できる。
    • ソースコード短縮による可読性向上。
      • 継承を利用しない場合は、親クラスと同ソースコードを子クラスに再記述する事になってしまう。
      • 一方で、継承で親クラスのメンバーを引き継ぐ事は、親子クラスが密結合になるため、デメリットであるという考え方も存在する。
    • メンテナンス性向上。
      • 複数箇所に同ソースコードが記述されていると、メンテナンスのコスト,改修ミスリスクが高くなってしまう。

ポリモーフィズム（多態性）

What（何をする事なのか）

同一の親クラス（もしくはインターフェース）を持つ複数クラスを、親クラス（もしくはインターフェース）型の変数に代入する事で、一纏めに扱えるようにする事。

Why（何故やるのか、そのウマミ）

クラス提供者目線

複数クラスの仕様（メソッド名など）を統一させる事ができる。

クラス利用者目線

  • 同一の親クラス（もしくはインターフェース）を持つ複数クラスに対して一度のメソッド呼び出しで同時に命令を下せるため、下記を実現できる。
    • ソースコード短縮による可読性向上。
      • 複数クラスをバラバラに扱うと、クラス数の回数だけメソッド呼び出しの記述を行う必要が有る。
    • メンテナンス性向上。
      • メソッドを呼び出す際、メソッドを保有しているのが誰（どのクラス）なのかを気にせず利用する事ができる。

具体例（ソースコード）

abstract class Mammal{
    abstract void naku();
}


// Mammalクラスを継承。
class Dog extends Mammal{
    void naku(){
        System.out.println("ワン！");
    }
}


// Mammalクラスを継承。
class Cat extends Mammal{
    void naku(){
        System.out.println("ニャオ！");
    }
}


// ポリモーフィズムを利用した記述のMainクラス。
class Main{
    public static void main(String args[]){
        Mammal[] mammals = new Mammal[2];

        Mammal dog = new Dog();
        Mammal cat = new Cat();

        mammals[0] = dog;
        mammals[1] = cat;

        // メソッド呼び出し処理が下記の様に複数箇所存在する場合に、仕様変更でCatクラスがBirdクラスに変わったとしても、Catクラスのインスタンス化部分だけ改修すれば良い。
        // つまり、メソッド呼び出し部分は改修不要。（メソッドを保有してるクラスが誰かなんて気にしなくて良い。）
        for(Mammal mammal: mammals) {
            mammal.naku();
        } 

        for(Mammal mammal: mammals) {
            mammal.naku();
        } 

        for(Mammal mammal: mammals) {
            mammal.naku();
        } 
    }
}


// ポリモーフィズムを利用しない記述のMainクラス。
class Main2{
    public static void main(String args[]){

        Dog dog = new Dog();
        Cat cat = new Cat();

        // メソッド呼び出し処理が下記の様に複数箇所存在する場合に、仕様変更でCatクラスがBirdクラスに変わってしまうと、Catクラスのインスタンス化部分だけの改修では不充分。
        // 全てのメソッド呼び出し箇所も改修する必要が有る。（メソッドを保有してるクラスが誰かを気にしなくてはならない。）
        dog.naku();
        cat.naku();

        dog.naku();
        cat.naku();

        dog.naku();
        cat.naku();
    }
}

所感

  • 親クラス継承とインターフェース実装の両方が存在するウマミが分からない。
    • 1つのクラスは1つの親クラスしか継承できないのに対し、インターフェースは何個でも実装できるため、インターフェースだけで事足りるのでは？
    • インターフェースは抽象メソッドしか定義できないが、親クラスは普通のメソッドも定義できるという違いがウマミ？
  • この程度の記事を書くのに1.5hもかかってしまった。もう少し文章Outputの速度を上げる必要が有る。

Jiraについて

目次

概要

AtlassianのJiraを会社とプライベートで使用しているが、いまいち各機能の建て付けが理解できず使いこなせていないので、Jiraに登場する概念や機能を理解する為に調査した結果を以下に纏める。

概念,機能

課題

開発メンバーがこなすべき開発タスクやToDo項目。
担当者,ステータス,想定工数,コンポーネント,リリース,エピックなどが設定できる。
下記3つの種別が有る。

  • タスク
  • ストーリー
  • バグ

サブタスクを持てる。

サブタスク

タスクを更に細かく分割したタスク。

  • 例）
    • タスク：ログイン機能を実装する。
    • サブタスク1：ログイン画面（クライアント）を実装する。
    • サブタスク2：認証機能（サーバサイド）を実装する。
    • サブタスク3：ログイン画面後の画面遷移を実装する。

ストーリー

「ユーザーストーリー」の事。
要件またはリクエストをエンドユーザーの観点から簡潔に纏めたモノで、複数のタスクを包括する。

プロジェクト

課題をまとめる1番大きな単位。
Gitのプロジェクトと同じ単位だと分かりやすいかも。

ボード

Jiraソフトウェアのボードは、進行中の作業を表示,管理,レポートする為の画面。

カンバンボード

進行中の作業の管理に重点を置いており、（スプリントではなく）継続的なフローで作業を監視するアジャイルチーム向けのボード。

Scrumボード

バックログから作業するアジャイルチームの場合、スプリントでの作業を計画および見積もり、定期的なスケジュールで作業を提供してくれるボード。

エピック

複数のタスクやストーリーをグルーピングできる。
ある課題の説明が1つの機能、もしくはもっと大きな作業になりそうであれば、エピックに変換する。

ロードマップ

エピック毎のマイルストーンや進捗を管理する為の機能。

コンポーネント

プロジェクトの課題をさらに小さく分け、管理しやすくするために存在する。
各コンポーネントには担当者を決められる。
エピックは、作業の大きさという軸で課題を包括する役割の一方、コンポーネントは課題の種別毎に課題を包括する役割のよう。
そのため、プロジェクトの中で、大枠の機能や役割でサブチームが構成されている際などに便利かも？

スイムレーン

カンバンボードを、タスクの担当者や優先度などに基づく複数の行に分割して、視覚的にタスクの種別を捉えやすくする機能。

リリース（バージョン）

課題に設定できるラベルの1つ。
リリース日（タスク完了のマイルストーン）を設定でき、対応するタスクをそれぞれのリリースに紐付ける事で、リリースに向けて必要なタスクの一覧やそれらの進捗が一目で把握できる機能。
タスクチケットの「バージョン」フィールドを設定する事で、任意のリリースにタスクを紐付ける事ができる。

所感

作業の大きさという軸で言うと、恐らくプロジェクト > コンポーネント > エピック > ストーリー > タスク > サブタスクの関係にあると理解した。

参考文献

WIP：自分のWill,Can,Mustについて

目次

概要

OffJTの学習内容を決めるにあたって何を優先して学習すべきか迷っている時に、R社が導入しているWill,Can,Mustというフレームワークが有る事を会社の先輩から教わった。
学習内容の決定にこれを活用してみる事にした。

前提

前提として、自分が学習したい（もしくはする必要が有る）と考えている学習内容を以下に書き出しておく。

プログラミングの基礎（すぐにでも学習したい）

  • やさしいC
    • 去年の研修時期に使用していた本で、プログラミングのお作法や基本的なプログラミングを学べる。
    • 途中で学習が止まってしまっており、プログラミングの基礎力を固める為にも最後までしっかり学びたい。

スマホアプリ開発（すぐにでも学習したい。来年度から配属予定の部署でもスマホアプリを開発している。）

  • SwiftによるiOSアプリの開発。
  • AndroidJavaによるAndroidアプリの開発。
  • Flutter（XPlatform）によるアプリ開発。
    • Dartと各ネイティブ言語（Swift,AndroidJava）の繋ぎの部分も学習したい。
  • スマホアプリのバックエンドの学習。
    • FirebaseなどのmBaaSについて学びたい。

Cloud（優先度低め）

  • クラウドを使用した案件が増えて来る可能性が有るため。
  • 漠然と学習した方が良さそうな雰囲気を感じているため。

開発手法（すぐには必要とはならないが、来年度から配属予定の部署では頼りにされる可能性大。）

  • Agile,DevOps,XP
    • 基本的な概念については、会社の研修や読書でインプットし、下記記事などにアウトプットする事である程度知っているくらいのレベル。
    • 実用的な知識や知見を更に身に付ける必要が有る。
      • 今後、Agileが必要とされる案件が増えて来る事や、来年度からの配属が決まっている部署に移った際に、Agile関連の知識については頼りにされる場面が多いと予想されるため。

体系的な知識

  • 応用情報技術者試験
    • 基本情報を取得したので、純粋に次のステップとして体系的な学習ができる良い機会。
    • 会社の昇進にもいずれ必要となってくる。

ビジネス（社会人としての基本行動にも繋がるので、Tech領域だけに偏った学習になりたくない。）

  • 考える技術・書く技術の読書。
    • 基本的な思考能力、文章構成力、説明力などを身に付けられる。
    • 会社の先輩にお勧めして頂いたが、途中までしか読めていない。
  • 英語（主にListening&Speaking）
    • 社会人としてはもちろん、一人の人間として当たり前に欲しい能力。
    • 今の部署では語学学習に対して補助金が出るので、移動前に利用したい。

Can,Will,Mustを書いてみた

iOSアプリの開発環境について

目次

概要

iOSアプリの開発環境ツールについて、様々なサイトを見ても結局よく分からない下記観点を簡単に纏めてみた。 - 使用するツールと、使用する理由。 - 環境整備の手順。

必要ツール

  • Mac
    • iOSアプリの開発に必須なXcodeは、Mac上でしか動作しない。
  • Apple ID（いらないかも）
    • 後述のXcodeをAppStoreからインストールするなら必要。
    • Xcodeをxipファイルなどを使用してインストールするなら不要。
  • Xcode
  • Homebrew
    • MacOS上の開発に必要なパッケージ管理ツール。パッケージマネージャー。
    • パッケージのインストール,アンインストールをコマンドラインで実行でき、パッケージ間の依存関係を自動で解決してくれる。
      • もし、パッケージマネージャーを使用しない場合、下記の様な手順を踏む必要が有る。
        1. インストールしたいパッケージのサイトをブラウザで見つける。
        2. パッケージのサイトでインストールの方法を確認する。
        3. バッケージのインストーラーをダウンロードする。
        4. 依存関係が有れば、そのパッケージを先にインストールする。
        5. パッケージをインストールする。
    • パッケージとは、実行ファイル,設定ファイル,ライブラリなどを1つに纏めたモノ。
    • Mac用のパッケージ管理システムでMacPortsというモノも有るが、ローカルに既存のパッケージを考慮せずインストールを行ってしまう。一方で、Hombrewはローカル既存のモノを極力使おうとしてくれる。
  • CocoaPods
    • アプリ開発用のパッケージ管理ツール。
      • Homebrewと同じく、パッケージのインストール,アンインストール,依存関係などを一元管理してくれる。
    • Homebrewはどちらかと言うと汎用的パッケージ向け、CocoaPodsはアプリ開発用パッケージ向け、らしい。
  • Swift Package Manager（いらないかも）
    • CocoaPodsと同じく、アプリ開発用のパッケージ管理ツール。
    • CocoaPodsの代わりに使用できるらしい（詳細はよく分からない）。
  • Git

環境整備手順

  1. Xcodeをインストール。
  2. XcodeのCommand Line Toolsをインストール。
    • Command Line Toolsとは：
    • Homebrewのインストール手順に記載の通り、XcodeのCommand Line Toolsが無いとHomebrewをインストールする事ができない。
    • Command Line Toolsのインストール方法は下記の2つ。
      • CUI：xcode-select --install
      • GUI：Xcodeのインストール後、初めて立ち上げた際に下記のようなダイアログが出て来るので、Installを押下。
        XcodeのCommand Line Toolsのインストール
    • Command Line Toolsのver確認方法。
      • Xcode > Preferences > LocationsのCommand Line Toolsを参照。
    • 注意点：XcodeのGUIとCUIのバージョンについて：
      • 上記で設定するCommand Line Tools(CUI)のバージョンと、アプリとして開くXcode（GUI）のバージョンに差異が生じているとエラーが吐かれるなどの不具合が生じるので、注意。
  3. Homebrewをインストール。
    1. 上記オフィシャルサイトの手順に沿ってインストール。
    2. brew updateで、インストールしたHomebrewを最新化する。
      • 定期的に実行して、Homebrewを最新状態に保つのが良いらしい。
  4. Gitをインストール。
    • brew install gitを実行。
    • GUIからインストールもできるようだが、せっかくなら、Homebrewでインストールして管理したい。
  5. CocoaPodsをインストール。
    • brew install cocoapodsを実行。
    • 他にもいくつかインストール方法が存在するが、せっかくなら、Homebrewでインストールして管理したい。
  6. Homebrewでインストールしたツールを最新化。
    • brew upgradeを実行。
      • インストールした全てのformulaeのバージョンを一斉に更新。

【補足】.gitignoreに記載すべきファイル（2022.12.4追記）

XcodeプロジェクトをGitで管理していると、自動生成される不要ファイルもGit管理対象に含まれてしまう。
管理対象から除外すべきファイルを以下に纏める。

  • .DS_Store
  • UserInterfaceState.xcuserstate
    • Xcoceにより自動作成される不要ファイル。

所感（2021.4.29追記）

  • Macにデフォルトで搭載されているRubyの正体がいまいち掴めない。それに付随するGemについても要勉強。
    • →　Rubyとは、オブジェクト指向のスクリプト言語の事。
    • →　Gemには、以下の2つの意味が有る。
      • Rubyのパッケージ（ライブラリ）。例えば、ユーザー登録機能や認証機能といった複雑な機能も、gemを使えば簡単に実装可能できる。
      • gem（パッケージ）の管理システム。正式名称はRubyGems。gemパッケージのインストールやアンインストールなどの操作に使う。
  • CocoaPodsはインストール方法が複数存在するが、最適方法の選定するにはまだ知識が足りない。
    • →　CocoaPodsのインストール方法として上記ではHomebrewを紹介しているが、CocoaPodsはRubyで開発されているためGemでもインストール可能。かつ、CocoaPodsとしてはGemでのインストールを推奨しているらしい。インストール方法毎のメリデメは以下。
      • Homebrew：
        • メリット：インストール,アップデート,アンインストールなどの管理が容易。
        • デメリット：インストール場所の自由度が低いらしい。
      • Gem：
        • メリット：Homebrewやrbenvなどの外部ツールが不要。
        • デメリット：古いバージョンのアンインストールが面倒。インストールの際に競合してしまう場合が有るらしい。
  • HomebrewとCocoapodsの使い分けがいまいち掴めない。
  • Homebrewのcaskの立ち位置がよく分からない。
    • →　ChromeやFirefoxなどのGUIツールをインストールする際に使用する。
  • Command Line Toolsの立ち位置がよく分からない。
    • →　招待は未だによく分からないが、Homebrewをインストールするには必須。

WIP：VUCAとは

目次

概要

Agileについて学習した際に、Agileという概念が世の中に必要になった理由が気になった。 その理由に深く関係するVUCAについて以下に纏めた。

Agileとは

daisukeinoue.hatenablog.com

VUCAについて

参考文献

VUCAとは？意味・VUCA時代の対応方法・OODAループを紹介 | | 人事部から企業成長を応援するメディアHR NOTE

Agileとは

目次

概要

従来の（レガシーな）開発手法であるウォーターフォールに代り台頭している、デジタルな開発手法Agile開発 について纏めてみた。

Agileとは

VUCAの時代の中で、目的を達成し、その成果を最大化する為の考え方,概念。
ソフトウェアの開発方法論というよりは、ビジネスの作り方らしい。

Agile台頭の理由

下記のように、ウォーターフォールの開発手法と現在のビジネス環境にギャップが生じているため。
ウォーターフォールでは対応できない様なビジネスが増えてきた。

ウォーターフォールとは

ウォーターフォール開発は名前の通り、水が下に向かって流れ落ちていくように、要件定義,外部設計,内部設計といった各工程を手戻りしないよう進めていく。
最初に全ての要求を集め、開発スコープを明確に定義し、その為に必要な期間,人員などのコストを見積もり、開発工程が終わった際に初めて大きな成果物をドカンと完成させるビックバン型の開発手法。
簡単に言うと、最初に行き先を1点に決めて、そこに向かってめちゃ大股1歩で進む（途中で方向転換不可）スタイル。
そのため、求められる要件がコロコロ変わったり、ビジネス効果の見通しがつき辛いといった特性のビジネスには向いていない。

  • メリット：
    • システムのゴールや各工程の成果物が明確で、進捗状況が把握しやすいことが挙げられる。
  • デメリット：
    • 全工程が完了して初めて、システムの動作を確認でき、ユーザーからのFBが得られる。
      • 例えば、要件定義の大前提が誤ったまま開発を進め、テスト工程になどでそれに気付いた場合、それまでの全工程が無駄になってしまい、0から作り直しという事も有るため、手戻りのダメージが大きい。
      • システム利用者の意見を、要件定義や設計工程の段階で全て洗い出す必要が有る。

一方で、現在のビジネス環境は

世の中がVUCAの時代を迎えている事で、企業の方針や取り巻く状況もどんどん変化が速くなり、予測できない未来が次々に訪れている。
スピード感が必要な事業や、Try＆Errorを繰り返しながら進んでいく領域では、WhatやHowが最初に完全にfixしている必要があるウォーターフォール開発では対応しきれなくなってきた。
VUCAについては下記記事を参照。 daisukeinoue.hatenablog.com

Agileの順応性

一方、Agileでは、「事前に全ての事を正確に予測し、計画する事はできない。」という事を前提としているため、期間や人員だけを決定,固定し、その範囲内で大事な要求（重要なモノ,リスクが高いモノ）から順にプロダクトを作成する。
また、それを短期間のサイクルで何度も繰り返す事で、動くモノを短期間で素早くリリースしFBを取り込み続けるスモールスタート型の開発手法。
簡単に言うと、最初に行き先を決め切らず方向性だけ決めて、そこに向かってめちゃ小股で何歩も刻みながら進む（途中で方向転換可能）スタイル。
そのため、求められる要件がコロコロ変わったり、ビジネス効果の見通しがつき辛いといった特性のビジネスに向いている。

ビュッフェを例にした簡単な説明

ウォーターフォールの場合

全ての料理に対して、どの順番でどの食事をどの量で取って来て食べるかを最初に綿密に計画し、全料理食べ終わるまで計画を変更せず（FBを取り入れない）、何が有っても（気分が悪くなったり、食べたく無いモノが有っても）計画に従って食事を終える。
→　最終的な満足度は高くないかもしれない。

Agileの場合

まずは重要そうな（自分が大好きな）料理だけを取って来て食べて、その後も気分や食べたくなったモノを優先的に、少量ずつ細かい頻度で料理を取って来て食べるを繰り返す。
→　料理を取り直す度に常にFB（その時の状況）を取り入れて最善の料理を取り食べているので、最終的な満足度は高いはず。

鬼ごっこを例にした簡単な説明

ウォーターフォールの場合

鬼の位置を低い頻度で確認しながら逃げる。
→　鬼の位置を把握していない（FBを得られない）間は、最適な軌道修正を行えないので、鬼に捕まりやすい（成果が出ない）。Agilityが低いと言える。

Agileの場合

鬼の位置を高い頻度で確認しながら逃げる。
→　鬼の位置をほぼ常に把握しており（FBを得ている）、常に最適な軌道修正を行えるので、鬼から逃げやすい（成果を出しやすい）。Agilityが高いと言える。

思想

下記の様な思想から成り立っている。

  • 関係者は目的達成の為に互いに協力し合いながら進める。
  • 一度に纏めて作るのではなく、小さな単位で少しずつ作成し動くモノを早い段階から届け、ユーザーやステークホルダーからの評価,FBを繰り返し得る事で、作っているモノ自体や計画を調整し、成果を最大化する。

思想の根底

上記の思想は、下記の考えが根底に有る。

  • ソフトウェアを作成する目的は、作成自体ではなく、その先に有る、成果をあげる事（あげ続ける事）。
  • 成果とは、ユーザーやお客様の課題を解決したり、お金を稼ぐ事。
  • よって、何の為に作るか（why）を常に明確にしつつ、現在作成しているモノが本当に成果を実現できているのかをこまめに確認しながら進めていく必要が有る。
  • その過程で、当初作ろうと思っていたモノよりも良いアイディアが出てくればそれを受け入れ、作るモノを変えていく事で、成果の最大化を図る。

実現手法

Agileを実現する為の手法には例えば下記の様なモノが有る。

Agile向きの案件とは

現代の全てのビジネスがAgileに向いているというわけではない。
ビジネスの特性から、採用すべき開発手法を見極める必要が有る。

Agile向きの案件例

Agile向きの案件特性としては大きく下記の2つ。

  • Delivery（俊敏性）重要視の案件
    ある時点まで、もしくは、なるべく早くリリースする事でビジネス効果が最大化される様な案件。例えば下記の様な案件。
    • 法律緩和,強化への対応。
    • 競合他者との競争。
    • トレンドへの急速な対応。
  • 即応性重要視の案件
    事前にビジネス効果の見通しがつかない、もしくは、要求がコロコロ変わる様な案件。例えば下記の様な案件。
    • 新規事業。
    • 先進技術活用。

WF向きの案件例

WF向きの案件の特性としては大きく下記の2つ。

  • 確実性重要視の案件
    元から要求が明確で、変更対応も求められない様な案件。
  • QCD平準性重要視の案件
    求める要求を、なるべく安く、決められた期間で確実に作りたい様な案件。

【おまけ】Agile案件に適した契約形態

  • 下記理由より、納品物に対してお金を頂く請負契約よりも、提供した稼働時間に対してお金を頂くSES（準委任契約）の方が適していると考えられる。
    • Agileの性質上、事前に成果物を明確に定義できないため。
    • WF特有の包括的なDocやプロセスを、Agileでは一部省略しながら進めるため、Doc納品が必須な契約は向いていない。
  • SESと請負のハイブリッドにする場合は、MVP（必ず実現すると決まっているコア機能）に対してだけ請負契約とし、他稼働についてはSESとするというパターンが考えられる。

WF特有の包括的なDocやプロセスをAgileで省ける理由

  • 純粋にAgilityを高める為。
  • 下記理由により、WFとAgileでDocの重要性に差が有るため。
    • WF：
      • 工程が分断されている事が多く、体制や人も分断される事が多いため、工程を跨いだ仕様情報の橋渡しの生命線をDocが担う事になるため。
      • 事前に成果物が明確になっていたり、品質を求められる事が多いため、請負契約の場合が多く、Docも納品物として定められている場合が多いため。
    • Agile：
      • WFと違い、工程が分断されていない事と、Scrumメンバが機能横断的（どのプロセス・工程も実行できる）なため、工程を跨いだ仕様情報の橋渡しがDocでなくても成立する。
      • SES契約の場合は、Docは納品対象でないため。

所感

  • Agile案件の契約形態における制限など有るのか、有るならどのようなモノなのか気になった。
    • →　有識者である先輩からFB頂いたので、上記に追記済み。
  • Agileが向いている案件,向いていない案件を判断する考え方も気になるので、今後の学習課題とする。
    • →　有識者である先輩からFB頂いたので、上記に追記済み。
  • AgileとDevOpsの関係性を明確に理解できていないので、今後DevOpsについても自己学習したい。

参考文献

なぜアジャイル開発？ウォーターフォール開発からの脱却 | Qbook

/* -----codeの行番号----- */