こんにちは、赤坂です。
安井 <yasui@....jp> san wrote:
> 訓練はわかりませんが、わたしの周囲ではコミュニケーションに
> よって実現している、と思います。参考になるか分かりませんが、
> わたしの周囲でのやりかたを紹介します。
安井さん、どうもありがとうございます。とても参考になります。
> 変更をラクにするためにどうするか？という観点から、
>
> ・まず、常に設計を複数人が把握している。
> ・「ほげほげクラス」と言えばイメージがだいたい一致できる程度
> に、クラスの責務を明確にしておく。
> ・クラスの責務はコーディング中に、メンバー間でイメージを共有
> しながら、洗練していく。
複数人が設計を共有し把握しているのはとても良いことですね。
だからこそ、のペア(ピアレビューの実践)ですよね。
> 設計はホワイトボードで相談しながらおおざっぱに決めて、コー
> ディングに入ってしまいます。コーディング中に出てくる疑問・問
> 題は、その場で相談して考えます。「この処理ってどのクラスに持
> たせようか？」と考え相談することで、徐々に「自然な分割」に
> なっていくように思います。
> メンバーが「これが自然だ」と感じるのがよい設計だという、ニ
> ワトリと卵みたいな話ではありますね。実際には誰かがリーダー
> シップを取ってアーキテクチャ部分を設計してしまうことも多いで
> すが、コーディングをしながら、より良い形になりつつ、メンバー
> の認識も統一されていきます。
> 要は、人によって微妙に違う「自然さ」を、コミュニケーション
> によってより一般的な形に洗練させていくというやり方、だと考え
> ています。チーム全体で身につける、と言ってもいいかも。
なるほど、なるほど。
安井さんのチームメンバー同志の信頼関係は問題ないとお見受けしました。
もし仮にメンバーの力関係に大きな差があると、
「力の強い人が自然と感じるモデル」がチームのモデル
になってしまう危険性もあるのかなぁと思います。
僕のところでは(力関係は微妙(^^;;)、僕をふくめ同僚それぞれが、
それぞれの「自然な役割分担」感を持っていて、
その調整が大変になることも（ほんのたまにですが）あります。
# 私は(懐が深いので?)簡単に折れる方です(^^;;
> # 書いてて、とてもすばらしいチームだ！という気がしてきま
> # したが、実際にはそんなにスムーズには進みません (^^;
> # 認識のズレや勘違いはしょっちゅうだし。作業を分担してひ
> # とりずつで設計・コーディングをしていると、全体に品質が
> # 落ちてくるし。
いつも意見が一致する必要は全然ないと思います。
品質に関しては、チームが間違った方向に進んでないか、
コミュニケーションで見えている範囲が妥当になっているか、
などをチェックしてくれるコーチがいると助かりますよね。
> 問いの「ソースコードのみで」という部分は、「否」です。ペア
> プロ中なら空中や紙に、何人かいればホワイトボードにクラス図や
> コラボレーション図やよくわからない図(笑)を書いて議論します。
> モデルをつねに頭に描きながら考える人もいれば、ソースコードを
> 中心に考える人もいる、というのが現実のようです。
それを聞いて安心しました。
> なお、今のプロジェクトは制御的な(ミドルウェア的な)ものなの
> で、業務システムだとまたやり方が変わってくるだろうとは思います。
データよりも制御のタイミングが中心になるシステムということですか。
規模が小さく、メンバー全員が全体構成を掴んでいるという感じでしょうか。
私は経験がありませんが、（話題のコンテキストが変わります）
もしかするとWebシステムのような場合、
アーキテクチャが割と固定されて(共通認識が得られて)いて、
システム開発上のリスクが少なかったりするのかもしれませんね。
その場合には、ほとんどテスト＆コードだけでOKなのかも知れません。
# 本当のところは全然知らないです。
Webシステム関係の方 いかがなものでしょうか？
以上です。
--
(株)オージス総研
赤坂 英彦 (Hidehiko AKASAKA)
akasaka@....jp