技術者間で利用される3つの言語

技術者間でコミュニケーションを行う場合、主に以下の3言語が利用される。

言語	内容
自然言語(natural language)	一般に人々が利用する言語
プログラミング言語(programming language)	プログラムのソースコードとなる言語
モデリング言語(modeling language)	プログラム構造を端的に表現する言語(図)

UML(Unified Modeling Language)

参考1: UML入門
 参考2: UML
統一モデリング言語とも呼ばれるUMLは、オブジェクト指向言語の設計図となるモデリング言語の「標準規格」となっており、以下の13種類に分類される。

分類	名称	描画内容
構造図	クラス図(class diagram)	クラス
	オブジェクト図(object diagram)	インスタンス
	パッケージ図(package diagram)	パッケージ
	コンポーネント図(component diagram)	コンポーネント
	コンポジット構造図(composite structure diagram)	システム(ソフトウェア)
	配置図(deployment diagram)	システム(ハードウェア)
相互作用図 (振る舞い図)	シーケンス図(sequence diagram)	オブジェクト・処理(時間的)
	コミュニケーション図(communication diagram)	オブジェクト・処理(体系的)
	タイミング図(timing diagram)	ライフサイクル
	相互作用概要図(interaction overview diagram)	相互作用図
振る舞い図	アクティビティ図(activity diagram)	処理
	ステートマシン図(state machine diagram)	オブジェクト
	ユースケース図(use case diagram)	システム化対象領域

クラス図

クラス図は、「クラス定義」や「クラス間の関連性」など、クラス構造を表す。

Class.wsd

@startuml
    ' メンバのアクセス修飾子
    ' +: public
    ' #: protected
    ' ~: package private(デフォルトアクセス)
    ' -: private
    interface CreatureMove {
        void move()
    }
    class Creature {
        -Belongings belongings
        +void move()
    }
    class Hero {
        -Pokedex pokedex
        -Party party
        +void fight()
        +void shopping()
    }
    class Party {
        +Hero hero
        #Pokemon pokemon1
        #Pokemon pokemon2
        #Pokemon pokemon3
    }
    class Pokemon {
        -String name
        +void attack()
        +void defend()
    }
    class PokemonCenter {
        +void heal()
    }
    class PokeLot {
        +void draw()
    }

    ' CreatureはCreatureMoveを実現(realization)
    CreatureMove <|.. Creature
    ' Hero,PokemonはCreatureを汎化(generalization)
    ' -> Creature1体に対してHero, Pokemonは1体
    Creature "1" <|-- "1" Hero
    Creature "1" <|-- "1" Pokemon
    ' HeroはPartyのコンポジション(composition)
    ' Party1つに対してHeroは1人
    Party "1" *-- "1" Hero
    ' PokemonはPartyに集約(aggregation)
    ' Party1つに対してPokemonは1匹以上6匹以下
    Party "1" o-- "1..6" Pokemon
    ' PokemonはPokemonCenterに依存
    PokemonCenter <.. Pokemon
    ' PokemonCenterとPokeLotは関連(association)
    ' PokemonCenter1箇所に対してPokeLotは1箇所
    PokemonCenter "1" -- "1" PokeLot
@enduml

クラス間相互関係

クラス間相互関係を表す用語は、以下の通り。

関係	内容
関連(association)	結びつき
集約(aggregation)	構成
コンポジション(composition)	強い集約(双方が依存)
依存(dependency)	片方に依存
汎化(generalization)	is-A関係
実現(realization)	実装

シーケンス図

シーケンス図は、「オブジェクト間のメッセージのやり取り」を時系列に沿って表す。
また、時系列の中でのイベント状態をライフライン上で表す。

Sequence.wsd

@startuml
    Hero -> Balbasaur : "summon"
    activate Balbasaur
    Opponent -> Charmander : "summon"
    activate Charmander
    Balbasaur -> Charmander : "Solar Beam"
    Balbasaur <-- Charmander : "Decreased HP by Solar Beam"
    Balbasaur <- Charmander : "Flamethrower"
    Balbasaur --> Charmander : "Decreased HP by Flamethrower"
    ...5 minutes later...
    Balbasaur <- Charmander : "Flamethrower"
    Balbasaur --> Charmander : "Decreased HP by Flamethrower"
    Balbasaur -> Hero  : <<sendLose>>
    Balbasaur <-- Hero : <<responseOK>>
    deactivate Balbasaur
    Charmander -> Opponent : <<sendWin>>
    Charmander <-- Opponent : <<responseOK>>
    deactivate Charmander
@enduml

ユースケース図

ユースケース図は「要件定義」の工程で利用され、「システム化対象領域」を表す。

UseCase.wsd

@startuml
    actor User
    rectangle requirement as "requirement definition" {
        usecase save
        usecase load
        usecase quit
    }
    actor FileServer

    User -- save
    User -- load
    User -- quit

    FileServer -- save
    FileServer -- load
@enduml

開発プロセス

主な開発プロセスは、以下の3種類。

開発プロセス	内容
ウォーターフォール型(water-fall model)	各工程を終えてから次の工程に進む手法
スパイラル型(spiral model)	各工程を繰り返して行い、最後にリリースを行う手法
アジャイル型(agile model)	各工程を短期間で繰り返して行い、何度もリリースを行う手法

また、アジャイル開発は**XP(eXtreme Programming)とスクラム(scrum)**に分類される。

エクストリーム・プログラミング(XP)

