基本情報技術者単語帳 - ソフトウェア開発管理技術

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

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

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

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

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

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

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

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

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

適用範囲

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

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

代表的な開発手法

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

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

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

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

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

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

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

適用範囲

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

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

代表的な開発手法

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

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

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

XPは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時間までに制限すべきとされる。

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

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

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

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

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

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

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

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

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

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

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

プログラミングをグループの共同作業として行う手法の一つで、3人以上のチームが同じコード編集画面を見ながら作業を進める。一人がコードをタイプする「ドライバー」、残りのメンバーがドライバーへ記述内容を指示する「ナビゲーター」となる。

ナビゲーターはプログラムでどのように処理を進めるべきか議論し、ドライバーに提案や指示を出す。ドライバー自身は議論に加わらずコード記述に徹するが、記述の仕方についてナビゲーター達と密にコミュニケーションを取る。ドライバーは各メンバー持ち回りで担当し、10分前後で交代するのが望ましいとされる。

二人一組でプログラミングする「ペアプログラミング」を発展させた技法で、集団で議論しながら開発を進めることで困難な課題にも対処しやすくなり、全員が理解できる可読性の高いコードを作成することができる。メンバーの持つ知識やノウハウの共有・移転を進めることができ、新しい技術やツールに対する理解も深めることができる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

利点

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

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

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

難点

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

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

もとはエクストリームプログラミング(XP：Extreme Programming)において提唱された原則で、今現在具体的な必要性がないのに「将来必要になるかもしれない」とか、「あれば便利かもしれない」などといった見込みや思い込みで機能や要素を追加することは戒めるべきであるとする考え方を表している。

背景としては、漠然とした予想や見込みで追加された機能の多くが使われないまま放置され、費やした予算や時間、工数が無駄になる事例が多く見られることや、必要以上にプログラムの規模を大きくしても設計や構造が複雑になり保守や修正が難しくなり、また、いたずらにバグや不具合を増やしてしまうとする知見がある。

似た標語として「KISSの原則」がある。KISSは “Keep it simple, stupid.” (簡潔にしておけ、この間抜け！)の略とされ、ソフトウェアの設計を可能な限りシンプルに保つべきとする考え方である。YAGNIもKISSも、ソフトウェアは規模や複雑さの増大は可能な限り避けるべきとする経験則に基づいていると言える。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

従来のシステム運用はソフトウェアの設定や操作に熟達したシステム管理者が中心となり、主に手作業で管理ツールの操作やコマンド入力などを行い、システムの状態監視、定期的に必要な操作、トラブル発生時の対処などに取り組んできた。

SREでは運用担当にソフトウェア開発チームを取り込み、システム設定の調整や状態の監視、定型的な管理作業などを自動化するツールを開発する。ツールにより運用の効率化、自動化を図り、開発チームは新規のツール開発や既存のツールの改良、不具合の解消に引き続き取り組む。

ソフトウェアによる自動化、省力化の推進を運用業務の一環として取り込むことで、手作業により生じる人為的なミス(ヒューマンエラー)を継続的に削減することができ、システムの種類や規模が拡大しても比例して人員やコストを増やさずに対処できるようになる。

SREは米グーグル(Google)社が提唱した運用手法で、同社ではSREについて「SREとはソフトウェア技術者に運用チームの設計を依頼したときにできあがるものです」(SRE is what happens when you ask a software engineer to design an operations team.)と説明している。同社のSREチームは全作業量の半分を手動の管理業務の上限と定め、もう半分は運用管理のためのソフトウェア開発に割くこととされている。

開発環境で開発・修正したソースコードなどから自動的にビルドやテストを実施するCIを拡張し、インストールパッケージの作成や利用者への配信環境への登録などのリリース工程までを自動化する。

リリースされたパッケージは利用環境側での操作によって本番環境へ展開(デプロイ)され、実際に利用に供される。CDの導入により、テストが完了した修正版が即座に利用可能な状態になるため、運用環境への修正の適用も迅速かつ適時に行うことができる。

一方、リリースの後に本番環境への導入(デプロイ)まで自動化することは「継続的デプロイ」(CD：Continuous Deployment)という。略称が同じ「CD」で紛らわしいが、こちらはビルドやテストが済んだプログラムのリリース、デプロイまでが完全に自動化され、実運用環境のプログラムが継続的に自動更新されていく。開発者と運用者が同じであるようなネットサービス企業などで用いられることが多い。

開発環境で開発・修正したソースコードなどから自動的にビルドやテストを実施するCIを拡張し、利用環境へ実際に導入して利用に供する工程までを自動化することを指す。専用のツールなどを用いて、ビルドされたプログラムを利用環境に展開し、既存の古いプログラムを置き換えたり実行中のプロセスを再起動したりする。

CDの導入により、コーディングが完了したプログラムのビルド、テスト、リリース、デプロイまでの工程が完全に自動化され、改良や修正が即座に実際の運用環境に反映される。このように開発と運用を緊密に統合し、各工程を連続的、循環的に行う手法を「DevOps」(デブオプス)という。

一方、運用環境へのデプロイまでは行わず、デプロイ可能なパッケージの組み立てや提供(リリース)までを自動化することを「継続的デリバリー」(CD：Continuous Delivery)という。略称が同じ「CD」で紛らわしいが、継続的デリバリーは主に開発主体と運用主体が異なる場合(顧客から開発を委託されている場合や多数の利用者に販売・配布するソフトウェアなど)に、継続的デプロイは両者が同一である場合(自社開発ソフトウェアで運用するネットサービスなど)に適用されることが多い。

情報システムには、装置の故障や操作ミスなど何らかの局所的なトラブルが発生しても、全体を停止させずにサービスの提供を継続したり、影響の緩和や復旧などの対処策を迅速に講じることができる「粘り強さ」(レジリエンス)が求められる。

カオスエンジニアリングはシステムの備えるレジリエンスを検証し、また向上させるための技術的な方策の一つで、稼働中のシステムに対して対処可能と予想される小さなトラブルを故意に生じさせ、実際に対処させてみる手法である。想定通りの対応が行われるかを確かめ、見落としていた問題点を発見したり、プロセスの改善に繋げることができる。

人為的なトラブルの内容はシステムの種類や構成によって異なるが、例えば、一部のネットワーク機器やサーバ、ストレージ装置を停止させる、一部のプログラムを強制終了させる、ネットワークケーブルを引き抜く、大きな処理負荷をかける、故意に誤ったシステム操作を実施するといったものがある。

このプロセスをソフトウェアツールを用いて自動化し、定期的に繰り返し実行することにより継続的な検証と改善を行う手法を実践している企業もある。動画配信大手の米ネットフリックス(Netflix)社では「Chaos Monkey」という自社製ツールを2011年から投入しており、システム運用の一環として継続的にカオスエンジニアリングに取り組んでいるとされる。

自社開発のソフトウェアを自社サーバで運用するような環境で、開発チームと運用チームの間のコミュニケーションや情報共有を改善し、開発と運用のサイクルを統合することでソフトウェアの迅速な開発・導入、頻繁な改善・更新を可能にする方法論を「DevOps」と呼ぶ。

DevSecOpsはこのプロセスにシステムの安全を確保するセキュリティチームを合流させる方法論で、開発の初期からセキュリティ確保を意識した仕様策定や設計、プログラミングなどを進め、導入・運用・更新もセキュリティを意識しながら進めていく。

セキュリティチームが運用開始後に監視や設定などを中心に関わる場合に比べ、初期段階から運用に至るまで一貫してセキュリティを意識しながら工程を進めることができ、運用後に重大な脆弱性が発見されて大幅に手戻りするといったリスクを減らすことができる。

一般的なソフトウェア開発では、仕様や設計を元にプログラミング言語を用いてソースコードを記述するコーディング過程が多くの時間と工数を占め、コードの記述によってソフトウェアの振る舞いのほとんどが決定される。

ローコード開発では、図形などのグラフィックによる表示・操作を行うGUI(Graphical User Interface)ツールを使い、画面上でシンボルを配置したり繋ぎ合わせたりしてプログラムの挙動を決めていく。表示画面の設計も実際に画面に表示要素を配置してデザインする。完全にコードが不要とは限らず、細かな設定や挙動の記述のために部分的にコードを記述することはある。

ローコード開発はプログラミングなどに習熟していない従業員などでも行うことが可能で、設計工程やテスト工程の一部も統合できるため、業務現場のニーズに即して迅速に低コストで特定目的・用途のソフトウェアを開発・導入できる利点がある。

ただし、多くのツールは「ローコード開発プラットフォーム」(LCDP：Low-Code Development Platform)として開発環境と実行環境が統合されており、特定の製品やメーカーへ依存したシステム構造(ベンダーロックイン)となる。利用可能な機能や連携可能な外部システムなどにも制約があり、コードを記述せず複雑な機能を作り込むことも難しい。

また、コード記述が不要と言っても適切なデータ構造や処理パターンの設計などには一定のスキルやノウハウが必要なほか、全社的なデータ基盤やシステム基盤、共通システムの整備などが行われないまま部署単位で独自にローコード開発を進めると、却って全体最適や効率化が阻害される危険(サイロ化/シャドーIT化)もある。

ほぼ同様の手法で、まったくコードを書かずにソフトウェア開発を完結させられる手法を「ノーコード開発」(no code development)という。ローコードよりも敷居が低く、迅速に開発を進められるが、実現できる機能の幅はより狭くなる。

