ITパスポート単語帳 - ソフトウェア開発管理技術

一般的には「順接、反復、分岐の三つの制御構造のみを組み合わせて処理の流れを記述すること」と説明されることが多いが、これは本来の定義とは異なる誤解が広まったものだとも指摘される(後段で詳述)。

今日一般的に言われる構造化手法とは、プログラム中のコードの実行順の制御を、記述した順番に実行する「順接」あるいは「順次」(sequence)、指定された条件が成り立つ間繰り返す「反復」あるいは「繰り返し」(iteration)、指定された条件を満たすか否かによって枝分かれする「分岐」あるいは「選択」(selection)の三つのみを組み合わせて記述することとされる。

特に、実行順の制御をこの三つに限定することにより、かつてのプログラミングで多用されていた、指定した任意の位置に無条件に移動する “goto” 文を排除し、処理の流れがあちこちへ飛んで見通しが悪くなるのを防ぐことが重要であると説明される。

構造化定理とその解釈

この原則は1966年にイタリアのコンピュータ科学者コラド・ベーム(Corrado Böhm)とジュゼッペ・ヤコピーニ(Giuseppe Jacopini)が証明した「構造化定理」(Structure theorem)あるいは「構造化プログラム定理」(Structured program theorem)によって基礎付けられているとされる。

確かにこの定理はすべてのアルゴリズムが順接、反復、分岐の三つの組み合わせで記述できることを示してはいるが、計算科学における理論上の可能性を述べており、これによって見通しの良いプログラムを開発できるといった趣旨の主張は含まれていない。

実際、高名なコンピュータ科学者のドナルド・クヌース(Donald Knuth)は、プログラムからgoto文を除去してこの三つの組み合わせに置き換えることにより却って構造が失われる例を示し、構造化定理のこのような解釈を批判している。

ダイクストラの構造化プログラミング

「構造化手法」(structured programming)の語が最初に提唱されたのは1969年にオランダのコンピュータ科学者エドガー・ダイクストラ(Edsger W. Dijkstra)が発表した論文で、本来はこちらが構造化手法の定義であるとされる。

彼の主要な問題意識は、プログラムの規模が大きくなっても正しさを容易に検証できるような「良く構造化されたプログラム」(well-structured program)を記述する方法論で、そのためのいくつかの考察と原則を構造化手法という概念でまとめた。

これには、現代では関数やサブルーチンなどとして知られる、プログラムの「段階的な抽象化」(step-wise abstraction)、現代のオブジェクト指向プログラミングに近い、「抽象的なデータ構造」(abstract data structures)とこれに関連付けられた「抽象的な構文」(abstract statements)の「共同詳細化」(joint refinement)が含まれる。

これらを適用したプログラムは上下に階層化された交換可能なモジュール(部品)を連結したような構造になると指摘し、これを真珠のネックレスの構造に例えて説明している。この論考には「構造化定理」も「三つの制御構文」も「goto文」も登場せず、構造化手法の本来の概念とこれらとはあまり関係がない。

しかし、ダイクストラが別の機会に発表したgoto文の濫用に疑問を呈する論説(1968年の “Go To Statement Considered Harmful” )や、他の論者とのいわゆる「goto文論争」、また、「構造化定理」と「構造化手法」の名称の類似性などを通じて、次第に「三つの制御構文」式の理解が広まっていったと考えられている。

システム全体を、現実世界の物理的なモノ(object)に見立てた「オブジェクト」と呼ばれる小さな構成単位の組み合わせとして捉える。システムの振る舞いはオブジェクト間の相互作用(機能の呼び出し/処理依頼)として記述される。

オブジェクトにはそれぞれ固有のデータ(属性/プロパティ/メンバ変数)と手続き(メソッド/メンバ関数)があり、外部からのメッセージを受けてメソッドを実行し、保有するデータを操作する。オブジェクトに付随するデータの操作は原則としてすべて内部のメソッドによって行われる。

この点をよく「生徒オブジェクトが数学、国語、英語の点数プロパティと平均点算出メソッドを持つ」といった例で説明するが、コンピュータプログラムではソフトウェアやデータに関連する概念や対象も取り扱うため、プログラム中のオブジェクトが必ずしも現実の物理的実体に対応するとは限らない。

オブジェクト指向はデータと操作手順を一体化(カプセル化)し、外部には処理の依頼方法(インターフェース)のみが公開されるため、ある箇所の変更が外部に与える影響を小さくすることができる。チームでのソフトウェア開発で分担などが行いやすく、大規模開発に向いていると言われる。適切に設計されたコードは他のプログラムで再利用しやすいため、似たような機能を重複して開発することを避け、開発の効率化を促すとされる。

オブジェクト指向の考え方をプログラミングに応用した手法を「オブジェクト指向プログラミング」(OOP：Object-Oriented Programming)と呼び、単にオブジェクト指向といった場合はこれを指すことが多い。オブジェクト指向開発のための仕様が盛り込まれたプログラミング言語を「オブジェクト指向言語」(OOL：Object-Oriented Language)という。

オブジェクト指向の概念自体はシステムやプログラムの設計や分析にも用いられ、「オブジェクト指向モデリング」(OOM：Object-Oriented Modeling)、「オブジェクト指向分析」(OOA：Object-Oriented Analysis)、「オブジェクト指向設計」(OOD：Object-Oriented Design)などの技法が存在する。

