ソフトウェア開発管理技術
同じソフトウェアでも、要件の固まり方によって向く進め方が変わります。作ったものの版を管理し、他人の権利を使うときは許諾の範囲を守る。その管理の方法をまとめた単元です。
要点
開発プロセス・手法
- ソフトウェア開発モデル
- ウォーターフォールモデルは要件定義から順に工程を進め、前の工程に戻らない前提で計画する。
- 試作を見せて要求を固めるのがプロトタイピングモデル。要件を先に決め、機能を分けて順に作って出すのが段階的モデル。
- 作りながら要件を育て、改良を繰り返すのが進展的モデル。共通の部品から製品群を作るのがソフトウェアプロダクトライン。
- 機械学習のモデルの開発と運用を回し続けるのがMLOps。
- アジャイル
- 短い期間で動くものを作り、変化に合わせて計画を直す進め方。考え方はアジャイルソフトウェア開発宣言と12の原則にある。
- 期間ごとのふりかえり（レトロスペクティブ）を、続けること・問題・試すことのKPTで整理する。全員で1つの作業をするのがモブプログラミング。
- XP
- XP（エクストリームプログラミング）は、テストを先に書くテスト駆動開発、2人で書くペアプログラミング、リファクタリングを重んじる。
- コードは全員のもの（共同所有）。継続的インテグレーションで頻繁に統合し、今要らない機能は作らない（YAGNI）。
- スクラム
- 何を作るかに責任を持つプロダクトオーナー、進め方を支えるスクラムマスター、作る開発者でチームを組む。
- 数週間以内のスプリントを繰り返す。要求の一覧がプロダクトバックログ、そのスプリントでやる分がスプリントバックログ。
- DevOps
- 開発と運用が協力して早く確実に届ける。テスト済みの変更をいつでも出せる状態に保つのが継続的デリバリー、本番まで自動で出すのが継続的デプロイ。
- わざと障害を起こして強さを確かめるカオスエンジニアリング、安全も組み込むDevSecOps、信頼性を技術で保つSRE。
- ローコード／ノーコード開発
- 画面の操作で部品を組み合わせて作る。早く作れるが、複雑な処理は苦手で、特定の製品に縛られやすい。
- ソフトウェア再利用
- 再利用される前提で部品を設計する。モジュールの独立性と標準化が要る。パッケージは必要な分だけカスタマイズする。
- リバースエンジニアリング
- 既存のソフトウェアを解析して仕様を得る。結果を使って無断で製品を作り売ると、知的財産権の侵害になるおそれがある。
- 利用許諾契約で禁止されていることもある。関数の呼び出し関係を図にしたのがコールグラフ。
- マッシュアップ
- 複数の提供元のAPIを組み合わせて新しいサービスを作る。早く作れるが、提供元の停止や仕様変更の影響を受ける。
- モバイルアプリ開発
- 端末に入れるネイティブアプリ、ブラウザで動くWebアプリ、その中間のハイブリッドアプリ、インストールできるWebアプリのPWA。
- カメラなどを使うときはパーミッション要求で許可を得る。ストアで配るにはアプリの審査を通す。
- 構造化手法
- 大きな処理を段階的詳細化で階層に分ける。構造化チャート・HIPO・DFD・状態遷移図で表し、保守しやすくする。
- 形式手法
- 仕様を自然言語ではなく形式仕様記述言語で厳密に書き、あいまいさを除いて品質を上げる（例：VDM）。
- 開発プロセス
- 作業の範囲と用語を共通にする枠組みがSLCP（JIS X 0160）。日本向けにまとめたのが共通フレーム（SLCP-JCF）。
- 組織のプロセスの成熟度を段階で評価し、改善に使うのがCMMI。
知的財産適用管理
- 著作権管理
- プログラムは著作物。会社の指示で業務として作り会社名義で公表するものは、会社が著作者になる（職務著作）。
- 外部に開発を委託した場合、契約で決めないと、著作権は作った側（受託者）に残る。
- 特許管理
- 開発で生まれた発明は特許権で守る。設定した範囲を独占させるのが専用実施権で、その範囲では特許権者も実施できない。
- 通常実施権は使ってよいという許諾で、同じ範囲を複数の相手に許諾できる。
- ライセンス管理
- 使用を許諾する側がライセンサー、受ける側がライセンシー。契約を超える台数や人数で使わないように管理する。
- 技術的保護
- 複製を防ぐコピーガード、利用を制御するDRM、正規の利用者かを認証させるアクティベーション、記録媒体向けのCPRM。
開発環境管理
- 開発環境構築
- 開発用の機器・ツール・ネットワーク・シミュレータを要件に合わせて用意する。本番に近い検証用の場所がステージング環境。
- 開発環境稼働状況管理
- コンピュータ資源や開発支援ツールの稼働状況をつかみ、足りなくならないように管理する。
- 設計データ管理
- 設計データをリポジトリに集め、更新履歴とアクセス権を管理する。機密を含むものは、誰がいつ使ったかまで記録する。
- ツール管理
- ツールの種類やバージョンが人によって違うと互換性の問題が出る。使うツールとバージョンをそろえる。
- ライセンス管理（開発環境）
- インストール数と保有ライセンス数を定期的に照合する（棚卸）。不正コピーは違法で、処罰の対象になる。
構成管理・変更管理
- 構成管理
- ソフトウェアがどの構成品目の組み合わせでできているかを識別し、構成管理計画に沿って管理する。
- 使っている部品とその版の一覧がSBOM。部品に脆弱性が見つかったとき、影響する製品をすぐ探せる。
- 構成状況の記録
- 基準にした構成品目について、変更の回数・最新の版・移行の状況を記録する。
- 構成品目の完全性保証
- 中身が正しくそろい、構成品目どうしが食い違わない（一貫性・正確性）ことを確かめる。
- リリース管理と出荷
- 完全性を確かめてから新しい版を出荷する。コードと文書はバージョン管理し、決めた保管期間のあいだ保守する。
さわって確かめる
開発モデルの選び方、ブランチとマージ、知的財産の仕分けを、次の3つで試します。
1. 状況に合う開発モデルを選ぶ
4つの状況それぞれに向く開発モデルを選び、「答え合わせ」を押そう。
- 法律で計算方法が細かく決まった給与計算システム。要件は途中で変わらず、工程ごとに承認を取って進めたい。
- 利用者が完成した画面を想像できず、要求がはっきりしない。早めに試作を見せて意見を集めたい。
- 要件は最初に全部決まっている。受付の機能を先に使い始め、集計の機能は後から順に追加して出したい。
- 新しいサービスで、利用者の反応を見ながら優先順位を毎回見直し、2週間ごとに動くものを出したい。
2. ブランチとマージで履歴が伸びる
feature ブランチを作って2回コミットし、main に戻って1回コミットしてからマージし、main からたどれるコミットの数を数えよう。
上の段が main、下の段が feature。数字はコミットの順番、二重の円はマージコミット。HEAD は今いるブランチの最新のコミット。
3. 著作権・特許・ライセンスの場面を仕分ける
5つの場面がどれに当たるかを選び、「答え合わせ」を押そう。
- 社員が会社の指示で業務として作り、会社の名前で公開したプログラム。著作者は会社になる。
- 特許発明を、決めた範囲ではA社だけが実施できるようにした。特許権者自身もその範囲では実施しない。
- 同じ特許を、B社にもC社にも使ってよいと許諾した。
- 10台分のライセンス契約なのに、棚卸をしたら15台にインストールされていた。
- 起動するとネットワークでライセンスキーを確かめ、登録した1台のPCでしか使えないようにした。
3問チェック
最初に選んだ答えで採点します。全問正解で、この単元に「済み」の印が付きます。
-
スクラムで、プロダクトバックログの項目に優先順位を付け、何を作るかに責任を持つ役割はどれか。
- スクラムマスター
- プロダクトオーナー
- 開発者
- モデレーター
答えと解説
正解はイ。スクラムマスターはチームがスクラムをうまく進められるよう支える役、開発者はスプリントで実際に作る人。モデレーターはインスペクション（レビュー）の進行役で、スクラムの役割ではない。
-
特許権を持つX社が、Y社に専用実施権を設定した。設定した範囲の中について、正しいものはどれか。
- X社とY社の両方が、自由に実施できる
- X社は、Z社にも同じ範囲の通常実施権を許諾できる
- Y社だけが実施でき、X社も実施できない
- 特許権そのものがY社に移る
答えと解説
正解はウ。専用実施権は設定した範囲を独占させる権利で、その範囲では特許権者のX社も実施できず、他社に許諾することもできない。特許権そのものはX社に残るので、エも誤り。アは通常実施権を許諾した場合の様子。
-
最初のコミット1つだけがある main から feature ブランチを作り、feature で2回、main で1回コミットした。その後 feature を main にマージし、マージコミットを1つ作った。main からたどれるコミットは、最初のコミットを含めていくつか。
- 3個
- 4個
- 5個
- 6個
答えと解説
正解はウ。最初の1個、feature の2個、main の1個、マージコミット1個で5個。マージコミットは親を2つ持つので、feature 側のコミットも main からたどれる。3個は feature の分を数えていない、4個はマージコミットを数えていない値。ブランチを作るだけではコミットは増えないので6個にはならない。