一般的なソフトウェア開発では、仕様や設計を元にプログラミング言語を用いてソースコードを記述するコーディング過程が多くの時間と工数を占め、コードの記述によってソフトウェアの振る舞いのほとんどが決定される。

ノーコード開発では、図形や画像などのグラフィックによる表示・操作を行うGUI(Graphical User Interface)ツールを使い、画面上でシンボルを配置したり繋ぎ合わせたりしてプログラムの挙動を決めていく。表示画面の設計も実際に画面に表示要素を配置してデザインする。

ノーコード開発はプログラミングなどに習熟していない従業員などでも行うことが可能で、設計工程やテスト工程の一部も統合できるため、業務現場のニーズに即して迅速に低コストで特定目的・用途のソフトウェアを開発・導入できる利点がある。

ただし、多くのツールは「ノーコード開発プラットフォーム」(NCDP：No-Code Development Platform)として開発環境と実行環境が統合されており、特定の製品やメーカーへ依存したシステム構造(ベンダーロックイン)となる。原則としてツール側に用意された機能を組み合わせてソフトウェアを構成するため、用意されていない機能を追加したり細かな挙動を作り込むことは難しい。

また、コード記述が不要と言っても適切なデータ構造や処理パターンの設計などには一定のスキルやノウハウが必要なほか、全社的なデータ基盤やシステム基盤、共通システムの整備などが行われないまま部署単位で独自にローコード開発を進めると、却って全体最適や効率化が阻害される危険(サイロ化/シャドーIT化)もある。

ローコード開発との違い

ほぼ同様の手法で、ソフトウェア開発の大半をツールの操作によって済ませることができるが、一部にプログラムコードの記述を加えることができる(あるいはコード記述が必要となる)手法を「ローコード開発」(low-code development)という。ノーコードよりも実現できる機能の幅が広がるが、基礎的なプログラミング技能が要求される。

既成品という意味のパッケージ

既成品という意味のソフトウェアパッケージは、開発元が自ら設計・開発して完成品として流通事業者や顧客に販売しているソフトウェア製品を指し、利用者の要望に応じて個別に設計・開発されるオーダーメイドのソフトウェアと対比される。

個人が購入・利用するソフトウェアのほとんどはパッケージだが、企業などの情報システムでは構想時にパッケージと個別開発を比較検討してどちらにするか選択することがある。ソフトウェアパッケージの中には機能を改変したり追加できる仕組みを提供しているものもあり、これを利用して一部を自らの必要に応じて作り変える(カスタマイズ)場合もある。

ソフトウェアパッケージはすでに完成して販売されている製品であるため、利用者側にとっては設計や開発にかかる時間を省いてすぐに購入して利用することができる。他にも利用者がいるため、使用ノウハウなどの有益な情報を開発元から得るだけでなく利用者間で共有できる場合がある。多数の利用者が日々使用することで問題点なども早期に発見され、速やかに修正されることが期待される。コストも同規模、同機能、同性能で比較すればほとんどの場合既成品の方が安い。

ただし、仕様は開発元が策定し、潜在的利用者が共通して求めると想定される最大公約数的な内容であることが多いため、個々の利用者にとっては自らにとって必要な機能が不足していたり、不要な機能ばかり多く費用対効果が低かったりする場合もある。当然ながら自分(自社)しか使用しない特殊な機能などが標準で実装されることは期待できない。

物理的な梱包という意味のパッケージ

提供方式としてのソフトウェアパッケージは、プログラムやデータがCD-ROMやDVD-ROM、Blu-ray Discなどの物理的なメディアに記録され、マニュアルや保証書、利用許諾契約書(ライセンス)などと共に紙箱やプラスチックケースなどに梱包されて利用者に届けられるものを指す。店頭で販売され利用者が購入して持ち帰る場合と、オンラインで注文して宅配便などで配達される場合がある。

インターネットを通じてプログラムなどを配布するダウンロード販売(オンラインソフト)や、Webブラウザなどを介してインターネット上のサービスとしてソフトウェアの機能を提供するSaaS/クラウドサービスなどと対比される。

インターネット回線が低速だったりWebシステムの機能が貧弱な時代にはソフトウェア製品の標準的な提供手段だったが、現代ではスマホアプリのようにネットワークを通じた提供が一般的になり、パッケージ販売はパソコン向けの一部の製品で行われるのみとなっている。

例えば、ネジの標準化が行われる前の時代は、メーカーや製品、部品ごとにばらばらな寸法・形状のネジが使われ、機能やサイズに違いがないのに細部が微妙に異なる多品種のネジを個別に少量ずつ製造していた。

メーカーは自社製品専用のネジを少量ずつ自社生産しなければならず、大量生産してコスト削減や効率化を図ったり、専業の生産者から安く買い付けたりすることは難しい。購入者も割高なネジが使われた高価な製品しか選択肢がなく、修理などの際も必ず製造元から特注品を取り寄せなければならない。

ネジの仕様が公的機関や業界団体の主導により標準化されると、各メーカーは同じ寸法・形状のネジを使うようになり、製品間で同じネジを採用して大量生産による効率化を図ったり、外部への販売や外部からの購入も自由にできるようになった。他の汎用部品についても標準化が進められると、完成品メーカーと部品メーカーの役割分担が進み、産業全体の効率が高まった。

標準化は度量衡などの単位や送電網の電圧などの社会インフラ、ネジのような工業製品、部品などモノの仕様から始まったが、現代ではデータ形式などの無体物、圧縮符号化方式や通信プロトコルといった情報処理の手順、製造プロセスなどの仕組みや業務手順、組織体制などについても行われるようになっている。

標準の種類

産業における標準は主導者や成立過程によりいくつかの類型に分かれる。このうち、公的な標準化団体などが定められた手続きや法制度に則って正式に策定するものを「デジュールスタンダード」(de jure standard/「デジュリスタンダード」とも)という。ISOなどの国際機関が定めた規格、日本国内のJIS規格などが該当する。

一方、公的機関の手続きなどに依らず、特定の企業が仕様を定めて製品を市場で普及させた結果、広く受け入れられて事実上の標準となったものを「デファクトスタンダード」(de facto standard)という。変化の速いIT分野はデファクト標準が多く、標準化機関が後追いでデジュール標準化する例も見られる。

両者の中間的な方式として、複数の企業や専門家集団が業界団体(フォーラム)を形成し、共同で仕様を策定する「フォーラム標準」(forum standard)がある。DVDフォーラムが策定したDVD規格などの例が見られる。フォーラム標準は市場で定着してデファクト標準化し、その後に公的機関がデジュール標準化することが多いが、デファクトの地位を得られず撤退することもある。

標準化団体

標準化を推進する組織を標準化団体という。各国の代表が参画して運営される国際機関としてはISO(国際標準化機構)、IEC(国際電気標準会議)、ITU(国際電気通信連合)などがよく知られる。IEEEのように国際的な専門家団体が標準化団体を兼ねている例、3GPPのように国家と企業が関与する例などもある。

各国には法的に定められた公的規格があり、これを策定する標準化団体がある。日本の場合、JIS規格を発行する日本規格協会(JSA)および審議機関の日本産業標準調査会(JISC)、電波産業会(ARIB)、情報通信技術委員会(TTC)などが該当する。欧州域内の標準化を推進するCEN(欧州標準化委員会)やETSI(欧州電気通信標準化機構)のように国家連合が主導する機関もある。

IT分野では、フォーラム標準を策定する業界団体、企業連合も有力な標準化団体である。DVDフォーラム(DVD)、Blu-ray Discアソシエーション(Blu-ray Disc)、SDアソシエーション(SDメモリーカード)、Unicodeコンソーシアム(Unicode)、Wi-Fiアライアンス(Wi-Fi)、JEDEC(各種メモリ規格)、The Open Group(UNIX)などがよく知られる。

インターネット分野では、伝統的に専門家や開発者が個人の資格で参画する、企業連合的でないコミュニティ型の標準化団体が有力となっている。IETF(インターネット技術全般)やW3C(Web技術)、WHATWG(Web技術)などである。

ソフトウェアの場合には、あらかじめ設定や構成をある程度変更できる機能が内蔵されている場合があり、利用者はこれを変更して自分に合った設定にすることができる。また、業務用のソフトウェアなどでは、コンピュータプログラムそのものを追加・修正するなどして、より根本的かつ大規模に改修を行う場合もある。

コンピュータのハードウェアなどモノの製品の場合には、購入者が発注時に販売元に指示して製品の構成や設定を変更し、好みや要望に適した状態にしてから購入することを指す。カスタマイズ可能な製品はあらかじめ変更可能な箇所や選択肢が提示されていることが多く、その範囲の中で変更を指示することができる。変更内容によって購入額が上下する場合がある。

製品のカスタマイズは、完全にオーダーメイドで特別な製品をゼロから作るよりは利用者の要求に添える範囲は狭まるが、量産品や完成品を元に変更を加えるため、コスト面では有利なことが多い。カスタマイズにより本来の製品とは異なる仕様となった製品のことを「カスタム品」などという。

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

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

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

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

一般的なソフトウェア製品では、コンピュータへの導入(インストール)時に画面上に契約条件が表示され、利用者が「同意する」などと書かれたボタンを押すなどして意思を示すことで契約が締結されたとみなされる(クリックラップ契約)。パッケージに書面が添付され、記録メディアの開封時に自動的に許諾したとみなす場合もある(シュリンクラップ契約)。