まず業務で扱うデータ全体をERモデル(Entity-Relationship model)など何らかの手法でモデル化し、データベースやデータファイルの設計や構造などとして明確化する。プログラムはこのデータ群を業務手順に従って入出力、加工、保存する道具として設計・実装される。

企業などが永続的に保存・管理するデータの種類や意味、形式などは比較的安定しており、これをシステム構造の基礎におくことで、業務内容や手順に変更があってもデータベース部分はそのままでプログラムのみを修正・置するといった更新が行いやすくなる。

また、データ中心アプローチでは具体的な処理内容やプログラムの実装とは切り離してデータを定義・蓄積するため、様々なシステムや部門(野心的なプロジェクトでは全社・全システム)で共有される情報資産としてのデータ基盤を構築することができる。一度データ基盤を整えれば、システムやプログラムの追加や修正も局所的な変更で対応できるようになる。

データ中心アプローチやそれに類似する考え方(DCE：データ中心工学、IE：インフォメーションエンジニアリングなど)は1970年代に広まったもので、それ以前は業務の流れや処理の手順などを中心にシステムを設計するPOA(Process Oriented Approach：プロセス中心アプローチ)が一般的だった。

これは業務の一部の手順を自動化する小規模なプログラムの開発には適していたが、システムの規模や対象の範囲が広がると、データの形式や扱い方が部署やシステムごとに異なり整合性がないことが開発や運用の効率悪化を招くようになり、データを中心に据えるデータ中心アプローチの考え方が脚光を浴びるようになった。

業務の手順や工程を図などに書き表して定義し、それに合わせてシステムの挙動を決定していく。現実の手順に基いてシステムの動作を考えるため分かりやすく、設計工程を低コストで手早く済ませることができる。

特定部門の特定の業務手順をシステムに反映させることが主眼であるため、部署を超えた利用やデータの伝送、再利用などはあまり考慮されず、システム間でデータの重複や不整合が起こったり、接続や連携ができず全体最適化の妨げとなることがある。また、業務手順が変更されるとわずかな違いでも大幅な改修が必要になったり、データの連続性が失われたりすることがある。

一方、業務の内容を表すデータの構造や流れに着目し、データモデルの策定を中心に設計を行う手法を「データ中心アプローチ」(DOA：Data Oriented Approach)という。業務へのコンピュータ導入の初期(1970年代頃まで)にはプロセス中心アプローチが一般的だったが、システムの規模や種類が増えデータ管理が重視されるようになるとDOAへの注目が集まった。

情報システムやソフトウェアの設計や振る舞いの分析などで用いられる概念の一つである。利用者などの主体(「アクター」と呼ばれる)がシステムを用いて何かの機能を利用したり目的を達成しようとする際に、特定の状態からスタートしてどのような操作や応答が行われる(べき)かを記述する。

ユースケースはシステムの機能や要素と一対一に対応するとは限らず、一つのユースケースが行われる間に複数の要素を横断的に用いることもある。アクターが異なればユースケースも異なることがあり、一人のアクターが複数のユースケースを必要としたり、逆に一つのユースケースが複数のアクターで共有される場合もある。

ユースケースシステムは開発の初期段階で要求を明確化するために検討・記述されるのが一般的で、利用者やビジネス分析の専門家の視点から、対象システムをブラックボックスとして扱い、システムによって何をどのように行うのかを明らかする。

情報システムの専門家が関与して作成することは問題ないが、利用者が内容を理解できる形で作成しなければ意味がないため、システム上の専門用語や専門的な概念は極力用いないことが望ましい。また、この段階では過度に詳細化したり詳しい実装に立ち入るべきではないとされる。

システムの設計に必要な情報を図示する技法を定義した「UML」(Unified Modeling Lanugage)では、ユースケースを記述するための図法として「ユースケース図」(use case diagram)を定義している。開発現場でもこれを用いて図示することが多いが、各項目やフローの内容を箇条書きした表などの形で表すこともある。

ソフトウェア開発では、プログラムを作成する前にシステムの設計や構造、振る舞いを定義し、発注者と開発者、あるいは開発チーム内で仕様について共通認識を得る必要がある。その際、説明が文章や箇条書きだけだと分かりにくく、多数の要素の複雑な相互作用などを簡潔に表現することが難しい。

UMLでは、システムをオブジェクトの組み合わせとしてモデル化し、その構造や仕様を図表によって記述するための表記法を定めている。システムの構成要素の定義や、要素間の関連性、要素の振る舞いなどを図示することができる。

図表の描き方が人や組織によってまちまちでは相互理解に支障を来すが、標準化されたUMLという共通の「言語」を用いることで、書き手の意図を正しく読み手に伝えることができる。システムの様々な側面を伝達できるよう、UMLには14種類の図が用意されている。

UMLの仕様は1996年に当時のラショナル・ソフトウェア(Rational Software)社(2003年に米IBM社が買収)が策定した。その後、仕様の策定・改訂は業界団体のOMG(Object Management Group)が行うようになった。UML1.4が2005年にISO/IEC 19501として、UML 2.4が2012年にISO/IEC 19505としてそれぞれ国際標準となっている。

図の種類

UMLで定義される図は大きく分けて、システムの構造を表す「構造図」(structure diagram)と、動作や変化を表す「振る舞い図」(behavior diagram)の2種類に分類される。

