ソフトウェアレビューが成功する進行役の6条件
ともすると漫然と取り組んでしまいがちなソフトウェアレビューだが、メンバー1人1人の役割を明確化すれば、非常に効率的に行うことができる。中でも司会進行役は、レビューの結果を左右する大きなカギを握ることになる。 レビューに“役割”が必要なこと、認識していますか？ 第3回『“読み方”を知って、レビューをもっと効果的に 』では、まず「何のためにレビューを行うのか」という目的を認識し、それに最適なドキュメントやソースコードの読み方を採用することで、レビューを効率的に行えることを解説しました。今回はその続編として、「レビューにおける役割分担」を紹介したいと思います。 レビューは進め方の自由度が高い分、参加者1人1人の役割があいまいになりがちなものです。そこで最初に適切な役割分担を行い、1人1人が自身の役割に集中するように心掛けると、レビューの効果・効率を大幅に高めることができます。 例えば、皆さんの周
"自分がやったほうが早い"はダメ! マネージャがやってはいけない5つのミス | 経営 | マイコミジャーナル
マネージャの仕事の中でも重要なものに、部下に適切に仕事を任せる、というものがある。英語では"delegating(権限の委譲)"という。仕事を丸投げしたり、介入しすぎたりしては部下も思い通りの仕事ができないことは容易に想像がつく。U.S.News & WORLD REPORTに「部下に仕事を任せる際の5つの間違い(原題: 5 Ways Managers Fail at Delegating)」という記事が載っているので紹介しよう。 1. 共通の認識を持たない 仕事が成功裏に終了した時のゴールは何かということを事前に部下と確認しなかったため、最後に出てきたものがあなたの期待したものと違っていたということはよく起こる。 2. 進捗管理をしない プロジェクトの最初に話をするだけで、計画通りに仕事が進む……なんてことはない! プロジェクトに関与し続け、チェックすることはマネージャの有効な武器だ。進
システムの納期とは確率分布だ − Publickey
昨日はIBMのラショナルソフトウェアカンファレンスに参加しました。1日中、ソフトウェア開発方法論に関するセッションを聞いていたのですが（最後のセッションは、自分が司会のパネルディスカッションでもありましたが）、その中で最も印象的だったウォーカー・ロイス氏のプレゼンテーションを紹介したいと思います。 ウォーカー・ロイス氏はIBMラショナルソフトウェア部門のバイスプレジデントで、アジャイル開発手法としてよく知られるRUP（Rational Unified Process）の創始者でもあります。彼の講演は、この日の基調講演の1つでした。
デッドライン ソフト開発を成功に導く101の法則
正しい管理の四つの本質・適切な人材を雇用する。 ・その人材を適所にあてはめる。 ・人々の士気を保つ。 ・チームの結束を強め、維持する。 （それ以外のことは全部管理ごっこ） 安全と変更・変更は、あらゆるプロジェクトの成功のために（ほかの大抵の物事についても）必要不可欠である。 ・人は安全だとわからないと変更を受け入れない。安全が保証されていないと、リスクを避けようとする。 ・リスクを避けることは、それに伴う利益をも逃すことになるため、致命的である。 ・人は、面と向かって脅されたときはもちろん、自分に対して不当に権力が行使されるかもしれないと思ったときにも、安全ではないと感じるようになる。 負の強化・脅迫は、結果を上げさせる手段としては不完全である。 ・どれほど強い脅しをかけても、最初に割り当てた時間が足りなければ、やはり仕事は完成しない。 ・さらに悪いことに、目標を達成できなければ、脅迫の内
開発マイルストーン
プロジェクト開発などのスケジュール管理をExcelで簡単かつグラフィカルに作成するマイルストーンは一つの指標です。 プロジェクトでは、達成したい目標へ向かってまずステップごとに段階を分け、計画を立てて実施します。 その結果の検証をして、これをもって修正された新たな計画を立て再び実施を行います。 このようなサイクルでプロジェクトを進めていく上で重要な指標がマイルストーンです。 ツール「開発マイルストーン」は、システム開発などで必要なプロジェクト管理をサポートするためのツールです。 MicrosoftExcelを使用して、簡単に入力でき、かつグラフィカルに表現することができます。 無料で使える工程管理ソフト 「開発マイルストーン」は、MicrosoftExcelが利用できる環境であればどなたでも利用できます。 また、本機能以外にもExcelに備わっている豊富な機
無料のプロジェクト管理ツール「activeCollab」をUSBメモリで動かす方法 - GIGAZINE
前の記事、「The Uniform Serverを使ってUSBメモリでタスク管理サーバを持ち歩く方法」では「The Uniform Server」をUSBメモリにインストールして使えるようにするところまでを解説しましたが、今度は実際にオープンソースのプロジェクト管理ツール「activeCollab」をUSBメモリで動かすことになります。 手順は以下の通り。簡単に「activeCollab」の動作画面も掲載しておきます。 ◆「activeCollab」のインストール まずは公式サイトにアクセスしてダウンロード activeCollab - open source project management and collaboration tool. http://www.activecollab.com/ ダウンロードしたら解凍し、wwwフォルダの中にまるごと移動 それから以下のアドレスにアク
意図が伝わる設計書作成の心得【第1回】：行きすぎた技術志向
設計書の書き方には絶対的な公式があるわけではない。必然的に，設計者の「経験」と「力量」に依存する部分が多くなる。標準の設計フォームや設計書作成ガイドラインを用意することで，このような事態を避けようとしている開発現場は多いだろう。しかし，型通りに作った設計書が，常に目的にかなった“正しいもの”であるとは限らない。 一般によく言われることだが，設計書の書き方には「正解」や「こうしなければならない」という絶対的な公式があるわけではない。必然的に，設計者の「経験」と「力量」に依存する部分が多くなり，完成した設計書の内容と質は設計者ごとに大きく異なる――といった結果に陥りやすい。 もちろん，標準の設計フォーム（ひな型）や設計書作成ガイドラインを用意することで，このような事態を避けようとしている開発現場は多いだろう。しかし，型通りに作った設計書が，常に目的にかなった“正しいもの”であるとは限らない。一
少人数開発と「能力プール」 - 設計者の発言
■少人数プロジェクトが儲かる理由 開発案件の最終利益率とプロジェクトメンバー数には一定の相関がある。開発に関わったメンバーの数が少ないほど、一般に利益率は高い。実際に数字で調べてみたわけではないが、筆者の過去の経験からも確信できるし、そのように思い当たる人も多いだろう。 その理由は単純である。メンバーが多いほど、メンバー間の情報伝達のためのコスト（情報コスト）が飛躍的に増えるためだ。指示やいわゆるホウレンソウのための初期コストだけでなく、訂正や伝達ミスにともなうさまざまな後追いコストが、人数の多いプロジェクトほど大きくなる。メンバーが２人のときに情報コストが１だとすれば、（１人のときなら０）、人数に従って次のようにコストは増えてゆく。 ２人 １ ３人 ３ ４人 ６ ５人 １０ ： ： ｎ人 n(n-1)/2 たとえこの事実が理解されていたとしても、これらのコストを考慮して工数積み上
Ringo's Weblog: 知識の量が質に変化する瞬間
プライバシーポリシー | サイトポリシー | 商標 | フィード | サイトマップ Copyright© 2000-2007 Community Engine Inc. All rights reserved.
ksh Days - デスマーチについて考える（デスマーチ経験のエピローグ）
このエントリは デスマーチについて考える前にデスマーチの経験を書く の続きです。(2007/2/16追記) 私はテスタとして、必ず バグの修正を「お願いします」と言う。 バグ修正確認時は、必ず直してないところも最低１箇所は触ってみる。（でよく落ちる） バグ修正が確認できたら、できるかぎり早く「確認できました。ありがとうございました」と言う。 を実践してゆきました。 ある日、一人のプログラマさんから相談を受けました 「今度の機能なんですが、納期が近いから単体テストせずにkshさんにテスト依頼しろってSEさんから言われたんですが、そんなことしたくないんです」 以下、全文はこちら
デスマーチについて考える前にデスマーチの経験を書く - ブログは死なず、ただ放置されるのみ。
その昔、とあるプロジェクトがものすごいことになっていて、猛烈な勢いでスケジュールが遅れているのに、仕様がまったく決まっておらず「とりあえず」作ったモノを現地にブチこんで、そのあと燃え上がるであろう事態を収めよという命のもと、テスタとして放り込まれたことがある。 まずお客さんがいいかげんだった。もともと現行システムがあるので「仕様は現行と同じでいい」と言いながら、思いつきで「新しいシステムだからこんな機能も欲しい」という、失敗するならそれ！ ということを頻繁に行った。 受けたSEもいいかげんだった。お客さんが「このボタンを押すと計算結果が出る」というと、仕様書には「ボタン押下により計算結果が出力される」としか書かなかった。その計算はどのデータに基づいてどのような式で行われるのかは書かれなかった。もしそれをお客さんが（幸運にも！）教えてくれても、それが議事録に書かれることはなかった。 受けたプ
スペシャリストはリーダーになれない？ ― ＠IT自分戦略研究所
将来に不安を感じないITエンジニアはいない。新しいハードウェアやソフトウェア、開発方法論、さらには管理職になるときなど――。さまざまな場面でエンジニアは悩む。それらに対して誰にも当てはまる絶対的な解はないかもしれない。本連載では、あるプロジェクトマネージャ個人の視点＝“私点”からそれらの悩みの背後にあるものに迫り、ＩＴエンジニアを続けるうえでのヒントや参考になればと願っている。 ■リーダーシップトライアングルにおける位置付け この連載では、システム開発プロジェクトにおけるリーダーシップを中心に、「私の視点＝私点」を皆さんにお届けしています。 今回の内容は、リーダーシップトライアングルのLove／Communication／Capabilityに関係します。Loveについては第10回「正しいことをし、行動力を発揮するココロ」を、Communicationについては第8回「コミュニケーションは
「仕事の好循環」に必要なもの － ＠IT自分戦略研究所
コラム：自分戦略を考えるヒント（28） 「仕事の好循環」に必要なもの 堀内浩二 2006/3/31 ■キャリアにも「流れ」がある？ 先日、「流れに乗るために大企業に入りたいのだが、どうすればよいのか？」という相談を受けました。「流れに乗る」という言葉が印象的でしたのでじっくり話をお伺いしたところ、こういうことでした。 一流のSE（システムエンジニア）には大企業出身が多い気がする。おそらく、大企業に勤めていることで「いい仕事」をすることができ、それによって「高い給料」がもらえ、さらに企業内での職位が上がっていい仕事が……、というような「流れ」があるのではないか。一流のSEになるために、実力だけでなくそういう「流れ」に乗ることが必要だとすれば、大企業に勤めた方がいいことになる。 つまり図1のような「好循環」があるのではないかということです。 そういう「好循環」があるかないかといえば、ある程度は
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Welcome | Will Barton
[記]『すごい会議−短期間で会社が劇的に変わる！』大橋 禅太郎(大和書房)![[記]『すごい会議−短期間で会社が劇的に変わる！』大橋 禅太郎(大和書房)](https://cdn-ak-scissors.b.st-hatena.com/image/square/5677f467bb102e8a98c11eed5c1245232be6fc97/height=288;version=1;width=512/https%3A%2F%2Fm.media-amazon.com%2Fimages%2FI%2F410x9kV%2ByVL._SL500_.jpg)
- nikkeibp.jp - 過去記事 - あるケータイ用ソフト技術者の場合 (2)
- nikkeibp.jp - 過去記事 - あるケータイ用ソフト技術者の場合 (1)
Amazon.co.jp： デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか
社会貢献うたうＩＴ経営者の偽善――過労自殺が語る業界の労働事情 ビジネス-最新ニュース:IT-PLUS
ソフトウェア開発の落し穴
