2007/07/05 日本情報システム・ユーザー協会（JUAS）は7月5日、ユーザー企業102社の357プロジェクトを調査した「ソフトウェアメトリックス調査2007」を発表した。システム開発の企画、開発計画に始まり、保守や運用管理まで実態を調査した内容で、企業情報システムの実態を伝える。調査結果からは“デスマーチ”となるプロジェクトの実態も浮かび上がった。 デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。だが、「（短

前回と同様、300人のSEに質問した「最悪だった火を噴くプロジェクト」の回答です。ただ今回は、「その中での楽しみ」にフォーカスしました。こじつけに思われるかもしれませんが、皆さんは地獄の中で一条の光を求めているのです。でしょ？ 某通信社の電話帳関連システムを開発。私は入社4年目で、課長の下で20人程度をまとめるサブリーダーだった。当社の受注はプログラム開発だけであり、仕様書や開発環境は顧客側が用意するとの契約。それが参入時点で、仕様書もその開発環境下での開発実績もなく、結局は仕様書から作成。開発は遅れに遅れた。

300人のSEに、「最悪だった火を噴くプロジェクト」を質問。「スケジュールに追われて残業が増える程度ではない悲惨さ」という条件をつけたので、ひょっとしたら「経験なし」の回答があるかも……と思いきや、ひとりも欠かさず全員から答えがありました。うーむ、複雑な心境です。 物流機械を製造するメーカーの、自動制御パッケージの開発を丸ごと請け負った。期間・品質ともにシビアな仕事だったが、マネジャーもリーダーもSI企業の下請け経験が長い人で、今思えばこんなプロジェクトの運営を統括できるスキルはなかった。私は入社3年目くらいで、プログラマとしてサブシステムを担当していた。

●長男の自閉症、妻のうつ病……こうした家族の事情を会社の上司や同僚から聞いたことはあるだろうか。仕事と私生活を切り離して猛烈に働くことを良しとしてきた日本社会ではまず考えられない話だろう。まして日本人は、家族の込み入った事情を隠したがる傾向にある。 ●そんな“日本型サラリーマン社会”に一石を投じるのが、東レ経営研究所の社長である佐々木常夫氏がこの6月に上梓した『ビッグツリー』（WAVE出版）だ。佐々木氏は、著書のなかで長男や妻の病を含めた家族の事情と再生劇を包み隠さずに語り、家族の問題を抱える人々には勇気を、仕事と家庭の狭間に立つビジネスパーソンには希望の光を与えている。 ●この本は家族愛の物語であると同時に、家庭を守りながらも企業人として駆け抜けてきた佐々木氏の仕事術を綴ったビジネス書でもある。これからの日本社会で、個人はいかに働き、企業と付き合っていくべきか？　そして企業はいかに社

第１回　コーチングでモチベーションアップを狙え 小田美奈子 2006/2/3 以前連載した「コーチングを身に付けよう」で、身に付けておくと役立つスキルであるコーチングの概要と活用事例について紹介しました。 今回は、IT業界でコーチングやファシリテーションなどのヒューマンスキルを活用している人を取り上げ、その事例を紹介していきたいと思います。皆さんがプロジェクトを成功に導くためのヒントになれば幸いです。 1回目は、大手のソフトウェア会社にて15年のリーダー経験がある後藤敏信氏が、プロジェクトでコーチングを活用して、成果に結びつけた事例を紹介します。 後藤敏信氏のプロフィール：1955年生まれ。ソフトウェア開発会社にて、大手通信事業者の顧客料金システム開発プロジェクトに携わる。システムエンジニアを経て、プロジェクトリーダー、提案型営業を経験。2005年より、インターネットマーケティング会社に勤

将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点＝“私点”からそれらの悩みの背後にあるものに迫り、ＩＴエンジニアを続けるうえでのヒントや参考になればと願っている。 ■リーダーシップトライアングルの中心は「ココロ」 前回の「ソフトウェアは目に見えない」で、リーダーシップトライアングルの構成要素の「Vision」（ビジョン）／「Management」（マネジメント）について説明しました。今回の記事では予定どおり、リーダーシップトライアングルの中心をなす構成要素、「Love」（ココロ）を解説します。 リーダーシップトライアングルでは、リーダーシップの基礎であるコミュニケーションの上

SEこそ、ファシリテーションが必要だという。そもそも、ファシリテーションとは何だろうか。そしてSEになぜ、ファシリテーションが必要なのか。それを解説しよう。 ■SEに役立つファシリテーション SEの皆さん、会議やミーティングに費やす時間はどれぐらいですか。 顧客との打ち合わせ、プロジェクトの進ちょく会議、部内打ち合わせ、営業会議……。すべてを合わせると、かなりの時間になるのではないでしょうか。 もし、この時間の効率が2倍になるとしたらいかがですか。つまり、会議時間が半分！ そんなうまい話があるものか。そう思われるのも無理はありません。しかし、それが、あるんですよ。 そして実際は、2倍どころかそれをはるかに超える効率アップが可能なのです。 顧客との要求仕様の見解の相違、これがシステムテストのときに明らかになったらいかがでしょうか。手戻り工数は莫大（ばくだい）です。プロジェクトの進ちょく会議、

エンジニアは日々現場で学ぶ 開発現場で学べること 最終回（第10回）　プロジェクトが失敗する不吉な匂いとは クロノス 山野寛 2004/11/2 エンジニアにとって最も大切なことの1つが、開発現場での経験だ。それがエンジニアに多くの知識と勘をもたらす。そんな開発現場で若きエンジニアが失敗し、そこで何を学んでいくか。それを毎回紹介したい。 ■プロジェクトが終了へ 1年以上続いたこのプロジェクト（「第1回　忙しいのはユーザーだ」を参照）も、ようやくカットオーバーを迎えることができた。今回の開発では、何度となく苦難やトラブルがあったが、いま考えるとすべてがよい経験になったように思う。そしてこの連載も今回が最終回である。いままでこの連載を読んでいただいた読者の中には、われわれのプロジェクトが最終的にどのような終わりを迎えるのかと興味をお持ちの方もいらっしゃるのではないだろうか。であれば安心していた

ソフトウェア開発ではこれまで、できるだけ「シンプル」に設計・開発することの有効性が繰り返し提言されてきた。ソフトウェアをシンプルにすればするほど、設計は見通しが良くなり、開発は容易になり、メンテナンスも楽になる。 では、開発を＜シンプル＞にするというのはどういうことなのか？ 一体どうすれば＜シンプル＞になるのか？ これらの質問にあなたは即答できるだろうか。実際のところ、頭ではシンプルにすることが良いと分かっていても、現実には実践できていなかったりするのではないだろうか。 そこで本稿では、現実の開発現場でシンプルな設計・開発を行うための1つの手段として、その「考え方のコツ」を考察する。もちろんこのコツを身に付けることは、すべてのソフトウェア開発で役立つものだろうが、特にNAgile（エヌ・アジャイルまたはナジャイル）を実践していくうえでは、ぜひ知っておいてほしい（NAgileについての概要は

This shop will be powered by Are you the store owner? Log in here