プログラミングができるだけではプロジェクトは成功しない

プログラマーなのに最近は電話対応で1日が終わる僕です。いろんな所でうめき声とともに紹介されていた「なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術」という本が面白そうだったので読んでみました。

ページをめくるたび、自分の状況と重なりすぎていたので、思わず監視カメラを探してしまいました。

システム開発がモメるポイント

本書は

• 要件定義
• プロジェクト計画と管理
• 設計
• プログラミング
• テスト
• 契約と仕事の完成

に分けてシステム開発を行うにあたってモメるポイントと対策がまとめられています。

本書の帯によると、システム開発のおよそ7割は失敗に終わるとのことです。「IT訴訟」が起こった例を参考に、トラブルの予防策や対処法を学べる1冊とのことで、結構ガチな本です。

個人的に嬉しいのが、要件定義書やプロジェクト計画書を作るときに外せないポイントを確認できるチェックリストが章末に付いていることです。

案件が炎上案件へと変化するまでには、要件定義が甘かったり、テストが甘かったりと必ず理由はあり、それを認識しないままの体制だと、燃えないはずの案件まで煙が立ち始めるのは確実です。

なので、こういったチェックリストを元にして、至る所に仕掛けられている地雷をいかに避けるかを考えられるのは非常に助かります。

「どう作るか」よりも「何を作るか」が大事

「システム開発を行う＝プログラムを作る」と思ってこの業界に入ってきましたが、本当に重要なのはそれではなく「何を作るか」です。

ユーザーから頼まれたものを作るときも、自社で企画した製品を作るときも、何をするために作るのかがハッキリしていないと、最終的に使う人の望んだものとは程遠いものができてしまいます。

案外、開発をしていると何をするために作るのかっていうのは、頭の隅っこに行きがちです。開発が進んでいくうちに、どんどんプログラマー目線で製品を見るようになってしまうのです。

作るのが難しい部分ばかりテストをやって、一番使われるであろうシンプルな部分には手が回らず、いざ客先で動かすと致命的なエラーが出てしまって使い物にならなくなったりします。
プロジェクトマネージャー、テスター等の役割がしっかりと決められてないところには結構ありがちではないでしょうか。

もちろん、プログラムも重要で赤ちゃんがハイハイを始めたレベルな僕はもっと勉強しないといけません。が、それだけではプロジェクトは成功しないのは忘れてはいけないです。

「システム開発」ってどんなものかが分かる

それぞれの章が一冊の本になるくらいのテーマなので、専門書と言うよりかは、「システム開発ってこういうもんなんだよ」っていうのが感覚でわかる本です。

特に感動的な話があるわけでもないのに、涙を流さずにはいられない本ってなかなかないです。数年前までは焼肉屋のバイトをしていた僕が、「今システム開発の会社で働いているんだなぁ、今度は焼かれる側なんだなぁ」としみじみしております。