第1回 真・開発プロセス
「月刊Windows Developerマガジン」（翔泳社 発行）の人気連載「降ればどしゃぶり」の筆者 だいだひろ氏 がITpro Developmentに登場。システム開発の現場で起こっている暗黒面に容赦なく光りをあて，教訓と改善のきっかけをもたらす！（と思う）。 はじめまして。だいだ ひろです。突然ですが，私は性格が悪い。どのくらい悪いか？ アメリカで「コンピュータのような先端技術は，優秀な白人じゃなきゃできない」と言っていた白人女性に対して，「われわれ日本人は天皇を神と信じていたが，進化論裁判はやらなかった。あんたたちは？」と質問するくらい，悪い。要するに「相手が触れてもらいたくない事実をあぶりだして恥をかかせる性格」と考えてもらえれば，私の性格の理解として間違いはない。 今回のコラムではこの性格の悪さを思う存分発揮したい。なぜか？ 皆さんがシステム開発の現場で直面しているIT業界の
[ThinkIT] 第1回：こんなにあるオープンソースのプロジェクト管理ツール (1/3)
プロジェクト管理用のソフトウェアといえば、定番のMicrosoft Office Projectをはじめ、これまで様々な商用の製品が存在しました。一方で、従来からオープンソースのプロジェクト管理ソフトウェアにも様々なものがあります。 例えばソフトウェア開発に従事されている方であれば、Edgewall Software社が無償で提供している軽量バグトラッキングシステムの「Trac」を使ったことがあるのではないでしょうか（図1）。 ただし、このような従来のオープンソースのプロジェクト管理ソフトウェアの多くは、目的が限定されているものや基本的な機能のみを実装するものが多く、企業の汎用的なプロジェクト管理に使えるものが少ないのが現状でした。 その背景の1つとして、オープンソースソフトウェアがWebアプリケーション技術に依存しているケースが多く、ガントチャートなど視覚に訴える機能を実現することが技術
最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 ― ＠IT
2007/07/05 日本情報システム・ユーザー協会（JUAS）は7月5日、ユーザー企業102社の357プロジェクトを調査した「ソフトウェアメトリックス調査2007」を発表した。システム開発の企画、開発計画に始まり、保守や運用管理まで実態を調査した内容で、企業情報システムの実態を伝える。調査結果からは“デスマーチ”となるプロジェクトの実態も浮かび上がった。 デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。だが、「（短
igaiga diary(2007-06-20)
_ 思いやり駆動開発 オブジェクト倶楽部夏イベントに参加して、 LTを「思いやり駆動開発」という題で行い、 ベストトーカー賞を頂きました LTで喋る前からみなさんに「がんばってください！」と励ましのお言葉を頂いたり、 喋ったあとも「おもしろかったですよ！」とありがたいお言葉を頂いたり、 懇親会でぼそっと「今週末で30になります」と言ったら みんなでハッピーバースデーを唄って頂いたり、 みなさんのおかげでとても楽しい1日を過ごすことができました。 とてもとても幸せな1日でした。 本当にありがとうございました。＞ご参加のみなさま また詳しい話は追々この日の日記に追記していきます。 発表資料も後日UPします。 ひとまずコミュだけ作りました。 つ【ODDユーザーグループmixiコミュニティ】
ODD - おもいやり駆動開発：An Agile Way：オルタナティブ・ブログ
思いやり駆動開発（ODD） ソフトウェア開発を成功させる、もっともシンプルな「こころがけベース」のアプローチである。オブジェクト倶楽部2007夏イベントで発表された。ここでは、ついカッとなって私なりにこのコンセプトを膨らませてみたい。 ソフトウェア開発はコミュニケーションでできている。ソフトウェアの欠陥が発生しやすいのは、人と人の境界、プロジェクトとプロジェクトの境界。そしてそこにはコミュニケーションが生まれている。コミュニケーションには相手があり、その相手を「思いやる」ことが、大切だ。読み手のことを思いやるコードを書こう。システムのユーザを思いやる仕様にしよう。そんなシンプルな「こころがけ」だ。 具体的には、こういうこと。 システムを実際に使う「ユーザー」を思いやろう。ストレスなく使え、「思った機能がそこにある」ようなシステムにしよう。そのユーザが普段使っている言葉のUIを提供しよう。製
なぜ、diffのpオプションが重要なのか - L'eclat des jours(2007-06-15)
_ なぜ、diffのpオプションが重要なのか diffには、-pというオプションがあって、これを指定すると変更された関数名が含まれる。 例） /tmp$ diff -u test.c test2.c --- test.c 2007-06-15 01:12:37.886290094 +0900 +++ test2.c 2007-06-15 01:17:49.292036097 +0900 @@ -4,6 +4,9 @@ for (i = 0; i < 100; i++) { n *= i; } + if (x) { + n ** x; + } return n + x; } /tmp$ diff -pu test.c test2.c ← p付き --- test.c 2007-06-15 01:12:37.886290094 +0900 +++ test2.c 2007-06-15 01:1
MOONGIFT: » コラボレーション2.0「Mindquarry」:オープンソースを毎日紹介
コラボレーション2.0「Mindquarry」 2007/06/15 Windows, Mac OSX, Web, オープンソース Linux, GUI, Java, Wiki, Firefox, IE, Perl, Ajax, コラボレーション, プロジェクト管理, ビジネス, Mozilla Public License 物凄くよさそうなソフトウェアを見つけてしまった。これはぜひとも試すことをお勧めしたい。 プロジェクト管理する上での基本といえば、情報の統合管理、タスク管理、そして生成物のバージョン管理などが基本になると思う。その点において間違いなく役立つソフトウェアだ。 今回紹介するオープンソース・ソフトウェアはMindquarry、リッチなインタフェースを持ったコラボレーションソフトウェアだ。 Mindquarryに実装されている機能は主に4つに分けられる。チーム管理をベースとして
ポストモダンプロジェクトマネジメント - 思っているよりもずっとずっと人生は短い。
メモ。この前角谷さんと話した内容を下敷きに。 プロジェクトマネジメントはポストモダン化しつつある。 キーワードは「感情管理」。近代的なプロジェクト管理では、作業者は機械と同様、定量的なタスクをこなす装置（機械）と考えられていたが、現代的なプロジェクト管理では作業者の感情にフォーカスする。これはチームのメンバーにもリーダーにも当てはまる（リーダーの方がより強くあてはまる）。 ポストモダンプロジェクトマネジメント技法の代表例としてコーチングとファシリテーションが挙げられる。前者は規律訓練型、後者は環境管理型の側面が強い。コーチングが主にリーダーに対し、その振る舞いを規定し、強要する一方、ファシリテーションではその意図を不明確に・あるいは隠蔽し、メンバーの感情を暗黙のうちに管理しようとする。高度なファシリテーションではリーダーすらも暗黙のうちに管理されるようになる。 プロジェクトマネジメントがポ
ウノウラボ Unoh Labs: バグの状態でプロジェクトの状態を知る
こんにちは！やまもと＠テスト番長です。 以前バグのステータスというのを書いたのですが、その最後の方で続きがあるようなことを申したら、気になるから教えろという奇特な方がいらっしゃいましたので今回は続きを書いてみましょう。 BTSはバグを管理するだけの道具ではありません。バグを追いながら適切に記録をつけて統計を取ることで、プロジェクトやチームの状態を知ることが出来ます。例えば、以下のような事象です。（なお、WEBアプリが前提） ・バグの報告数が増えず、結果がVERIFIEDになることが多い。 →まだデバッグが始まったばかりのプロダクトか、慎重過ぎるテスターがアサインされています。 ・バグの報告数が少なくなり、VERIFIED以外の結果が目立つ。 →デバッグは最終段階を迎えています。もしもまだ納期前ならば、それなりに上手く行ったプロジェクトでしょう。 ・NEWが発生してからRESOLVEDに
プロジェクトリーダーは十二分な準備で自信を生み出せ
プロジェクトリーダーは十二分な準備で自信を生み出せ：ユーザーサイド・プロジェクト推進ガイド（10）（1/2 ページ） 広く深い検討の仕方 前回「プロジェクトチームのリーダーに向く人、向かない人」で、リーダーには自信が必要であり、努力と十二分な準備によって獲得できると述べました。十二分な準備とは広く深く検討することです。 人類にとってまったく未知のプロジェクトであれば話は別ですが、世の中一般の“未経験プロジェクト”はたいてい、問題解決のヒントや解が手の届くところ──例えば担当部署などの相談相手、書籍・Web上のドキュメントなどで見つけることができるものです。要は、自分にとって未知であっても、ヒントや解を素早く見つけ無駄なく利用する方法を知ることです。 5W2Hと5times why 広く検討するということはさまざまな方面から検討するということであり、ケース・前提条件・制約条件の種類と程度を考
現場の叫びで分かった嫌われるプロマネの正体 － ＠IT自分戦略研究所
プロジェクトをマネジメントするどころか、メンバーを地獄に陥れるようなプロマネの正体を暴く。現場の悲痛な叫びはプロマネに届いているだろうか。（Tech総研／リクルートの記事を再編集して掲載） 複雑化・高度化した現代の技術。1人のエンジニアが、1つの案件を仕上げることができるケースなどほとんどない。そこで重要になってくるのが、メンバーを率い、プロジェクトをまとめ上げるプロジェクトマネージャ（プロマネ）の力量だ。しかし……。 Tech総研が、主にIT分野のエンジニア100人に行ったアンケート調査によれば、これまでにプロマネの下でスムーズに進めることができたプロジェクトは5割に満たないと答えたエンジニアが、何と88％にも上っている（図1）。しかも、そのうち79％が、別のプロマネであればうまくいったはずと答えているのである（図2）。
実践！ 自己組織化プロジェクト
前回のまとめ ～ すべてのものを「粒」で考えてみよう 前回の「アリの生態にみる自己組織化のルール」では、プロジェクトマネジメントと一見何の関係もない、「アリ」の社会的行動が、シンプルなルールにのっとって自立的に機能している開発プロジェクトと同じ現象～「自己組織化」という現象なのではないか？ ということを述べました（比喩的に似ているのではなく、同じ現象なのではないか？ というのがミソです）。 そこで、この「自己組織化」現象をさらに推し進めるため、プロジェクトのあらゆるところで、自然のプロセスに倣い、 大きさのそろった「粒」をできるだけ増やすこと 「粒」と「粒」との連携は可能な限りシンプルにすること 「粒」と「粒」との連携方法に例外をなくすこと という、シンプルなルールを当てはめるとよいのではないか、という結論を書きました。あらゆるものを「粒」としてそろえられないか？ と考えるところがポイント
Another brick in the wall | MindMap駆動プロジェクト管理
私はUMLのモデリングツールとしてJudeを使っています。 このJudeの最新版にはマインドマップを作成する機能(有料版のみ）があり重宝しているのですが、マインドマップの要素をUMLのモデルに変換できます。 この機能をうまく活用してプロジェクト管理に活かせる方法を思いつきました。 私がプロジェクト管理を行う場合、以下のアクションを繰り返します。 (1)WBSの項目に対してタスク分析を行いTo Doを抽出する。 (2)リスク分析を行いTo Doを抽出する。 (3)定期のミーティングでTo Doを抽出する。 (4)状況分析を行いTo Doを抽出する。 (1)〜(4)の分析はマインドマップを使用することが多く、いつも 分析結果から抽出したToDoをEXCELの表に転記する方法を取っていました。 Judeのマインドマップテンプレート、マインドマップからモデル
アジャイルと大きめプロジェクトと、「スクラム」という新しい単語【与太】 - kokepiの日記
スクラムという開発スタイルがあるらしい。 スクラムとは、チームとそのサイクルを意味するもので、次の5つのプラクティスからなるスタイルだそうだ。 http://www.tech-arts.co.jp/agile/agile8.html 【スプリント】 30日ごとに課題を決める 【スプリント・レビュー】 30日終了後に、関係者全員でレビュー＆次を決める。 【バックログ】 残り課題リスト。 【スクラム・ミーティング】 毎日ミーティング。 【スクラム・マスタ】 チームを前進させ、守り、責任を持つ。 なるほど。 おれの勤務先での開発スタイルは 基本的には週単位でリリース 週に1時間、社内全関係者で次の週の課題（機能、バグ）を決める 開発タスク（や要望、不具合）は全部BTS（影舞）管理 週の課題として決まったら「受付」ステータス 毎朝、技術スタッフは、下記についてスタンドアップミーティング 昨日やった
わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え（まとめ）
この連載を始めたのは、Waterfall 2006を見たから。ついカッとなって書いてしまった。今は反省している。この連載は体系的じゃないし、blog よりむしろ出版物の形で問うべき。何よりも、今週の睡眠時間を大幅に犠牲にしてきたので、眠くてたまらん。 …というわけで、ここでは総括＋補足して締める。 ウォーターフォール・モデルとは、プロジェクト構造化モデルと言い換えられる。その特徴として、以下のことが挙げられる。（その1） プロジェクトを構造化し、段階を踏んで要素成果物を構築する 次に、必要な要素成果物を適切なタイミングで持ち寄り、組み上げる 要素成果物を構築する工程はスパイラル・モデルを適用できる。しかし、組み上げる工程は逐次的であることが求められる プロジェクトを構造化することにより、プロジェクトを「見える化」できる。全体と部分、出来てるところと空白のところが分かる。未確定事項がオープン
わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え（その5）
ウォーターフォールの怨嗟の的になっているのは「ドキュメント」だろう。使うかどうかも分からぬような大量のドキュメントを書かされる。しかも顧客の一言で大幅に書き直しを命ぜられる。さもありなん。だが、ここでは、ウォーターフォール・モデルにおけるドキュメントの必要性を強調する。 ドキュメント＝契約書 なぜドキュメント化が嫌われるのか? SEの立場から言うと、ちゃんと検討していないまま、「とりあえず」ドキュメント化をさせられるから（結果、後から手直しが多発する）だろう。PGの立場からすると、理解してコードに落とすだけの内容を、なぜ語弊の出る日本語に書き直さなければならないか、疑問に思うだろう。 本当の問題はSE/PGがドキュメントを書いていること。あるいは、片手間にドキュメントを書いていることをなんとかすべき。本来なら専門部隊を準備するか、リソースを明示的に割り当て、執筆期間を設ける必要がある。 こ
わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え（その4）
決めるべき2つの日どり 二つ目の戦略。それは「日どり」だ。「あいまいな仕様」が"今は"決まってないことを顧客自身の口から言ってもらった後は、何月何日までに仕様凍結するかプロジェクト全体のスケジュールの中で顧客と決める。「仕様の再確認」ができていない以上、そいつができる日はいつなのかを決める。 こいつを最初に決める。ここを過ぎると挽回が不可能とうい点「ポイント・オブ・ノーリターン」を"今"決める。ここまでギッチリ動機づけしておけば、仕様凍結の最大の脅威「先送り」を回避できる。 あるいは、こっちの方がもっと重要なのだが、「仕様凍結を先送りしている事実」を共有できる。極端な話、仕様が凍結されていないのが問題なのではない。仕様が凍結されていないことが公になっていないまま、先へ進んでいるほうが深刻なり。 表向きは仕様は固まっているはずなので、顧客からは口頭や電話だけで「指示」がくる。当然、仕様書は書
わたしが知らないスゴ本は、きっとあなたが読んでいる: ウォーターフォールはこう使え（その3）
ちょっと思い出して欲しい。次の弾丸が飛んでくるのはいつだろうか? 「すでに決まったはずではないか」 「そう読み取れるではないか」 「いまさら言われても困る」 よい子のみんなはもちろん分かってる。納品が間近に迫ってきたときだね。品質がアレなのか、そもそもマトモにできていないことが明らかになったか、トリガーは様々だけど、たいていはプロジェクトも終盤になってそんな弾丸が飛んでくる。 これは「仕様のあいまい性」を先送りしてきたツケだ。実はこの弾丸、プロジェクトを通じて3度発射する機会があるという。 1回目：顧客との契約時、仕様の確認をするとき 2回目：ベンダーと請負会社の契約直前に、請負会社から仕様の確認を求められ、顧客に問い合わせるとき 3回目：火ダルマになっていることが知れ渡り、顧客が乗り込んできて「こんなのを作れなんて言ってない」と言い放つとき .…にもかかわらず、3回目がほとんどだろ。この
[を] スクラム(scrum)という言葉を聞き及んだのでメモ
スクラム(scrum)という言葉を聞き及んだのでメモ 2006-02-14-4 [仕事] はてなダイアリー - スクラムとは <http://d.hatena.ne.jp/keyword/%a5%b9%a5%af%a5%e9%a5%e0> アジャイル開発手法の一つ。[...] プロジェクト管理が弱いとされるeXtreme Programming (XP)を補完される 形で併用されることが多い。 主なプラクティスは - スプリント：30日間のイテレーション - 日次スクラム：毎朝行う15分程度のミーティング - プロダクトバックログ：優先順位付けされた製品の仕掛かりリスト - スプリントバックログ：スプリント中に行う仕掛かりリスト なるほど！ そもそもどういう位置づけのものなのか、が分かった！ Technologic Arts Incorporated--推進技術
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TechCrunch Japanese アーカイブ � Basecampに無料ソフトのライバルが！
