VPoE handbook | エンジニア組織のマネジメントに悩んでいた三年前に戻れるなら渡したい。VPoE handbookを書き終えました (目次&サマリ付)｜Takayuki Shimizu
（この記事はVPoE handbookの目次＆サマリパートです） 以下で書き始めを宣言してから進捗が悪思わしくなかったhandbookですが、ようやく書き終わりました。 数えるといつの間にか合計30,000字ほどになり、意外とボリュームが増えてしまったので、少しずつ読みやすいように章ごとに記事にしています。 目次はこの記事の目次部分、もしくはこちらのマガジンの一覧からご覧ください。 この記事自体ではその目次と簡単な解説をつけ、ざっくりと全体像を知り、詳しく読みたい気になる記事を見つけやすくするような構成で書いていきたいと思います。 （この7月からは開発マネジメントのキャリアとはまた違った方向に進みだしたので、賞味期限切れギリギリ?!になりましたがなんとか整理も終わりました。） VPoE handbookを書こうと思った理由まずはなぜ書こうと思った？の問題意識から。 この記事にあるように、三
「職位が高い人間ほど、技術的な実務から遠ざかってしまう」のを解消しようとして、失敗した時の話。
どうも、しんざきです。 実を言うと先月・先々月と、プロジェクトが割と生死をさまようレベルで炎上しておりまして、夢のデスマ王国という風情だったんですが、お蔭様で今月はだいぶ落ち着いてきまして、若干人間的な生活が出来る状況になってきました。 デスマ程健康に悪いものはこの世に存在しないと思います。 失敗した時の話をします。 十年近く前の話ですが、システム開発の会社に勤めていたことがあります。 それ程有名な会社ではないのですが、一応独立系で、社員は4桁に届かないくらいで、SI案件とSES案件が大体半々くらい、自社業務と客先常駐も大体半々くらいという、まあよくある「昔ながらのシステム開発会社」だったと思います。 私はその会社で、主に金融関連のプロジェクトを担当する部署に所属していました。 ぬるい案件もあれば地獄案件もあったのですが、まあそれはいずれ、ほとぼりが冷めた頃に書こうと思います。 某大きな銀
新メンバーが多い大型プロジェクトでの不確実性との戦い方 - スタディサプリ Product Team Blog
ペアプロ・モブプロ、スキルマップ、1-on-1等々… チーム開発にまつわる各論・方法論・話題をよく見る昨今、関心の高まりは歓迎さるべきことながら つまるところそれらが現実のどのような問題を解決していくのか？ どのように相互作用するのか？ これらが有機的に結びつくことで現実のどのような問題を解決していくか？ こうした疑問に答えたり、具体例とともに記した記事はさほど多くないのではと思います。 本記事では昨年度に筆者のチームが約7ヶ月携わったプロジェクトにて、プロジェクト特性に起因する不確実性と我々がいかに戦ったかを記します。チーム開発を行う方にとってこの記事が実りあるケーススタディとなれば幸いです。*1 なお、本記事では以下のことは本旨とは逸れるため割愛させていただきます。 プロジェクトの機能的側面 技術的不確実性 各取り組み単体の詳細 はじめに / プロジェクトの雰囲気を伝える図 この記事で
デスマーチが起きる理由 - ３つの指標
鳥のさえずり声を聞いて、私は悪態を吐いた。今日の早朝に予定されていたミーティングのことをすっかり忘れていたのだ。 まったく、最悪の朝だ。着替えている間に、電話も鳴った。「高い金を払ってコンサルタントを雇った極めて重要なミーティングだ」と念を押されていたというのに。 それもこれも昨日のバグのせいだ。睡眠時間も、開発スキルも、人員も、私の現場には何もかもが足りていない。 それにも関らず、理解の足りない上司は「テスト工程を削ってでも早く納品しろ」とプレッシャーを与えてくる。 あの馬鹿どもめ。一体何を考えているんだ？ スーツに着替え終わった私は、冷蔵庫の缶コーヒーで空腹を誤魔化すと、バイクに跨った。通勤時間が5分なのが、せめてもの救いだ。 「遅れてすまない」 そう言って会議室に入ると、奇妙なことに気がついた。教室のように整然と並んでいたはずの机が、即席の半円形に並べ替えられていた。 何より、ホワイ
PRINCE2の教え－－プロジェクトで大事なのはマネジメントかガバナンスか？ | タイム・コンサルタントの日誌から
このサイトをご覧の読者の方なら、『鉄の三角形』という言葉をご存知と思う。プロジェクトを定める「スコープ」「コスト」「スケジュール」という三大制約条件を、三角形の形で模式的に示したものだ。 三角形の一片の長さは、他の辺に影響を与えずに変えることができない。同じように、プロジェクトの三つの制約条件は、独立でなく必ず他と関わり合っている。例えばプロジェクトのやるべき責任範囲である「スコープ」が増えたとしよう。すると「コスト」が増えるか、「スケジュール」が伸びるか、あるいはその両方が必ず起きる。そこでプロジェクトマネージャーは、これら3つのファクターの相互関係とバランスを、よく考えながらコントロールする必要がある。 ちなみに、製造業の三大ファクターと言えば「QCD」、すなわち、品質(Quality)・コスト(Cost)・納期(Delivery)である。プロジェクトの場合は、品質で三角形を書くことも
レベルいくつの議論をしているの？ | タイム・コンサルタントの日誌から
わたしの働くエンジニアリング業界では、プロジェクトの構造や規模感について、ほぼ国際的な常識ないし合意事項がある。我々の業界で大規模プロジェクトといったら、予算総額1,000億円以上を通常、指す。そして大規模プロジェクトを構成する種々の単位作業（Activity）の総数は、大ざっぱに3～5万程度だ。もっとも最近はプラントの大型化が進み、規模感はややインフレ気味だが、上記の数字は一つの目安になる。 ところで、Activity数が3～5万と書いたが、これはプロジェクトを構成する最下位のActivity数である。プロジェクトを作業単位に階層的に分解して管理番号をつけ、予算や要員やスケジュールをコントロールしていく基準とする手法は、現代プロジェクトマネジメントの基本である（この作業の階層構造をＷＢＳ = Work Breakdown Structure と呼ぶことは、本サイトの読者諸兄ならばよくご存
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
