エンジニアにとっての本当の「顧客」は誰？！
システム開発における「人」（＝開発担当者）に視点を当て、普遍性を持ったプロジェクト運営プロセスを探り出す連載の第3回です 前回「エンジニアのやる気は報酬だけじゃ維持できない、前々回「スキルシートでいったい何が分かるのか」は、プロジェクト内でうまく活躍できなかった担当者を例に取り、その原因を探りました。今回はプロジェクトでは活躍し、貢献したものの、プロジェクトを去らねばならなかった例を見てみましょう。その中から、これまでと同様、「プロジェクトと人」をうまく結び付ける要因を探ります。 まずは、前回のWeb投票「プロジェクトへのモチベーションが一番高まるのは以下のうちどれを獲得したときといえますか？」の結果を確認してみます。 金銭的報酬 107人 35.2％ 107人 35.2％ 顧客からの評価 73人 24.01％ 73人 24.01％ チームメンバーからの評価 21人 6.91％ 21人 6
エンジニアのやる気は報酬だけじゃ維持できない（Page 1） ― ＠IT情報マネジメント
本連載は「プロジェクトと人」を「人」に視点を当て、そこからある程度の普遍性を持ったプロジェクト運営のプロセスを探り出すことを目的としています。第1回（「スキルシートでいったい何が分かるのか」）はEさんを例に、プロジェクト内でうまく活躍できずに去らざるを得なかった経緯を見ながら、「チーム構成プロセス」や「開発プロセス」の「難しさ／問題点」を洗い出しました。今回は、皆さんから寄せていただいた第1回記事に対するWeb投票結果の考察から話を展開していきます。 集計結果から導き出される次なる課題 以下がWeb投票の結果です。「第1回において、Eさんがチームを去らねばならなかった最大の問題点は何だと思いますか」というのが質問です。選択肢は5つ設定しました。 プロジェクト入隊試験などフィルタリングを行わないチーム構築プロセスの未整備。あるいはメンバー選びなどを支援するノウハウのない所属する組織 メンバー
すごい技術者はすごいマネージャになれるか？
前回「エンジニアにとっての本当の『顧客』は誰？！」はFさんを例に、単に活躍するだけでもうまくいかない事例を通して「ステークホルダー」の調整の難しさを考えてみました。 さて、早速前回のWeb投票の 結果（2007年3月5日時点）を簡単に分析してみましょう。 ［質問］ ITプロジェクトの運営・遂行の上で非常に重要なのは？ ■アンケート結果 メンバーのスキル 23人 33.82％ マネージャのスキル 19人 27.94％ 見積もり 13人 19.12％ プロセス 6人 8.82％ 根性 7人 10.29％ まず2位について。やはりプロジェクトの成否において、マネージャのスキルは誰もが重要だと考えています。プロジェクトの遂行に責任を負っているのが「プロジェクトマネージャ」という言葉の意味である以上、最初に「重要な要素」として挙げられるのは理解できます。 例えば、多くの場合システムが「オーダーメイド
スキルシートでいったい何が分かるのか（Page 1） − ＠IT情報マネジメント
本連載はプロジェクトの成否を握る大きな要素「人とチーム」の関係に焦点を当てます。開発プロジェクトが成功するか失敗するかは結局、開発チームを構成するそれぞれのスタッフの力量にかかっているといってもいいかもしれません。 ITプロジェクトの人集めって何だろう？ システム構築と「人集め」 プロジェクトを遂行するとき、マネージャとアーキテクチャの大切な仕事の中に「チームづくり」があります。プロジェクトの成否・効率は「人選び」によって左右されるといっても過言ではありません。 この「人選び」にも大きく分けて2種類あります。1つは「プロジェクトの命運を握る人」という意味での人選びです。「マネージャ」「アーキテクチャ」といった中心的な役割を果たす1、2名がこれに当たります。もう1つは、そういった「命運を握る人」が一連托生（いちれんたくしょう）として選ぶ「プロジェクトメンバー」です。 無論、人選をはじめとする
【翻訳】How to be a program manager - Joel on Software - GoTheDistance
たまたま見かけたのですが、とても示唆に富む記事だったので頑張って和訳してみました。延べ2週間近くかかった・・・。 ITを武器にする企業は、ベンダーやユーザーに関わらず｢program manager｣と呼べる人たちが必要だと思っています。37Signalsの｢Getting Real｣に近しいことをJoel自身も語ってくれていますし、今後僕らがどのようなキャリアを積んでいけばいいのか、技術力を梃子にしていく組織を作るのにはどうしたらいいのか、そういうヒントが込められています。 Joelの英語は、同じような意味の言葉を複数の言葉を使い分けて言っていたり、ぐるっと回り込んでから要点を記述することが多いので、正確な意味を伝え切れていないかもしれませんが、大きく意味が外れないように留意したつもりです。 原文はHow to be a program manager - Joel on Softwar
要件定義をロジカルシンキングで解析する - プログラマの思索
「30の「勝負場面」で使いこなす ロジカル・シンキングの道具箱」を読んで、高度情報処理試験の論文問題を解いているような気がしてきた。 要件定義と問題解決、ロジカルシンキングについて考えたことをメモ。 【1】業務系システム開発のリスクは、Railsのような最新技術の習得、TiDDのようなプロジェクト管理、TestLinkのようなテスト管理など色々あるが、一番のネックは要件定義だ。 元々の要件が顧客の認識とずれていたら話にならない。 しかしながら、新規顧客の場合、顧客と一緒に開発してリリースして運用しなければ、顧客の本来の要求が何だったのか、が分からない時はすごく多い。 だから、SIerのビジネスモデルとしては、1次開発は赤字だったとしても2次開発や運用保守で黒字になるように仕向けるのが普通だろう。 特に大手SIerが政府の公共システムを受注する場合が当てはまるだろう。 だが、そういうリスキー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.machu.jp/posts/20090301/p01/