構造図には「クラス図」(class diagram)、「オブジェクト図」(object diagram)、「コンポーネント図」(component diagram)、「パッケージ図」(package diagram)、「配置図」(deployment diagram)、「複合構造図」(composite structure diagram)、「プロファイル図」(profile diagram)がある。

振る舞い図には「アクティビティ図」(activity diagram)、「ユースケース図」(use case diagram)、「ステートマシン図」(state machine diagram)、「相互作用図」(interaction diagram)がある。

相互作用図はさらに、「シーケンス図」(sequence diagram)、「コミュニケーション図」(communication diagram、以前はコンポーネント図と呼ばれていた)、「タイミング図」(timing diagram)、「相互作用概要図」(interaction overview diagram)に分かれる。

ソフトウェアの開発者と運用者はそれぞれ異なる目標を持ち、組織や所属も分断されていることが多く、しばしば考え方や利害が対立する。両者の壁を乗り越え、コミュニケーションや情報共有を改善し、開発と運用のサイクルを統合することでソフトウェアの迅速な開発・導入、頻繁な改善・更新を可能にする方法論をDevOpsと呼ぶ。“Development” (開発)と “Operations” (運用)を組み合わせた造語である。

DevOpsを構成する具体的な手法には様々なものが提唱されているが、代表的な手法としてはBTS(Bug Tracking System)やコラボレーションツールなどによる深い情報共有や密なコミュニケーション、継続的インテグレーション(CI：Continuous Integration)ツールなどによる導入・展開(デプロイ)の自動化、設定自動化ツールなどによる環境設定の自動化やコード化(IaC：Infrastructure as Code)などがある。

DevOpsの導入にはソフトウェアの頻繁な更新が必要となるため、ウォーターフォール型などの従来型の開発手法ではなく、いわゆるアジャイル方式の反復型の開発手法が採用される。アジャイル方式では最初から大規模なソフトウェアの完成は目指さず、シンプルな、あるいは小規模なソフトウェアをリリースしてこれを頻繁に改善、更新することで次第に完成度を高めたり状況の変化に対応させる。システムの稼働後も運用側からのフィードバックに迅速に対応できるようになる。

要件定義、外部設計、内部設計、開発(実装)、試験、本番稼働(納品)、運用といった各工程を時系列に沿って順に並べ、一つ前の工程が終わったらその成果物をもとに次の工程を始める、という単純なルールで進めていく方式である。滝(waterfall)を水が流れ落ち、逆戻りしないという意味合いでこのように呼ばれるようになった。

各工程は一度限り行われることが期待され、次の工程へ進む前に成果物の品質が厳しくチェックされる。それでも何らかの問題や状況変更が起き、前工程をやり直す必要が生じる場合もあり、これを「手戻り」という。

工程管理や見積もりのしやすさ、分かりやすさから、反復型(スパイラル型)の開発手法が数多く提唱されている現代でも、特に大規模開発で広く用いられている。よく指摘される問題点として、設計前に要件が、実装前に設計が完全に固まり、詳細かつ明確に定義され、後から変更されないという前提が現実離れしており、しばしば工程管理上の問題や依頼主とのトラブルの原因になっていると言われる。

従来よく知られるウォーターフォール型の開発モデルでは、設計、実装といった各工程は原則として一度限り行われ、前工程の成果物が完成していることを前提に次工程に取り掛かる。

一方、スパイラルモデルでは素早く開発プロセスを一周して機能や品質は完全ではないがとりあえず稼働するシステムの原型(プロトタイプ)を開発し、これを元に再び同じ開発プロセスを繰り返して追加や改良、品質の向上などを行う。

仕様の修正や再設計が行いやすく顧客の満足度は高めやすいが、プロセスを何周で終わらせるのか、どのような基準で完成とみなすのかなどについて十分な議論や合意がなければ工期や予算の目算が大きく狂う場合もある。

ITシステムやソフトウェアでは、利用者がどのような機能をどのように使いたいのか自身も明確には理解していない場合があり、最初に完全に仕様を確定してから開発に入ることが困難だったり、開発工程に入った後や完成後の修正、やり直しが頻発する場合がある。

プロトタイピングモデルでは、要求を分析する初期の段階で、最低限の機能や操作画面を実装した原型(プロトタイプ)を用意して、業務に適用することを想像しながら操作してもらい、利用者の具体的な要求を引き出していく。プロトタイプの作成と検証を繰り返すことにより、次第にシステムに必要とされる機能・仕様が具体化・明確化していく。

利用者が早期から実際のシステムの利用状態を想像することができるため、開発者と利用者の間に生じる製品の完成形についての理解の齟齬を小さくすることができる。製品の種類や規模によっては開発期間の短縮やコスト低減の効果も見られる。

一方、初期のプロトタイプの機能や見た目、操作法などを漸進的に改善していく形となるため、根本的に異なる形態の方が適していたとしてもそのことに気付かないまま開発が進んでしまうことがある。また、大規模で複雑な製品だとプロトタイプの制作や修正に大きな負担がかかるため適用しにくいと言われる。

RADツールには、プログラムコードの入力支援や自動生成などの機能、ソフトウェアの半製品や部品(モジュール)、雛形(テンプレート)などが用意され、ゼロからコードを記述していくよりも少ない手順で開発を進めることができるようになっている。

