技術とか戦略とか

証券レガシーシステムを8年間いじった普通のSEによるブログ。技術のみではなく趣味の戦略考察についても。

アーンドバリューマネジメント

目次

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時間のタスクである「チケット」に分割し、チケットを管理することで、メンバーの作業把握と成果物の更新理由の把握を容易にする。
  • ストーリーポイント
    案件の規模や複雑性を「ストーリーポイント」と呼ばれる直感的・相対的な基準で測ることにより、俯瞰的な視点で直感的に迅速に見積もりを行う。

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

ウォーターフォールモデルとV字モデル

目次

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

-------------------------------
次はソフトウェア開発のプロセスモデルについて書きます。
様々なプロセスが存在しますが、今回は最もメジャーなウォーターフォールモデルについて書きます。
日本でシステム開発をする場合、大部分のプロジェクトでウォーターフォールモデルが採用されており、試験だけでなく実務でも超メジャーな分野です。
 
ウォーターフォールモデルでは、実際にプログラムを作るまでは「要件定義(基本計画)」→「外部設計(基本設計)」→「内部設計・プログラム設計(詳細設計)」→「プログラミング(製造)」といった工程を踏みます。
ユーザの要求からスタートし、段階的に詳細化しシステム化の方針を決めるといった形で、トップダウンで開発を行います。
プログラムを作り終えてからは、「単体テスト(UT)」→「結合テスト(IT)」→「システムテスト(総合テスト、ST)」→「運用テスト(UAT)」といった工程を踏みます。
バグ頻発でテスト進行が妨げられることを防ぐために、細かい箇所からテストを行い徐々に統合するという形で、ボトムアップで開発を行います。
 
開発工程とテスト工程は、以下のように連関しています。
プログラミングの内容は単体テスト、内部設計・プログラム設計の内容は結合テスト、外部設計の内容はシステムテスト、要件定義の内容は運用テストで検証します。
これをV字モデルと呼びます。

 f:id:akira2kun:20180708001904j:plain

誤りを修正する場合、後の工程になるほど手戻り工数が増え、修正コストが増大します。
(最悪なのは、リリース後に誤りが発見され、修正の必要が生じた場合です)
教科書的には、レビューを強化する等し、ある工程で埋め込んだ誤りはその工程の中でできる限り解消することが重要になります。
仮に後の工程で誤りが発見された場合は、その誤りについてなるべく早い段階で例外的に前工程に戻り、その誤りの修正に関わる要件・設計・実装を見直すことが重要になります。
大規模かつミッションクリティカルなシステム開発では特にこの原則を守ることが重要となります。
以下は東証のシステム更改の例で、前工程への手戻りを正式にプロセスに組み込むことで手戻り工数を削減する「フィードバック型V字モデル」が採用されました。

http://ac.nikkeibp.co.jp/cn/xdev10/pdf/10907-xdev-A-1.pdf

  
なお、実務では、実現性が疑わしい箇所について開発開始前にプロトタイプを作成し、実現性をあらかじめ検証するという手法も使われます。
プロトタイプを作ることで、開発開始時に実現性の問題が出て手戻りが発生することを防ぐことができます。
 
ざっくりまとめると、先が見える場合は1つ1つの作業を確実にこなす、先が見えない場合は先回りして視界を良好にする、という姿勢がプロジェクトを進行する上で重要になります。

モジュール強度とモジュール結合度

目次

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

-------------------------------
テストについては一通り書いたので、今度は製造・単体テスト工程以前の工程に戻ります。

今回は、内部設計について、試験頻出のモジュール強度・モジュール結合度について書きます。
 
モジュール強度・モジュール結合度は構造化分析の結果が妥当であるかを判断するための指標です。
(主に手続き型言語で開発する場合に構造化分析を使用します。構造化分析については参考書以上のことが書けないのでここでは取り扱いません。)
ここで言う「妥当」とは、「モジュールを修正した際に、他のモジュールに影響を与えず、影響範囲を限定できる」という意味です。
修正による影響範囲を限定することは、結合テストシステムテストの手戻り工数を削減したり、リリース後の保守工数を削減したりする上で重要になります。
影響範囲を限定することができないと、修正にかかる工数が跳ね上がり、最悪の場合リリースできなくなったりリリース後の保守をしきれずにサービス撤退することにもなりかねません。
 
モジュール強度・モジュール結合度の話は以下のようなものです。
参考書では文書だけで説明されているケースが多いと思うのですがイメージがわかないと思うので、例(イメージ図)を付記しています。

f:id:akira2kun:20180707143901j:plain

  • モジュール強度が弱いと困る例
    遅延証明書のフォーマットが変更され、気の利いた一言欄が追加になった。「言い訳機能」「勤怠入力機能」に気の利いた一言欄を用いた処理を追加する。連絡的強度よりモジュール強度が弱いと、「言い訳機能」「勤怠入力機能」の変更が同一モジュール内の別の機能に影響を及ぼす可能性があり、影響調査や修正の工数が増大する。

f:id:akira2kun:20180707144005j:plain

  • モジュール結合度が強いと困る例
    遅刻して言い訳したことで上司に怒られ、叱られフラグが立ち、叱られ文字列が更新された。これを受けて反省モジュール(反省機能)により反省するのが正しい挙動だが、制御結合より結合度が強いと叱られ文字列更新により他の機能が影響を受ける可能性があり、影響調査や修正の工数が増大する。

なお、影響範囲を限定するという視点はシステム開発を担う者として欠かすことができない視点であると共に今なお追い求められているテーマの一つで、データ中心アプローチや、今流行りのオブジェクト志向言語のフレームワークデザインパターンというのも、影響範囲を限定する考え方を突き詰めたものです。

システムテスト等について

目次

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

-------------------------------
テストについては一通り書こうと思います。
今回は、システムテストについてです。
あまり面白いことは書けませんが…。
 
システムテスト結合テストの後に開発部隊が行うテストであり、システムが要件を満たしていることを確認するためのテストです。
以下の2つの要件を満たしていることを確認します。
(なお、バグの原因切り分けを容易にするため、モジュール単独で検証できることは前工程で行う必要があります。例えば、性能テストに関して、SQL単独の性能計測は単体テストの範囲です。)

  • 機能要件
    システムが提供する機能に関する要件。
    ユーザインターフェースやその裏側の業務処理等。
    実運用を想定し、シナリオテストや実時刻テストを行うことにより検証する。
     
  • 非機能要件
    機能要件を実現するための土台として必要になる要件。
    性能テスト、負荷テスト、セキュリティテスト等により検証する。

また、本番環境でのテストもシステムテストで行う必要があります。
テスト環境と本番環境で環境差異(関連モジュールやライブラリのバージョン差異、ネットワーク構成の差異等)がある可能性があり、それがシステムの機能に影響を及ぼす可能性があるためです。
サービス提供時間にテストを行うことはできないため、サービス提供時間外にテストを行うことになります。
場合によっては、テストのために例外的にサービス停止することも検討します。
 
ついでに説明しますが、ユーザ部門による運用テストも同フェーズで実施します。
運用テストでは、開発されたシステムで実運用できるかを検証します。
また、保守開発(本番サービス中のシステムに対する改修)の場合は、リグレッションテスト(退行テスト)も実施します。
リグレッションテストは改修した箇所が他の箇所(現行サービスで問題なく提供できている機能)に影響を及ぼしていないかを確認するためのテストで、同一のインプットで同一のアウトプットが出ることを確認します(現新比較)。