技術とか戦略とか

IT技術者が技術や戦略について書くブログです。

情報処理技術者試験対策「ゲーム理論」

目次

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM

-------------------------------
今回は、OR・IE分野のゲーム理論について説明します。
これも実務で直接的に使う知識ではありませんが、意思決定を行う際に利用できる知識なので社会人であれば知っていて損はありません。
この分野について好きに書き始めると本が一冊出来上がりかねないので、今回は情報処理技術者で出題される可能性がある範囲に絞って説明します。
 
ゲーム理論は、複数のプレイヤーが存在する状況下において、最適な選択肢を選択するために使われる理論です。
主に「ゲーム木」と「利得表(利得行列)」を用いて状況を分析するのですが、情報処理技術者試験で集中的に出題されるのは利得表の方です。
とは言えゲーム木も出題される可能性があるので、簡単に説明します。
 
ゲーム木は、選択肢による分岐と各々の分岐で得られる利得を記述する方法です。
それぞれのプレイヤーが交互に意思決定を行う(相手がどの選択肢を選んだのかを見てから自分の選択肢を選べる)場面で有効な方法であり、例としては下記のように記述します。f:id:akira2kun:20180710235006j:plain

利得表は、各々のプレイヤーの選択肢の組み合わせと、各々の組み合わせの利得を表形式で記述する方法です。
それぞれのプレイヤーが同時に意思決定を行う(相手がどの選択肢を選んだのかわからない状態で自分の選択肢を選ぶ)場面で有効な方法で、例として下記のように記述します。

f:id:akira2kun:20180710235031j:plain

利得表から導き出せる戦略・状況としては、下記のようなものがあります。
もしかしたら下記にない戦略・状況が出題されるかもしれませんが、その場合は問題文中で何かしらの説明があるはずです。
(下記にない戦略・状況については、利得表外のパラメータが別途必要となるため)

  • ナッシュ均衡
    お互いに最適戦略(相手が選ぶ選択肢によらず、必ず他の選択肢よりも高い利得を得られる選択肢)が存在する場合に、お互いに最適戦略を採用する状態のことを指す。
    この状態の時は、お互いに他の戦略を選択する動機が生まれず、状況が硬直化する。
    例1ではお互いに最適戦略が存在するため、ナッシュ均衡の状態になる。
    プレイヤーaの最適戦略はa1である。
    (プレイヤーbがb1を選ぶ場合は、a1なら40、a2なら30の利得となりa1が優れる。プレイヤーbがb2を選ぶ場合は、a1なら50、a2なら25の利得となり、この場合もa1が優れる。)
    また、プレイヤーbの最適戦略はb2である。
    (プレイヤーaがa1を選ぶ場合は、b1なら20、b2なら30の利得となりb2が優れる。プレイヤーaがa2を選ぶ場合は、b1なら10、b2なら25の利得となり、この場合もb2が優れる。)
    よって、a1とb2でナッシュ均衡となる。
  • 純粋戦略
    ある一つの選択肢を確定的に選ぶ戦略。
    上記のナッシュ均衡の例で言うと、プレイヤーaはa1を選び続ける純粋戦略であり、プレイヤーbはb2を選び続ける純粋戦略である。
  • ラプラス原理
    相手の各選択肢の選択確率が不明の場合に、各々の選択肢が等確率で選ばれると仮定して期待利得を算出し、最も期待利得が高くなる選択肢を選択する。
    例2において、プレイヤーbの戦略b1と戦略b2の選択確率が共に0.5であると仮定すると、戦略a1と戦略a2の選択確率は以下のようになる。例2ではどちらも期待利得が変わらないのでどちらを選んでも良い。
    戦略a1…-15*0.5 + 20*0.5 = 2.5
    戦略a2…5*0.5 + 0*0.5 = 2.5
  • 期待値原理
    相手の各選択肢の選択確率が予測できる場合に、各々の選択肢の選択確率を考慮して期待利得を算出し、最も期待利得が高くなる選択肢を選択する。
    例2において、プレイヤーbの戦略b1の選択確率が0.8、戦略b2の選択確率が0.2であると仮定すると、戦略a1と戦略a2の選択確率は以下のようになる。この場合は戦略a2を選択するべきである。
    戦略a1…-15*0.8 + 20*0.2 = -8
    戦略a2…5*0.8 + 0*0.2 = 4
  • 混合戦略
    相手がどのように選択肢を選んだとしても、常に一定の期待利得を得らえるように一定の確率で各選択肢を選択する戦略。
    例2においては、プレイヤーaは戦略a1を0.5、戦略a2を0.5の確率で選択することで、プレイヤーbがどのように選択肢を選択したとしても2.5の期待利得を得ることができる。また、プレイヤーbは、戦略b1を0.5、戦略b2を0.5の確率で選択することで、プレイヤーaがどのように選択肢を選択したとしても-2.5の期待利得を得ることができる。
    混合戦略となる選択肢の選択確率を算出する方法としては、連立方程式を解く方法、微分を用いる方法等がありますが、試験では出題されないと思うので詳細は割愛する。
    (仮に混合戦略が出題されたとしても、選択式問題なので算出方法を知らなくてもなんとかなります)
  • マクシミン原理
    相手が自分にとって最も望ましくない(最も自分の利得が少なくなる)選択肢を選ぶという前提において、得られる利得が最も大きくなる選択肢を選択する。
    損失を避けたい場合に採用する原理である。
    例2において、プレイヤーaが戦略a1を選択した場合は、戦略b1が最も望ましくない選択肢であり、この場合のプレイヤーaの利得は-15である。戦略a2の場合は、戦略b2が最も望ましくない選択肢であり、この場合のプレイヤーaの利得は0である。よって、マクシミン原理に従うならプレイヤーaは戦略a2を選択するべきである。
  • マクシマックス原理
    相手が自分にとって最も望ましい(最も自分の利得が多くなる)選択肢を選ぶという前提において、得られる利得が最も大きくなる選択肢を選択する。
    一般的には楽観的な原理であるとされているが、筆者の見解としては相手が選ぶ選択肢をコントロールできる場合に採用するべき原理であると考えている。
    例2において、プレイヤーaが戦略a1を選択した場合は、戦略b2が最も望ましい選択肢であり、この場合のプレイヤーaの利得は20である。戦略a2の場合は、戦略b1が最も望ましい選択肢であり、この場合のプレイヤーaの利得は5である。よって、マクシマックス原理に従うならプレイヤーaは戦略a1を選択するべきである。

