新規事業開発や風土改革を担当するチームが感染に注意すべき３つ（４つ）の病：ナレッジ！？情報共有・・・永遠の課題への挑戦：オルタナティブ・ブログ
ひとつ前のエントリーで、イノベーティブな試みを担当したチームがよく直面する嫌な中間管理職が振りかざしがちな論理として「唯一絶対解の存在信仰」とか「解決策の論理的完璧性追求症候群」がある、なんてことを書いたところこれらについてちゃんと説明しろというお叱りを（隣席から）受けた。 正直に白状するとこの２つの信仰とか症候群ってとっさに自分で考えてつけたネーミングなのだ。でもせっかくだしちゃんと書いてまとめてみることにトライする。 まずは、それぞれの解説から。 「後出しジャンケンプラクティス」 今泉さんの例示によるとこれは、完成形をイメージせずに都度提示されたモノに対して思いつきレベルでコメントを発したり、他にはlizy氏のブクマでの指摘にあったように「意見を求められた側は、何らかの意見を言わないと仕事をしてないことになるため、必ず難癖をつける」というアリバイ作りのためのコメントの繰り返しによって革
スーツにはスーツの道がある - GoTheDistance
勢いで書く。 スーツ側の人は業務内容が密接にプロジェクトや会社の中の話と結びつくことが多いので、はてな界隈ではなかなかスーツ側の人はスーツ側の濃ゆい話を書くことが出来ないことが多いようだ。圧倒的にスーツ側の人間がはてなを始めとしたブロゴスフィア全体で少ないなぁとつくづく思う。QAも少ないけど。この辺をアツく語るブロガー出てこないかなー。 私は200X年に今の会社に入社して、数年間WEBアプリケーションの開発をやった。多くはJavaの案件だった。最後の案件は去年の夏ごろだ。前任のPMが逃げるように辞めていってしまい、非常に複雑なロジックを自分が担当することになった。1500行越えktkr。それを参考にして(これが大間違いだったんだよセニョールorz)２週間かけて作ってみたはいいものの、テストを繰り返しているうちにどんどんボロがでて、結局その当時のPMとパートナーさんに相談して設計からやり直し
迷ったら狩野さん！...狩野分析法による優先度付け - masayangの日記（ピスト通勤他
追記 id:discypusさんから、狩野分析法の出典に関するコメントをいただきました。 狩野法って、 狩野 紀昭 氏 http://www.sangakuplaza.jp/page/134499 の http://www.yahoo-vi.co.jp/method/b10.html の手法かと 思うのですが、合ってますでしょうか？ まさにこれですね。http://www.yahoo-vi.co.jp/method/b10.html にある日本語のほうがすっきりしてます。 お詫び 分析用配列に誤りがありました。修正してあります。 要旨 先日受講したScrum Product Owner Trainingで印象に残った分析法を紹介。 Agile開発では「優先度順に要件（フィーチャ）を開発していく」のが基本だが、いざ優先度をつけようにも話は簡単ではない。発注側に強力な指導者がいてその人が独裁的
【IT Service Forum 2007】プログラミング軽視が使えないシステムを生む----積水化学の寺嶋氏がベンダーに苦言
「今のITベンダーはプログラミングを軽視しすぎている。全員がプログラマでありSEでなければ企業が喜ぶシステムは作れない」。積水化学の寺嶋一郎コーポレート・情報システムグループ長（写真）は、11月27日に開催した「IT Service Forum 2007」の講演「ITベンダーに望むこと」で、ITベンダーにこう苦言を呈した。 「システム開発でどんな技術や開発手法を使うかはアーキテクトが決める。経験上、良いアーキテクトが設計すると、開発と運用のコストを段違いに削減できる。良いアーキテクトとは、業務とプログラミングをよく知っている技術者だ」と寺嶋グループ長は話す。だが、今は「プログラミングを知らないSEが“売らんかな”でツールやパッケージの導入を目的に設計し、オフショア開発などで業務の分からないプログラマが実装している」（同） この状況を改善する策として寺嶋グループ長は「内作型開発モデル」を提唱
未経験者がユーザーテストを行う際の10のポイント - livedoor ディレクター Blog
こんにちは、ディレクターのほうの谷口です（余談ですが、ライブドアには3名の谷口がいて、私はプログラマーじゃないほうの谷口です）。今回は、ユーザーテストについてお話したいと思います。 ユーザーテストは、ウェブサイトの新規立ち上げやリニューアルの際、ユーザーがウェブサイトやプロトタイプを実際に操作してもらう様子を目の当たりにすることで、問題点を発見する方法です。 ライブドアのサービスは、作る側とユーザー像が近いことが多かったので、頻繁にはユーザーテストをしてきませんでした。しかし、今後は自分たちと違うユーザー像も対象としていきたいことから、ユーザーテストの数を増やしていきたいと思っています。 ユーザーテストの専門会社に頼むという手もあり、そうすることで厳密に調査をしてくれます。しかし、ポイントをしぼって外注せずにすむ方法もあるので、ここに紹介します。 1. 被験者は友人か知り合いでいい 専門会
最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 ― ＠IT
2007/07/05 日本情報システム・ユーザー協会（JUAS）は7月5日、ユーザー企業102社の357プロジェクトを調査した「ソフトウェアメトリックス調査2007」を発表した。システム開発の企画、開発計画に始まり、保守や運用管理まで実態を調査した内容で、企業情報システムの実態を伝える。調査結果からは“デスマーチ”となるプロジェクトの実態も浮かび上がった。 デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。だが、「（短
Martin Fowler's Bliki in Japanese - 朝会のパターン：立ってるだけじゃないよ
朝会（デイリー・スタンドアップ・ミーティング、デイリー・スクラム、デイリー・ハドル*1、朝のロールコール*2）を説明するのは簡単だ。チーム全員が毎日顔を合わせ、現在の状況を迅速に確認しあう。立ってやるのはミーティングの時間を短くするためだ。以上。 でもこれだけじゃあ、「良い朝会」と「悪い朝会」の微妙な違いは分からないだろう。 朝会の定義は非常に簡単なものなのに、 うまくいっていない朝会があって私はとても驚いた。 すぐに原因は分かったが、そのチームはそれが何なのか分かっていなかった。 朝会の基本原則と詳細を意識していなかったのだ。 そのために朝会の問題について診断や解決がなされていなかったわけだ。 良い朝会を経験した人たちは、 うまくいってないときに何をすればいいかを知っている。 朝会に慣れていない人たちは、 うまくいってないときに何をすればいいかに気づかない。 「暗黙知なんだから、とにかく
Joel on Software - ジョエル・テスト
Joel Spolsky ジョエル・スポルスキ 翻訳: Fukushige Erika 福重 永里香 翻訳チェック: Takeda Toshiyuki 武田俊之 9.8.2000 SEMAについて聞いたことがある？かなり難解なシステムで、ソフトウェアの開発チームがどれくらい良いかを測るためのものだ。ちょっと待った！そのリンクに飛ばない方がいい。きっと書いてあることを理解するだけで6年はかかるだろう。そこで、私は自分で作ることにした。これはソフトウェア開発チームの質を評価するものだが、とっても当てにならないいいかげんなテストだ。このテストの素晴らしいところは、3分程度で終わることだ。節約した時間を使って、医学部に通うことだってできるだろう。 ジョエル・テスト ソース管理システムを使っているか？ １オペレーションでビルドを行えるか？ 毎日ビルドを行うか？ 障害票データベースを持っているか？ 新
直感を信じろ、自分を信じろ、好きを貫け、人を褒めろ、人の粗探ししてる暇があったら自分で何かやれ。
ここ一週間、たくさんの日本の若い人たちと話した。JTPAツアー、九州大学ツアー、そして昨日のLingrイベント。それでつくづく思ったこと。もう前にも一度言ったことだし、当たり前のことだし、言わなくても伝わっているだろうとふと思っても、しつこく言おうと。なぜなら、僕が考えていることと正反対の言葉を、日本の大人たちから皆はシャワーのように浴び続けているし、僕がこうあるべきと思うことと正反対の経験を日々せざるを得ない状況にある、ということがよくわかったから。 二十歳にもなれば、その人のすべてはもう顕れている。その自分の良いところを見つけるには、自分の直感を信じ(つまり自分を信じるということ)、自分が好きだと思える「正のエネルギー」が出る対象を大切にし、その対象を少しずつでも押し広げていく努力を徹底的にするべきだ。そういう行動の中から生まれる他者との出会いから、新しい経験を積んでいけば、自然に社会
高木浩光＠自宅の日記 - RFID児童登下校管理システムのクオリティは安心安全ソリューションってレベルか
■ RFID児童登下校管理システムのクオリティは安心安全ソリューションってレベルか 2004年から2005年にかけてたびたびNHKニュースやテレビ東京で華々しく宣伝されていた、RFID児童登下校通知システムだが、去年あたりから悲惨なことになっていたようだ。 2006年8月13日の日記からリンクしていた個人ブログを再び見に行ってみたところ、その後こんなことになっていた。 「情報科な日々のつれづれ」の「ICタグ」カテゴリ 朝、7:36。 ICタグによる登下校システムの停止。（略） 事務所の電話は、鳴りっぱなし。 何とかならないかといわれても・・・・。 とにかく富士通に対応してもらうまで待つしかない。 原因は、どうやら、メールサーバの停止らしい。 7:36に最後の送信をしてから、停止したらしい。 それ以降に登校した子どもには、メールが送信されていません。（略） 27 September ご迷惑を
効率的に意思決定をするための3段階。 : ひろゆき＠オープンSNS
【教えてくん】コミュニティーなのです。 なんかニュースとかあったらここに書こうかと思ってますよ。とりあえず、おいらのブログ 効率的に意思決定をするための3段階。 ・決定権のある人に情報を集める。 ・決定権のある人に選択肢を提示して決定するように迫る。 ・決定権を持つ人がしぶしぶ決める。 上記の3点で物事というのは決まるわけです。 とりあえず、頭数を揃えると会議をはじめることが出来るので、 みんなで話をしたりすると、必要なことをしてる気がするので、 真面目に会議が始まります。 思ってることや課題を各々の会議参加者が喋ったりします。 この状況は「情報を集める」段階でしかないわけです。 そして、必要な話が全て終わったところで、 決定権のある人に選択肢をだして結論を迫ります。 んで、決定権のある人は下記の3つのうちのどれかを選びます。 「情報が足りない」 「結論先延ばし」 「決定」 これで、うまく
プロトタイプを重視するカルチャー
最近、UIEJのメンバーの間で「うみがめ」というGoogleの「20%ルール」に相当するルール作りの話が盛り上がっている。ルール作りはおおいに結構なのだが、「なぜうみがめが必要か」というプリンシプル（相当する良い日本語がないが、あえて選ぶなら「筋」－詳しくは「プリンシプルのない日本」参照）を見失って「ルールのためのルール作り」に陥らないで欲しい、というのが私からのお願いである。 そこで、今まで私がプロトタイプ作り、ベータ版サービスの重要性に関して言って来たことをまとめてみた。 １．UIEのような会社にとって何よりも大切なものは、賢くてクリエイティブな人。そんな人たちが働きたいと思うような、そして彼らがクリエイティビティを最大に発揮できるような環境を提供することが大切。 ２．本当のイノベーションはごく少人数でおこすもの。一人とか二人とかのクリエイティブな人が、「こんなもの作りたい」という情熱
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MOZANBLOG 昇給をネゴしてみよう
notfound
ソフトウェア開発の落し穴