怒りの構成管理ツイートまとめ

ますごん @ymasuda_

構成管理大事。この重要さ、何を管理するかわかってない人が、経験が10年を超えるエンジニアに、そこそこいることに驚愕し、辟易してる。

ますごん @ymasuda_

@ymasuda_ 構成管理のスタートは仕様の管理から。システムは厳密なもので、仕様に矛盾があると、まともに動かない。起動すら、いやコンパイルすら通らないかもしれない。

ますごん @ymasuda_

@ymasuda_ そして、 仕様は発注側・開発側の両方の都合で常に変わる。どちらかというと、開発側は矛盾を正すために変える、か。

ますごん @ymasuda_

@ymasuda_ この変更の基点になる整合性の取れた仕様をベースラインと呼ぶ。変わり続ける仕様の静止点となる。ベースラインは動く。単なる変更の基点（ベースライン）に過ぎない。

ますごん @ymasuda_

@ymasuda_ 変更は、むやみやたらに入れられるものではない。整合性を取りながら取り込んでいかなければならない。なので、開発進行上の都合で、先に発生した変更要求でも取り込めないこともあれば、後から発生した変更要求を先に取り込まなければ、開発が進められない場合がある。

ますごん @ymasuda_

@ymasuda_ どの変更を取り込んで、どの変更を取り込んでないのか、というのを管理するのが変更管理。 繰り返しになるが一つ一つの変更は、システム全体の仕様が整合するように取り込むのが前提です。

ますごん @ymasuda_

@ymasuda_ 変更を取り込んだ一つ一つの仕様の状態をバージョンと呼ぶ。バージョンごとの成果物の状態を管理しているのがバージョン管理。

ますごん @ymasuda_

@ymasuda_ バージョン管理はファイルサーバー上のファイル名やディレクトリ名で管理する場合もあるが、Git や Subversion などの VCS --- Versions Control System --- を使うのが一般的。

ますごん @ymasuda_

@ymasuda_ 構成管理は、ベースライン管理（仕様管理）、変更管理、バージョン管理の三位一体で意味を成す。どれか一つが欠けると、瞬く間に破綻する。

ますごん @ymasuda_

@ymasuda_ ということを、職場のメンバーに小一時間説明したい。

ますごん @ymasuda_

@ymasuda_ ちょっと、ここから派生して、アジャイル開発だと、、、 という部分も考えてみる。 当然、アジャイルであっても構成管理は必要。どうやるかっていうと、チケット単位なのかなぁ。

ますごん @ymasuda_

@ymasuda_ チケットで整合性とれるように変更しようとすると、縦割り（機能ごとの担当制）だと難しいので、XP で言われた 「コードの共同所有」 というのは必要そう。 でも、あまり詳しくない機能を直したときの品質保証は、ユニットテストがあるのとないのでハードル高さは全然違う。

ますごん @ymasuda_

@ymasuda_ 機械的に、コンパイルと、ユニットテストがあれば ユニットテストが常に実行されてるというのは、「整合性取れてるよね」の確認出来てうれしい。

ますごん @ymasuda_

@ymasuda_ しかし、こういった仕組みは、あくまでも コードレベルの整合性でしかない。仕様との整合性はユニットテスト？文書とコードの整合性は？ とか考え出すと、文書はやっぱり極力少ない方がいい、ってのも頷ける。

りょーへい｜新米部長の組織変革ストーリー @ryohei_nakazawa

@ymasuda_ いろいろな切り口での整理があるが、ベースラインや構成管理の考え方はその通りなので、小一時間といわず、ガンガンやってほしいwww アジャイル以前の話については、どうやったら新人にも分かるか、を考えたいものだ。

りょーへい｜新米部長の組織変革ストーリー @ryohei_nakazawa

@ymasuda_ 以前、仕様書と設計書の話があったが、自然言語レベルで理解するさいに、その背景となる言葉の定義や整理って重要で、この三位一体は否定しないが、少しは違和感があるのも事実。間違ってはないと思う。

りょーへい｜新米部長の組織変革ストーリー @ryohei_nakazawa

@ymasuda_ 物事を抽象化して理解する力って、設計時のモデリングする力にも通じるところがある。この辺の話をするときに、プログラミングはとってもよい題材なんだよねぇ～ この辺の思考力を鍛えたいものです。自分も含めて。

りょーへい｜新米部長の組織変革ストーリー @ryohei_nakazawa

@ymasuda_ アジャイルの例の流れにひとつレス。コード間の整合性と、仕様との整合性は論理的には分けてテストしたほうがよいかも。これってUnitテストのテストケース考えるときにも言えそう。勝手レスはいじょwww

ますごん @ymasuda_

@ryohei_nakazawa 違和感、気になるｗ。 言葉の定義、使い方 をコンセンサス取りながら議論していくのは、かなり難しいけど、そういうことを地道にしていくことで 使える形式知 になっていくんだと思っている。雰囲気でわかった気になって、全然 わかり会えてないことよくある。

りょーへい｜新米部長の組織変革ストーリー @ryohei_nakazawa

@ymasuda_ 「雰囲気で分かった気」になっちゃうよね、特に日本人同士w　その感覚って大事なんだけど、ズレていることに気づかなかったフリして、話を進めちゃうとお互い辛いんだなぁぁぁぁぁぁぁぁqあwせdrftgyふじこlp

ますごん @ymasuda_

@ryohei_nakazawa Wikipediaを斜め読みして概要の内容を俺の理解と対比してみた。構成識別＝ベースライン管理、構成制御＝変更管理、構成現況記録＝バージョン管理って感じかな。これらの言葉のなんとわかりにくいことよ。ja.wikipedia.org/wiki/%E6%A7%8B…

りょーへい｜新米部長の組織変革ストーリー @ryohei_nakazawa

@ymasuda_ ちなみにﾌﾛｼﾞｪｸﾄﾏﾈｼﾞﾒﾝﾄに○○管理って、たくさんあるけど、ｼｴｽｴｽﾋﾟ2には、進捗管理、リスク管理、課題管理、要求管理、変更管理、構成管理が標準化されてて。他にもあるけど。 で、今回の話は、

りょーへい｜新米部長の組織変革ストーリー @ryohei_nakazawa

@ymasuda_ 要求管理（仕様のベースライン化・トレーサビリティ）と、変更管理（ベースラインに対する変更を管理・成果物個々のバージョン管理含む）を構成管理が包含しているって感じかな。Wikipediaのまとめだけだと、他の分野とのつながりを考えるとイマイチかなぁ・・・

りょーへい｜新米部長の組織変革ストーリー @ryohei_nakazawa

@ymasuda_ この辺がすっきりしていると、SCRUMでもTiDDでもやることの整理がしやすいとおもわれ。

ますごん @ymasuda_

@ryohei_nakazawa そんな感じだな。正直、要求管理ってのが昔から理解しにくい。仕様が目の前にあるので、仕様を管理って方がしっくりくる。もちろん仕様の源泉は要求だということはわかってるんだが、要求だと抽象的すぎで、管理があいまいになりそうな気がして。俺の思い過ごしか。