後悔先に立ちくらみ:ありがちなプロジェクトの姿（パクリ） - livedoor Blog（ブログ）
http://ntd.way-nifty.com/blog/2005/05/post_80fd.html ここに「プロジェクトの姿」という、実にわかりやすい説明があったので、思わず受けてしまった（笑）すげえありがち！！ そこで、少々わかりやすく書いてみました。 問題あったら教えて下さい。削除します。コメントに書いて下さい。 顧客が説明した要件 「他社に無い高性能なブランコを頼むよ」 「能力三倍で」 プロジェクトリーダーの理解 「承知いたしました」 「しかし３段なんて無理だと私だからこそ気付ける。常識的な仕様に変更だ」 アナリストのデザイン 「分析の結果、リーダー提示では漕げません。仕様を満たすため邪魔な幹を除いて…」 「ありゃ倒れるな？支柱をどこかにつけなくては・・・」 「どうにかしてブランコが動けるようにデザインしたぞ！」 プログラマのコード 「ブランコ板と
顧客が本当に必要だったもの ～ 少し長めのあとがき｜IT暴言-59-｜鈴木 正之助
『ＩＴ暴言』は、今回でおしまいです。約２年間、どうもありがとうございました。後半は、発行のペースを乱してしまい、大変に申し訳ありませんでした。プレリリースや他マガジンへの提供分なども含めると、書いた本数は全６０本。少しでも皆様のお役にたてたのであれば、嬉しいです。 全体を通して振り返ってみると、字数を多く割いているところは、『問題解決』と『コミュニケーション』についてです。特にコミュニケーションは、企業内の業務システムの開発で最も大事なことだと、私は思っています。プログラミングなどの技術力と共に、『システム開発の両輪』であると言えますね。 ところで、『顧客が本当に必要だったもの』というタイトルの風刺絵があるのをご存知ですか？ 私は今年の春に知りました。開発者の間では、かなりメジャーな存在となっていますが、これほど的確に、システム開発の実情を表現しているものはないと思います。御存知ない方は、
towardsgrowth_thumb.jpg | Hiroiro
Qrio Lockとは？ Qrio Lockは既にご存じの方が多いと思いますが、玄関の解錠・施錠をスマートフォ...
404 Blog Not Found:まとめ - 顧客が本当に必要だったもの
2007年06月14日13:45 カテゴリ翻訳/紹介 まとめ - 顧客が本当に必要だったもの 元ネタがネットで広まってから二年ほど経つので備忘録代わりに。 [追補アリ] どうやら開祖 Tire Swing Cartoon 多分元祖 from the mind of Phord - Blog Archive ? What the customer really needed 日本における紹介 顧客が本当に必要だったもの 〜 少し長めのあとがき｜IT暴言-59-｜鈴木 正之助 これらを受けて、 シャブ壱inDEEP - 画像：顧客が本当に必要だったもの：グラビアver 顧客が本当に必要だったもの（ガンダム編） 萌え理論Fotolife - ゲームが本当に必要だったもの 出会い系サイトの実態とは-安藤美姫 - 世界フィギュアスケート選手権応援ブログ 画像コーナー リリカルゴルカルApple100
ネトサン 顧客が本当に必要だったもの いろいろ
クリックすると大きく表されます。（すいません。リンクが外れていました） 「顧客が本当に必要だったもの」をコミカルな風刺絵で表しています。英語版を探していたら日本語版があったのでそちらを載せました。結構有名なんですねぇ。 本当に考えさせられる風刺絵です。何故か開発プロジェクトって訳の分からない方向に走っていきますよね。開発以外でも本当に話が変な方向に行ってしまうんですけどね。 でもこの風刺絵と似たのを昔見たと思ったら、いろいろなバージョンが存在します。 ガンダム編 http://www.hiroiro.com/entry/282.html グラビアアイドル編 http://www.os.rim.or.jp/%7Ecosuck/geolog/img/project.jpg ゲーム開発編 http://f.hatena.ne.jp/sirouto2/20060609205859 シンセサイザー編
顧客が本当に必要だったもの | "March Rabbit's" Web site
…という諷刺画（？）がありまして、当時いたく感銘を受けたものです（こういうブラックなネタが好きなもので）。 それがちょっとしたwebサービスになっているようなので、早速俺バージョンを作ってみました。あんまり業界に馴染みのない方向けにちょっとした説明もつけてみたので参考までに（カッコ内は英語版でのキャプション）。 顧客が説明した要件(How the customer explained it) 「結局何がしたいんだ？」 冗長、欠落、自己撞着。顧客の説明が要領を得ないことは少なくないとはいえ、それ自体は大した問題ではありません。この段階できちんとした対処ができるなら。 …大抵の場合はこの段階でのボタンの掛け違えから悲劇の種が蒔かれる訳ですが。 つ［○○なんか飾りですよ］ 営業あるいはコンサルタントの表現･約束(How the business consultant described it)
顧客が説明した要件:アルファルファモザイク
「ゼリーのみ規制…モチはいいのか？」→野田聖子氏「モチは喉に詰まるものというのが常識」…消費者庁構想に暗い影
第3回 トラブルシューターは一匹狼有害な“正論”を盲信するな：ITpro
SEも企業社会の一員である以上，無数に存在する正論や常識を守ることが求められる。しかし，その正論や常識がすべて現実のSEの世界で通用するかというと，必ずしもそうではない。特にトラブルシューターには，決してうのみにして欲しくない正論がある。今回はそんな有害な“正論”を2つ紹介しよう。 第1は「仕事は部下に任せよ」というものだ。誰しもSEを何年か続けていれば，数名の部下を持ち，管理職としての責務を負うようになるだろう。このとき多くの人は，管理職の心得として，まずこう言われるはずだ。「何もかも自分でやるのではなく，部下に仕事を任せて育てることが君の仕事だ」と。 一見，正論である。しかし，トラブルシューターに関する限り，これは必ずしも正しくない。筆者はむしろ，真実は逆だと考える。「部下任せにするのではなく，仕事は自分の手でやれ」と。 もちろん，何もかも自分でやれと言うつもりはない。部下に任せる仕事
Martin Fowler's Bliki in Japanese - 朝会のパターン：立ってるだけじゃないよ
朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2）を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく
大迫正治 REPEDANT BLOG > 「中毒性」ある受託開発がソフトウェアベンチャーの躍進を阻む : ITmedia オルタナティブ・ブログ
日本のソフトウェア産業は「製造業」よりも「サービス業」に分類される。なぜなら、革新的なプロダクトを研究開発し、一気呵成に市場に展開するよりも、顧客ニーズに沿ったオーダーメイドのシステムを逐次的に開発することが主流となっているからだ。 創業期は受託開発で糊口をしのぎ、徐々に自社製品の研究開発に資金を回して、いつかは自社ブランドで世界を席巻する、というストーリーは巷にあふれるが、これは結局のところローリスクでスタートしながらハイリターンを得ようとする野望であり、実現へのハードルは低くない。その理由は、中毒性のある受託開発と、ソフトウェア産業の悲惨この上ない「重層下請け構造」にある。 １．受託開発では「技術」が蓄積しない 住信インベストメントの辻俊彦氏はご自身のブログで次のように述べている。「クオリティの高い受託開発力は、オリジナリティ溢れる尖った自社開発力を生み出す素地になると思っている。投資
もっと失敗しよう：江島健太郎 / Kenn's Clairvoyance - CNET Japan
このへんを読んでいて思ったこと。 「中毒性」ある受託開発がソフトウェアベンチャーの躍進を阻む - 大迫正治 REPEDANT BLOG [ITmedia オルタナティブ・ブログ] HOW DO YOU LIKE SILICON VALLEY? | やはり受託からイノベーションは生まれない いやはや、まったくおっしゃるとおり。 ともかく、みんな「リスク」とか「不確実性」とか、そういう浄化されたビジネス用語をつかって説明しようとするからリアリティーがないんだ。 いまの日本のITイノベーションに足りないのは、転んで生傷をつくりまくる失敗経験だよ。 「１０のチャレンジのうち９の失敗をよしとする」ということは、それ自体、相当の覚悟と思考体系の適応力が求められる難しいテーマ。ハンパに受託をやりながら、そういうマインドを維持できると思ってる人がいるとは、いかにもおめでたい。 だいたい、国際交流試合や全
HOW DO YOU LIKE SILICON VALLEY やはり受託からイノベーションは生まれない
一定期間更新がないため広告を表示しています
会議での「先送り助け舟」が本当に迷惑な点について
私は基本的に会議はきらいだが、特にアジェンダがはっきりと決まっていない会議だとか、何も決定を下さない会議が大嫌いである。そんな中でも、もっとも許せないのが「提案を文書にする」「次のミーティングを設定する」などの一見建設的だが、実は単に意思決定を先延ばしすることを許容するだけの「助けにならない助け舟」である。 営業部長「こうなると選ぶ道はAかBしかありませんね」 社長 「そうは言っても色々と難しい面もある」 技術部長「ここで、決めるしかありませんね」 社長 「そんな簡単な話ではないだろう」 営業部長「そんな悠長なことを言っている暇はありません」 社長補佐「まあまあ。じゃあ、まずは営業部長に彼の提案を文書にしてもらうというのは、どうでしょう」 技術部長「文書にするって、今さんざん話したばかりで、もう分かっているじゃないか」 社長補佐「そうあわてずに。文書にしてもらえば見えてくることもありま
ダメな文章に共通する3つの問題点に注意：日経ビジネスオンライン
■若手の文章はココがダメ！ 1 何を伝えようとしているのかハッキリと分からない 2 「私はこう思う」という書き手の思いだけを書いた言い切りの文章が多い。その理由が分からないため、説得力がない 3 意味が曖昧な言葉を気軽に使いすぎ ■正確に伝わる文章を書く4つのポイント 1 伝えたいことを明確に 依頼文なのか返答なのか、読み手に何を求めるのか、書き始める前に深く考えよう 2 過不足のない構成に 自分の考えを書くだけでは相手に納得してもらえない。提示した事柄に対しての論証を書くべきだ。文書の種類によっては、結論から述べるのではなく、背景分析から始めたり、起承転結の構成にした方がいい場合もある。目的に合わせた構成を 3 理解しやすい表現を選ぶ 文芸作品を書くわけではない。味のある文体を目指すのではなく、理解してもらいやすい表現にする 4 曖昧な言葉を使わない 複数の意味を持つ言葉を不用意に使って
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://programmer-wanted.capcom.co.jp/
顧客が本当に必要だったもの - pal-9999の日記
haruszpapa's tumblr
Justin Hourigan
顧客が本当に必要だったものリンク集 - 一分一秒真剣勝負！
つくるぶ -デベロッパー応援プロジェクト