第134話 経営情報システム25 開発プロセス
正直言うとこの「情報」という科目が一番自信がありませんね。SEさんがみんなナイスな点数をゲットするもんだから、「SEさんも苦戦するような問題を」ということで試験委員が張り切っているわけです（著者の妄想）。
それでも平均点があまりにもヒドいと得点調整が行われるので平均点を50点くらいに設定するのでしょうか。
二次試験にはあまり関係のない科目ですので60点ギリギリでいい、といいながらも生来の天邪鬼ぶりが発揮されるので、人が60点しか取れないのだったら自分は65点を、とか思ってしまうわけです。それがいけないのだけれど。
１．アジャイル開発プロセス
“アジャイル”とは、俊敏なとか素早いとかいった意味があり、アジャイル開発プロセスとは、軽量で素早い開発を目指そうということになる。アジャイル開発プロセスとは、ソフトウェアを迅速に、また、状況の変化に対して柔軟に対応できるよう開発する手法の総称。短いプロセスを何度も反復して次第に全体を組み立てていくアプローチの手法が多い。
アジャイル開発プロセスでは、４つの価値を重視する。
①プロセスやツールより人と人同士の相互作用を重視する
②包括的なドキュメントよりも動作するソフトウエアを重視する
③契約上の交渉よりも顧客との協調を重視する
④計画に従うよりも変化に対応することを重視する
従来から主流であるウォーターフォール型などの開発プロセスでは、要件定義、設計、実装、テストなどの各工程を順番に一度だけ行なうことを前提にしているが、アジャイル開発プロセスでは一度ですべてを作ろうとせずに、当初は最低限の機能だけを持ったソフトウェアの完成を目指し、各工程を迅速に進める。
とりあえず動作するソフトウェアを元に、開発チーム内あるいは顧客とチームが密接に議論を交わし、変更する箇所や追加する機能を決め、もう一度各工程を反復する。このサイクルを短い間隔で何度も繰り返すことにより徐々にソフトウェアの完成度を高めていく。
アジャイル開発プロセスはどのような開発プロジェクトにも適しているわけではなく、一ヵ所に集まった10人程度までの少人数の開発チームが、ネット関連など変化の速い分野や、最初からはっきりとした要件を定義するのが難しい分野のソフトウェアを開発する際に最も適しているとされる。
２．XP(eXtreme Programming)
XPは、単純さ、コミュニケーション、フィードバック、勇気と４つの価値を置くソフトウエア開発手法である。エクストリームプログラミングは従来の「重厚な」開発方法論と比較して、思想面も実践方法も開発現場の問題意識に根ざしたものになっており、プログラマの広い支持を受けている。開発の初期段階の設計よりもコーディングとテストを重視しており、また、各工程を順序立てて順番に積み上げていくことよりも、常にフィードバックを行って修正・再設計していくことを重視している。
●XP → コーディングとテストを重視
１）５つの基本原則
XPは、４つの価値を５つの基本原則として具体化している。
①素早いフィードバック ②単純さの採用 ③インクリメンタルな変更 ④変化を取り込む ⑤質の高い作業
２）適用可能性
XPでの適用可能なプロジェクトは、次の特性を有しているのが望ましいとされる。
①プロジェクトの規模が比較的小さい（初期段階で10人以下）
②顧客の要求が最初にあまり明確でなく、PJ期間中に変更される可能性が高い
③明確な顧客が存在し、プロジェクトに積極的に関与することが出来る
３）12のプラクティス
XPでは、12あるいはそれ以上の実践項目、プラクティスを定義している。余計な複雑さを排除する「シンプルデザイン」（simple design）、動作を変えることなくプログラムを書き直す「リファクタリング」（refactoring）、1台の開発マシンを2人で共有して常に共同でコードを書く「ペアプログラミング」、小規模な改良を頻繁に行う「スモールリリース」（small releases）、週40時間以上働かない「40時間労働」（40-hour work）、顧客を常に開発チームに参加させる「オンサイト顧客」、「コーディング標準」などである。顧客の立場で、ということなのでしょう。
次です。
次は開発管理（PJ管理）の話題です。
ここでは、開発管理に関して、PJ管理手法のデファクトスタンダードである「PMBOK」や、PJ計画、ソフトウエア開発見積もり技法、PJ組織のプロセス習熟度評価について概観します。
１．PMBOK（Project Management Body of Knowlegde）
PMBOKは、「ピンボック」とよむ。PMBOKは、プロジェクトマネジメントの遂行に必要な基本的な知識を汎用的な形で体系立てて整理したものである。PMBOKでは、プロジェクトを遂行する際に、スコープ（プロジェクトの目的と範囲）、時間、コスト、品質、人的資源、コミュニケーション、リスク、調達、統合管理の9つの観点（「知識エリア」と呼ばれている）でマネジメントを行う必要があるとしている。適用分野（業界）を超えた標準知識体系を定めることによって、プロジェクトマネジメントの共通概念・用語を設定している。
また、PMBOKは規則ではなく標準となるガイドラインであり、個々のPJに適用する場合には、各プロセスや技法などを特定のPJに適した形に変更するテーラリングを行う必要があるとされている。
●PMBOK → PJ管理の標準
２．BABOK（A Guide to the Business Analysis Body of Knowledge）
非営利団体のIIBAにより策定されたビジネス分析のための知識体系。PMBOKと似ているがあまり関係ない。
３．PJ計画
開発規模は、開発プログラムのスタッフ数とか開発工数（人月）、開発期間などで表現される。
１）作業計画立案技法
PJの目標達成に必要な作業項目を、トップダウン的に階層構造で表現したものを、WBS(Work Breakdown Structure：作業分割図)という。WBSを網羅的に作成することで、PJ管理が容易になる。
２）日程計画立案技法
縦軸に作業項目、横軸に日付（時間）をとり、作業別に作業（タスク）内容とその実施機関を棒状に図示したものをガントチャートという。ガントチャートは、作業の相互関係を把握することは難しく、ある作業の遅れが作業全体にどのような影響を与えるのかを把握するのには向かない。
４．ソフトウエア開発見積り技法
ソフトウエア開発環境を左右する大きな要素として、ソフトウエア開発規模と開発費用がある。なお、予算の見積りリスクは開発過程の後段階ほど小さくなる。ここでは、ソフトウエアの開発見積りの代表的な技法を確認する。
１）COCOMO
COCOMOでは、開発するプログラムの想定ソースコード行数を元に、プログラマの習熟度や再利用できるソフトウェアの量などの様々な要因から開発規模を見積もり、これに十数個の補正係数（コストドライバと呼ばれる）を掛け合わせて工数を見積もり、最後に工数から開発期間を見積もる。
２）ファンクションポイント法
ソフトウエアが持つ機能（ファンクション）に基づいて、システムの開発規模を見積もる方法。FP法が開発される前は、ソフトウェアのソースコードの行数（SLOC; Source Lines of Code）やファイルサイズなどがソフトウェアの規模の尺度として用いられてきたが、FP法の登場で以前より客観的・定量的にソフトウェアの規模を算出することができるようになった。
「機能が多いソフトウエアほど、開発工数が多くなる」という特徴があるため、ユーザの理解が得られやすい。
５．EVMS（Earned Value Management System）
EVMSとは、プロジェクトマネジメントにおいて進捗状況の把握・管理を行う手法の一つ。作業の到達度を金銭などの価値に換算したEV（Earned Value：出来高）という概念で把握する。EVMともいう。
EVMSでは、まずWBSなどを用いてプロジェクト全体を細かい工程に分割し、各工程にかかる予算コストを見積もって、これをスケジュールに沿って積算した計画値（PV：Planned Value）を用意する。プロジェクト開始後、ある時点までに完了した工程の予算コストの合計が出来高（EV：Earned Value）で、これとその時点のPVとの差が計画と実際のスケジュールの差異を表す。また、その時点までに投入した実コストの積算値（AC：Actual Cost）も算出し、これとPVとの差が計画と実際のコストの差異を表す。
EVMSでは現在のコスト・スケジュール両面の進捗状況を統一的な尺度で把握することができ、また、ある時点での計画とのズレの大きさから、完成までの総時間・総コストを予測することもできる。
６．CMM
CMMとは、ソフトウェアの開発能力を客観的に示す品質管理基準のこと。米カーネギーメロン大学ソフトウェアエンジニアリング研究所が研究している。
主にスケジューリングやマネジメントの能力を評価するモデルで、マネジメントが成立していないレベル（レベル1）からプロジェクトの最適化を図れるレベル（レベル5）まで、5段階に分かれている。レベルの認定は同研究所が行っている。
CMMはモデルとしての標準的な取り組みのテーマや注意点が書かれているだけなので、実際にどのように運用するかは、その組織において考えるか、適切なコンサルティングを受ける必要がある。
７．CMMI
CMMIとは、米カーネギーメロン大学ソフトウェア工学研究所が公表したソフトウェア開発プロセスの改善モデルとアセスメント手法であるCMM（Capability Maturity Model）に、有識者の意見や多くのプロセス改善事例を反映させて作成された新しい能力成熟度モデルのこと。
CMMIではハードウェア、サービス業務、コミュニケーション、リーダーシップなどの人的側面も評価され、実務レベルの指標として利用可能となっている。両者をあわせてCMM/CMMIとも呼ばれる。組織や企業のソフトウェアプロセスの成熟度を示すことができ、組織におけるソフトウェア開発などの能力を向上させたり、能力を客観的に判断するための指標として利用されている。
成熟度はレベル1～5で表され、各レベルで持つべきプロセスを規定されている。レベル1は、ソフトウェア開発においてルールや開発標準などがまったく統制されていない状態。レベル2は、同種のソフトウェア開発を、組織の一部のチームなどが一定の水準で繰り返す方針や手順が確立されている状態。レベル3は、組織全体でソフトウエアの開発・保守の方針、ガイドライン、手順が確立されていて安定的に一定水準の品質のソフトウェアが開発できる状態。レベル4は、さらにそれらを定量化して計測・評価できる状態。レベル5は、組織が自発的に開発行為などの改善を行える段階を指す。実際には、多くのソフトウェア開発組織がレベル1または2の段階にあるといわれ、レベル3以上の組織は少ない。
長くなったけれど、今日はここまで。
続く。
