アート・オブ・アジャイル デベロップメント 社内読書会＃６
６章 協力すること
６−１ 信頼
チームの組織進化
フォーミング（形成期） → ストーミング（騒乱期） → ノーミング（標準期） → パフォーミング（成熟期） → アジャーニング（散会期）
「私たち対彼ら」のギスギス
顧客⇔プログラマ(PG)
- 顧客→PG「ニーズや締め切りへの配慮が足りない。」
- PG→顧客「達成できないような約束をさせて、健康と人間関係を傷つけている」これはちょっと言い過ぎな気が・・・
同じようにプログラマ⇔テスターの間にも「私たち対彼ら」という考え方が起こることがある。
印象が悪い
XPチームはたとえ仕事がうまく行っていても、XPを知らない人から非難の目で見られることがある。
おしゃべりばかりしてるように見える。定時で帰る。→「本当に仕事してるのか？」
ステークホルダーに正しく評価してもらって信頼を得る必要がある。
- 頑張りを見せる
- 約束を果たす
- 問題を管理する
- 顧客の目標を尊重する
- チームを宣伝する
- 正直になる
６−２ 全員同席
人の距離が遠いと誤解が生まれ、遅延が紛れ込み、質問の答えを待つ前に推測をし始め、間違いが起こる。
全員同席によってそういったムダをなくすことによって、生産性が劇的に向上する。
まずはオープンな仕事場を作ることから。
浸透するコミュニケーション(osmotic communication)
人は自分の会話に集中していても、脳は部屋の会話すべてに注意を払っている。
周囲の会話が耳に入ってくることによって他の人が即座に返事をくれたりする。
６−３ 真の顧客の参加
顧客とエンドユーザの目標と不満を理解する。
誰のためのソフトウェアか。
| 種類 | 真の顧客 |
|---|---|
| 個人的な開発 | 自分 |
| 社内カスタム開発 | スポンサー、エンドユーザ |
| 外注カスタム開発 | 同席は無理なら自分達が出向いてみよう。 |
| 特定業種向けソフトウェア | 顧客のニーズを把握しているプロダクトマネージャを抜擢。顧客とのレビュー会も設ける。 |
| 汎用ソフトウェア | 顧客のニーズを把握しているプロダクトマネージャを抜擢。 |
６−４ ユビキタス言語
プログラマは必ずしも書いているソフトウェアの分野の専門家ではない。逆も然り。
２つの立場の人々がそれぞれ別の言語で話せば、情報が正確に伝わらない可能性がある。
同じ言語を話す方法
プログラマがドメイン専門家の言語を話すべきである。
所感
確かに日本語と英語が混在する名前はダサいと思うけど、それにこだわって名前で混乱して生産性を低下させるのは良くない。
慣習には良いものと悪いものがある。その悪い方の慣習について"やっぱり悪い"ということを読書会メンバーとの話し合いで確認できた。
メモ：
ドメイン駆動設計・ドメインモデリング。