具体的な条文や条件は製品によって異なるが、著作権などの権利の所有者の宣言・確認や、購入者に許可される行為と禁止される行為、ソフトウェアの使用に伴い生じた結果についての開発元の免責などがうたわれることが多い。

多くの場合、購入者本人が使用する以外の行為のほとんどは禁止あるいは厳しく制限されており、特に、第三者への譲渡や販売、貸与、複製、改変、二次著作物の作成、逆コンパイル、リバースエンジニアリングなどは明示的に禁止されていることが多い。

後方互換と前方互換

同じ系列の新しい製品が、古い製品の仕様や機能を包含しており、互換性がある状態のことを「後方互換」(backward compatible)、逆に、古い製品が新しい製品に対して互換性を有する状態を「前方互換」(forward compatible)という。一般に、既存の製品の仕様はすでに明らかだが、将来の製品の仕様を正確に予見することは難しいため、前方互換性は限定的なものになることが多い。

上位互換と下位互換

また、同じ系列の上位の(機能や性能などが優れている)製品が、下位の製品の仕様や機能を包含しており、互換性がある状態のことを「上位互換」(upward compatible)、逆に、下位の製品が上位の製品に対して互換性を有する状態を「下位互換」(downward compatible)という。通常、下位の製品は上位の製品に比べ機能や仕様が制限・限定されているため、下位互換性は部分的・限定的なものである場合が多い。

ソース互換 (ソースレベル互換)

ある機種やOSで動作するコンピュータプログラムのソースコードを、追記・修正せずそのまま別のコンピュータ向け使用できることをソースレベル互換(source-code compatibility)あるいはソース互換(source compatibility)という。

ソースコードは人間にわかりやすいプログラミング言語で書かれたプログラムで、そのままではコンピュータ(のCPU)が解釈・実行することができないため、コンパイルやリンクなどの工程を経て実行可能形式のバイナリコードに変換される。

ソースレベル互換とは、ある複数のプラットフォーム間で、同一のソースコードを用いてコンパイルなどを行い、同じように動作する実行プログラムを作ることができる互換性を指す。

バイナリ互換 (バイナリレベル互換)

ある機種やOSで動作する実行可能形式のコンピュータプログラムを、そのまま異なる種類のコンピュータシステム上で動作させることができることをバイナリレベル互換(binary-code compatibility)あるいはバイナリ互換(binary compatibility)という。

バイナリコードはコンピュータ(のCPU)が直接解釈・実行できる機械語(マシン語)や、仮想マシン(VM)で実行できるバイトコードなどを用いて構成されたプログラムで、コンピュータで直に起動・実行することができる。

バイナリレベル互換とは、ある複数のプラットフォーム間で、同じ実行形式のプログラムファイルなどを同じように起動して動作させることができる互換性を指す。

Web上で何らかのサービスを提供する事業者の中には、一定の利用規約や料金に基づいて、外部のサービスやソフトウェアからデータや機能を呼び出して使用できるWeb APIを提供・公開している場合がある。これを利用して様々な機能やデータを繋ぎ合わせ、独自の新たなサービスを生み出す手法をマッシュアップという。

例えば、オンライン地図サービスと飲食店のデータベースを組み合わせ、利用者がスマートフォンなどで現在地周辺の飲食店を検索すると、地図上に重ね合わせて各店舗の情報が現れるといったサービスが提供されている。

個々のソフトウェアの開発者が毎回すべての機能をゼロから開発するのは困難で無駄なため、多くのソフトウェアが共通して利用する機能は、OSやミドルウェアなどの形でまとめて提供されている。

そのような汎用的な機能を呼び出して利用するための手続きを定めたものがAPIで、個々の開発者はAPIに従って機能を呼び出す短いコードを記述するだけで、自分で一から処理内容を記述しなくてもその機能を利用したソフトウェアを作成することができる。

広義には、プログラミング言語の提供する機能や言語処理系に付属する標準ライブラリの持つ機能を呼び出すための規約などを含む場合もある(Java APIなど)。

また、APIを経由して機能を呼び出す形でプログラムを構成することにより、同じAPIが実装されていれば別のソフトウェア上でそのまま動作させることができるのも大きな利点である。実際、多くのOS製品などでは同じ製品の旧版で提供していたAPIを引き継いで新しいAPIを追加するという形で機能を拡張しており、旧バージョン向けに開発されたソフトウェアをそのまま動作させることができる。

APIの形式

APIは人間が記述・理解しやすい形式のプログラムであるソースコード上でどのような記述をすべきかを定めており、原則としてプログラミング言語ごとに定義される。

関数やプロシージャなどの引数や返り値のデータ型やとり得る値の意味や定義、関連する変数や定数、複合的なデータ構造の仕様、オブジェクト指向言語の場合はクラスやプロパティ、メソッドの仕様などを含む。

通信回線を通じて遠隔から呼び出すような構造のものでは、送受信するパケットやメッセージの形式、通信プロトコル(通信規約)などの形で定義される仕様をAPIと呼ぶこともある。

Web API

近年ではネットワークを通じて外部から呼び出すことができるAPIを定めたソフトウェアも増えており、遠隔地にあるコンピュータの提供する機能やデータを取り込んで利用するソフトウェアを開発することができる。

従来は通信を介して呼び出しを行うAPIはRPC(リモートプロシージャコール)の仕様を元に製品や環境ごとに個別に定義されることが多かったが、インターネット上でのAPI呼び出しの場合は通信にHTTPを、データ形式にXMLやJSONを利用するWeb APIが主流となってきている。

2000年代前半まではWeb APIの標準として仕様が巨大で機能が豊富なSOAPの普及が試みられたが、2000年代中頃以降は軽量でシンプルなRESTful APIが一般的となり、狭義のWebアプリケーションだけでなく様々な種類のソフトウェアやネットサービス間の連携・接続に幅広く用いられるようになっている。

APIと実装

API自体は外部からの呼び出し方を規定した決まりごとに過ぎず、呼び出される機能を実装したライブラリやモジュールなどが存在して初めてAPIに挙げられた機能を利用することができる。

あるソフトウェアのAPIが公開されていれば、同じAPIで呼び出すことができる互換ソフトウェアを開発することもできる。ただし、APIを利用する側のプログラムが(スクリプトなどではなく)バイナリコード(ネイティブコード)の場合にはこれをそのまま動作させることはできないのが一般的で、同じソースコードを元に互換環境向けにコンパイルやビルドをやり直す必要がある(ソースレベル互換)。

また、API自体は標準実装における動作の詳細までは定義していないため、APIが同一の互換ソフトウェアだからといって動作や振る舞いがまったく同じであるとは限らない。商用ソフトウェアの場合はAPIが非公開だったり、すべては公開されていなかったりすることが多く、公開情報だけではAPI互換の製品を作ることも難しい。

APIと知的財産権

従来は特許で保護されている場合を除いて、APIそのものには著作権その他の知的財産権は存在しないとする見方が一般的で、実際、元のソフトウェアのコードを複製せずすべて独自に実装するという方法でAPI互換ソフトウェアが数多く開発されてきた。

ところが、米オラクル(Oracle)社が権利を有するJava言語やその処理系に関して、米グーグル(Google)社が同社の許諾を得ずにAndroidスマートフォン向けにJava APIを実装した実行環境(Dalvik VM)を開発・提供しているのは著作権侵害であるとの裁判が起こされ、米裁判所は訴えを認める判決を出した。今後はAPIの権利について従来の状況が変化していく可能性がある。

ソフトウェアを構成する実行ファイルの形式が、特定のCPU(マイクロプロセッサ/MPU)とOSの組み合わせで動作する「ネイティブコード」(native code)となっているものを指す。

対象機種・OS以外の環境では動作しないが、プログラムサイズが小さく実行速度が速い。また、当該環境が提供する機能を制約なくフル活用することができ、高機能・高性能を実現しやすい。

一方、非ネイティブアプリケーションソフトウェアはコンピュータが直接実行可能なプログラム以外の形で実装・配布されるもので、性能や機能では劣るが一つの配布パッケージで様々な異なる環境(パソコンとスマートフォン、WindowsとmacOSなど)に対応できる利点がある。

これには、HTMLなどのマークアップ言語やJavaScriptなどのスクリプト言語を組み合わせた「Webアプリケーション」(Webブラウザなどで動作する)や、Java言語で開発された「Javaアプリケーション」(実行環境上のJava仮想マシンで動作する)などが含まれる。

なお、スマートフォンやタブレット端末などで普及しているAndroidは、アプリの配布にJavaプログラムの亜種を用い、端末の実行環境に合わせてコード変換を行う方式を取っているため、形式的にはネイティブアプリケーションソフトウェアではないと言えるが、Webアプリなどとの対比で慣例的に「Androidネイティブ」であるとみなされる。

Webアプリケーションはインターネット上の特定のWebサイトにアクセスすることで利用できるが、PWAによってホーム画面にアイコンを作成してアプリを起動するようにアクセスできるようになる。実体はWeb上にあるためアプリのようにストアからインストールする手順は不要である。

Webブラウザ内部にスクリプトを常駐させることができるService Worker(サービスワーカー)の仕組みを利用して、サイトのデータや機能の一部または全部をブラウザ内に送り込み、オフラインの状態でも起動して動作させることができる。オフラインでどの程度まで動作するかはアプリの設計による。

