6月19日，DeNAヒカリエ本社の会議室にてDevLOVEのイベント「進め，現場のチーム開発 ～チーム開発実践入門～」が開催されました。本稿では『チーム開発実践入門』の著者である池田尚史氏（@ikeike443）の発表を中心にレポートします。

イベント開会の挨拶 ～DevLOVEとは

DevLOVE主催者である市谷聡啓氏（@papanda）の挨拶をもってイベントが開催されました。DevLOVEは6年続けている開発者向けのコミュニティで今回は170回目の開催とのこと。

HangarFlight

飛行機乗りにとって，空がまだ未知で危険なものだった時代。格納庫に集まってお互いの体験を話し合い，空を知ろうとしました。DevLOVEはまさにそういう場にしようという思想のもと作ったイベントだそうです。デベロッパーにとっては，開発の現場とは未知なるもの遭遇の場です。「⁠Hangarに集まって，お互いの経験を話し合い，システム開発を知る」というコンセプトで開催されています。

「チーム開発をスムーズにするために何ができるか」

「言いたいことは本に全部書いてある⁠」⁠，そう言って池田氏の発表が始まりました。

今回は本の中身に少し触れつつ，チーム開発の課題ってそもそも何なのか，プロジェクトの課題，ツールの情報は散逸していること，執筆にあたって気にしたことについて話が進みました。

チーム開発の課題

チーム開発について語る前に，ソフトウェア開発やプロジェクトについて触れる必要があります。「⁠ソフトウェア開発プロジェクトによくある課題」として，次の事柄を取り上げました。

プロジェクトの目標が定まっていない

よくある過ちで「プロジェクト達成の定義」がされていない状態でプロジェクトが進むことがある。これでは，いつまでたってもプロジェクトが完了することはない。

誰が要件を決めるのか不明

誰がOKと言えば良いか，決裁者が不明のままプロジェクト進行することがある。また確認する人が居ない状態でプロジェクトが進むと，最終成果物が思っていたものと違う可能性もある。

価値を提供できているのか不明

プロジェクトの目標や要件が決まっていても，そこに価値がなければ成功とは言えない。プロジェクトを進める意義はあるのか，利益が度外視されていないかなどの共通認識で持っておく必要がある。

リスク管理ができていない

いわゆるプランBが無い場合に一つの失敗ですべてが破綻するプロジェクトもある。プロジェクトを進める上で，リスクヘッジのための代替策は用意しておくべき。

チームがパフォーマンスを出していない

一人で開発していた時のパフォーマンスが100％の時，2人になったからといって200％にはならない。

これらを言い換えると，次の言葉になります。

• ゴールはどこ？
• 決めるのはだれ？
• 利益は出るの？
• リスクは見えているの？
• チーム開発はうまくいってるの？

「見ての通り，“⁠チーム開発⁠”はあくまでプロジェクトの問題の一部であり，それだけでプロジェクト全体が改善するわけではない」と池田氏は述べていました。

「チーム開発を始めるにあたって考えるべきこと」については，次の事柄を挙げました。

• 方法論はどんなものを使うの？
• コミュニケーションプランはどうする？
• 成果はどう測るのか？
• チームビルディングはどうする？
• 開発ツールはどう使うのか？

ツールで解決できる問題

このようにツールはあくまでチーム開発を進める上で考えるべき事象の一部でしかない。そしてチーム開発は，プロジェクトを成功に導くための大事な基礎であると話しました。

チーム開発をしていく上では，次の課題を挙げました。

• 市場の変化は早い
• 計画は容易に変わり得る
• 臨機応変に変化に対応しなければならない

これらの課題に対応するためには，次の点が重要だと言います。

• 遅すぎる開発サイクルはNG
• 複数人が素早く並行して開発できること
• でもデグレードは起こしてはいけない

そして，ツールで解決できる問題として，次のことを挙げていました。

• 重要メールが多すぎて優先順位が決められない
• テスト環境で動かしてみるまで，アプリが壊れていることに気づかない
• 自信を持ってリファクタリングできない
• バグの発生時期，修正時期がわからない，追跡できない
• 開発環境で動くものが本番環境では動かない
• リリースが複雑で属人的，時間がかかる，よく失敗する

本を執筆するにあたって気にしたこと

ここ3～5年Webを見て実践し続けている人なら新しいツールを活用できるだろうが，新人さんや訳あってキャッチアップしてこれなかった人はどうなるんだろう？ということを考えながら，『⁠チーム開発実践入門』の執筆にあたったそうです。

また，これまで出版されたプロジェクト管理本の多くは次のような切り口で取り上げていると言います。

• 予算管理の話
• 工数管理，見積もりの話
• チームのモチベートの話
• 採用の話

これらはもちろん大事ですが，「⁠作らない人」の 話ばかりです。

逆に「作る人」向けの，開発ツールに関する本の多くは次のような切り口で取り上げていると指摘しました。

• ツールの紹介
• インストール方法，コマンド解説
• 事例紹介
• チケット管理，バージョン管理，CI，CD等々をバラバラに解説

池田氏は，それぞれの本は担当している人にとってはたいへん有益な情報が載っているが，チーム開発全体を俯瞰できるわけではないことに言及し，「⁠開発の流れ全体を把握したいという方に『チーム開発実践入門』を読んでいただきたい」と述べていました。

2012～2013年に起きた開発環境の変化

執筆の話を受けた2012年頃の池田氏の開発環境は次のようなものでした。

• SVN/Backlog/Bugzilla/ReviewBoard/Jenkins
• Git/Githubはまだ試している段階
• Chef/Vagrantはまだまだ本格的ではなかった

この当時に執筆していたら今回のような本には仕上がらなかったと言います。なぜなら「2013年にCIは当たり前になってきた」「⁠このような背景とGitHubも使う会社も増えてきて，デプロイの自動化周りを支えるツールもホットになってきた」「⁠2012年ではなく2013年から2014年にかけて執筆したからこそ，良い本に仕上がった」と話していました。

自身のトラウマが克服するための自叙伝でもある

特に第2章「チーム開発で起きる問題」は池田氏の実体験を元に執筆し，自身のトラウマが克服するためにも書いていました。そして，自分が体験してきた，トラウマになっているような現場で働いている人たちを少しでも減らしたい。手助けになればという想いを込めたそうです。今回の発表のまとめとして，池田氏は，

「『チーム開発実践入門』が開発現場のゴールへの地図になれば」

という言葉で締めくくっていました。