5分で人を育てる技術 (22)“はじめて部下を持つ人"への5つのアドバイス ：ITpro
前回は，部下を持つことで混乱している坂本に上司としてどう行動していくべきかを伝えました。そして，私は彼に“はじめて部下を持つ人"への5つのアドバイスをすることにしたのです。 坂本は，中堅社員ですが，長く部下を持たなかったので，自分のことだけを考えていれば済みました。しかし，今後はそれでは済みません。彼にはしっかり部下の面倒を見てもらい，組織マネージメントを身に付けてほしいからです。 坂本に限らず，多くの人は部下を持つとそれまでとは違った苦労をします。自分だけで精一杯なところに，知識も経験も劣る部下の面倒も見なくてはならないのですから，その大変さは誰でも理解できるところでしょう。 しかし，組織で力を出していく以上，部下の戦力化は避けて通れない道です。どうせやらなくてはならない部下マネージメントなら，しっかりとした「やり方」を身に付けたいものです。まず，私はこれを坂本に教えなくてはならないと思
やまざきメソッド ジェネレーター
やまざきメソッドとは デザイナーやまざきさんが突然使いだした進捗表示方法なのだ！ 目盛りは横書きで、各項目が縦書き。別名「縦横メソッド」！ なんかすごく見やすいし、進捗把握しやすいんですけど！ エディターで再現してみてください。めっさ面倒だから！ そこで、簡単にやまざきメソッドで表現できるジェネレーターの登場だ！ やまざきメソッド ジェネレーターの使い方 「たいとる」を入力する。左上に横書きで表示されるよ。 「はじめのことば」を入力する。目盛りの左側に横書きで表示されるよ。 「おわりのことば」を入力する。目盛りの右側に横書きで表示されるよ。 「もじしょく」を入力する。"000000"みたいに16進数で入力してね。 「はいけいしょく」を入力する。"FFFFFF"みたいに16進数で入力してね。 「いまここ」を選択する。進捗表の場合は選択すると目盛りの色が変わるよ。 「こうもく」を入力する。勝手
最適な工期は「投入人月の立方根の2.4倍」、JUASが調査 ― ＠IT
2007/07/05 日本情報システム・ユーザー協会（JUAS）は7月5日、ユーザー企業102社の357プロジェクトを調査した「ソフトウェアメトリックス調査2007」を発表した。システム開発の企画、開発計画に始まり、保守や運用管理まで実態を調査した内容で、企業情報システムの実態を伝える。調査結果からは“デスマーチ”となるプロジェクトの実態も浮かび上がった。 デスマーチ化するプロジェクトの条件の1つは工期の設定が不適切であることだろう。調査から導き出された標準開発工期は「投入人月の立方根の2.4倍」。調査対象のプロジェクトの全体工数と全体工期をグラフ化し、回帰直線によって求めた。この計算によれば1000人月のプロジェクトの場合は24カ月の工期を設定するのが標準的といえる。事情によってこの標準工期よりも短い工期しか取れない場合は、その短縮率を計算して対策を採るべきとJUASは提言。だが、「（短
わたしが知らないスゴ本は、きっとあなたが読んでいる: 困った現場に効く「プロジェクトマネジメント現場マニュアル」
プロマネ本は沢山あるが、こいつは具体的。プロジェクトのその場その場で発生する問題とその解決策がよく分かる。「こんなときどうする?」形式なので、自分なりの対策を考えて→次のページで"答え合わせ"をするといった読み方もできる。カユいところに手が届く仕掛け。 例えば… 問題がいつまでたってもなくならない。進捗報告はペンディングの山。どうやって片付ける? テストが甘い。行き当たりばったりで、テスト自体のモレヌケによりつぶすべきバグが後になって湧く。なんとかするには、何をどうすればいい? アバウトな品質要求「使いやすい画面にしろ」といわれたとき、何をどうすれば「使いやすい画面」になっているといえるのか? 進捗管理が甘い。「90パーセントです」が1ヶ月続く。あるいは、進捗会議の場が、「なぜ遅れているのか」の言い訳の場になっている。どうする? 答え 問題を管理する。責任者、期限、優先度を決め、進捗を監視
Java初心者のチームが挑む基幹系刷新プロジェクト（番外編）
私は，2007年2月2日付の記者の眼「『使えない人間』などいない」で「Java初心者で構成されるチームがいかにプロジェクトを完遂したか，という事例」があり，その事例を取材したうえで，日経ソフトウエア2007年5月号のJava特集でレポートすると書いた。その号がいよいよ明日（3月24日），発売される。特集のルポ「Java初心者のチームが挑む基幹系刷新プロジェクト」という記事である。 具体的には，群馬県内の各JAやJA関連組織のIT共同利用施設であるJA群馬電算センターが提供しているシステムの事例だ。Javaをほとんど知らなかった4人のメンバー，JA群馬電算センター 経済情報部の片野富久氏，前原貴美子氏，大久保浩治氏，渋谷知央氏が，基幹系システムの刷新プロジェクトに先立つパイロット・プロジェクトを成功させた，というものである。 もっとも，取材を終えた今では，この事例を「『使えない人間』などいな
ちょっとだけ、失敗しないプロジェクトに近づくための3つのヒント
プロジェクトマネジメントを考える上で、Apple、はてな、Googleという3つの企業の事例を紹介しましたが特殊事例だったかもしれません。今回は、もっと身近な事例を考えてみましょう。 前回、失敗しないプロジェクトマネジメントを考える上で、Apple、はてな、Googleという3つの企業の事例を考えてみました。はてなブックマークでも、多くの方からコメントを頂きましたが、やはり「そうは言ってもね」というのが正直な反応だと思います。 そこで今回は、プロジェクト管理の「負のスパイラル」を脱出するために、もう少し身近な事例を参考にしてみたいと思います。 ちょっとだけ、失敗しないプロジェクトに近づくための3つのヒント 短期ではなく、長期で考える 遅い人ではなく、早い人に注目する 大きく始めず、小さく始める 短期ではなく、長期で考える 通常のプロジェクトでは、前回紹介したAppleのように「締め切りを事
「HTML画面をそのまま仕様書に」，5カ月で1000画面を構築した就職サイトPuffの高速開発手法：ITpro
上段左からティーアンドエフカンパニー 事業推進統括責任者 情報化戦略コンサルタント 西岡祐弥氏，ティーアンドエフカンパニー 代表取締役社長 佐藤裕司氏，パフ 代表取締役社長 釘崎清秀氏，下段左よりティーアンドエフカンパニー 最高技術責任者 出羽健一氏，パフ 取締役兼株式会社プロシンクワーク代表取締役社長大場京子氏，パフ 事業サポートグループ グループマネージャー 保坂光江氏 Webシステムを開発する際にはほとんどの場合，ユーザーとの打ち合わせのためにHTMLによるモックアップを作る。「このHTMLがそのまま仕様書になれば」と思ったことはないだろうか。就職情報サイトPuffの再構築プロジェクトでは，まさにモックアップをそのまま仕様書した。「十数人の開発者で，5カ月で1000画面のシステムを開発する」必要に迫られたからだ。 HTMLに仕様とメモを埋め込み，CSSで切り替え 「この未体験のスピー
[ThinkIT] 第1回：複数人による開発の要所を押さえる (1/3)
PHPは生産性の高い開発言語として広く普及しました。現在も多くのWebアプリケーション開発でPHPが採用されており、その手軽さも手伝って実績を伸ばし続けています。手軽に開発できることから、個人での開発もでき、独自の開発手法が多く存在し、複数人では統一が難しいといわれています。 そのため複数人による開発では、確固とした開発手法がとられてない事例が多いのも事実です。開発手法が確立されてない場合、規模が大きくなるとすぐに破綻してしまいます。それを避けるには、開発手法を確立しておく必要があります。 本連載では複数人によるPHPを用いたWebアプリケーション開発において、実際に筆者の所属するウノウ株式会社が行っている手法を例に効率的な開発手法を解説していきます。本連載の内容はPHPだけでなくRubyやPerlのような他の言語にも適用できます。また1人で開発を行う時に非常に有効な方法です。実際に筆者が
自転車置場の議論 - bkブログ
自転車置場の議論 人が集まると、なぜかどうでもいいようなことほど議論が紛糾してしまう傾向がありますが、このような現象のことを、FreeBSD のコミュニティでは自転車置場の議論 (bikeshed discussion) と呼んでいることを知りました。 この、「瑣末なことほど議論が紛糾する現象」はパーキンソンの法則という本の「議題の一項目の審議に要する時間は、その項目についての支出の額に反比例する」という法則として知られています。 この本の中で著者は、原子炉の建設のような莫大な予算のかかる議題については誰も理解できないためにあっさり承認が通る一方で、市庁舎の自転車置場の屋根の費用や、果ては福祉委員会の会合の茶菓となると、誰もが口をはさみ始めて議論が延々と紛糾するというストーリーを紹介しています。 このように、「瑣末なことほど議論が紛糾する現象」はパーキンソン氏によって見事に説明されているの
オープンソースプロジェクトを予期せぬ事態から守る方法 | OSDN Magazine
2006年10月11日09:52 Brian-W.-Fitzpatrick（2006年10月5日（木）） ソフトウェアプロジェクトではバス問題 ― プロジェクトのメンバーが何人バスに轢かれたらコードベースを熟知する人間がいなくなるか ―がよく取り沙汰される。オープンソースの世界では、事前に備えをしておかなければ、開発者がたった1人いなくなるだけでプロジェクトが壊滅に陥る可能性さえあるのだ。 プロジェクトをバス問題から守るためにできることで一番大切なのは、強力な開発者コミュニティをプロジェクトに呼び込むことだ。普通、オープンソースの開発者は最初にユーザとしてプロジェクトに関わるので、まずはプロジェクトにユーザを呼び込む必要がある。そのためには、人々に使ってみたいと思わせるほどのものを作り上げ、ユーザからのフィードバックに注意深く耳を傾けなければならない。今日のユーザは明日のリリースマネージャ
共同作業に最適な人数は3人 | スラド
「第三の男」程度にはなりたいAC曰く、"医学都市伝説の記事経由American Psychological Associationのプレスリリースによると、共同作業を行うに当たって最適な人数は3人であるというPatrick Laughlin、 Erin Hatch、 Jonathan Silver、とLee Bohの4人の心理学研究者による結果がJournal of Personality and Social Psychologyに発表されたそうだ(論文全文[PDF])。この研究はAからJまでの文字に0から9の数字を割り当て、A+D=Bなどの数式から文字に当てられた数字を推測するというテスト(letters-to-numbers coding problem)をイリノイ大学の760人の学生に解かせたもので、学生は1人、もしくは2～5人で相談できるグループで行いそのパフォーマンスを見たもの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
