進め、現場のチーム開発〜チーム開発実践入門〜 (DevLOVE関西Ver) 参加してきた

進め、現場のチーム開発〜チーム開発実践入門〜 (DevLOVE関西Ver) - DevLOVE関西 | Doorkeeper

勉強会などはブログに感想などを書くまでが勉強会（ｒｙ、などと言われるのでざっくり感想を書いてみようかと。

運悪く台風が近づいているという日であったので、予定されていた予定されていたセッションが全て行われず、池田さんのセッションとチーム開発よろず相談部屋のみで短時間でしたが有意義な時間だったと思います。今回初参加だったのですが、非常におもしろかったですね。

チーム開発をスムーズにするために何ができるか、してきたか

池田さんのセッションは、細かいところはチーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)を読もう！という感想になるのだけど、何を考えて改善してきたということを丁寧に話されていた印象。

そもそもチーム開発の前に、

ソフトウェア開発の課題
- プロジェクトの目標がないとか
- 要件が定かでない、要件決める人が不明
  - 仕様がくつがえることたくさんあるよね
- 結果がおもてたのとちがう！
- これ価値が提供出来てるの？
- リスク管理ができてない（正常系はあるけど、異常系がない）
- チームがパフォーマンスだしてない
- 利益を産んでいない
  - ここでいう「利益」はお金だけじゃなくて、ナレッジなども含む

ということがあって、チーム開発の問題はこのソフトウェア開発の課題の一部だよねという指摘をされ、かつチーム開発の中でもツールの使いこなしだけでなくコミュニケーションプランをどうするかなどなど、チーム開発をうまく進める要素はたくさんある。ただその中でツールが解決する問題は3〜5年ぐらいWebをみて実践している人はできるだろうけど、新人やキャッチアップできなかった人が手がかりになるものを調べられるかというと情報多すぎるという問題があり、書籍としてチーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)を書いてとっかかりにしようという狙いがあったようだ。

Grace Hopperの「許可を求めるな謝罪せよ」*1を引用して、「まず実行して既成事実を作ってしまえ」という意識を持つということは非常に好感を持てた。SIer的なことを前職ではやってたので、くっそ古いVCSで辛い思いをすることやマージで死にそうになるなど共感する事例が紹介されていたけど、その先が違ったのはやはり壁を乗り越えられなかったからだなぁと。あと、便利なツールつかったりして改善しても、既存の業務フローとうまく統合してこそという指摘は思わず膝を叩きたくなりました。確かにそこまでやらないと、社内の人には結果が見えないですからね。なるほどこの部分も足りなかったかと、過去の自分に思いを馳せました。

2つ目の事例では某ソーシャルゲーム会社での事例（どこだろなー？）で、お話のコア部分としては企画と開発できっちり情報共有できていないという点に尽きるのかなと。今の会社だとそのあたりはJIRAに全部放り込んで、仕様などはConflenceに突っ込んでJIRAと連携するようなかたちにしているけど、それでも漏れる部分が出てきているのでみんな苦労しているのだなという印象を持ちました。

発表全体をまとめると、こんな感じ。

まず可視化
現実を直視できる環境を作れば、おのずと改善サイクルは回り出す
そのために必要なことはどんなことでもするのはスクラムマスター（またはプロジェクトマネージャー）の仕事
ちいさなことからコツコツと！
一人ではできない
- チーム開発です
管理しない
- 管理すると管理する人の能力を超えたものは出てこない
- シナジーを重視、そこから改善がまわりだす
- すべてのメンバーがフラットに全情報にアクセスできるように
- やれといわれたことよりやろうとおもったことのほうがでかい
つづかないこともある
- CIあるけどこけるので気にしなくなるとか
- チーム開発の改善もダイエットと同じ
- 課題がなくなるような習慣をつくろう
率先してやる、続けやすい環境をつくる、気張ってやり過ぎない（習慣付けをする）、出来る範囲で、無理しない

課題がなくなるような習慣をつくる、ということをダイエットを例に出されてましたが自分が1年ほどダイエットしているのでこれも腑に落ちるところ。習慣付けは大事です。いやほんとおもしろい発表ありがとうございました。

チーム開発よろず相談部屋

自分が参加したのは情報共有についてでしたが、ここでは他社の事例などを聞けてなるほどなぁと思う点が多々ありましたね。JIRAとBacklog [バックログ]を社内外で分けて併用していたり、社内メーリングリストでも気軽に発言できるような雰囲気を作っているなど、おもしろい事例が多かった。特に情報共有において、アウトプットを出しやすい環境を作るためにどうするかという点についてはいろいろな会社で苦心されているなぁと思い、かつ自分の会社で足りてないところかなと思いました。あんまり馬鹿話する感じではないからなぁ。

その他におもしろかった話では例えば夕会などをすると、そこで宣言した内容（このタスクまだ終わってないから終わらせますなど）を達成するために残業が増えちゃったという話。このあたり企業内文化の違いもあるのか、うちの場合だと夕会が作業の終わりという感じもあって帰る人は帰っちゃうので、やはり最適なプラクティスというのはケースバイケースで、都度都度考えないといけないなと思いましたね。

自分は情報共有後、その情報の鮮度をどう保つかというところに問題意識があったのですがこれについてはどこも苦労されている模様。ただ、スクラムで回していたりすると完了の定義を仕様の更新なども含めて完了にするのはどうか、タスクとして登録しておくのもどうかなどいろいろ意見は出たのでこれを元に考えをまとめていきたいなと思います。