特に、アプリケーションの操作画面を編集する機能が用意されており、ウィンドウ上にボタンやテキストボックスといった操作要素を配置し、入力時の動作などを設定すれば、どのアプリケーションでも共通するような機能はコードを書かずに作り込むことができる。開発者はアプリケーション固有の処理のみをプログラムとして追加すればよい。

RADによる開発はグラフィック表示による操作画面(GUI：Graphical User Interface)を持つソフトウェアの開発を特に高速化することができ、開発期間の短縮や開発コストの削減が可能となる。一方で、出来合いのソフトウェア部品などを繋ぎ合わせる手法は実行速度の低下やプログラムサイズ(ファイルサイズ)の増大を招きやすいとも言われる。

企業などが他社製品のリバースエンジニアリングによって得られた情報は、類似製品や互換製品の開発、同等の機能の実現などのために利用されることが多いが、自社特許の侵害が無いか調査するといった目的で行われることもある。

ソフトウェアの場合には実行可能形式のプログラムから逆アセンブルや逆コンパイルなどを行って、(不完全な)ソースコードを取得して動作を解析することが多い。他の工業製品の場合と同じように互換製品などを開発するために行われるほか、コンピュータウイルスなどマルウェアの動作を詳細に調べ対策プログラムを開発したり、ソフトウェアの保安上の弱点(脆弱性)を探し出すなどセキュリティ上の目的で行われることも多い。

リバースエンジニアリングを行うこと自体は合法だが、抽出したコンピュータプログラムを丸ごと複製して自社製品に組み込むといった行為は著作権違反、企業秘密(営業秘密)として保護された製法や構造などを割り出して無許諾で模倣した場合は不正競争防止法違反などに問われることがある。

このような権利侵害を避けるため、リバースエンジニアリングを行うチームが外形的な仕様などを記述し、隔離された別のチームが書面を元に同じ働きをする実装方法を独自に考案するという手法が用いられることがある。これをクリーンルーム設計(クリーンルーム手法)という。ただし、この方式では特許権や意匠権の侵害を避けることはできない。

従来から主流であるウォーターフォール型などの開発プロセスでは、要件定義、設計、実装、テストなどの各工程を順番に一度だけ行なうことを前提にしているが、アジャイル開発では一度ですべてを作ろうとせずに、当初は最低限の機能だけを持ったソフトウェアの完成を目指し、各工程を迅速に進める。「アジャイル」(agile)には、俊敏な、しなやかな、素早い、などの意味がある。

とりあえず動作するソフトウェアを元に、開発チーム内あるいは顧客とチームが密接に議論を交わし、変更する箇所や追加する機能を決め、もう一度各工程を反復する。このサイクルを短い周期(多くの手法では数週間以下)で何度も繰り返すことにより徐々にソフトウェアの完成度を高めていく。

適用範囲

アジャイル開発はどのような開発プロジェクトにも適しているわけではなく、一ヵ所に集まった10人程度までの少人数の開発チームが、インターネット関連など変化の速い分野や、最初からはっきりとした要件を定義するのが難しい案件のソフトウェアを開発する際に最も適しているとされる。

一方、開発途上で要件がほとんど変化しないことが最初から分かっている場合や、大人数や大規模なプロジェクト、不具合が人命や財産に大きく関わるような社会的に重要なシステムなどの開発には適さないとされる。

代表的な開発手法

どのような条件を満たせばアジャイルであると言えるのかという厳密な定義や要件が決まっているわけではないが、2001年に著名な軽量開発手法の提唱者が集まって共同で策定した「アジャイルソフトウェア開発宣言」の主旨に適う手法が該当するとされる。

代表的な手法として、「エクストリームプログラミング」(XP：eXtreme Programming)や「Scrum」(スクラム)、「Crystal」(クリスタル)、「フィーチャ駆動型開発」(FDD：Feature Driven Development)、「適応的ソフトウェア開発」(ASD：Adaptive Software Development)、「リーンソフトウェア開発」(LSD：Lean Software Development)などがよく知られている。

製品を使って利用者が何をしたいのか、どうなることを望んでいるかを、技術的な概念や語彙を極力用いず、利用者が容易に理解できる平易な言葉で記述する。具体的にどういう仕組みや挙動、表示、操作によりそれを実現するかはこの段階では触れない。

一つの希望を一つの文で表現することが望ましく、たくさんのストーリーを箇条書きで列挙したものが利用者が製品に求めるものの総体となる。「私は ～ として ～ のために ～ したい」といった定型文(テンプレート)に当てはめて記述する手法がよく用いられる。

漠然とした大きな目標のようなものを表すストーリーのことは「エピック」(epic)と呼ばれ、より具体的で詳細なストーリーに分割していく。適切な大きさのストーリーの集まりを定義することができたら、各ストーリーを技術的にどのように実現するかを「タスク」(task)として定義し、開発作業に入る。

事前に仕様や設計を明確に定めてその通りにプログラムを記述することを重視とする従来手法と異なり、プログラミングを始めた後でも変更や修正、仕様の明確化などが行われることを前提として、小規模な設計、実装、テストを何度も繰り返して段階的に完成度を高めていく反復型開発を採用している。

エクストリームプログラミングは10人程度くらいまでの小規模な開発チームに適した手法とされ、開発スピードやビジネス環境の変化への素早い対応が求められるベンチャー企業の自社製品開発やオンラインサービス開発などで人気が高い。