一度読み込んだデータやプログラムはキャッシュとして保管され、機能や内容をあらかじめ読み込んでおく先読み(プリキャッシュ)機能もあるため、ネットワークから読み込むWebアプリよりも軽快に動作させることができる。

従来はネイティブアプリにのみ可能だったプッシュ通知も扱うことでき、サイト側から能動的に情報を告知することができる。ブラウザ側のメニューの一部を非表示とするなど、表示・操作画面の構成などもネイティブアプリ風に設計することができる。

サイトをPWA化するには伝送経路を暗号化するHTTPSへの対応が必須となる。その上で、ページ内にService Workerの動作を定義するスクリプトを記述し、Webサーバ上にアプリの設定や概要をJSON形式で記述したマニフェストファイル(拡張子.webmanifestのファイル)を用意する必要がある。

PWAという用語および概念は米グーグル(Google)社が2015年に発表したもので、当初は同社の(Androidスマートフォン上の)Google Chromeでの利用を想定していたが、他のブラウザ製品でもService Workerの実装が進み、Apple Safari、Mozilla Firefox、Microsoft Edgeなど主要なWebブラウザで利用可能となっている。

一般に、利用者(user)の代理(agent)として何らかの処理や通信を行う機器やソフトウェアをUser-Agentという。特に、ネットワーク上で外部と通信するクライアントソフトなどを、サーバ側から見てこのように呼ぶことが多い。

単にUser-Agentという場合は、WebにおけるWebブラウザやWebクローラーなどのクライアントソフトを指すことが多い。利用者の指示を受けて、あるいはプログラムにより自律的にWebサーバへアクセスし、ファイルの取得や内容の画面表示、利用者の操作の受け付けなどを行う。

HTTPのUser-Agentヘッダ (HTTP_USER_AGENT)

Webコンテンツの伝送に用いるHTTP(Hypertext Transfer Protocol)では、クライアントからのリクエスト送信時に、HTTPリクエストヘッダ内の「User-Agent」フィールドにソフトウェアの名前やバージョン番号などの情報を記載することができる。

分野や文脈によっては、この識別文字列を指してUser-Agentと呼ぶことがある。サーバ側ソフトウェアのHTTP環境変数では「HTTP_USER_AGENT」に格納される。プログラムから参照して、ブラウザとクローラーの判別、ブラウザの種類の判別、動作環境(プラットフォーム)の判別などに用いられる。

各Webブラウザは自身の名前やバージョンを含む固有のUser-Agent値を持つが、この値はクライアント側で任意に設定できるため、いい加減な内容を設定する開発者や、他のソフトウェアと同じ文字列を設定してそのソフトに偽装する開発者もいる。

User-Agent文字列は、例えば「Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36」といった内容になっている。これはGoogle Chromeバージョン72のものだが、動作環境が64ビットx86プロセッサ向けWindows 10である(Windows NT 10.0; Win64; x64)といった記述も含まれる。

また、特定のWebブラウザの特定のバージョン以上でのアクセスを要求するWebサイトやサービスが多く作られてきた歴史的な事情から、旧Netscape Navigator 4.0の後継であることを示す「Mozilla/5.0」や、米アップル(Apple)社のWebブラウザと互換性があることを示す「Safari/537.36」といった他のブラウザのUser-Agentの一部を付け加えている慣習がある。

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

今日一般的に言われる構造化手法とは、プログラム中のコードの実行順の制御を、記述した順番に実行する「順接」あるいは「順次」(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文論争」、また、「構造化定理」と「構造化手法」の名称の類似性などを通じて、次第に「三つの制御構文」式の理解が広まっていったと考えられている。

様々な表現形式があるが、一般的な手法では、対象が取りうる状態を円や矩形などで列挙し、どこからどこへ遷移が起きうるかを矢印によって示す。各矢印の脇に、その遷移が起きるための条件やきっかけとなる出来事などを記述する。自らに遷移する場合は自分を指し示す輪っか状の矢印を書き入れる。

対象に開始や終了がある場合は、特殊な記号で示される場合がある。UMLでは開始を塗りつぶした丸印で、終了を内側を塗りつぶした二重丸で記載するよう定められている。

状態遷移表

状態遷移図の各状態を一行として表の形で書き表したものを状態遷移表という。

一般的な形式では、各行が対象の状態を、各列がイベントを表し、ある状態のときにあるイベントが起きたときにどの状態に遷移するかを書き入れていく。

また、縦軸・横軸ともに状態を並べ、各状態の交差する項目にそのような遷移が起こるイベントを書き入れていく様式もある。

ソフトウェア開発の分野ではテストを行う際にテストケースを漏れなく網羅するために状態遷移表が作成される場合がある。

ステートマシン図 (state machine diagram)

ソフトウェアの設計などに用いられるUML(Unified Modeling Language)では、状態遷移図に相当する図をステートマシン図(state machine diagram)として定義している。

あるオブジェクトの振る舞いを漏れなく記述するために用いられるもので、開始状態を塗りつぶした丸印(●)、終了を内側を塗りつぶした二重丸で表し、途中の状態を角丸の矩形を並べて図示していく。

状態間は遷移する方向に矢印で繋ぎ、脇に遷移の説明を添える。遷移したときに実行する動作がある場合は矩形を横に区切って下半分に動作の内容を記述する。

システムが扱うデータの流れを整理するための図法で、対象となるシステムと利用者や外部のシステムなどのデータの流れを図示する場合と、システム内の構成要素(データストアやプロセスなど)間の流れを図示する場合がある。

データは発生源から様々な処理(プロセス)を経て出力先へ収まる。一つの図にあまり多くの要素を図示すべきではないとされ、。全体的で抽象的なレベルから作図し、段階的に詳細化した図を描いていくという手法が用いられることが多い。

DFDでは、データの保管や取り出しを行う「データストア」を平行な上下二本線で、データを処理するソフトウェアなどの「プロセス」を丸で、データの発生源や出力先である「外部実体」(ターミネータ)を長方形あるいは楕円で示す。これらの要素の間をデータの流れ(フロー)を表す矢印で結んでいく。

プロセスには入力と出力を表す「フロー」がそれぞれ一つ以上必要で、データストアや外部実体は入力または出力のいずれか一方のフローが必要となる。また、各フローの一方の端は必ずプロセスでなければならない。

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」が発行されている。

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

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

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

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

共通フレーム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年改訂版)を元にしている。

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

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

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

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

成熟度レベル

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

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

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

CMMと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)などがあった。プロセス成熟度はこれらを統合して様々な分野に汎用的に適用できる手法として開発され、2000年に最初のバージョンが公表された。ソフトウェア開発のほか、プロジェクト管理、ITサービス提供、システム調達、人材開発などに適用できる。

企業などの組織が業務やプロジェクトを遂行する際、そのプロセスをどのように管理・改善できているかを、最も未熟なレベル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サービス提供、システム調達、人材開発などに適用できる。

大きく分けて、人間の知的活動によって創作された表現に対して認められる「著作権」、商業上有用になりうる情報や標識などに対して認められる「産業財産権」(工業所有権)、この二つに属さないその他の権利に分かれる。

著作権は思想や感情を創作的に表現した者がその表現の利用を独占できる権利で、複製権や上演権、公衆送信権、貸与権、翻案権など様々な権利で構成される。また、音楽などの場合には実演家や記録物の製作者、放送事業者などに著作を利用した実演などに対する「著作隣接権」が認められ、広義にはこれも知的財産権の一種とみなすことがある。

産業財産権は企業などの経済活動に関連する情報などを保護する権利で、発明に認められる「特許権」、有用なアイデアなどに認められる「実用新案権」、工業製品のデザインや特徴的な外観に認められる「意匠権」、営業活動に用いる名称や標識などに認められる「商標権」などが含まれる。

これ以外にも、IC(集積回路)の設計など半導体の回路配置を保護する「回路配置利用権」、品種改良で産み出された有用な植物を保護する「育成者権」、企業の営業上のノウハウや秘密の情報などを保護する「営業秘密」(企業秘密)、著名人の容姿を写した記録物の持つ商業的な価値を保護する(財産権としての)「肖像権」、インターネット上のドメイン名を保護する権利などがある。

産業財産権 (工業所有権)

知的所有権のうち、企業や経済活動に関わりの深いものを産業財産権(industrial property right)あるいは工業所有権と総称する。日本では商標権、特許権、意匠権、実用新案権がこれに含まれる。

国際的には、1883年にパリで締結された「産業財産権の保護に関するパリ条約」(パリ条約)および、その最新の改正版であるストックホルム改正条約(1967年)によって規定された諸権利のことを意味し、「特許、実用新案、意匠、商標、サービス・マーク、商号、原産地表示又は原産地名称及び不正競争の防止に関するもの」(特許庁訳)と規定されている。

日本では明治時代にパリ条約の訳文に「工業所有権」の語が用いられ、一般にも定着したが、2002年の「知的財産戦略大綱」以降、政府公式の文書などでは「産業財産権」の語を用いるようになっている。

著作権法では対象となる著作物を「思想又は感情を創作的に表現したものであつて、文芸、学術、美術又は音楽の範囲に属するもの」と規定しており、小説や随筆、論文、絵画、写真、図形、立体造形物、建築、音楽、映画、コンピュータプログラムなどがこれに該当する。新聞や雑誌、辞書などは要素の選択や配列といった編集に創作性が認められ、編集著作物として保護される。