情報処理技術者試験対策「リーダーシップ状況論」

目次

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM

-------------------------------
今回から企業活動について記事を書いていこうと思います。
今回は、経営・組織論の内、リーダーシップ状況論について書こうと思います。
ちゃんとした説明がないと理解が難しい所だと思うので。
実務で直接的に使う知識ではありませんが、どの業界でも使える知識なので社会人として知っていて損はありません。
 
組織とリーダシップの関係は下記図のようになるとされています。
組織が成熟するにつれて、有効なリーダーシップの取り方がa→b→c→dに移行するとされています。

f:id:akira2kun:20180710234353j:plain

aは組織の発足時の段階であり、構成員のスキルも自主性も不足しているため、仕事関係本位でリーダー自ら先頭に立ってチームを引っ張る必要があります。
スポーツに例えると「選手をきちんと管理することが勝つための条件だ。」という状態です。
 
bはaから成熟度が進み、構成員がスキルを身に付け始める頃です。
構成員を引っ張ることから、構成員の自主性を育てることに徐々にシフトしていくため、仕事関係本位のリーダーシップだけでなく人間関係本位のリーダーシップも強めていくことが有効になります。
スポーツに例えると、「うるさく言うのも半分くらいで勝てるようになってきた。」という状態です。
 
cは更に成熟度が進み、構成員が自主性を身に付けはじめ、自分の仕事を自ら見つけ、必要なスキルを自ら身に付けるようになり始める段階です。
この段階になると、仕事本位のリーダーシップを取る必要性が薄くなり、構成員の自主性を維持するための人間関係本位のリーダーシップを前面に押し出すことが有効になります。
スポーツに例えると、「勝つためには選手と十分に話し合って戦略を作ることだ。」という状態です。
 
dは成熟度が最も進んだ段階で、各々の構成員が自らリーダーシップを取るようになるので、リーダーは人間関係本位のリーダーシップも弱め、構成員に任せて見守るというリーダーシップの取り方が有効になります。
スポーツに例えると、「勝つためには選手に戦術の立案と実行を任せることだ。」という状態です。

情報処理技術者試験対策「リスクマネジメント」

目次

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM

-------------------------------
今回は、リスクマネジメントについて書きたいと思います。
基本情報ではまず出題されないテーマなのですが、個人的にこういう話は好きなので。すみません。
実務では勘と経験と度胸に基づく判断がされがちなので、実は直接的に使うことは少ないのですが、リスクへの対応を考える際にリスクマネジメントの手法を知っているのと知らないのとでは決断の質に差が出ると思います。
 
そもそも、リスクとは予想される結果が不定であり、良い結果に終わるケースと悪い結果に終わるケースで差がある状態のことを指します。
そのため、悪い結果をもたらす脅威のリスクだけでなく、良い結果をもたらす好機のリスクも存在します。
対応が必要なのは、主に脅威のリスクに対してです。
 
プロジェクトには様々なリスクがあり、優先順位をつけて対応する必要があります。
優先順位を定性的に判断するための手法が、発生確率・影響度マトリックスです。
下記図のように、発生確率と影響度を表にし、発生確率と影響度が共に高いリスクを優先的に対応します。

f:id:akira2kun:20180709232605j:plain

  

定性的に優先順位付けされたリスクに対しては、定量的な判断を行い、具体的にどの程度の損失・利得が発生するのかを数値(金額等)で表現し、意思決定を行います。
定量的な判断を行う手法については、以下のようなものがあります。

  • デシジョンツリー分析
    取り得る対応策と対応策を選んだ結果得られる損失・利得を樹形図にして表現する。
    状況次第で、一つの対応策につき複数の結果に分岐し得るため、どの程度の確率でどの分岐に進むのかも記述する。
  • 感度分析(トルネードチャート)
    各々のリスクについて、最良の結果を始点として最悪の結果を終点とする棒グラフを書き、結果にどの程度のブレが生じ得るのかを数値化・視覚化する。
  • 期待金額価値分析(EMV
    各対応策について、デシジョンツリー分析により各結果の生起確率と結果の損失・利得を求めた後に、生起確率×損失・利得で期待金額を算出し(加重平均を取り)、各対応策を選んだ結果得られる損失・利得の平均値を求める。
    この平均値により意思決定を行う。
  • インタビュー
    専門家やステークホルダーにインタビューを行い、リスクの発生確率や影響度を数値化する。
    楽観値・最頻値・悲観値を求める三点見積もりが良く用いられる。
  • モンテカルロシミュレーション
    プログラムを用いてランダムな試行を統計的に信頼できる回数繰り返すことで、法則や期待結果を疑似的に導出し、未来の結果を予測したり、最良の選択肢を選びだしたりする。
     

リスクへの対応策としては、大きく分けて以下のようなものがあります。f:id:akira2kun:20180709232641j:plain

情報処理技術者試験対策「アーンドバリューマネジメント」

目次

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM

-------------------------------
コストマネジメントの手法として、アーンドバリューマネジメントと呼ばれる手法があります。
実際にかかったコストや実際の成果物の量を計画値と照らし合わせることでコスト管理をする手法であり、応用情報や高度情報(PM)では頻出です。PMPの試験でも出題されます。
実務でもPMがよく使っています。
PGやSEの内はあまり馴染みがないと思いますが、PMを目指すなら避けては通れないですし、基本情報でも出る可能性はあるので、これを機に覚えた方が良いでしょう。
 
アーンドバリューマネジメントでは、管理対象の工程についてまずPV(計画価値、Planned Value)を定めます。
PVは「計画工数(人日)×1人日当たりの費用」で求まります。
また、縦軸にコスト、横軸にスケジュールをとると、PVは下記のようにS字を描きます。

f:id:akira2kun:20180708232625j:plain


(工程開始時は前準備のため工数を割けない、準備が整い次第工数を割いて進捗、工程完了間際は一部の残作業の消化となるため再び工数を減らす)

次に、実際にかかった費用をAC(実コスト、Actual Cost)として計測します。
ACは「実際の工数(人日)×1人日当たりの費用」で求まります。
ACがPVよりも高ければ予定よりもコストがかかっているということになり、逆に低ければ予定よりもコストが少なく済んでいるということを指します。

f:id:akira2kun:20180708232649j:plain

そして、実際に生産された成果物の価値をEV(アーンドバリュー(直訳すると取得価値)、Earned Value)として計測します。
EVを計測する方法としては重み付けマイルストーン法や固定法等がありますが、情報処理技術者試験では金額という形で前提条件として提示されます(今のところは)。
EVがPVよりも高ければ予定よりも多くの成果物を生産できていることになり、逆に低ければ予定よりも成果物を生産できていないということを指します。

f:id:akira2kun:20180708232714j:plain

 

PV、AC、EVの3つの指標を見ることで、進捗状況を把握することができます。
例えば、ACがPVよりも高く、EVがPVよりも低い場合、多くのコストをかけても予定通りに成果物を生産できていないことを指していますので、進捗しない原因を調べて除去する、計画が楽観的すぎでないか見直す、等の対応が必要になります。
 
以下は、PV、AC、EVの3つの指標から算出できる指標です。
これも出題されることがあります(計算式も覚える必要があります)。

  • CV(コスト差異、Cost Variance)
    コストが予算内に収まっているかを計測(CV≧0なら予算内)。
    成果物(EV)を生み出すのに必要以上にコスト(AC)がかかっていないかを計測すれば良いので、
    CV = EV - AC
  • SV(スケジュール差異、Schedule Variance)
    計画通りに成果物を生産できているかを計測(SV≧0なら計画通りかそれ以上)。
    成果物(EV)が予定(PV)よりも早く出来上がっているかを計測すれば良いので、
    SV = EV - PV
  • CPI(コスト効率指数、Cost Performance Index)
    1単位のコストに対する成果物の生産量を示す割合(CPI≧1なら予定以上の効率)。
    CVを指標(比率)として算出したものである。
    CPI = EV / AC
  • SPI(スケジュール効率指数、Schedule Performance Index)
    1単位の期間に対する成果物の生産量を示す割合(SPI≧1なら予定以上の効率)。
    SVを指標(比率)として算出したものである。
    SPI = EV / PV
  • BAC(開始時プロジェクト予算、Budget At Completion)
    プロジェクト全体の予算。
    各工程のPVの合計。
  • ETC(残作業のコスト見積り、Estimate To Completinon)
    残作業で発生するコストの見積もり。
    残作業は、プロジェクト開始時で生産予定の成果物-今まで生み出した成果物である。
    ここで、コストに対する生産量を把握できれば、残作業がどの程度のコストをかければ完了するのかを把握することができる。
    よって下記式となる。
    ETC = (BAC - EV) / CPI
  • EAC(完成時総コスト見積り、Estimate At Completion)
    プロジェクト完了時の実際のコストの見積もり。
    過去の作業の実コストはAC、未来の作業のコスト見積もりはETCで求まるため、下記式となる。
    EAC = AC + ETC

なお、今回は具体的な金額の例を出しませんでしたが、これについては過去問が良い例になりますので、実際に過去問で計算して確かめてみましょう。

情報処理技術者試験対策「クリティカルパス」

目次

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM

-------------------------------
今回は、プロジェクトマネジメントのプロジェクト・タイム・マネジメントについて、クリティカルパスの話をしたいと思います。
 
システムを開発する上では、色々な作業を並行して進めます。
並行して進める作業の内、多少の遅れであれば全体のスケジュールの遅延に繋がらない作業と、少しでも遅れれば全体のスケジュールの遅延に繋がる作業が存在します。
クリティカルパスとは、後者の作業のことを指します。
 
例えば、「言い訳機能」と「反省機能」で成り立つ遅刻対応システムを以下の条件下で開発しているとします。

  • 製造・単体テスト工程は5日間の予定
  • 言い訳機能の製造・単体テストに5人日を要する予定
    (1人の人が5日間作業すれば終わる作業量、の意)
  • 反省機能の製造・単体テストに3人日を要する予定
  • 言い訳機能に1人を割り振る予定
    (→5日間かかる)
  • 反省機能に1人を割り振る予定
    (→3日間かかる)


この場合、反省機能であれば2日間遅れても製造・単体テスト工程の遅延には繋がりません。
しかし、言い訳機能は少しでも遅れれば製造・単体テスト工程全体の遅延に繋がります。つまりクリティカルパスです。
 
クリティカルパス上の作業については原則として遅延が許されないため、人を増やす(言い訳機能に2人を割り振れば計算上は2.5日間で終わる)、計画時にあらかじめバッファを持たせる(製造・単体テスト工程を7日間で計画すれば、2日間の余裕を持たせられる)、クリティカルパス上に高スキルの人員を割り振る、等の方法でスケジュール遅延のリスクに対応します。
スケジュールをコントロールする上では、このようにクリティカルパスに注目し重点的に対策を取ることが重要になります。

情報処理技術者試験対策「クラウドコンピューティング」

目次

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM

-------------------------------
志向を変えて、システム戦略について書こうと思います。
今回はクラウドコンピューティングについて書きます。
クラウドコンピューティングは今流行りのサービス形態の一つであり、ここ2~3年で情報処理技術者試験でもSaaS・PaaS・IaaSの定義を知らないと解けない突っ込んだ問題が出題されるようになりました。
 
クラウドコンピューティングとは、サービス事業者が管理するシステムにインターネットを介して接続することで、目的のサービスを受けるというものです。
月額必要を支払うことで、自社でシステム資源を用意し管理する必要がなくなるというメリットがあります。
可用性等のシステム要件はサービス提供事業者毎に異なり、SLAにより合意します。
世界的に有名なサービスとしては、Amazon Web Services(AWS)、Google Cloud Platform(GCP)、Microsoft Azure等が挙げられます。
最近では、実務でもこれらのサービスの名前を耳にすることが多くなってきたかと思います。
 
クラウドコンピューティングのサービス形態は、大きく分けると以下の3つがあります。
(先頭の一文字が何の略かを覚えれば覚えやすいです)

  • SaaS(Software as a Service)
    サービス提供事業者はアプリケーション・ミドルウェア・OS・ハードウェアを提供・管理する。
    利用者はクラウド上のアプリケーションを使用する。
    利用者が管理するものはない。
    利用者はアプリケーションにおける設定可能範囲内でカスタマイズが可能。
  • PaaS(Platform as a Service)
    サービス提供事業者はミドルウェア・OS・ハードウェアを提供・管理する。
    利用者は、クラウド上で用意されたプログラミング言語・ライブラリ・サービス・ツールを使用し、アプリケーションを実装する。
    利用者はアプリケーションを管理する。
    利用者はミドルウェアにおける設定可能範囲内でカスタマイズが可能。
  • IaaS(Infrastructure as a Service)
    サービス提供事業者はOS・ハードウェア、若しくはハードウェアのみを提供・管理する。
    利用者は、クラウド上で用意されたインフラ資源を利用し、システムを構築する。
    利用者はアプリケーション・ミドルウェアを自前で用意・管理し、OSがサービス提供事業者から提供されない場合はOSも用意・管理する。
    利用者はアプリケーション・ミドルウェア・OSに関するコントロール権を持ち、場合によりネットワーク設定も認められた範囲で変更できる。

 
なお、クラウドコンピューティングは、仮想化技術によって支えられています。
仮想化技術とは、1台の物理サーバを複数台の仮想的なサーバに分割し、それぞれに別のOSやアプリケーションソフトを動作させる技術のことです。
1台の物理サーバで複数の仮想サーバをコントロールできるため管理が容易になりますが、1台のサーバに処理が集中し競合も起きるため、サーバの利用率やCPUのオーバヘッドは上昇します。
仮想化を実現する製品は、VMWareデファクトスタンダードとなっています。
仮想化技術も時折出題されるキーワードですし、実務でも関わる可能性が高まっているので、ついでに覚えておくと良いでしょう。

情報処理技術者試験対策「アジャイル開発」

目次

https://1drv.ms/b/s!AivF3bzWXOzuhG1Xk5hscKYqkLkM

-------------------------------
プロセスモデルの一つとして、「アジャイル開発」というものがあります。
ウォーターフォールモデルと比較すると新しいモデルであり、最近になって情報処理技術者試験でも出題されるようになりました。
 
アジャイル開発はその名の通り迅速に開発を行うもので、短い期間(数週間~1ヶ月程度)毎にユーザにとって重要な機能から順番にリリースを行います。
一つの期間はイテレーションと呼ばれ、計画・設計・実装・テストがこの期間の間に行われます。
このように開発を行うことで、ユーザは少ない期間・コストで重要な機能を使用することができるようになります。ユーザの要求の変更にもいち早く対応することができます。また、システムを実際に使うと新たな要望が浮かぶものなのですが、システムを早い段階で手に取ることができるので新たな要望を早く出すことができます。仮に、せっかくリリースした機能がユーザに響くものでなかったとしても、その問題に少ない期間・コストで気付き、軌道修正することができます。
これらの利点により、重厚長大ウォーターフォールモデルを採用した場合に比べて、ビジネス上で優位に立つことができるようになります。
(特にスタートアップ企業にとってはこれらの利点が重要)
 
しかし、アジャイル開発はユーザの要望が頻繁に変わる小規模システムの開発には向くものの、要望が固定されているミッションクリティカルな大規模システムの開発には向かないとされています。
アジャイル開発ではシステムを小出しで開発するので、システム全体の整合性や最終製品の品質を上手く管理しないと、システムの品質が低下する問題やシステムのスケーラビリティが損なわれる問題が発生してしまいます。
そのため、教科書的には、要望が固定されているミッションクリティカルな大規模システムの開発はウォーターフォールモデルの方が向いているとされています。
 
ところで、迅速に開発しろと言われても、そのための手法がなければただのカオスとなってしまいます。
アジャイル開発を実現するための手法、またアジャイル開発と親和性の高い考え方としては、以下のようなものがあります。
(試験で出そうな順に並べています。スクラム以降はまだ試験では出ていません(多分)。)

  • アジャイルソフトウェア開発宣言
    http://agilemanifesto.org/iso/ja/manifesto.html
  • エクストリームプログラミング(XP)
    迅速にプログラミングを行うための手法。リファクタリング(保守性を高めるためのコード見直し)、ペアプログラミング(一人がコーディング、もう一人がリアルタイムにコーディングを見ることで、即座にレビュー・知識共有を行う)、テスト駆動開発(テストケース・テストコードを先に設定してからプログラミングを行う)により実現する。
  • プロトタイピング
    ユーザからのフィードバックを早期に得るために試作品を作成して提供する。試作品はコーディングして作成するとは限らず、紙芝居のような形でコンセプトを伝えるペーパープロトタイピングと呼ばれる手法もある。
  • スクラム
    チーム一体となってプロジェクトを遂行して行くことに重点を置くプロセスモデル。デイリースクラム(始業時に今日の予定と問題点を共有する)、プロダクトバックログ(システムの要求一覧)、スプリントバックログイテレーション内で対応する要求一覧)、イテレーション、スプリントレビュー(イテレーション内で開発した機能のユーザとのレビュー)、ふりかえり(イテレーション終了時の改善点の共有)により実現する。
  • バーンダウンチャート
    縦軸に「作業量」、横軸に「時間」を割り当て、残りの作業量を折れ線グラフにより記述したチャート。ガントチャート等と比べて、プロジェクトの進捗状況をいち早く把握することができる。紙媒体で誰もが見える場所に張り出すと効果が高い。
  • リーン生産方式
    トヨタ生産方式を元に編み出された方式。開発工程におけるムダを排除することを目的として、製品および開発工程の全体にわたって、トータルコストを系統的に減らそうとするのが狙い。「ムダをなくせ(顧客に価値を与えない作業を無くす)」「学習を強化せよ(反復型開発)」「決断を遅らせよ(状況の変化に合わせた決断)」「できる限り早く出荷せよ(機会損失防止)」「チームに権限を(チームの手で最良のプロセスを採用)」「摺り合わせて作り込め(ユーザとのトライ&エラーの繰り返し)」「全体を見よ(全体最適化)」という7つの原則によって成り立っている。
  • チケット駆動開発
    スプリントバックログを約2~3時間のタスクである「チケット」に分割し、チケットを管理することで、メンバーの作業把握と成果物の更新理由の把握を容易にする。
  • ストーリーポイント
    案件の規模や複雑性を「ストーリーポイント」と呼ばれる直感的・相対的な基準で測ることにより、俯瞰的な視点で直感的に迅速に見積もりを行う。

日本ではアジャイル開発はあまり普及しておらず、アジャイル開発を採用しているプロジェクトには巡り合えないかもしれませんが、それでも顧客の要望に沿ったシステム開発を行う必要があることには変わりないので、アジャイル開発の手法や考え方は部分的にでも取り入れる必要があるかと思います。
 
なお、情報処理技術者試験では、「スパイラルモデル(要求分析から実装までの開発プロセスを繰り返し、システムを構築するプロセスモデル)」、「ラウンドトリップ(オブジェクト志向開発において、設計とプログラミングを何度か行き来し、トライ&エラーで改良する手法)」についても出題されたことがあります。
アジャイル開発に通じる所もあるので、ついでに覚えると良いでしょう。

-------------------------------
 
2019/02/12 追記
 
偶然、IPAが発行している初心者向けガイドを見つけました。
200ページ超で、内容も書籍と同じくらい濃いです。
これが無料で読めるのは凄いことなので、興味がある方は是非。
 
アジャイル型開発におけるプラクティス活用事例調査 調査報告書 ~ガイド編~

https://www.ipa.go.jp/files/000026849.pdf