最も重視する原理を「コミュニケーション」(communication)、「シンプルさ」(simplicity)、「フィードバック」(feedback)、「勇気」(courage)、「尊重」(respect)の「5つの価値」として定めている。その上で、開発者が行うべき具体的な実践や守るべき原則を4つの領域に分かれた12のプラクティス(practice)としてまとめている。オリジナルの12のプラクティス以外にも、一部を追加、変更した異なる数や内容の原則を提唱する人もいる。

「細かいフィードバック」(fine-scale feedback)領域では、常に2人1組でプログラミングする「ペアプログラミング」(pair programming)、ストーリーカードに基づいて作業計画を策定する「計画ゲーム」(planning game)、常にコードより先にテストを記述する「テスト駆動開発」(TDD：Test-Driven Development)、顧客と密接にコミュニケーションを取る「オンサイト顧客」(on-site customer)の4つが定められている。

「継続的なプロセス」(continuous process)領域では、コード全体のビルドとテストを頻繁に繰り返す「継続的インテグレーション」(continuous integration)、既存のコードも常に改善していく「リファクタリング」(refactoring)、不完全でも迅速に完成させ段階的に改良していく「小規模リリース」(small releases)が定められている。

「共通理解」(shared understanding)領域では、コードの記法などの標準を定めて皆が従う「コーディング規約」(coding standards)、すべてのコードは全員が等しく共有しているとする「コードの共同所有」(collective code ownership)、設計を簡素に保つ「シンプル設計」(simple design)、関係者全体でシステムの構造や振る舞いのイメージを事例や例えを通じて共有する「比喩」(system metaphor)が定められている。