一方、思想や感情ではない単なるデータや、創作性に乏しい他人の作品のコピーや誰が書いても同じになるような定型文書、文芸・学術・美術・音楽に含まれない日用品や工業製品、法令や判決文、行政機関などの発行する通達等の文書などは除外される。また、アイデアなどはそれを記したものはその表現が著作物として保護の対象となるが、アイデアそれ自体は著作物ではないため対象外である。

著作者に認められる権利はいくつかあり、大別すると、著作者の人格的利益を保護する著作者人格権、著作物の利用を独占的に制御することを認める財産権としての(狭義の)著作権に分かれる。また、音楽などの場合には著作者以外にも実演家やレコード製作者、放送事業者に著作隣接権が発生する。

人格権には公表権、氏名表示件、同一性保持権などが含まれ、著作権(財産権)には、複製権、上演権、公衆送信権、展示権、頒布権、譲渡権、貸与権、翻訳権、翻案権、二次的著作物の利用についての権利などが含まれる。音楽の実演家などには、著作隣接権として、その実演についての同一性保持権や録音権、放送権、送信可能化権、譲渡権、貸与権などが認められる。

発明を審査・登録して出願者に権利を付与する行政手続きを「特許」というが、一般には特許登録された発明(特許発明)のことを指して特許ということが多い。

特許権の対象となる発明とは、自然科学の法則を応用して新たに考案された物や方法、物を生産する手段などで、特許発明として登録されるには新規性や進歩性、産業への応用可能性がなければならない。

出願された内容がすでに公知の場合や、科学的に実在を確認できない原理や存在に基いている場合、自然科学の法則を利用していない場合、既存の技術よりあらゆる面で劣っている場合、産業における有用性が見込めない場合、公序良俗や法律に反する目的や手段を含む場合などは、審査により却下される。

特許発明の出願者には独占的な使用権が認められ、発明を許諾なく使用した者に対し、使用の差し止めや損害賠償を請求することができる。特許権の有効期間は日本の現在の制度では出願から20年間で、原則として延長はできないが、薬品などごく一部の分野に限って5年間の延長が認められる。登録中は毎年特許庁に特許料を収めなければならず、これを怠ると20年を待たずに特許権は消滅する。

特許発明の内容は特許庁によって公開され、誰でもその詳細を知ることができる。また、特許権は商標権のように任意の期間延長することはできず、存続期間が終了すると誰でも自由にその発明を利用できるようになる。

このため、自社の優位を少しでも長く維持したい企業や、知的財産権の保護体制が未整備な国への技術流出を恐れる企業では、自社独自の技術などをあえて特許出願せず、秘密を厳重に管理して守ろうとする場合もある。

発明を審査・登録して出願者に権利を付与する行政手続きを「特許」というが、一般には特許登録された発明(特許発明)のことを指して特許ということが多い。

特許権の対象となる発明とは、自然科学の法則を応用して新たに考案された物や方法、物を生産する手段などで、特許発明として登録されるには新規性や進歩性、産業への応用可能性がなければならない。

出願された内容がすでに公知の場合や、科学的に実在を確認できない原理や存在に基いている場合、自然科学の法則を利用していない場合、既存の技術よりあらゆる面で劣っている場合、産業における有用性が見込めない場合、公序良俗や法律に反する目的や手段を含む場合などは、審査により却下される。

特許発明の出願者には独占的な使用権が認められ、発明を許諾なく使用した者に対し、使用の差し止めや損害賠償を請求することができる。特許権の有効期間は日本の現在の制度では出願から20年間で、原則として延長はできないが、薬品などごく一部の分野に限って5年間の延長が認められる。登録中は毎年特許庁に特許料を収めなければならず、これを怠ると20年を待たずに特許権は消滅する。

特許発明の内容は特許庁によって公開され、誰でもその詳細を知ることができる。また、特許権は商標権のように任意の期間延長することはできず、存続期間が終了すると誰でも自由にその発明を利用できるようになる。

このため、自社の優位を少しでも長く維持したい企業や、知的財産権の保護体制が未整備な国への技術流出を恐れる企業では、自社独自の技術などをあえて特許出願せず、秘密を厳重に管理して守ろうとする場合もある。