参考1: Extreme Programming(XP)
参考2: Extreme Programming
XPで定義された、開発者に必要な「5つの価値観」と「19のプラクティス」は、以下の通り。

価値観	内容
コミュニケーション(communication)	プロジェクトメンバー間での円滑なコミュニケーションを行う
簡潔性(simplicity)	無駄を省くことで保守性を高める
フィードバック(feedback)	改善と実践(プラクティス)を繰り返す
勇気(courage)	進捗・不具合・仕様変更に対して柔軟に対応する
尊重(respect)	プロジェクトメンバーを尊重したフィードバックを行う

分類	プラクティス	内容
共同(joint)	反復(iterations)	フィードバックに対する改善の反復
	共通語(common vocabulary)	理解の共有
	オープンな作業空間(open workspace)	コミュニケーションの円滑な職場
	振り返り(retrospectives)	定期的なフィードバック
開発(development)	テスト駆動開発(test-driven development)	要件を満たすテスト主導の開発
	ペアプログラミング(pair programming)	ドライバー役とナビゲーター役のペア開発
	リファクタリング(refactoring)	ソースコードの改善
	ソースコードの共同所有(collective ownership)	メンバー全員がコードの責任者
	継続的インテグレーション(CI; continuous integration)	ビルドとテスト(=統合)の短期的な反復
	YAGNI	シンプルな実装(You Aren't Going to Need It.)
管理(management)	責任の受け入れ(accepted responsibility)	メンバー主体でのチーム開発
	支援(air cover)	継続的なメンバーへの支援
	四半期ごとの見直し(quarterly review)	定期的な必要事項の精査
	ミラー(mirror)	課題発見、メンバーへの提案・鼓舞
	持続可能な進度(sustainable pace)	適切な開発ペース
顧客(customer)	要件の精査(storytelling)	反復可能な要件量
	リリース計画(release planning)	機能の順序付け
	受け入れテスト(acceptance tests)	プログラム完成後の迅速な受け入れテスト
	小規模リリース(frequent releases)	プログラムの段階的改良

スクラム(scrum)

スクラムで定義された、プロジェクトメンバーの「3つの役割」「3つのリスト」「4つのミーティング」は、以下の通り。

役割	内容
プロダクトオーナー(PO; product owner)	「製品としての成果」を求める、製品に関する最終責任者
スクラムマスター(SM; scrum master)	「チームの成長」を求める、開発チームの管理者
開発メンバー	デザイナーやテスターを含む、開発を行うメンバー

リスト	所有者	内容
プロダクトバックログ(product backlog)	プロダクトオーナー	要件・機能を優先度順に箇条書きしたリスト
スプリントバックログ(sprint backlog)	開発メンバー	要件・機能ごとの進捗状況を記述した表
障害リスト(impediment list)	スクラムマスター	開発中のあらゆる障害を懸念度順に箇条書きしたリスト

ミーティング	スプリント内での実施タイミング	内容
スプリント計画ミーティング	最初の1回	スプリントバックログの策定
デイリースクラム	毎日	進捗状況・問題点の共有
スプリントレビュー	最後の1回	顧客による評価・フィードバック
スプリントレトロスペクティブ	スプリントレビューの直後	今期スプリントの振り返り次期スプリントでのチーム方針の策定

デイリースクラムのプラクティス

デイリースクラムにおける「3つのプラクティス」は、以下の通り

1回につき15分以内

→ デイリースクラムの目的は「迅速な情報共有」

割り込み・議論(質問)の禁止

→ デイリースクラムが長引く原因の排除

全員への共有

→ 「自己組織化」されたチームへの昇華

用語集

用語	内容
バージョン管理システム(VCS; Version Control System)	ソースコードの変更を管理するシステム。ソフトウェア構成管理(SCM; Software Configuration Management)とも呼ばれる。
レポジトリ(repository)	ファイルの格納場所。
フォーク(fork)	他人のリモートリポジトリを自分のリモートリポジトリとして`clone`すること。
プルリクエスト(pull request)	フォーク先ライブラリの変更点をフォーク元ライブラリに`pull`するよう依頼すること。
非機能要件(non-functional requirement)	ユースケース図では表現できない、性能・耐障害性・セキュリティなどの要件。
マイクロサービスアーキテクチャ(micro service architecture)	小規模システムを連携させて稼働させるサービス構造。
WBS(Work Breakdown Structure)	プロジェクト計画と進捗状況を記述する資料。
懸案権利表	計画外の状況・課題をリストアップした資料。
アジャイルソフトウェア開発手法(agile software development method)	「アジャイル」をベースとした開発手法。
イテレーション(iteration)	アジャイル開発における1回の工程反復期間。「スプリント(sprint)」とも呼ばれる。
スプリント(sprint)	一般的に「2~4週間程度」の開発周期。
自己組織化(self-organization)	メンバー全員を「リーダー」として主体的に行動すること。
ビルドパイプライン(build pipeline)	「コンパイル→テスト→カバレッジ計測→Javadoc生成→アーカイブ処理」の一連の作業。
継続的デリバリー(CD; Continuous Delivery)	高頻度かつ継続的にリリースすること。
継続的デプロイメント(CD; Continuous Deployment)	自動的・継続的・高頻度でデプロイを行うこと。
ビルドエージェント(build agent)	レポジトリに変更があった際に自動でビルドパイプラインの実行(CI)を行う開発支援ツール。
CI/CD	「継続的インテグレーション(CI)」と「継続的デプロイメント(CD)」を併せて実施すること。