ヨードンによると、以下のいずれかに該当するとデスマになるとしている。 与えられた期間が、常識的な期間の半分以下である エンジニアが通常必要な人数の半分以下である 予算やその他のリソースが必要分に対して半分である 機能や性能などの要求が倍以上である この定義を鵜呑みにすると、じゃぁ人(=予算だと思っている)を投入しようということになる。そして、人が増えれば、ミスコミュニケーションが増えるからデスマになる。では、期間(納期)を伸ばしたり、要求を減らしたらデスマはなくなるのか。 デスマを「納期に間に合わすため(納期遅延を起こしたため)長期にわたる過剰残業」と定義すると、それは違法就業なので犯罪に加担しているわけで、別の問題。密輸をしている企業にそうとは知らずに就職してしまい、密輸に加担しているのと同じ。と片付けられないことが問題ということになってしまう。労働環境が劣悪なのも同様。 上野(にかぎら

ITの世界には「スキル」という言葉がある。SEや営業が，どの程度のIT力やプロジェクト管理力や提案力などを持っているか，それを表すのに使う言葉だ。いわゆる技術力などを測る物差しである。そして「このSEはWindowsのスキルがある」とか「SEのスキルアップは必須だ」，「ネットワークSEは最低ネットワークのスキルレベル3は必要だ」などと使う。また，IT関連の雑誌などでも「日本のSEのスキルは…」と述べている。 筆者は現役時代，このスキルという言葉と30年近く付き合ったが，この言葉にはかなり苦労させられた。その理由は，日本では横文字の「Skill」と日本語の「スキル」は必ずしも同じ意味ではなく，下手をするとそれがSEの技術偏重の要因の一つになりかねないからだ。今回はそれについて述べる。 「スキルがあるSE」とはどんなSEか 読者の皆さんがある時「あのSEはネットワークのスキルがある」という言葉

また新たなメタファー(メメタァ)を覚えた。 トリアージ ちくわさんの mixi 日記から。バーンダウンと合わせて。

初回に，建築家の中村好文氏の「どんな家が欲しいのか，依頼者には分からない」という言葉をご紹介したが，今回も建築の話題をひとつ。 幅広い音楽ジャンルで活動しレコーディング・スタジオの設計・建設でも活躍されているミキシング・エンジニアの赤川新一氏がこんなことを言っていた。 「優れた建築家ほど，現場での変更が多い」 駄目な建築家は，当初の設計どおりに作ろうとする。しかし，ものづくりでは，設計の段階でユーザーの要求を漏れなく盛り込めるわけではない。優れた建築家は，どれくらいの要求が漏れているのかだいたい分かっていて，それを前提に行動する。工事が始まってから新たな事実が発覚したときに，ためらうことなく，効率的に変更ができるのが優れた建築家である。 レコーディング・スタジオのような難しい建築工事になると，初期のユーザー要求は明確になっていてもそれを実現する方法が十分に見えていない状態での着工になること

「あるときは深夜まで残業し、またあるときは休日にも出勤して、一生懸命に開発・保守しているこのシステム。打ち合わせなどで会うのは、お客様企業の情報システム担当の方々が中心だけど、実際には、どんな人たちが、どんな風に使ってくれているのだろう。」自分が携わったシステムがどのように役立っているのか、Ｋさんはとても気になるそうです。日々多大なエネルギーを投入している仕事なのですから、それがどのような効果を生み出しているか、知りたくもなりますよね。 実際どうなのでしょう もちろん、ものをつくる行為そのものが楽しいという人もおられるでしょう。また、それを構想するところにワクワクするひと、予定どおりに正確に完成させることに満足を覚える人もおられるでしょう。そして、Ｋさんのように、自分がつくったものが誰かの役にたつことが嬉しい人もおられます。このような方にとっては、そのシステムによってお客様企業にどのような

前回に続いてアプリケーション・パッケージの採用を前提としたシステム構築の話題である。 今回は「業務の学習に2カ月も付き合ってはいられない。パッケージを採用したわけだから，我々は可能な限り，業務をパッケージ合わせるつもりである。そのためには，当社がどうであるかにかかわらず，まずベンダーとしてのベストプラクティスを提案して説明してほしい」というのがユーザーの言い分であるという第2のケースである。 このケースの問題に立ち入る前に，パッケージ・ソフトのジレンマについて考えてみたい。 今からさかのぼること二十数年前の1980年代，パッケージ・ソフトは基本的に信用されていなかった。パッケージ・ソフトを売り込みに行くと，「我が社の業務はそんなパッケージがごときにカバーできるほど簡単ではない」とことごとくあしらわれたものである。パッケージ・ソフトは様々な企業の様々なケースに対応してくることで鍛えられてきた

「システムの全面再構築は楽しい仕事。失敗するのではないか、できないのではないかと悩まずに、勇気を持って一歩を踏み出すのが大事だ」。トヨタ自動車の天野吉和常務役員は10月25日、日経コンピュータが開催した創刊25周年記念セミナーでこう述べた。 講演は、トヨタ自動車の天野常務とJFEスチールの菊川裕幸システム主監による対談形式で進んだ。両者の共通点は、システムの全面再構築プロジェクトの責任者を務め、成功させたことだ。 トヨタ自動車は、300億円を投じ3年がかりで部品表データベースと基幹系システムの再構築を成功させている。プロジェクトの陣頭指揮を執った天野常務は、「全面再構築は大変だったのではないかとよく聞かれるが、そうは思わない。やればできると思う」と話した。 今年3月に基幹系システムの全面刷新を果たしたJFEスチールの菊川主監は、「プロジェクトを通じてベテランから若手に技術を継承できた。人も

■仕様書など書く必要がないと信じているプログラマ 第7章「優れた仕様書の記述」は、こんな一文から始まる―― 「私は昔、仕様書など書く必要がないと信じているプログラマと議論したことがあります」―― 議論の顛末は予想通り。おそらく、このblogを読んでいる全員がこの話をしたことがあるに違いない。各人がどういう結論を持っていようとも、本章から新たな気づきが得られるはずだ。 なぜなら、「優れた仕様書とは何か?」について徹底的に考え・実践してきたことが記されているから。目の前の仕事にとって仕様書が必須/邪魔の話をしているのではなく、もっと本質的なことが書いてある。コードから仕様書を生成するツールとか、仕様書を書く上でのテクニック集といったものは、無い。根っこの部分「そもそもプロジェクトにおける仕様書の目的は?」とか「仕様書によってできること/できないことは何か?」について非常に明解に応えている。 で

金谷 敏尊 氏 アイ・ティ・アール METAグループシニア・アナリスト 大手ユーザー企業に対してIT戦略立案やベンダー選定などのアドバイスを提供する。ITインフラ，システム運用，セキュリティ分野を専門に幅広く活躍する。 企業がシステム開発や運用を外部委託する局面でベンダーに提案を求めるRFP（提案依頼書）の手法は市場に定着したといってよいだろう。ソリューションプロバイダにとってRFPは案件獲得の絶好の機会だが、同時に競争にさらされることの通告を意味する。大規模案件においては十数社もの候補を相手に、1次、2次の選考に勝ち残らなければならない。並み居る競合を差し置いて良質の案件を手中にするのは、容易なことではない。 提案を少しでも有利に進めるためにはRFPを提出した相手の事情を知っておきたい。最近は、雑誌などで特集されることもあり、RFPの一般的な評価基準はある程度予想できるようになってきた。

「ITプロジェクトの実態とは！」というエントリで取り上げられていたソフトウェア開発を皮肉った絵をきっかけに、ソフトウェア開発では30年以上も前の本が通用するという話題になっている。 http://www.dashiblog.com/blogs/000140.php http://blogs.itmedia.co.jp/kyoko/2006/10/post_54f4.html http://blogs.itmedia.co.jp/kurikiyo/2006/10/post_aa72.html http://blogs.itmedia.co.jp/himi/2006/10/post_fa30.html 実際、「十年一日のごとく進歩なし」と書いたように、ソフトウェア開発には進歩がないかのように見える。それには以下のような理由がある。 人の心は読めない ソフトウェア開発に関わる人々が学習しようとし