英語の “license” には医師免許(medical license)や自動車運転免許(driver's license)のように行政機関などが交付する免状などが含まれるが、日本語の外来語の「ライセンス」は、著作権や特許権、商標権などの知的財産権の所有者が他者に与える利用許諾や、そのような契約、契約書などを指すことが多い。

ソフトウェアライセンス (software license)

IT分野では、各国の著作権制度に基づき、ソフトウェアのプログラムを開発した著作者が、他者が入手・使用する際の条件をまとめた文書や、これに基いて利用者に与えられる許諾のことをライセンスということが多い。

商用ソフトウェア製品などでは、最終利用者に使用許諾の条件を提示した契約書面のことを「EULA」(End-User License Agreement：使用許諾契約)と呼び、これを単にライセンスと呼ぶ場合もある。購入者以外の使用や無断複製、譲渡、貸与、販売などの禁止が宣言されていることが多い。

企業や官公庁、学校などの法人向けに、ソフトウェアパッケージやプログラムとは切り離して、利用許諾権のみを必要な人数分まとめて販売する契約形態もあり、「コーポレートライセンス」「ボリュームライセンス」などと呼ばれることがある。

開発者がソースコードを公開・配布して、誰でも自由に利用や改変、再配布を許諾しているソフトウェアを「オープンソースソフトウェア」というが、これは著作権を放棄しているのではなく、「オープンソースライセンス」と呼ばれる許諾条件に基づいて配布されている。利用者は原著作者の表示などライセンスに記載された要請事項を守る必要がある。

著作権以外のライセンス

著作権以外の知的財産権についても、一定の取引条件を定めて他者に使用を認める契約などをライセンスということがある。例えば、工業製品の設計情報や製造技術を供与して他社による生産を認めることを「ライセンス生産」(ライセンス製造)、二社が所有する同一分野の特許権の実施をお互いに無償で認めあう「クロスライセンス契約」などの用例が見られる。

ライセンサーは著作物や発明(特許)など何らかの知的財産の独占的な権利を保有しており、利用を希望する法人や個人と利用許諾契約(ライセンス契約)を結んで利用を許諾する。金銭的な対価を受け取って利用を許諾することが多く、対価を「ライセンス料」(license fee)あるいは「ロイヤリティ」(royalty)という。

単にライセンサーという場合は特許権に基づいて発明の実施許諾を行う特許権者を指すことが多いが、著作権に基づいてキャラクターなどの著作物の利用許諾を行う著作権者や、商標権に基づいてブランド名やロゴなどの登録商標の利用許諾を行う商標権者、意匠権に基づいて製品デザインなどの利用許諾を行う意匠権者も含まれる。

特定の標準規格の製品を作るのに複数の特許が必要な場合には、関連する特許を保有する権利者が連合を組んで特許の管理を代行する組合組織を立ち上げ、組合が一括して利用許諾を行い、ロイヤリティを各権利者に分配する場合がある。このような仕組みを「パテントプール」(patent pool)という。

ライセンシーは著作物や発明(特許)など何らかの知的財産の独占的な権利を保有するライセンサーと利用許諾契約を結び、知的財産を利用して商業活動などを行う。ライセンサーに金銭的な対価を支払う場合が多く、この対価を「ライセンス料」(license fee)あるいは「ロイヤリティ」(royalty)という。

単にライセンシーという場合は特許権に基づく許諾を得て発明を実施する事業者を指すことが多いが、著作権に基づいてキャラクターなどの利用許諾を得て関連グッズなどを製造・販売する事業者や、商標権に基づいてブランド名や製品名、ロゴなどの利用許諾を得て関連商品を製造・販売する事業者、意匠権に基づいて特定のデザインの製品を製造・販売する事業者なども含まれる。

知的財産には様々な種類があり、法律で権利保護の対象となっているものには著作物(著作権)や実演(著作隣接権)、発明(特許権)、商標(商標権)、意匠(意匠権)、肖像(肖像権)、物品の形状(実用新案権)などがある。商業上の利益に繋がる特許権、実用新案権、意匠権、商標権は「産業財産権」あるいは「工業所有権」とも呼ばれる。

広義には、営業秘密(企業秘密)や植物の品種(育成者権)、農畜産物の産地表示(地域ブランド)、インターネット上のドメイン名、文字の書体(フォント)、半導体の回路設計(回路配置利用権)なども含まれる。肖像については人格権と財産権(パブリシティ権)に分けて考えることもある。

一方、ある事柄について体系的に記録・蓄積されたデータなど、経済的な価値のある情報の一種だが、それ自体は法律上の保護の対象とならない知的財産もある。また、主にビデオゲーム産業を中心とするエンターテインメント業界では、知名度や過去の実績が顕著な、有力な作品タイトルやシリーズ、キャラクターなどを指して知的財産という意味で「IP」という用語を用いる。

磁気テープなどアナログメディアの時代から著作物の違法コピーの問題は存在したが、デジタルメディアでは複製が容易になり、何度複製を繰り返しても信号が劣化しなくなったため、海賊版の流通が社会問題化するようになった。これに対抗するため、様々な記録媒体や記録形式に複製を制限・防止するためのコピーガード技術が採用されるようになった。

音声や映像の複製防止

音楽CDのように、もともとの技術的仕様にコピーガードが含まれていなかったものは、後からコピーガード技術を追加・普及させようとしてもうまくいかないことが多い。DVDやBlu-ray Discのビデオ記録仕様やデジタル放送には最初からコピーガードのための仕様が含まれており、対応していない機器では録画・再生などができないようになっている。

デジタル放送などでは複製を完全に禁止するわけではなく、ダビング10方式の「10回までコピー可能」というような制限が行われることがあり、このような方式は「コピー制御」「コピーコントロール」と呼ばれることもある。

ソフトウェアの複製防止

ソフトウェア(コンピュータプログラム)のコピーガードには、販売パッケージごとに異なる英数字列(シリアルナンバー、プロダクトID、ライセンスキーなどと呼ばれる)を添付し、コンピュータへの導入(インストール)時に入力を求める方式が長年用いられてきた。

この英数字列ごとコピーされる不正コピーが後を絶たないため、パッケージに同梱された専用のコネクタ(ドングルと呼ばれる)をUSBポートなどに装着しないと動作しない方式や、インターネットを通じて開発元や販売元に利用登録を行なったコンピュータでのみ動作するようにする「プロダクトアクティベーション」方式がよく用いられている。

コピー制御情報 (CCI)

デジタルデータの複製制御のために「コピー制御情報」(CCI：Copy Control Information)と呼ばれる符号をデータに付加して配布する場合がある。再生機器による読み込み時に、コピーの許可や禁止、制限などを指示することができる。

規格によって形式は様々だが、DTCPやデジタル放送などで用いられる最も一般的なCCIは2ビット、4種類の値で表現される。2進数で「00」(10進数で0、以下同)が「自由にコピー可」(Copy Freely)、「01」(1)が「これ以上のコピー不可」(Copy No More)、「10」(2)が「一度だけコピー可」(Copy Once)、「11」(3)が「コピー不可」(Copy Never)を表す。「10」に設定されたデータをコピーするとCCIが「01」に変更して記録され、そこから再びコピーすることはできなくなる。

デジタル化された音楽などの著作物は何度コピーしても、どんな遠距離を送受信しても品質が劣化しないため、インターネットの普及や回線の高速化、コンピュータの性能向上に伴って、著作者の許諾を得ない違法な配布・交換などが増えている。

これに対抗するため、コンテンツの複製や再生などに一定の制限を設け、正規の手段でしか利用できないようにする技術がDRMである。内容を暗号化して正規の再生環境でのみ復号できるようにして、複製データや非正規の環境では暗号化を解除できないようにする手法がよく用いられる。

具体的な実装形態は様々で、ディスクやメモリーカードなどの媒体側に特殊な加工や機構を組み入れたり、音声や動画の再生機器やプレーヤーソフト、ファイルの送受信・転送ソフトに組み込んだり、それらを組み合わせたシステムなどがある。

DRMが普及して以降、このような技術的な保護手段が講じられていない状態で提供されるデジタルコンテンツを「DRMフリー」(DRM free)と呼ぶことがある。これは技術的には複製や伝送が可能であることを表し、利用者に認められた権利上、自由に複製や伝送しても良いという意味ではない(自由である場合もそうでない場合もある)。

特殊なツールなどを用いてDRMコンテンツから複製・配布可能な状態のデータを抜き出す行為(DRM解除)はもともと違法ではなかった(そのデータを無断で配布・販売等すれば著作権侵害となる)が、日本では2012年の著作権法改正で、DRMの解除が違法化(刑事罰は無し)され、DRM解除ツールの配布も違法化(刑事罰あり)された。

ソフトウェア製品のアクティベーション

商用のソフトウェア製品では、利用者がその製品を正規に入手したことを開発元・販売元が確認し、非合法に入手した不正コピー品などを利用できないようにする手続きを「ライセンス認証」あるいは「アクティベーション」という。

アクティベーションが必要なソフトウェアは、コンピュータへ導入(インストール)しただけでは完全に利用可能な状態とはならず、所定の手続きが完了するまで起動しなかったり、一部の機能が制限されたり、一定期間が経過すると使用不能になったりする。

利用者はインターネットなどを通じて、メーカーにシリアル番号やライセンスコードなど製品パッケージなどに添付された識別情報を申告し、これが正規に販売され、まだ未使用の状態であることが確認されると、起動制限・機能制限が解除されて完全に利用可能な状態になる。

識別情報の申告時に利用者の身元や連絡先などの入力を要求し、利用者登録(ユーザー登録)手続きを同時に行う場合もある。また、ネットがなくても手続きができるよう、電話や郵送などによる手続きを受け付ける窓口を開設しているメーカーもある。

ソフトウェア本体をインターネットなどを通じて無償配布し、インストール直後は機能や期間が制限された試用版・体験版となっているが、購入手続きを行ってアクティベーションを実施するとそのままフル機能の製品版に変化する、といった販売手法を採用しているソフトウェア製品もある。

アクティベーションを解除して実施前の状態に戻す手続きを「ディアクティベーション」(deactivation)あるいは「アクティベーション解除」「アクティベーション停止」などと呼ぶ。コンピュータを買い替えたり、複数台のコンピュータを切り替えて使用する場合などで、使わなくなった(使わない)側のコンピュータで必要になる場合がある。

機器のアクティベーション

モバイル機器などの中には、購入後の初回使用時に様々な設定や必要事項の入力、ユーザーアカウント作成などの手続きを行い、使用可能な状態にする一連の操作をアクティベーションと呼ぶことがある。iPhoneやiPadなど米アップル(Apple)社製品でよく用いられる用語で、パソコンなどの場合は同様の手続きや操作を「セットアップ」(setup)と呼ぶことが多い。紛失時に第三者が再利用できないよう初期化を封じる機能を「アクティベーションロック」という。

CPRM対応メディアには1枚ごとに固有の「メディアID」と一定の生産枚数ごとに変更される「MKB」(Media Key Block)と呼ばれる情報が記録されている。メディアにコンテンツを記録する際にはこの2つに加え録画機器の持つ「デバイスキー」を用いて暗号化を行い、記録する。

他のメディアにコンテンツをコピーすると暗号化されたデータ本体を記録することはできるが、メディアIDやMKBまではコピーできないため、復号時に暗号化に使用した鍵を生成することができず、再生することができない。

かつてDVDで使われていたCSS(Content ScramblingSystem)方式は再生機器の暗号鍵の管理がずさんなメーカーがあったため、すべての暗号を解除できるソフトウェアが公開され実質的に無効化されてしまったが、CPRMではこれを防ぐための機構が用意されている。

録画機器の持つデバイスキーが流出すると、新規に生産される記録メディアのMKBを変更して、そのデバイスキーを元に鍵を生成できないよう設定する。すでに生産され流通しているメディアMKBは変更できないが、新しいメディアでは流出したデバイスキーを持つ機器での記録や再生ができなくなるため、万能の暗号解除ソフト等を作ることはできない。

CPRM対応の録画用メディアとしては、DVD-RAM、DVD-RW、SDメモリーカードなどがある。2004年4月5日から、BS/地上デジタルテレビ放送に、原則「1回だけ録画可能」(コピーワンス)なコピー制御信号が加えられ、デジタル放送番組のデジタル録画をするためには、CPRMに対応しているレコーダーと録画用メディアが必要となった。「1回だけ録画可能」なデジタル放送をデジタル録画した場合、他のデジタル機器にはダビングできず、CPRM対応プレーヤーでなければ再生できない。

CPPM (Content Protection for Prerecorded Media)

著作物の収録された再生専用メディア(prerecorded media)の違法コピーを防ぐ技術。1999年に米IBM社、米インテル(Intel)社、松下電器(現パナソニック)、東芝などによって提案された。主に映像作品などの収録されたDVDメディアで採用されている。

メディアの内容は暗号化されて記録され、メディア本体とメディアを再生する機器(もしくはソフトウェア)がそれぞれ暗号を解読するために必要な暗号鍵を持っている。メディア側の持つ鍵と、再生機器側の鍵がそろわなければ、暗号化されたメディアを復号し再生することはできない。

メディア側の鍵はMKB(Media Key Block)と呼ばれ、メディア内のリードイン領域と呼ばれる場所に記録されている。リードイン領域は、通常のディスク操作ではアクセスできない領域であり、一般的な方法による複製ではリードイン領域の内容はコピーされない。つまり、違法コピーによって複製されたメディアは正しい鍵を持っていないことになり、再生できない。

CPPMでは、かつてDVDメディアの暗号化技術であるCSS(Content Scrambling System)において秘密の暗号鍵の流出により暗号が破られた経験を踏まえて、暗号をより強力にし、万が一暗号鍵が流出した場合でもその鍵を無効にすることができるようになっている。

CSS (Content Scrambling System)

市販のDVD映像ソフトの多くに採用されていたデジタルコピー防止機構。映像データにスクランブルをかけ、CSSデコーダを内蔵したプレーヤでしか再生できないようになっている。

CSSではマスター鍵、ディスク鍵、タイトル鍵という3種類の暗号鍵が用いられる。タイトル鍵はディスク内に記録されたタイトルごとに設定される鍵で、コンテンツの暗号化に使用される。ディスク鍵はディスクごとに設定される鍵で、そのディスクで使用されるタイトル鍵の暗号化に使用される。

マスター鍵はDVD機器製造メーカーに個別に割り当てられる鍵で、これを使用してディスク鍵を暗号化し、ディスクの先頭に記録する。復号時にはDVD機器や再生ソフトが内蔵するマスター鍵でディスク鍵を復号し、ディスク鍵でタイトル鍵を復号してコンテンツのスクランブルを解除する。

再生ソフトでのマスター鍵の管理がいい加減なメーカーが存在したため、CSSはあっさり破られてしまった。1999年11月にノルウェーの数人のプログラマによって「DeCSS」というCSSスクランブル解除ソフトが開発され、インターネットなどを通じて世界中に公開された。これを機にCSSは使われなくなり、このような手法が通じないよう工夫されたCPRMやCPPMに取って代わられた。

コンピュータプログラムには著作権が発生し、開発者は著作権を有する。開発者は利用者に許諾する事項をライセンスとしてまとめ、利用者に提示する。商用ソフトウェア製品では、購入者以外の使用や無断複製、譲渡、貸与、販売などの禁止が宣言されていることが多い。

最終利用者に使用許諾の条件を提示した契約書面のことを「EULA」(End-User License Agreement：エンドユーザー使用許諾契約)と呼び、これを単にソフトウェアライセンスと呼ぶ場合もある。EULA文書をパッケージに同封し、プログラムを記録したメディア(光学ディスクなど)を開封したら同意したとみなす「シュリンクラップ契約」という契約手続きが用いられることが多い。

法人向けライセンス

企業や官公庁、学校などの法人向け製品の場合には、一定の人数まで複製して使用できることを定めた「ボリュームライセンス」(コーポレートライセンス)によって販売を行うことが多い。これには利用権の付与の仕方によって様々なソフトウェアライセンス形態がある。

例えば、利用者単位(ユーザーライセンス)か機器単位(デバイスライセンス)か、一台単位か搭載CPU個数単位(CPUライセンス)かCPUコア数単位(コアライセンス)か、機器を固定(ノードロックライセンス)するか権限を移動(フローティングライセンス)できるかといった違いがある。

オープンソースライセンス

ソースコードが公開され、誰でも自由に入手、使用、改変、再配布などできるオープンソースソフトウェアの場合も、原著作者の定める利用条件を記載した「オープンソースライセンス」に基いて許諾が与えられることが多い。

基本的には利用者がソフトウェアを自由に扱うことを認めるが、二次的著作物を作成した際に原著作物と同じライセンス条件での公開を求めるか、派生物には商業的な独占や秘匿などを認めるかといった違いがあり、利用者は原著作者の要請に従う義務がある。

ソフトウェア作者が自ら条件を記述してライセンスを作成する場合もあるが、「GPL」(GNU General Public License)や「BSDライセンス」「MITライセンス」「Apacheライセンス」など、著名なオープンソースライセンスが存在し、その中から選んで採用することが多い。

複数の異なるオープンソースライセンスや、商用ライセンスとオープンソースライセンスの適用を認め、利用者側で好ましいものを選べるようにする場合もある。これを「マルチライセンス」と呼び、特に2つの場合を「デュアルライセンス」という。

開発された新システムの導入や公開の直前に、本番と同じ状態で実際に稼働させてみて問題が起きないか確認・検証するために構築されるテスト用の環境である。検証が済んだシステムは本番環境(プロダクション環境)に導入され、利用に供される。

ハードウェアやオペレーティングシステム(OS)、ミドルウェアやライブラリ、ネットワーク環境、およびそれらの設定などを本番環境にできるだけ揃えるが、コストや手間を抑えるためロードバランサや冗長構成など一部の構成要素は省略される場合がある。

具体的な環境の構成はシステムの種類により様々である。サーバの形態を取るものを「ステージングサーバ」、Webサイトの形態を取るものを「ステージングサイト」というように呼ぶこともある。実際の利用者(エンドユーザー)には公開せず、テスターや開発者のみが利用する。

機材の手配、OSやサーバソフトウェアの導入や設定を手作業で行うのは手間がかかるため、クラウドサービスやコンテナ型仮想化、IaC(Infrastructure as Code)ツールなどを用いて環境構築の自動化・省力化を行う事例が増えている。

システムを構成するコンピュータやネットワーク、ソフトウェアなどの状態を常に記録し、異状や障害、不正、およびその徴候が無いかを常に監視する。データの複製保管(バックアップ)やソフトウェアの更新(アップデート)など、定期的に必要な保守作業も行う。

サービスの提供を妨げるシステム障害や外部からの攻撃などの事象が発生した場合には、監視システムや利用者の報告などによる事象の検知、原因究明や被害状況の把握、被害拡大を防止する応急処置の実施、関係者への連絡や調整、原状への復旧や再発防止のための対策などを行う。

また、システムの利用者(従業員)からの問い合わせや要望の受付、トラブル対応、システムに関する利用案内や変更点の告知など、社内の他部門に対する情報システム関連の窓口となるユーザーサポート、サービスデスク(ヘルプデスク)業務も重要である。

運用管理業務は社内の情報システム部門が担当することが多いが、定型的な業務を中心に外部の専門の事業者に委託(アウトソーシング)する場合もある。大企業などで、独自システムの開発を一括してシステムインテグレータ(SIer)などの専門事業者に発注している場合は、同じ事業者に引き続き運用業務を委託する例も多く見られる。

以前から図書館で目当ての本を(人力で)探す行為などを検索と呼んでいたが、コンピュータの発展や普及により、大量の情報を蓄積してプログラムによる自動処理で条件に合致する情報を探し出すことができるようになり、現代ではコンピュータで情報を探すことを検索と呼ぶことが多い。

例えば、インターネット上のWebサイトで公開されている情報を収集し、指定したキーワードに関連するサイトやページを一覧表示する「Web検索エンジン」や、コンピュータのストレージ内に格納されたファイルを索引付けし、条件に一致するものを探し出す「ファイル検索」などが馴染み深い。

コンピュータによる検索システムは、どのような情報を対象に、どのような条件で探すことができるかによって様々な種類に分かれる。文書などの文字データを対象とする文字列検索、画像データを対象とする画像検索、動画データを対象とする動画検索などである。

情報科学・コンピュータ科学などの分野では、データ集合の中から指定の条件に一致するものを探す処理のことを「探索」と呼ぶことが多い。「線形探索」や「二分探索」のように、対象をどのような手順で探すかを定義したものを「探索アルゴリズム」という。

英語では “search” “find” “retrieve” などが「検索」に近い意味を持つ。“retrieve”(名詞形はretrieval)には「探し出して実際に持ってくる」という意味がある一方、“search” や “find” には「あるかどうか調べる」「見つけたもの(の名前や所在など)を知らせる」といったニュアンスがある。コンピュータによる情報検索という文脈では “search” を検索に対応する概念とすることが多い。

IT分野では、ソフトウェア開発などに用いるバージョン管理システムやプロジェクト管理システムなどで、プロジェクトを構成するプログラムのソースコードやドキュメント、関連する各種のデータやファイルなどを一元的に管理する格納場所のことをリポジトリという。

特に、データそのものに加えて、版数(バージョン番号)や最終更新日時、更新履歴など「データについてのデータ」(メタデータ)を記録・管理し、複数人が共同で編集作業を行ってもデータを矛盾なく管理・共有できる仕組みを備えたシステムや保管場所のことを指すことが多い。

リポジトリを用いてデータを管理することで、同じデータの過去の特定時点の版を取り寄せたり、最新版と以前の版の違い(差分)を求めたり、新しい版を破棄して過去の版に差し戻すといった操作が容易になる。多人数での共同のプログラミングなどでは必須の管理方式となっている。

バージョン管理システムとリポジトリ

バージョン管理システム(VCS)の場合、CVSやSubversionなどの集中型システムでは単一の「中央リポジトリ」(central repository)に各利用者が接続して操作するが、GitやMercurialなどの分散型システムでは中央リポジトリの内容を各利用者の手元に複製した「ローカルリポジトリ」(local repository)に対して操作を行う。

オープンソースソフトウェアの開発に用いられるリポジトリなど、誰でも自由にアクセスできるようインターネット上で公開されているリポジトリを「パブリックリポジトリ」(public repository)、企業内のシステム開発など関係者のみがアクセス可能なものを「プライベートリポジトリ」(private repository)という。ネット上にはVCSの中央リポジトリの運用環境を貸与するGitHubなどのホスティングサービスもある。

システム管理ソフトなどのリポジトリ

機器やソフトウェア、システムなどを管理・操作するためのソフトウェアなどで、管理対象の設定や状態、属性に関するデータを一元的にまとめたファイルやデータベースなどのことをリポジトリということがある。特に、多数の対象を管理者が一元的に把握・管理するためのシステムで、データを統一的に扱うために用いられる仕組みを指すことが多い。

既存のデータを修正・更新する際に元のデータを直接上書きしてしまうと、後で誤りに気づいても以前の状態に戻すことができない。データ更新の際に誰が、いつ、どのように変更したのかを履歴として蓄積していれば、後から過去の任意の時点の状態に戻して修正し直すことができる。

また、ある版と別の時点の版を比較してどこがどのように変更されたのかを調べたり、複数人で共同作業する際に他の人の更新内容を上書きして消してしまうのを防いだりすることもできる。ある時点の版を元に本筋とは異なる変更、追加を行い、派生的な成果物を作ることも容易となる。

バージョン管理システム

バージョン管理を行うための専用のソフトウェアを「バージョン管理システム」(VCS：Version Contorol System)という。現代では単にバージョン管理という場合はデータをそのようなシステムに保存して管理することを意味することが多い。

ファイルシステムと同じように複数のファイルを階層的なディレクトリに整理でき、全体をまとめてプロジェクトとして管理することもできる。ファイルとその変更履歴やバージョン番号(リビジョン)などの管理情報は「リポジトリ」(repository)と呼ばれる一種のデータベースにまとめて集積される。

利用者はクライアントソフトを用いてリポジトリにアクセスし、あるファイルの最新版や過去の版を指定して取り出したり、編集した新しい版を登録することができる。変更履歴の流れをある時点を起点に分岐(フォーク)させて派生版を作成したり、再び元の流れに統合(マージ)することもできる。分岐した時系列を「ブランチ」(branch)という。

ネットワーク上に設置したサーバ上でリポジトリを運用すれば、離れた場所にいるメンバー同士が内容の整合性を保ちながら共同で編集作業を進めることができる。現代の大規模なソフトウェア開発には欠かせない仕組みとなっている。

日本の著作権法では、文書や画像、音楽、映像、ソフトウェアなどの著作物の複製については「複製権」という権利で保護されており、権利者に無断で、あるいは利用許諾契約などに定めた範囲を超えて複製することは違法となる。

違反すると権利者に損害賠償請求権が生じ、複製品を販売するなど悪質な場合は検挙され刑事罰が課されることもある。ただし、個人的に利用するために少数の複製を取ることは「私的複製」と呼ばれ合法となる。

ソフトウェアの違法コピー

IT分野で単に不正コピーと言った場合は、販売されているソフトウェア製品やゲームソフト、CDやDVD、Blu-ray Disc、インターネットなどで提供されるデジタルコンテンツを無断で複製すること、および無断で作成した複製を指すことが多い。

ソフトウェア製品の多くはパッケージや添付された文書などで利用許諾条件(ライセンス)を提示しており、例えば、一つのパッケージや一つの個体識別番号(シリアルナンバー)につき一台のコンピュータに導入(インストール)して使用可能といった制限が課されている。

これを守らずに、購入したライセンスで規定される台数を超える機器に導入して同時に使用したり、記録メディアの複製やインターネットを通じたデータ伝送などによって第三者に提供・販売するのは不正コピーとなる。違法な複製(海賊版)であることを知って入手したり使用することも違法となる。

デジタルデータは複製や伝送が容易なため、コンピュータやデジタル機器の普及でソフトウェアやコンテンツの不正コピーは大きな社会問題となっている。インターネット上での提供行為については権利者団体や警察などが積極的にパトロールや摘発を行っており、組織内での「使い回し」行為についてはBSA(The Software Alliance)が報奨金を用意して従業員の内部告発を奨励している。

既存のデータを修正・更新する際に元のデータを直接上書きしてしまうと、後で誤りに気づいても以前の状態に戻すことができない。データ更新の際に誰が、いつ、どのように変更したのかを履歴として蓄積していれば、後から過去の任意の時点の状態に戻して修正し直すことができる。

また、ある版と別の時点の版を比較してどこがどのように変更されたのかを調べたり、複数人で共同作業する際に他の人の更新内容を上書きして消してしまうのを防いだりすることもできる。ある時点の版を元に本筋とは異なる変更、追加を行い、派生的な成果物を作ることも容易となる。

バージョン管理システム

バージョン管理を行うための専用のソフトウェアを「バージョン管理システム」(VCS：Version Contorol System)という。現代では単にバージョン管理という場合はデータをそのようなシステムに保存して管理することを意味することが多い。

ファイルシステムと同じように複数のファイルを階層的なディレクトリに整理でき、全体をまとめてプロジェクトとして管理することもできる。ファイルとその変更履歴やバージョン番号(リビジョン)などの管理情報は「リポジトリ」(repository)と呼ばれる一種のデータベースにまとめて集積される。

利用者はクライアントソフトを用いてリポジトリにアクセスし、あるファイルの最新版や過去の版を指定して取り出したり、編集した新しい版を登録することができる。変更履歴の流れをある時点を起点に分岐(フォーク)させて派生版を作成したり、再び元の流れに統合(マージ)することもできる。分岐した時系列を「ブランチ」(branch)という。

ネットワーク上に設置したサーバ上でリポジトリを運用すれば、離れた場所にいるメンバー同士が内容の整合性を保ちながら共同で編集作業を進めることができる。現代の大規模なソフトウェア開発には欠かせない仕組みとなっている。

ITシステム全体を対象とする場合、システムを構成するサーバなどの機器(ハードウェア)や主要部品、OSやミドルウェア、アプリケーションなどのソフトウェア、商用ソフトウェアのライセンス、ネットワークの配線や配置、ソフトウェアやネットワークの設定情報などが管理対象となる。

これらを構成管理ツールなど専用のソフトウェアで台帳のようなデータベース(CMDB：Configuration Management Database)に記録し、個々の要素について識別情報や属性、状態、設定、変更履歴、要素感の関連などの情報を一元的に管理する。システムのどこにどのような要素があり、来歴や現状がどうなっているのかを素早く把握することができる。

こうした情報はシステムの現状把握や問題解決、改善などを行う際の基礎的な資料として活用できる。例えば、利用者からの要望の答えるためにどこにどのような機器を増強すべきか判断したり、障害発生時に影響範囲の特定や原因の調査を行ったり、商用ソフトウェアのライセンス違反を防止する際などに役立つ。

ITILなどに基づくITサービスマネジメントでは、ITサービス提供の最適化のために必要なプロセスの一つとして構成管理が重視される。インシデント管理、問題管理、変更管理など他の活動を効率的に行うための基礎としても、構成管理を通じてCMDBの構築と管理をしっかり行うことが重要となる。

ソフトウェア環境の構成管理では、OSや言語処理系、サーバソフトウェアなどの構成や設定をある種のコンピュータプログラムとして記述し、ツールを通じて自動的に適用する「IaC」(Infrastructure as Code)という仕組みが注目されている。同じ設定のサーバを多数用意する場合などに管理作業を自動化、効率化することができ、履歴の把握や変更の管理も容易になる。

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」が発行されている。

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

企業などが用いる大規模なソフトウェアは独自開発のソースコード群のみで成り立っているとは限らず、外部のモジュール、パッケージ、コンポーネント、ライブラリなどを組み合わせて構成されることが増えている。

これらは企業などが販売する有償の製品、オープンソースソフトウェアなどが混在し、それぞれ固有の使用・配布条件(ライセンス)を課していたり、さらに外部の別のモジュールなどの存在に依存しており、必ず一緒に導入しなければならないなど個別の事情がある。

ソフトウェアの開発や更新の際にこのような構成部品となるソフトウェア群の情報を専用のデータベースなどに記録し、開発元、バージョン、ライセンス、依存関係などを後から簡単に一覧、参照できるようにするのがSBOMの考え方である。

近年では広く普及したオープンソースのライブラリなどに深刻なゼロデイ脆弱性が発見されたり、悪意のあるコードの混入や差し替えなどの事象が発生した際に、企業や官公庁が自らの情報システムに含まれるかどうかを即座に判断できず対応が遅れる事例が報告されており、SBOM整備の必要性が叫ばれている。

システムへの変更が野放図に行われることでサービスの提供に支障が生じたり、無計画なサービスの中断が起きることを防ぎ、停止時間(ダウンタイム)の最小化、サービス品質の安定、変更に伴うリスクの管理を可能とする。

変更管理の対象は分野や業務により様々だが、ITシステムの場合にはオペレーティングシステム(OS)やアプリケーションソフトの新規導入やアップデート、機器や配線などの増設や交換、撤去、移動、組織体制の変更や担当者の異動、担当業務の変更、業務運用の見直しなどがある。ソフトウェアやシステムの導入については「リリース管理」「デプロイ管理」などとして別に管理することもある。

既存のデータを修正・更新する際に元のデータを直接上書きしてしまうと、後で誤りに気づいても以前の状態に戻すことができない。データ更新の際に誰が、いつ、どのように変更したのかを履歴として蓄積していれば、後から過去の任意の時点の状態に戻して修正し直すことができる。

また、ある版と別の時点の版を比較してどこがどのように変更されたのかを調べたり、複数人で共同作業する際に他の人の更新内容を上書きして消してしまうのを防いだりすることもできる。ある時点の版を元に本筋とは異なる変更、追加を行い、派生的な成果物を作ることも容易となる。

バージョン管理システム

バージョン管理を行うための専用のソフトウェアを「バージョン管理システム」(VCS：Version Contorol System)という。現代では単にバージョン管理という場合はデータをそのようなシステムに保存して管理することを意味することが多い。

ファイルシステムと同じように複数のファイルを階層的なディレクトリに整理でき、全体をまとめてプロジェクトとして管理することもできる。ファイルとその変更履歴やバージョン番号(リビジョン)などの管理情報は「リポジトリ」(repository)と呼ばれる一種のデータベースにまとめて集積される。

利用者はクライアントソフトを用いてリポジトリにアクセスし、あるファイルの最新版や過去の版を指定して取り出したり、編集した新しい版を登録することができる。変更履歴の流れをある時点を起点に分岐(フォーク)させて派生版を作成したり、再び元の流れに統合(マージ)することもできる。分岐した時系列を「ブランチ」(branch)という。

ネットワーク上に設置したサーバ上でリポジトリを運用すれば、離れた場所にいるメンバー同士が内容の整合性を保ちながら共同で編集作業を進めることができる。現代の大規模なソフトウェア開発には欠かせない仕組みとなっている。