迫り来る納期、増えるプロジェクトメンバー。されども何も生み出されない……。そんな「ダメプロジェクト」はなぜ発生してしまうのか。システム開発現場の“負のあるある”について、クレイジーワークス総裁の村上福之さんに寄稿してもらった。
システム開発の多くは“カオス化”します。ぼくも年を取ったもので、システム開発でいろいろな死屍累々(ししるいるい)の修羅場を見てきた気がします。数年もかかったプロジェクトがいきなり中止になっても、もう驚かないようになりました。例えばこんなダメプロジェクト、皆さんも身に覚えはないでしょうか。
「働きアリの法則」によると、多くの労働環境では、20%のアリが働いて、80%はまじめに働きません。しかし、ひどいソフトウェア開発の現場ではもっとひどくて、だいたい10人に1人のプログラマーがバーサーカーのように働いて、それでなんとか持っているという状況も多いです。残りの人は、仕事をしてなかったり余計にバグをまき散らすだけだったりします。
RPGのパーティーに例えると、こんな感じですね。
「Lv99-せんし Lv1-あそびにん Lv1-あそびにん Lv1-あそびにん Lv1-あそびにん」
実際、ぼくもシステム開発の現場にいるときは「Lv1」の人でしたが、そういう状況を何度も見てきました。「Lv99」の人の力だけで完成し、世に出回っているシステムというのは本当に多いです。
Lv99の人は往々にして仕事が大好きですし、人に任せるのが面倒くさいという理由で自分でやってしまう人が少なくないので、そうなってしまうケースがあります。ただ、小規模案件ならいいのですが、大規模案件だと「Lv99の人のソウルジェムが濁ってしまう」ケースが多いので、難しいところです。
頭のよくない管理者ほど、納期が迫ると人を増やしてスピードアップさせようとします。
残念ながら、ソフトウェア開発は「お刺身の上にタンポポを乗せる作業」とは違って、人を増やせば勝手にスピードアップするものではありません。分かっていない人が増えるだけです。プログラミング開発なんて、できる人とできない人の実力の差が激しすぎる世界で、残念ながら使える人の方が少ないのです。
しかも、納期が迫っている状況では、ドキュメントもなければ仕様を説明するヒマもありません。ネット系の企業で、スマートフォンのエンジニアを大量に採用して困っているというケースも耳にしますが、短期間でプログラマーを大量に雇うとよくないケースが多いです。人を増やすのであれば、コストはかかっても最初から増やしたほうが賢いと思います。
Web系の開発でよくあるのが「オレオレフレームワーク」です。ぼくは「オレームワーク」と呼んでいます(ぼくもよくやります)。
「オレが作ったフレームワークが最強!」みたいな「俺だけ伝説」はどこにでもあります。1人で開発しているならそれでいいこともあるのですが、オレームワークの欠点は、会社で開発すると“暗黙知”が多くなってしまうということです。
さらに、どうしてもバグが残っている可能性があることと、フレームワーク自体がこなれていないこと、ドキュメントがしっかりしていないことが多いので、将来的に他の人がプロジェクトに入ってくると、暗黙知が多すぎてカオスになることもあります。
「オレオレフレームワークの方が学習コストが低い!」と思っている人もいますが、はっきり言って学習コストが低くなるのはその人だけです。
まっとうなフレームワークなら、当然のことながら困った時はネットで検索すればなんとかなってしまうこともあるので、学習コストは高くても伝授コストは低くなります。ただ、小規模案件の場合はオレームワークで十分だと思いますし、ぼくもそうしています。
「節子、それバージョン管理ちゃう! ただの、zipや!」
バージョン管理の方法がソースコード一式を固めたzipファイルで、日付がファイル名とか、開発現場ではマジであります。“ダメなプロジェクトあるある”の決定版です。
バージョン管理が全くできていないか、できていても、上記のような日付zipファイルだったりするダメプロジェクトは少なくありません。バージョン管理ツールが世に出てから20年以上たちますが、いまだにバージョン管理ツールが導入されてないケースも日本にはあるのです。
「Redmine」「trac」などのプロジェクト管理ツールが一般的になって久しいですが、いまだに何も導入していない企業も多いです。また、導入していても誰も見ていないケースもありますし、誰も更新していないとか、放置されているケースもあります。
Excelで関数管理:「やめてー!」
Excel方眼紙で仕様書:「やめてー!」
Excelで課題管理:「やめてー!」
と、そんな状況があったりなかったりします。
ストイックな開発現場では、テストコードを最初から組みまくる“テストファースト”思想ができつつありますが、一方で、テスト自体がかなり軽視されている案件もあります。また、当初はテスト期間を設定していても、プロジェクトが押して、テスト期間が2週間から1週間になり、最後は半日になってしまった……というケースもあります。
特に、組み込みソフトウェアの開発プロジェクトは、高度化、複雑化し、工数が読めなくなってきました。そのせいで、ほとんどテストしないまま「出しちゃった」という製品もよくあります。
以上、思いつくままとエンジニア同士で盛り上がった話題を中心に書いてみましたが、いかがだったでしょうか。
1つでも当てはまると立派な「クズプロジェクト」だと思いますが、意外と日本では、2013年の現代社会でも、そういう案件が普通にあったりします。これを機に、自社が取り組んでいるプロジェクトがまともかどうか、見直してみてはいかがでしょうか?
村上福之(むらかみ・ふくゆき) 1975年大阪府生まれ、クレイジーワークス代表取締役総裁。大手家電メーカーの開発者からフリーに転身し、オーストラリアの語学学校でのシステム開発などさまざまなプロジェクトを担当。帰国後に開発会社クレイジーワークスを創業、代表取締役総裁を務める。近著は「ソーシャルもうええねん」。Twitter「@fukuyuki」
IBM Worklightは、iPhone、iPad、Android、Windows Phone等のスマートフォンとタブレットを対象にしたオープンで幅広い機能を持つ高度なモバイル・アプリケーション・プラットフォームです。アプリ開発者に役立つ情報や必読のホワイトペーパーダウンロードはこちら
Copyright © ITmedia, Inc. All Rights Reserved.
提供:日本アイ・ビー・エム株式会社
アイティメディア営業企画/制作:ITmedia エンタープライズ編集部/掲載内容有効期限:2013年3月31日
TwitterやFacebookなどの利用につきまとう“炎上”の危険性。企業がソーシャルメディアを活用する場合の炎上リスクについて、IT部門はどう考えればいいのか。「ソーシャルもうええねん」の著者でもあるクレイジーワークス総裁の村上福之さんに寄稿してもらった。
多くの困難を伴う「パッケージ導入」。IT部門が経営陣向けに説明する時とプロジェクトを動かす時では、異なる視点が必要だ。クレイジーワークス総裁の村上福之さんによる連載の最終回は、ITマネジャーに求められる“二枚舌スタイル”について。
ソーシャルメディア情報を活用した株価分析サービスから移動営業所による証券窓口サービスに至るまで、数多くのプロジェクトを統率した敏腕ITマネジャーが示すプロジェクト成功のポイントとは。
納期や予算、メンバー管理……。開発の現場にはさまざまな苦難も付きまとう。オンラインサービスの最前線を指揮してきたクックパッドの井原正博氏は、「ITで価値創造する」というマインドを忘れないことが大事だと話す。
「アメーバピグやアメブロなどのシステム担当者ってどんな人!?」。上智大学の準ミスキャンパスである細野さんが、サイバーエージェント Amebaサービスのインフラ全体を統括する怡土氏に仕事ぶりなどを聞いた。
STEP1:@ITM_campaignをフォロー
STEP2:ハッシュタグ「#ITマネあるある」付きで投稿
Tweet #IT%E3%83%9E%E3%83%8D%E3%81%82%E3%82%8B%E3%81%82%E3%82%8B