仕事の行動指針はITのメカニズムに学ぼう
プロジェクト管理支援のコンサルティングをしていると、こんな笑い話を聞くことがある。「開発チームのリーダーが先週まで“予定通り”と報告していたが、今週は“2週間遅れ”と報告してきた」というものだ。1週間しかたっていないのに2週間遅れるのは変だと言いたいわけである。 こういう報告を弁護するわけではないが、遅れを認めたくないリーダーの立場で考えれば内情はある程度推察できる。よくあるのは、先週の報告は「普通にやれば1週間遅れだが、無理すれば予定通りにできる見込み」という意味である。うまくいけば進捗遅れの事象はなかったことにできるはず。しかし、今週その無理をしようとして、1週間空転した揚げ句に断念した。よって今週の報告は「2週間遅れ」になっている。ここでいう無理とは、徹夜や休日出勤、増員要請といった挽回策だ。 このような状況を指して、プロジェクトの進捗管理が機能していないと論評するのは簡単だが、管理
チケットの粒度と進捗ビューの関係 - プログラマの思索
チケットの粒度と進捗ビューの関係について、考えたことをメモ。 【元ネタ】 TiDD初心者によく聞かれる質問part2～チケットの粒度はどれくらいが妥当ですか？: プログラマの思索 【1】チケットの粒度はどれくらいが妥当か？という質問はよく聞く。 RedmineやTrac、Mantisで色々試行錯誤した結果、気にせず登録した方がいい、という回答にしている。 その代わり、トラッカー(ワークフロー)単位では粒度を揃えて、ビューによる切り替えを上手く使えばいい、と回答することにしている。 前者の回答は、チケット駆動開発を運用した場合、チケットはタスク、要望、課題、問合せなど色んな種類があるので、そもそも観点が異なるし、粒度を揃えること自体が無意味だからだ。 開発者の観点では、チケットの粒度を揃えて綺麗にチケットを書くよりも、成果物を早く作るための作業記録代わりにみなした方がいい。 Agile開発な
プロセス改善活動についての新たな手法とその適用のためのツール類を公開
2011年12月1日 更新 2011年7月7日 公開 独立行政法人情報処理推進機構 技術本部 ソフトウェア・エンジニアリング・センター 概要 IPA/SECでは、ソフトウェアの開発プロセスに問題意識を持つ技術者を対象に、プロセス改善の新たな手法として「SPINA3CH （*1）自律改善メソッド」と、このメソッドを適用するための利用ガイドブックおよびワークシート3種からなるツール類を公開しました。 携帯電話をはじめ、銀行のATM、水道・電気などのライフラインの制御システムなど、ソフトウェアはさまざまな場面で利用されています。それらソフトウェア開発の現場では、安全で使いやすい多様な機能の実現と同時に、市場の競争激化によるコスト削減や厳しい納期要求に応えることが求められています。 ソフトウェアプロセス改善とは、ソフトウェア（製品）の品質の安定・向上を達成するために仕事のやり方を工夫する取り組みで
ソフトウェア開発に本当に必要なものは人手か？ | Social Change!
当たり前のことなんですが、100人月のソフトウェア開発があったとして、100人投入したからといって1ヶ月で出来る訳がないですよね。なのに、そのパラメータは可変だと信じている人がまだまだ多いです。しかも、1人月のバラツキをなくすために生産性の低い方に揃えるなんて馬鹿げています。私はソフトウェア開発で最も重要なパラメータは「期間」だと考えています。かける工数の時間ではなくて、あいた時間も含めての期間です。 SonicGardenでは月額定額のサービス型の受託開発を行っています。その詳しい説明は別の機会にしますが、ポイントは月額定額という点です。月額定額なので、可変できるパラメータは「期間」だけになります。そのポリシーの背景には以下の考え方があります。 ・アジャイル開発のボトルネック ・Publickey「納期を半分にしてくれ、金なら出す」 大規模なソフトウェアを作るには、大人数が必要と考えがち
スケジューリングは最適化の問題ではない | タイム・コンサルタントの日誌から
旅行の予定を立てるとき、普通はまず時刻表を見る。飛行機か鉄道か、手段はさまざまだが、目的地と到着すべき時刻がはっきりしている限り、コストと所要時間を見てもっとも良い移動方法を見いだすことは簡単だ。経路が複雑な場合は手間がかかるかも知れないが、それでも最適なルートは必ずあるはずだ・・・。 こういう信念で生産計画の問題にも挑みたくなる気持ちはよく分かる。工場の稼働時間と生産能力、こなすべき生産指示と必要な資材、こうした条件がはっきりすれば、手間さえかければ最適なスケジュールを組めるはずだ。問題はその手間をいかに短くするかにある、と。 ところで、あいにくわたし自身はこうした意見に反対だ。スケジューリングを最適化問題の枠組みでとらえるべきではない。拙著「革新的生産スケジューリング入門―“時間の悩み”を解く手法」でも、その後の学会発表などでも、つねに私はこう主張してきた。しかし、なかなか理解してもら
新任リーダー学・超入門 その１ | タイム・コンサルタントの日誌から
Sさん。昇格おめでとうございます。お知らせをいただいたのに返信が遅くなって申し訳ありません。 いよいよ「リーダー」格になられたわけですが、この1ヶ月間のご感想はいかがですか。思ったより面白い、とか、思ったほど仕事の中身は変わらなかった、とか、感じ方はいろいろあると思いますが、ともあれ「マネジメント」職に一歩、踏み出されたわけです。 それにしても、「リーダー」という職名は不思議なものです。わたしの業界では「リード・エンジニア」という言い方をしますが、まあ実質は同じです。課長とかマネージャーではない。でも、責任ある立場で、後輩をまとめる仕事を任されます。小さな案件ではプロジェクト・リーダーとして、直接顧客と折衝する必要にも迫られる。つまりリーダーとは、管理職手当の付かない、しかも残業代はしばしばサービスさせられる立場に与えられた名前だ、と皮肉混じりにおっしゃりたくなる気持ちは分かります。 リー
トラブルの「技術的解決」と「マネジメント的解決」はどう違うか？ | タイム・コンサルタントの日誌から
マネジメントとは「人に仕事をしてもらう」ことであり、その仕事の最小単位を『アクティビティ』と呼ぶ、ということはすでに何度か書いた。アクティビティを規定する要素としては、アウトプット、インプット、リソース、完了条件（納期）、そして指示情報と報告情報がある（「仕事の最小単位－－アクティビティの構造を学ぶ」参照）。また仕事をちゃんと動かすために、コスト（Cost）、時間（Time）、リソース量（Resources）の3種類を、基本的なパフォーマンス指標として用いるべきことも説明した（「仕事の最小単位（２）－－アクティビティのパフォーマンスを測る」）。 さて、仕事をマネジメントするためには、もう一つ必須の事柄がある。それが問題解決である。どんなお仕事にも、問題の発生する可能性はつねに存在する。アクティビティで問題が発生した時、頼まれた側がすべて自分で即刻解決できればベストだ。だが、そうも行かない場
管理能力を放棄してしまうマネージャータイプとは--3つの落とし穴を考える
同じ仕事をしていても、それをやり遂げられる人とやり遂げられない人がいるのはなぜだろうか。企業幹部向けのリーダーシップコーチである筆者は、マネジメントにおける3つの鍵にその答えが潜んでいると考えている。 同じ肩書きを持っていても、マネジメント力を上手に行使している人と行使できていない人がいる。あなたはこの事実に気付いているだろうか。 例を挙げてみよう。他部署のリーダーに支援を要請する際、必ずといっていいほどその要請に応えてくれるリーダーがいる。その一方で、要請に応えられない理由をあげつらうことしかしないというリーダーもいる。 筆者はこの事象について、長年に渡って調査してきた。こういったことは担当者間の相性に由来するものだと捉える人もいるかもしれないが、実際のところは業界や性別、肩書き、部署の責任といった範囲を超えて普遍的に見受けられる事象なのだ。そしてこれは、以下の例のように人が職場を変えた
時間の無駄？ 進捗会議が泥沼にはまる理由
時間の無駄？ 進捗会議が泥沼にはまる理由：新任PMがついやってしまうNG集（3）（1/2 ページ） 1人で仕事をしているプログラマ時代は、ばりばり仕事がこなせたのに、PMになった途端に仕事がうまく進まない！ そんな新任PMの悩みを解決するTipsを紹介します。 会議は「時間の無駄」ですか？ 管理ツールや報告書を見ている限りにおいては、メンバーの仕事は何事もなく順風満帆に進んでいるように見えます。進捗（しんちょく）率も予定どおり推移中。 しかし、「進捗率」の数字なんて当てにはなりません。そのことに、あなたもうすうす気が付いているでしょう。実際、進捗会議で確認してみると、予定どおりの数字と実態がまったく違っていたり、問題が山積みだと発覚することはよくあります。その事実についてメンバーが指摘すると、「そもそも仕事が忙しすぎるのが悪いんですよ！」と逆ギレされて、進捗会議が泥沼にはまってしまう……そ
「大丈夫」という部下の報告を信じてはいけない理由
1人で仕事をしているプログラマ時代は、ばりばり仕事がこなせたのに、PMになった途端に仕事がうまく進まない！ そんな新任PMの悩みを解決するTipsを紹介します。 「あのメンバー、仕事の進捗（しんちょく）は大丈夫かな？」 PM（プロジェクトマネージャ）なら、誰もが気になるところです。 「予定の期日に間に合います！」というメンバーの力強い返事を信じて任せていたら、完了予定日になって「実はまだできていませんでした」という相談が来て、結局対応に追われるはめになる……そんな経験はないでしょうか。 しかも、往々にしてこのようなことは1回だけでなく、何度も繰り返し起こります。一段落した時、メンバーに仕事が遅れた理由を聞いても、返ってくるのは「申し訳ありません」という平謝りと「今後はしません」という形ばかりの口約束だけ。 こんな調子じゃ、安心して仕事を任せられません。しかし、こんなふうになってしまうのには
東電トップはどうするべきだったのか――マネジメントを考える
組織図はあるが、組織が存在しない会社は多い。つまり、組織が機能していないということだ。マネージャーや部長などという役職には就いていても、マネジメントできていない組織というのは、人が育つこともなく、当然、会社の目標を達成することすらできない。 マネジメントとは何か？ 役職をもらっていながら、この基本的な質問に答えることすらできない人も多い。何を求められ、何をなすべきなのか？ 考えるべきことは、キリがない。そのポジションでしか気づかないことも多い。「マネジメントできない」ということは、組織において大いなる損失となる。 理想のマネージャーとは？ では、マネージャーとはどうあるべきか？ 部下の「足らず」を補う 分かりやすい言葉である。マネージャーが部下と同じことをやっているようでは、その部下はいらないのかもしれない。もしくは、そのマネージャー自身がいらないのかもしれない。会社からみれば、そう思う。
3年使ったRedmineの使い方について共有したい10のこと
前回は、1000人のエンジニアがRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。 1. Redmineのオブジェクト構造を理解した方がいい Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。 プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ 注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考
「計画的にやれ」が悲しいほどメンバーに通じない理由 − PG時代と何が違う？ 新任PMがついやってしまうNG集 − ＠IT自分戦略研究所
1人で仕事をしているプログラマ時代は、ばりばり仕事がこなせたのに、PMになった途端に仕事がうまく進まない！ そんな新任PMの悩みを解決するTipsを紹介します。 お悩みのPM諸君、ついこんなこと言っていませんか 同じ「プロジェクト」に関わるにしても、PM（プロジェクトマネージャ）になる前と後では大違いです。プログラマの1人として働いている時は、自分の作業に専念していればよかったのに、PMになった途端「顧客から新しい要望が来た」「○○さんの作業が遅れている」といってはフォローに追われる日々。「何で皆、ちゃんと動いてくれないんだ！」とストレスをためるPMも多いはずです。 ですが、「自分が動くこと」と「人に動いてもらうこと」が違うのは当然のこと。ですが、ついそのことを忘れて、こんなことを言ってしまうPMは多いのではないでしょうか。 これらはPMの発言としては“NG”です。いくら口をすっぱくして注
Redmineが1000人のエンジニアに使われるまでのこと
デブサミ2011の後に、Shibuya.tracの第10回勉強会で初LTをしました。テーマは「EnterpriseレベルのRedmine導入結果について」です。外の勉強会は緊張しますが、@yusuke_kokuboさんや@akipiiさん、アジャイルなゆかいな仲間たちにお会いすることができ、とても楽しい勉強会でした。また学びに行かせていただこうと思います。 はじめに 上の資料はそのときのものです（Slideshareはこちら）。5分間のLTだったため、あまり詳細をお話しすることができませんでしたが、勉強会の時に知り合った方と、今度、Redmine導入＆運用の情報交換会を企画しており、そこで共有するネタとして、まずは、Redmine導入時の経験をここにまとめようとおもいます。まずはその前に、私の仕事内容を少しだけ説明させてください。 標準化とか全社共通とかいう仕事 私は入社以来、サービス開発
受託開発でTracを導入してよかったことや失敗したこと
Trac、Redmineといったチケット形式のプロジェクト管理ツールが人気となっています。 デブサミ2011では、[デブサミ]速報：2011ベストスピーカー賞(敬称略) via IWAKIRIさんのブログにもありますように、ベストスピーカー賞3つのうち、2つがチケット管理システムに関しての発表でした。「チケット管理システム大決戦」というセッションは、デブサミ史上最大の観客数となったと聞いています。 なぜ、プロジェクト管理ツールがここまで注目されているのでしょうか？ 開発の現場はそれぞれ異なり、抱える課題も様々だと思います。しかし、プロジェクト管理の中でもタスク管理に関しては、「作業を適切なサイズに分割する」「優先順位をつける」「人をアサインする」という固定のパターンがあり、さらに、現在のアジャイルムーブメントにより、これらの要素がより明確化され、その重要性が認識されてきたように思います。
TiDD初心者によく聞かれる質問part1～チケットが放置されがちです #tidd - プログラマの思索
チケット駆動開発についての質問のうち、「チケットが放置されがちだがどうすればいいか？」「チケットの粒度はどれくらいがいいのか？」の二つはいつも聞かれる。 最初の質問について、自分なりに考えたことをメモ。 【元ネタ】 チケット駆動開発を導入しても変わらないこと - Basic まずは箇条書きより始めよ - Basic デベロッパーズサミットまとめ【チケット管理システム編】 ? prototype002 【1】「チケットが放置されがちだがどうすればいいか？」という質問の背景を類推すると、チケットを起票する運用はできているものの、チケット管理ができてないことを意味する。 チケット一覧画面で、一生懸命チケットをフィルタリングしながら、どのチケットが遅れているのか、どう対処すればいいのか、必死になって考えている間にも、どんどんチケットが増えていってしまっているのだろう。 チケットが放置されがちな状況
まずは箇条書きより始めよ - rabbit2goのブログ
昔、ソフトウェア開発のベテランの方に質問したことがある。 「どうしたら優れた開発者になれるのでしょうか？」 予想していた回答は「この本を読め」とか「あれを学べ」と言ったものだったのだけど、実際の回答は全然違っていた。 「自分の作業を箇条書きで表現出来るようになることだ」 これだけでは腑に落ちないので、その理由を聞いてみたところ、こんな説明が返ってきた。自分がやるべき範囲がどこまでなのか、何が必須項目の作業であり、何が見送り可能な項目なのか、作業に必要なものは何なのか等々を全て考えば、簡潔に箇条書きで表現できるはずだ。箇条書きで表現できないのなら、それは自分がやるべき事を自分自身で分かっていないことの証拠に他ならない。開発者は実際の作業の中でアレコレと疑問を持つはずなのに、それを確認しないまま勝手に作業を進めてしまい、後で予期せぬ問題を引き起こすことが多い。本当の開発者なら、その確認、検証、
仕事の最小単位－－アクティビティの構造を学ぶ | タイム・コンサルタントの日誌から
「マネジメント」という行為の、最も原初的な定義は“人に働いてもらう”ことである。人に働いてもらうことで、自己の、あるいは共通の目的を、達成する。自分自身で手を動かして自己の目的を達成することは、マネジメントとは呼ばない。単に作業とか行為と呼ばれる。 あなたがもし食卓で母親に「ねえ、そこのお塩とって。」と言って手渡しもらったら、あなたは、その瞬間だけは、母親をマネジメントしているのである。母親に働いてもらって、自分の目的を達したからだ。でも、何も言わない前に、母親が気を利かせて塩をとってくれたら、もちろんマネジメントしたことにはならない。そもそも、座っているだけで目の前に夕食が出てきたとしても、たぶんそれは母親が自発的に調理をしてくれたのであって、自分がわざわざ命令を下してやらせている行為ではない。はっきりした依頼や指示や命令の有無が、マネジメントと、自発的な協調行動との境界線になる。 「は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Microsoft サポート
近頃のオンラインゲームの Agile っぽい開発手法とか 〜ONE-UP における10の取り組み〜
