読者です 読者をやめる 読者になる 読者になる

非エンジニアが「チーム開発実践入門」をよんだ

 わたくしエンジニアではございませんが「チーム開発実践入門」を読んでみました。

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

チーム開発実践入門 ~共同作業を円滑に行うツール・メソッド (WEB+DB PRESS plus)

 本書はエンジニアを対象としたチーム開発を行う上でのツールやメソッドの入門書です。非エンジニアである私は『チーム開発 = 複数人でコミュニケーションを取りながら目的に向かう』と捉えて読んでみました。結論、エンジニア以外でも楽しめたので思う所を書き出します。

プロジェクトを炎上させないために有効な道具たち

 この本は2章で「炎上プロジェクト」のケーススタディから始まります。メールでのタスク管理、そしてあたり前にコミュニケーション破綻。バージョン管理されていないソースコード、当然のデグレ。IT業界にいる人なら誰でも見聞きしたことがあるような胃が痛くなるケーススタディです。

 このような炎上プロジェクトを防止するために有効な道具や手法は数多く生み出されています。

 「ファイル名に日付を入れて管理する事がバージョン管理とかおかしくないか?」とか「ミスの防止策で『ダブルチェックを徹底します』とか現実的に何もしませんと同義だよね」などと感じられている方は多くいますよね。本書はこのような疑問に対して、防ぐためにどのような道具が生み出されていて、それはどのように運用されているのか?そしてどのような歴史を辿って今に至るのか?が紹介されています。道具を実際に使うかはさておきこの辺りを抑えておくだけでも思考が深まるのではないでしょうか。

チケット管理は全てのビジネスマンにあてはまる

 第4章のチケット管理は非エンジニアでも実際に使える道具です。期限をきちんときってタスク管理を行うというのはソフトウェア開発だけでなくあらゆるお仕事に共通するものです。

 タスク管理は非常に重要な事でありながら意外に未整備な事が多いです。タスク管理と称して、エクセルファイルにタスクの洗い出しがされていても更新されていなかったりしませんか。更新されているタスク管理エクセルを探すことは、パワポに書かれた通りPDCAサイクルが回っているプロセスを探すのと同等に困難です。

 「エンジニア同士だからそんなツールを使う事が可能なんだ。多くのクライアントや営業社員は『ITリテラシー』の問題からエクセルでないと無理なんだ。」というご意見もあろうかと思います。そのような場合はそっと胸に手をあてて、問題は「相手のITリテラシー」なのか「自分の説明能力」なのかを熟考する必要があるのではないでしょうか……

 まずは少人数や小規模プロジェクト(2ヶ月程度)で、紹介されているツールを使ってみてはどうでしょうか?個人的には社内外問わずやりとりが2ヶ月を超えそうな場合は紹介されているBacklogを使うようにしています。

ベストプラクティスなどなく、あるのはベタープラクティスの組み合わせ

本書にはこのような言葉が出てきます。

最適なプラクティスはケースバイケース チーム開発の世界では、どこにでも通用する万能のベストプラクティスがあるというより、状況に応じたベターなパターンの組み合わせが何通りもある、という考え方が正解に近いでしょう。実際自分が関わるプロジェクトに応じた最適解を見いだせるかどうかが、プロジェクトを成功に導く鍵といえるでしょう。

 けだし名言です。チーム開発だけでなく何事にも銀の弾丸は存在しないものです。だからと言って諦めて何もしなくてもよいという事にはなりません。結局は改善するために学習を続け、様々な組み合わせパターンを試行錯誤し続けるしか方法はないのでしょう。


 先日、知り合いの内装屋の方が「IT企業の引っ越しを手伝うと、色々なツールを使ってプロジェクト管理がされているのを目の当たりにしてスゴイなーって関心するんですよ。今、ああいうプロジェクト管理の仕組みを社内でも取り込めないか検討しているんですよね〜」と仰っていました。この話をお伺いした時は本書はまだなかったですが、今おすすめしたら面白く読んでくれたのではないのかな?と思います。

 まぁ、自腹で買うというよりは経費で買って部内みんなで回し読みするというのがおすすめですかね :p