「プログラマの厚生」(programmer's welfare)領域では、開発者の労働負荷を常に一定に保つ「持続可能なペース」(substaineable pace)が定められ、労働時間を週40時間までに制限すべきとされる。

「テストファースト」(test first)と呼ばれる原則に従って開発を進めていく手法で、まずプログラムの機能や仕様に基づいて、そのプログラムが通るべきテスト条件やテストコードを記述していく。実装すべきプログラムができていないため、この段階でテストを行うと必ず失敗する。

テストができたら、そのテストに合格する最低限のコードで構成されるプログラムを実装する。この段階では、本来の処理を行わず条件を満たす定数を記述したり、同じコードを何度も重複させるなど、どんな方法を使っても良いのでとにかくテストを通るプログラムを作る。最後に、テストに通ることを確認しながらコードの重複などを取り除き、明快で洗練されたコードに書き換えていく。この工程を「リファクタリング」(refactoring)という。

何度も繰り返し大量のテストを実施する必要があるため、よほど小規模でない限り手動でテストを行うのは現実的はなく、テストツールやフレームワークなど何らかのテスト自動化環境を用意してから開発に取り掛かるのが一般的である。

開発の途上でも常に仕様上満たすべきテストを通過させながら先に進めていくため、後の工程で誤りが発覚して開発のやり直し(手戻り)が起きることを防げる。その特性上、セキュリティソフトやGUI操作のソフト、並列処理を行うプログラム、開発ツールが自動生成するコードなどには適用しにくいとされる。

一人がキーボードでプログラムコードを打ち込み、もう一人は傍らでどのようなコードにすべきか一緒に検討したり、誤りを指摘したりする。前者を「ドライバー」、後者を「ナビゲーター」または「オブザーバー」と呼ぶ。

ドライバーとナビゲーターの役割は固定的なものではなく、一定の時間(例えば30分から1時間)の経過や、作業の区切り(例えば単体テストを実行するタイミング)ごとに入れ替えるのが良いとされる。また、ペアを組むメンバーの組み合わせは固定せずに、できれば毎日違う組み合わせでペアを組むのが良いとされる。

派生的な手法として、別の場所にいるメンバー同士がネットワークを通じてコードの編集画面を共有し、ビデオ通話や音声通話で会話しながらコーディングを進める「リモートペアプログラミング」がある。文字入力が相手方にリアルタイムに反映される共同作業用のコードエディタや画面共有ツールなどを用いて行われる。

利点

一台のコンピュータを囲んで二人で共同作業することによる単純な効用としては、もう一人が常に隣にいるためサボったり休んだりしにくい、外部からの問い合わせにナビゲーターが応答することでドライバーが作業に集中し続けられるといった点がある。

効率や品質に関わる効用として、一人では難しくて考え込んでしまう問題も、もう一人の助言や二人で議論することで乗り越えやすくなる。コードに誤りがあっても、もう一人が気付いてすぐに修正でき、コードの品質が高まる。二人が理解して納得したロジックを記述していくため、「独りよがり」な難解な記述を減らし、見通しや保守性の良いコードになることが期待される。

そして、組織として中長期的に得られる効用として、開発チーム内でペアを入れ替えながらプログラミングを進めることにより、チーム全体でコードへの理解が深まり、技能や知識の共有・移転が進む。メンバーの技能レベルの向上と均等化が進めば効率がより向上することが期待できる。

難点

ペアの組み方によっては効用が十分に得られない場合もある。例えば、極端に技能に差があるペアの場合には、熟練者は初心者から得るものが何もなく、単なるプログラミング指導のような時間になってしまうこともある。初心者同士が組んだ場合、それぞれ単独でプログラミングするより効率は高まる可能性はあるものの、お互い相手から何かを得ることはあまり期待できない。

また、IT技術者は他者と密にコミュニケーションを取って共同作業することを苦手とする人も多く、一人で深く思索する方が力を発揮するタイプの人もいる。組織の構成や勤務形態などによっては、ペアを組んで長時間同じ場所で同じ作業に従事させるスケジュールを組むのが難しい場合もある。

規模の大きなプログラムを長期間に渡って開発し続けていると、急な仕様変更や機能追加でその場しのぎの継ぎ接ぎが行われた箇所や、柔軟性や拡張性に乏しい設計や構造、無駄な重複、意図の読み取りにくい難解・煩雑な箇所が増えてくる。

そのような場合に、そのまま開発を続行するのではなく、一度立ち止まって既存のコードを見直し、開発者にとって理解のしやすい構造や設計に改める作業をリファクタリングという。機能の追加や不具合の改善などは行わず、内部構造の改善に徹し、あくまで外部から見た振る舞いは変えないのが原則である。

リファクタリングによって開発の進捗そのものは変わらないため、一見、工数が増えて工期が遅れるだけの無駄な作業のように感じられるが、内部がひどく混乱したプログラムの場合、そのままコードの追加・修正を続けるよりも、見通しを良くして作業を再開する方が開発効率や速度が向上し、新規コードの品質向上や新たなバグの抑制を期待できる。

リファクタリングによって挙動が変化したり品質が低下することがないよう入念にテストする必要があり、小刻みにテストを実施できる環境作りが重要となる。また、リファクタリングに失敗しても元の状態に戻すことができるよう、バージョン管理システムなどで変更履歴の把握や管理を適切に行う必要がある。

アジャイル開発プロセスの一つであるスクラム(Scrum)では、短期間(1週間～1ヶ月程度)で計画と実行を行う「スプリント」(sprint)という作業単位を繰り返し、徐々に開発物の完成度を高めるというアプローチを取る。

一回のスプリントの終盤、計画の実施が終わったら、開発物がどのように変化したかを確かめて発注者にデモンストレーションを行う「レビュー」(review)が行われる。その後、スプリントの締めくくりとして、開発チーム内で行われる振り返りの話し合いがレトロスペクティブである。

レトロスペクティブでは、プロジェクトに関して開発物「以外」の要素に関して検討を行う。すなわち、個人やチームの能力や関係性、プロセスやツールなどに関して、現状認識を共有し、課題や改善案などを出し合う。今回のスプリントについてうまく行ったことは何か、どんな問題があるか、次のスプリントで実施可能な改善策は何かなどを話し合い、チームの能力や開発効率の向上に繋げる。

分散バージョン管理システムなどを用いて開発している場合によく用いられる手法で、各開発者は定期的、あるいは頻繁に自らの担当するソースコードを中央サーバ(共有リポジトリなど)へ提出・統合する。

中央サーバ側では誰かが変更操作を行う度に(あるいは決まった時間間隔などで)プロジェクト全体のビルドや各モジュールの単体テスト、変更のあったモジュール間の結合テストなどを実施する。

結果は素早くアナウンスされ、また各担当者にフィードバックされる。何らかの不具合が生じた場合には各ビルドの直前に行われた変更や、変更箇所に関連するコードが原因として最も疑わしいため、問題点を早期に発見・修正できる。

手作業でこうしたプロセスを実施することは負担が大きいため、通常はCIツール(CI支援ツール)と呼ばれる自動化ソフトウェアを用いて実施する。近年ではそのようなソフトウェアの機能を提供するクラウドサービスも登場している。

ビルドやテストの後、自動的に利用者の環境へ提供可能な状態に準備する仕組みを「継続的デリバリー」(CD：Continuous Delivery)、実際にテスト環境やステージング環境、本番環境(運用環境)へ自動的に展開・更新する仕組みを「継続的デプロイ」(CD：Continuous Deployment)という。CIとこれらは併用することが多いため、「CI/CD」とまとめて表記されることが多い。

スクラムでは開発作業は「スプリント」(sprint)と呼ばれ、1週間から1ヶ月程度に期間を区切って作業を行い、最後に成果の確認(レビュー)と開発作業の振り返り(レトロスペクティブ)を行う。また、スプリント中は毎日必ず短時間(15分程度)のミーティングである「デイリースクラム」(daily scrum)を行い、進捗の確認や調整を行う。

事前に要件や設計などを固めず徐々に完成度を高めていく適応型、反復型の開発プロセスであり、スプリントを何度も繰り返しながら機能の追加や品質の向上、不具合の解消、時には方針の修正を進めていく。毎回のスプリントレビューには顧客が参加し、開発チームと共に現状の確認と今後の方針のすり合わせが行われる。

スクラムでは、取り組むべき作業や事柄を「バックログ」(backlog)と呼ばれるリストに優先度順に掲載し、これをチームのメンバーがこなしていく。バックログは開発している製品に必要となる項目を列挙した「プロダクトバックログ」と、スプリントで実施すべき項目を列挙した「スプリントバックログ」がある。

スクラムチームには一般的な意味でのリーダーや管理者は置かないが、顧客の意志を反映して製品の方向性を定める「プロダクトオーナー」、チーム内外の調整(ファシリテーション)や外部との窓口となる「スクラムマスター」が置かれる。すべてのメンバーが主体性を持って行動し、チームに責任を負うことが期待される。

スクラムはソフトウェアのアジャイル開発手法の一つで、開発チームが「スプリント」(spint)という短期間の工程を繰り返すことでプロダクトの完成度を徐々に高めていく反復型の手法である。

スクラムではプロダクトに最終的に必要とされる要素を列挙した「プロダクトバックログ」(product backlog)というリストを作成し、これに基づいて次のスプリントでどの要素を実現、実装するかを検討し、開発を進めていく。

プロダクトオーナーは顧客ニーズの聞き取りを行い、プロダクトのゴールを設定してメンバーと共有する。プロダクトバックログの作成と管理に責任を負い、スプリント間のミーティングでメンバーとバックログ項目の優先順位を話し合って決定する。次のスプリントで何に取り組むかをチーム内に周知する。

スクラムチームには一般的な意味でのリーダーや管理者は置かないことになっており、プロダクトオーナーはチームメンバーの上司ではないが、プロダクトの顧客(文字通り取引先の場合もあれば経営層などの場合もある)から見たチームの代表者であり、現在の開発状況の説明を行うこともある。

スクラムは反復型の開発手法で、一度に全体を開発しようとせず、小さな単位で計画と実装を繰り返し、少しずつ全体の完成度を高めていくというアプローチを取る。その際の反復の単位となるのがスプリントで、一般的には1週間から1ヶ月程度の期間で一回のスプリントを実施する。

スプリントは大きく分けて4つの工程で構成される。最初に「スプリントプランニング」を実施し、製品に最終的に必要とされる要素を列挙した「プロダクトバックログ」と前回のスプリントの結果を受けて、今回のスプリント中に実施すべき作業を「スプリントバックログ」として作成する。

開発作業に入ると、毎日同じ時間に同じ場所で15分程度のミーティング「デイリースクラム」を開催し、前回からの進捗、目下の課題、次回までにすることなどをチーム内で確認、共有する。立ったまま簡潔に報告し合う形が望ましいとされ、込み入った要件がある場合は別に会議を開催する。

終盤には「スプリントレビュー」が行われ、製品の目指す姿である「プロダクトゴール」に照らし合わせて、現状の製品がどの程度実現できているか評価する。今回のスプリントで追加できた項目に焦点を当て、チームメンバーだけでなく発注者などの関係者も交えて評価を行う。

最後に「スプリントレトロスペクティブ」を実施して一回のスプリントは終了となる。レトロスペクティブとは「振り返り」という意味で、製品「以外」の要素に関して検討を行う。すなわち、個人やチームの能力や関係性、プロセスやツールなどに関して、現状認識を共有し、課題や改善案などを出し合う。今回のスプリントについてうまく行ったことは何か、どんな問題があるか、次のスプリントで実施可能な改善策は何かなどを話し合い、チームの能力や開発効率の向上に繋げる。

スクラムは反復型の開発手法で、一度に全体を開発しようとせず、小さな単位で計画と実装を繰り返し、少しずつ全体の完成度を高めていくというアプローチを取る。一回の反復の単位は「スプリント」(sprint)と呼ばれ、概ね1週間から1か月程度の期間でスプリントを実施する。

スクラムでは開発チームが取り組むべき課題やタスクを「バックログ」(backlog)と呼ばれるリストで管理する。これは一種のでToDoリストであり、課題が優先順位を付けて列挙される。開発プロジェクト全体を通じて参照されるバックログがプロダクトバックログである。

プロダクトバックログには、製品に実装すべき機能(フィーチャー)、既存の開発物に見つかったバグの修正、技術的負債の解消、今後の開発で必要となる知識獲得や情報収集などの項目が組み込まれる。現在プロジェクトに必要とされる課題や作業はすべて含まれている必要があり、反復が進むに連れてバグ修正などが新たに追加されていく。

毎回のスプリントでは、プロダクトバックログの内容に基づいて、当該スプリントで取り組むべき作業や課題を「スプリントバックログ」として抽出する。スプリント期間中はこれをすべて消化することを目標にチームが作業を進めていく。スプリントが終わると、プロダクトバックログから完了した項目を取り除き、新たに生まれた項目があれば追加する。

開発期間中には、プロダクトオーナーと開発チームが揃って定期的に「リファインメント」というミーティングを実施し、プロダクトバックログの項目を再検討する。各項目について関係者全員が認識を揃え、内容の詳細化や明瞭化を行う。検討結果によっては項目の追加や削除、分割、優先順位の入れ替えなどが行われることがある。

情報システムやソフトウェアの開発や運用を委託する際、発注者と受注者の間で用語や作業工程、業務や役割の分担や範囲、契約上の権利・義務などを巡って理解や解釈の齟齬が生じないよう、各工程の内容について共通の枠組みを示している。

実際の作業手順を具体的に定めたものではなく、顧客側とベンダー側でそれぞれ持っている独自の開発方法、プロセスを共通フレームに対応させ、お互いの役割を把握し、共通認識として相互理解するためのものである。

発注者と受注者が共通フレームに基いて交渉や契約を進めることで、工程の把握や、費用や期間の見積もり、品質管理などにおける相互の認識のずれによるトラブルの発生防止、共同作業による作業効率の向上などが期待される。

共通フレーム94 (SLCP-JCF94)

最初の版は1994年3月に策定された「ソフトウェアを中心としたシステムの取引に関する共通フレーム」(共通フレーム94/SLCP-JCF94)で、ISO/IECで審議中だったSLCPに関する標準規格ISO/IEC 12207の内容を先取りする形で策定された。

共通フレーム98 (SLCP-JCF98)

1998年10月には「ソフトウェアを中心としたシステム開発および取引のための共通フレーム 1998年版」(SLCP-JCF98、共通フレーム98)が策定された。これは1995年に正式に標準となったISO/IEC 12207や、これを日本語化したJIS X 0160:1996をベースに改訂されたものである。

共通フレーム2007 (SLCP-JCF2007)

2007年10月には「共通フレーム2007」(SLCP-JCF2007)が発行された。これには2002年と2004年に発行されたISO/IEC 12207の改訂版の内容が反映されている。2009年9月にはその改訂版である「共通フレーム2007第2版」が発行された。

インターネット・Web関連など新しいソフトウェア技術への対応や、開発の前段階の企画プロセス(いわゆる「超上流」工程)の強化と要件定義プロセスの新設、経営層や業務部門の役割の明確化、プロジェクト進行途上での契約変更に関するプロセスの定義などが盛りこまれている。

共通フレーム2013 (SLCP-JCF2013)

2013年3月には「共通フレーム2013」(SLCP-JCF2013)が発行された。これは国際標準のISO/IEC 12207:2008(2008年改訂版)およびこれを国内規格化したJIS X 0160:2012(2012年改訂版)を元にしている。

品質管理や意思決定、リスク管理などいくつかのプロセスについての規定が追加されたほか、一部のプロセスの名称変更などが行われた。従来はソフトウェア開発のみが対象だったが、ハードウェアを含むシステム開発全体を取り扱うことが明示された。システム導入後の運用、サービス提供についても独立したプロセスとして重視されるようになった。

1995年8月に国際標準化機構(ISO)によって策定されたISO/IEC 12207はSLCPの標準的なモデルを示しており、SLCPを構成する各工程や、個々の作業内容、用語の意味などを定義している。同規格は2002年と2004年、2008年に改訂されている。

共通フレーム

日本では、1996年7月にISO/IEC 12207を日本語化したものがJIS X 0160としてJIS規格となっている。また、情報処理推進機構(IPA)がこれに日本独自の事情を織り込んだガイドラインである「SLCP-JCF」(Japan Common Frame：共通フレーム)を策定している。

1994年に、策定中の標準を先取りした「共通フレーム94」が発行され、1998年に「共通フレーム98」、2007年に「共通フレーム2007」、2013年に「共通フレーム2013」が発行されている。

組織的・商業的なソフトウェアの開発・運用に際しては、発注側(顧客)と受注側(ベンダ)の間で相互の役割や責任範囲、各工程の具体的な業務内容について認識に差異が生じないよう、こうした標準モデルを参照して共通理解を深める必要がある。

企業などの組織が業務やプロジェクトを遂行する際、そのプロセスをどのように管理・改善できているかを、最も未熟なレベル1から最も成熟したレベル5までの5段階の成熟度レベルで表す。

CMMIに取り組む組織に対する成熟度の認定制度などはないが、CMMI研究所ではプロセスの評定(アプレイザル)を行う「リードアプレイザー」(LA：Lead Appraiser)資格の認定を行っており、アプレイザーがプロセスの評価や改善すべき点の指摘などを行う。

元になった手法はソフトウェア開発プロセスの成熟度を測る「CMM」で、これに複数の同種の手法を統合した汎用的な手法である。米カーネギーメロン大学CMMI研究所が開発、公表している。

成熟度レベル

レベル1は「初期段階」(initial)で、特にプロセスが統制されておらず個々人の努力や能力に依存している状態を表す。レベル2は「管理された状態」(managed)で、部署やチーム、プロジェクトなどの単位でプロセスが管理され、計画や監視、コントロールなどが行われている状態を表す。

レベル3は「定義された状態」(defined)で、組織全体で統一された手順や用語、手法が整備され、標準化されたプロセスを各プロジェクトなどが個別に手直しして利用する状態を表す。レベル4は「定量的に管理された状態」(quantitatively managed)で、プロセスの状態を定量的に把握し、蓄積されたデータに基づく統計的な意思決定などが行える状態を表す。

レベル5は「最適化している状態」(optimizing)で、プロセスの定量的な把握を基礎として、組織内で継続的にプロセスの改善に取り組む体制が整備されている状態を表す。レベル4までの表現とは異なり「最適化された」(optimized)とはなっておらず、最適化「し続ける」状態にあることを示している。

CMMとCMMI

CMMIはカーネギーメロン大学ソフトウェア工学研究所(SEI：Software Engineering Institute)がソフトウェア開発プロセスの成熟度を計る指標として開発したCMM(Capability Maturity Model/SW-CMM)が元になっている。

CMMは1989年に初版が発行され、SW-CMM以外にも適用分野の異なるSECM(Systems Engineering Capability Model)やIPD-CMM(Integrated Product Development CMM)などがあった。CMMIはこれらを統合して様々な分野に汎用的に適用できる手法として開発され、2000年に最初のバージョンが公表された。ソフトウェア開発のほか、プロジェクト管理、ITサービス提供、システム調達、人材開発などに適用できる。