いち早く70%〜80%程度の完成度で人に見せられるものを作ることがいかに重要か、という話 - 肉とビールとパンケーキ by @sotarok
去年の年末、Facebookで以下の様な画像が流れてきて自分もついついシェアしたんだけど、久々に、というか、自分にとってのここ最近の課題をドンピシャで突かれたような気がして、しばらく頭から離れなかった。 出展: 中村 修治 - 中村 修治さんの写真アルバム | Facebook 「プロ」か「アマチュア」か、というのはこの際どうでも良くて、この図の、上の曲線が、目指すべきところだなって話なだけなので、とりあえずその話をまとめてみることにする。 けど、まぁ、だいたい、こういう話をまとめるのは苦手だし途中で面倒になってしまうので、以下サブセクションだけ先に作ってみたものの、ちゃんと書くかどうかわからない... が、まあ、いい！あと、なんかグダグダ書いてしまいそうだけど、結局、サブセクションのタイトルにしたことをこねくりまわしているだけです。 作ってみるまでわからない 何にも言えることだけど作って
目標追跡型グローバルソフトウエア生産システムを考える(1)
前回は，牛尾 剛氏が「オフショア時代を乗り切る明確な要求仕様作成術」というタイトルで，RfS（Ruby for Specifications）の考え方を紹介した。牛尾氏が原稿の最後で紹介してくれたように，RfSは彼と私がディスカッションをするなかで生まれたものである。 その創造的で刺激に富んだディスカッションを通じて，私は以前から持っていたソフトウエア生産の方法についてそのイメージを鮮明にすることができた。ここではそれを「目標追跡型グローバルソフトウエア生産システム」と名付け，RfSのアイデアと関連付けながら，その可能性とメリットについて説明してみたいと思う。 RfSとは，Ruby言語，ならびにRubyによって書かれたオープンソースのWebアプリケーション・フレームワークであるRuby on Railsを用いて高速にプロトタイピングを行うことである。その意味では，RfSは一つのプロトタイピ
開発現場に見る今ドキの「自動化」
開発作業の「自動化」と聞いて，正直，うんざりする人もいるだろう。「思った通りの成果物なんてできやしない」「ソースコードの中身がブラックボックス化してしまう」「費用や教育といったツール導入の負担が大きい」――。自動化にはこうしたいくつもの不安やリスクがあるためだ。 だが一方で，生産性と品質のさらなる向上を目指し，企業トップやバックオフィス部門は自動化を強く推し進める。現場では渋々自動化に取り組むが，やはり失敗してしまう。「自動化なんて夢のまた夢，もう自動化はコリゴリだ」。そんな風に思うのも，当前と言えば当然である。 では自動化は悪か，と言えばそんなことはない。人間がやる作業をきちんと自動化できれば，それは素晴らしいことだ。自動化は作業の効率化・迅速化や，成果物の均質化といった大きなメリットがある。開発プロジェクトでは様々な作業が発生し，「猫の手も借りたい」と本気で思う現場はいくらでもある。そ
かんばんボードによるプロジェクトの見える化
アジャイル開発でプロジェクトを進めている現場では、やるべき作業を表す付箋や、進行状況を示すチャートをプロジェクトルームの壁に貼って状況を見える化し、共有している光景をよく見かける。 本稿では、昨今のアジャイル開発プロジェクトで広く浸透している見える化の手法を見ていく。その中で、チーム全体がプロジェクトの今の状況を把握し、開発者の自律的な作業を可能にし、協調作業を促進する、三つの視点(とき、こと、ひと)をうまく使うかんばんボードの利用法を提案する。そして最後に、三つの視点によるプロジェクトの見える化を実現している、かんばんボードのソフトウェアによる実装 “TRICHORD” を紹介する。 アジャイル開発プロジェクトにおける見える化 XP(eXtreme Programming)の中に、“情報発信する作業場所”というプラクティスが紹介されている。これはプロジェクトの進行状況を、一目で把握できる
迷ったら狩野さん！...狩野分析法による優先度付け - 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開発では「優先度順に要件（フィーチャ）を開発していく」のが基本だが、いざ優先度をつけようにも話は簡単ではない。発注側に強力な指導者がいてその人が独裁的
[Think IT] 第3回：中身の濃い進捗報告会を作るには〜前編〜 (1/3)
この連載には、ユーザ企業代表C社の新プロジェクトリーダー・結佐（ゆうさ）氏と、開発ベンダー代表R社の若きエースプロジェクトマネージャー・弁田（べんた）氏が登場します。 両者の間には立場の違いから来るギャップがありますが、それを埋めるためには、リアリティをもったプロジェクト像を描いて両者の認識をあわせるとよいという思いのもと、2人は奮闘しています。 今回の話のテーマは、プロジェクト管理に欠かせない「課題管理」です。ここで紹介するやり方ですべてのプロジェクトがうまくいくとはいえませんが、どのようなことを工夫すれば、大量の課題をうまく管理していけるのかをみていきましょう。 キックオフを無事終えた弁田氏がほっとしていると、そこへ結佐氏がやってきた。 結佐「いよいよ、これから本格的にプロジェクトが開始しますね。あたりまえの話ですが、今後プロジェクトを進めていく上で、課題はしっかり管理していく必要があ
redMine｜Ruby on Railsで作られたプロジェクト管理ツールredMineを使ってみよう!:第1回 プロジェクト管理ツールの必要性/Tracとの違い/redMineがオススメな理由|gihyo.jp
プロジェクト管理ツールの必要性 みなさんのプロジェクトは上手に運営できていますか？ プロジェクトメンバーのタスクの進捗管理はできていますか？ 問題・課題管理はスムーズに行えていますか？ ExcelやWord、紙資料を用いた管理で、作業が煩雑になっていませんか？ 進捗報告ミーティング用の会議資料作成やチームメンバとの情報共有のために、大きく時間を取られていませんか？ ファイルサーバには必要かどうか判断できない無駄な資料があふれかえっていませんか？ ソースコードはきちんと管理されていますか？ リリース用のソースコードに、どんな機能が盛り込まれ、どんな不具合が解決したのか、ちゃんと把握できてますか？ プロジェクトが混沌としてくると、ドキュメントやソースコードの構成管理がぼろぼろになり、プロジェクトメンバの作業の進捗具合をリーダが見通せなくなります。その結果、上記のような問いかけに対して「できてい
ギリガン島からの脱出
Jeff Atwood / 青木靖 訳 2007年6月18日 スティーブ・マコネルの書いた開発プロセスで良くある誤りのリストと、その付録のケーススタディを年に1度くらいは見直しておくと助けになる。私が前にも同じ話しをしているようだったら止めてほしい。 ｢ねえマイク｣トーマスが言った。｢プログラムを今日引き渡して、それを『機能完成版』だと言うことだってできる。だけど仕上げをするのに、そのあとたぶん3週間 くらいかかる｣。マイクはその｢仕上げ｣というのが何を意味しているのかトーマスに尋ねた。 ｢それぞれのページに会社のロゴがまだついていない。それから代理店の名前と電話番号をページの下の方に出すことになっているけど、それもやってない。なんかそういった細かいことだよ。重要なところはすべてちゃんと動くようになっている。99パーセントできているんだ｣ ソフトウェアの古い諺に言うように、｢タスクの最初の
ソフトウェア生産性におけるプロジェクト管理の諸問題(抄録):石井康雄
[抄録] ソフトウエア生産性の問題を扱うのに技術面と管理面の二つの接近法がある。ソフトウエア開発工程のほぼ40～50％がデバッキングに費されるといわれている現状にあっては、技術面の充実が急務と考えられ、新しい技法やツールの研究開発が重視されているのは当然である。しかしながら管理面の重要性も今更いうまでもない。技術的に良いとわかっていても予算、制度、組織の問題のために実現がおくれるということは時として耳にすることである。また、人の配置や外注管理の問題が生産性に重大な影響を与えることもある。教育訓練の問題は技術的にも管理的にも基本問題の一つとなっている。更に、プロジェクトの開発計画とその管理に欠陥があれば、単なる技術水準の差では考えられないほどの大きな損失を招きかねないことは、ソフトウェア開発の事例に明らかである。 技術面からソフトウェア生産性の問題に接近することはソフトウエア工学に関する多く
ソフトの「価格下落」は止まらない日本のIT企業は構造変化を見逃すな
「ソフトウエアのコモディティ化は避けられない。目指すべきはソフト製品とサービスのハイブリッド企業だ」。日米のソフトウエア産業を長年にわたり研究してきたマイケル・クスマノ氏は、こう主張する。日本のソフトウエア企業がハイブリッド企業に脱皮するには、品質と生産性のマネジメント、グローバルな視点でのリソース活用が必要と指摘する。（聞き手は桔梗原 富夫） 『ソフトウエア企業の競争戦略』という著書のなかで、「ソフトウエアのコモディティ化が進んでいる」と指摘していますね。ソフトウエア産業の現状をどう見ていますか。 現在のソフトウエア産業は、新しい競争の局面を迎えていると言えるでしょう。最も大きいのは、売り上げ構造の変化です。ソフト製品の販売でどうやって儲けるか、ビジネス・モデルを確立するのがますます難しくなりつつあるのです。 実際、多くのソフトウエア企業では、ソフト製品の売り上げが減少しています。代わっ
プロジェクトのはじめに計画を立てるのは無謀 ― ＠IT情報マネジメント
大半の組織では、各種アプローチのパフォーマンスや有効性を評価するためにさまざまな形で評価値を利用している。評価値のないものは、順調かどうかを判断するための主観的な意見にすぎない。評価値は必須なのだ。だが、評価値には用心が必要で、リソース利用率の有効性を実際に知りたい場合は産出量（生産性）の増加を評価するように、多くの場合、本当に知りたいものを直接評価することはできない。 評価値にはもっと難解な面もある。人は評価するものに注目し、評価されるものが重要だと仮定する。評価値が直接価値に結び付かなくても、評価が行われると考える分野のパフォーマンス向上に努めていく。カギとなるのは受け止め方だ。マネージャは、1つのことを公然といいながら評価値を通じて別のことを強調し、言葉に出した目的を事実上台無しにすることがある。評価値は、評価されているものが有意義であることを暗示する。 ポイントになるのは、人は評価
日本のソフトウエア生産性と品質は世界最高水準〜なぜ日本のソフトは国際競争力がないのか。 - 木走日記
●日本のソフトウエア生産性と品質は世界最高水準〜ではなぜ日本のソフトは国際競争力がないのか。 私の知人のアメリカ人スティーブ氏はＩＴコンサル業として長年日本で日本人スタッフとともにシステム開発に携わってきました。 同業者でもある彼は私の良き飲み仲間でもあり、私とは長年仕事の話から政治・経済の話まで本音で話のできる間柄であり、そして双方の奥さん同士も親友という家族ぐるみのつきあいをさせていただいております。 彼の日本のＩＴ業、特にソフトウエア開発業に関する知見は、日米双方の開発現場を渡り歩いてきた技術者として、とても参考になるのであります。 彼は大の親日家であり、ＩＴ業を通じて日米の架け橋となることを生涯の仕事と心に定めているのであります。 ■日本には下らない商習慣が多すぎる スティーブ「しかし日本のこの会計年度が３月末に集中している悪習はどうにかならんかね。なんで年度末になるとこうも忙しく
どうしたら日本のソフトづくりは強くなれるか？ － ＠IT
2006/12/19 ソフトウェア開発の効率性を考える時、よく引き合いに出されるのが「トヨタ生産方式」（TPS）である。1990年代、米国の製造業界はTPSを参考に、「リーン方式」「アジャイル方式」という管理手法を編み出し、日本に逆輸出した。現在のソフトウェア業界で話題にされるアジャイルなソフトウェア開発という考え方は、製造業における作業効率化のプロセスをソフトウェア開発に応用したものと考えられる。しかし、名古屋工業大学テクノイノベーションセンタ客員教授（トヨタ社友）の黒岩恵氏は、そんなソフトウェア業界に懐疑の目を向ける。 批判の核心は、ソフトウェアの製作工程における過度の分業化と、それに付随する人月見積もりである。日本のソフトウェア業界は、特に人月見積もりについては、現場から不満の声が上がっているのは確かだが、いまだに見積もりの尺度として活用されているのは事実だ。黒岩氏はそれを米自動車産
カイゼンを実践するマインド − ＠IT情報マネジメント
情報システム開発を取り巻く状況は複雑化の一途を辿っている。高品質な成果物を効率良く開発するには、“それなりのアプローチ”が求められ、また品質の確認を行うためのテスト作業を、開発工程の中にあらかじめ組み込んで、致命的な失敗を回避する策を講じておかなくてはいけない。牧歌的な時代は終わった。われわれはつねに失敗ソフトウェアの作成に荷担する危険性を担っているのだ。 1 最近のシステム開発を取り巻く状況 1.1 情報システムの役割の変化 多くのビジネス分野において、情報システムは、単なる業務処理の効率化ツールから、ビジネスを提供するための基盤としての役割を担うように変化してきています。銀行、証券、保険業界はビジネスの成り立ちとして情報システムがビジネスの基盤となっているのは当然ですが、このようなビジネスドメイン以外でも、情報システムは、生産から加工そして販売までの一貫した商品のトレーサビリティの要求
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
InfoQ: ベンチャーキャピタルグループが残業はスクラムに害をもたらすと認める
生産性第一主義によって余儀なく下された決断：原因、巻き添え、限界
Amazon.co.jp: アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き: Esther Derby (著), Diana Larsen (著), 角征典 (翻訳): 本
ソフトウェア開発の秘伝“Development Baseline 2007” ― ＠IT
常時結合のススメ（1/5） - ＠IT
http://hotwired.goo.ne.jp/original/maegawa/050118/index.html