IT業界の「デスマーチ」がもたらすものは、長時間労働や人材の疲弊だけではない。もっと深刻だ。
IT業界が外部の人間から敬遠される理由の一つに「デスマーチ」がある。 ほとんど実現不可能に思える無理なスケジュールで、深夜におよぶ残業、休日出勤の連続、人海戦術でほとんど役に立たない新人までが駆り出され、終わりの見えないプロジェクトの完成にひた走る、これがデスマーチである。 そこではプログラマは一人また一人と過労に倒れ、うつろな目でキーボードを叩き続けるプログラマの連続勤務時間は20時間を優に超える、といった光景が見られる。 このようなデスマーチについて、人材の疲弊やそれに伴う退職など、ITベンダー側の不利益が語られることは多いが、クライアント側の不利益、もっといえばプロジェクトの成果物自体がデスマーチで台無しになってしまうことはあまり知られていない。 デスマーチのきっかけ 営業の無謀な受注、仕様の調整不足などで、システムの実装行程が確保できず、どうやっても通常の開発体制ではシステムの完成
ムリ・ムラ・ムダ 〜 どれが一番いけないか？ | タイム・コンサルタントの日誌から
トヨタ生産方式では、周知の通り「働きに結びつかない動きをムダと呼ぶ」と定義する。そして徹底したムダ取りを行っていくのだが、このとき、「ムラがあるから、ムリをする。ムリをするから、ムダが出る」という因果関係で、物事を見る、と経験者からきいたことがある。つまり、なぜムダが生じるのか、という問題について、非常にジェネラル（汎用的）なレベルで
不安とストレスから解放される見積りとスケジュール方法 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを
ガントチャートとは？作り方と無料で作れるツール15選を紹介【テンプレート付】
ガントチャート（Gantt Chart）とは ガントチャート（Gantt Chart）とは、プロジェクト管理の手法で作業計画やスケジュール管理を目的に用いられる表のことです。 タスクそれぞれの関係性が分かることが特徴として挙げられます。プロジェクトの遅れの原因や重要なタスクなどを視覚的に把握できるため、ビジネスシーンでよく使われています。 上記画像のようにExcelを使って管理することが一般的です。他にも、スケジュール管理に優れたガントチャートツールを無料で使えるサービスが出ているので、それらを用いてスケジュール管理ができます。 ガントチャートを作成するメリット ガントチャートがどんなものか分かったところで、次は作成するメリットを見ていきましょう。ガントチャートを作成することで、以下のようなメリットを得られます。 全てのタスクや作業全体の状況を可視化できる 情報をメンバーに素早く共有できる
人を使うということのオーバーヘッド | タイム・コンサルタントの日誌から
なんだかひどく忙しい。そう、あなたは感じている。やらなければならない仕事が山のようにたまってしまった。このままでは期限までにアウトプットが出せそうにない状況だ。自分の下に誰かつけてもらって、やるべき仕事量を分担して進めるしかない。 あなたは上司に窮状を訴え、一時的な手助けのために、なんとか若手を一人つけてもらえることになった。この部に入ったばかりの、まだ右も左も分からない新米だ。しかし贅沢を言っていられる状況ではない。周りも皆、忙しいのだ。儲かってもいないのに、ウチはなぜこんなに忙しいんだ？ あなたは独り言をつぶやきつつ、そもかくその新米を席に呼ぶ。頼みたい仕事を説明するためだ。 頼む仕事は、比較的単純だ。あなたが作ったExcelシートに条件の数字をインプットして、何種類かケーススタディをしてほしい。あなたは、ある案件の原価と収支を計算して、売価や条件を関連部門に連絡しなければいけないの
プロジェクト・スポンサーシップが足りない | タイム・コンサルタントの日誌から
アメリカにNeal Whittenという著名なプロジェクト・マネジメントのコンサルタントがいる。何年か前に、ボストンで彼の講演を聴いたことがあった。彼はその中で、プロジェクトが失敗する三つの主な原因を挙げていたのだが、それがずっと頭にひっかかって残っている。彼のいうプロジェクトの三つの失敗理由とは、以下のようなものだ： (1) プロマネのハード・スキル不足 (2) プロマネのソフト・スキル不足 (3) プロジェクト・スポンサーシップの不足 プロジェクトの失敗の理由がプロマネに帰されるのは、ある意味、当然のことだ。Whittenはプロマネの能力を、ハード・スキルとソフト・スキルとに分解する。ハード・スキルとは、知識や技法など、いわゆる座学で習得できる種類のものである。WBSだとか、PERT/CPMだとか、パラメトリック見積法だとかいった事柄で、これらは技術として移転可能なものである。わたしの
PMPの資格はほんとうに仕事の役に立つのか | タイム・コンサルタントの日誌から
昨年、勤務先でPMIの来訪を受け、同僚と共にインタビューに応じた。目的は日本におけるPMP資格取得の動向を探ることで、相手はいかにも頭の良さそうな30代の米国人であった。名刺を見ると、PhD、つまり博士号保有者であるむね書かれている。むろんPhDのほかにPMPも資格として名前の後ろに書かれている。 今さら説明するまでもないが、PMIはProject Management Instituteの略で、米国発で世界最大のグローバルPM団体である。日本にも支部はあるが、米国の本部が、世界中の数十万人の会員を統括している。PMIは元々1960年代に、プロジェクト・マネジメントに携わる人々が、PMという仕事もプロフェッショナル専門職として世に認めてほしい、との願いをもって結成された組織だ。現在のPMIは、通称『PMBOK Guide』(R)、正式には"A Guide to Project Manage
炎上案件に突如ディレクターとして投入されたときにやってみたこと - Qiita
ぼんやり1メンバーとして眺めていたプロジェクトが、リリース1週間前になって「あれも足りない！これも出来てない！どうすんじゃゴラァ」となったときに突如ディレクターとしてぶっこまれ投入されたときにやってみたことのメモ。 一次対応 とにもかくにもPJTに投入されて最初にやったこと。 コミュニケーションルールをみんなで確認して、守ってもらうようにした 誰が何の情報を持ってて、そして誰から誰にどんな指示が出てて、それらがどんなステータスか、、、 もうぐっちゃぐちゃになっていた。 ディレクターは一度死ぬが、一旦全部ディレクターに報告させて、ディレクターから適切な人に指示を出すことにし、メンバー同士でのダイレクトなコミュニケーションをいったん、原則禁止した。 （ディレクターがAさんとBさんで直接やって、と指示を出すときもあるが、それもやりとりの結果をAさんから必ずフィードバックさせるようにした。） ただ
『プロジェクト・アナリスト』はなぜ必要か | タイム・コンサルタントの日誌から
わたしが「プロジェクト＆プログラム・アナリシス研究部会」を立ち上げたのは、3年半ほど前のことだ。2011年の5月、まだ東日本大震災と原発事故の余波がさめやらぬ頃で、毎日、小さな余震におびえ、計画停電という名の不便を皆が強いられていたときだった。スケジューリング学会会長（当時）の八巻・静岡大教授と、慶応大学の松川教授のご支援をいただいて、隔月に慶応三田キャンパスで勉強会を開く、今のようなスタイルに落ち着いたのはその年の秋頃だったと記憶する。第1回目は、発起人として、「リスク確率にもとづくプロジェクト評価と合理的意志決定の基準」という基調講演をした。内容は、その前年に出した自分の学位論文が中心で、数式だらけのOR的研究だが、なぜこんな研究部会が必要なのか、どうして長ったらしくて聞き慣れない会の名称をつけたのか、についても触れている。 それは、『プロジェクト・アナリスト』という職種の確立が必要で
存在しているだけで役に立つもの | タイム・コンサルタントの日誌から
これも、前回と同じ頃の話だ。 その日、わたし達は午前中の新幹線で出張に出ることになっていた。朝一番でオフィスに集まり、明日までの二日間の打合せで必要な書類一式を最終確認し、一緒にでかける手はずだった。ところが、プロジェクト・チームの一人が、なかなか出社してこない。彼は制御システムの担当で、その日の午後に、自動制御システム・メーカーと打合せする際の中心だった。気を揉みつつも、他のメンバーと書類の確認を続けていたら、ようやく40分近く遅れて、彼がやってきた。 －－どうした。遅かったな。待ってたぞ。 「すみません。ちょっと家内が入院するんで、病院まで送ってました。」 －－なんだ、奥さんが病気なのか。それは心配じゃないか。 「いえ、病気じゃないんです。だから出張は行けます。大丈夫です。」 －－病気じゃないのに、病院に行ったの？ 「今日が出産の予定日だったので・・。」 あきれて、わたしは怒鳴った。
これから技術者を目指す学生に本を紹介しろと言われたので選んでみた10選 | F's Garage
これから技術を学ぼうという学生に本を紹介しろと言われたので考えている。こういう回答にはセンスが求められて難しい。 技術の本はネットで探せば見つかるので、そこには触れず、仕事とは何かインターネットは何かということをざっくり掴むことが大切だと思う。なお、オッサン趣味なのはご容赦ください。というか最近、ネットの概念的な話の本が少ないような気がする。専門特化していったのもネットの現状なのですよね。 本棚にあったり、過去に読んだ記憶があるものしか思い出せないので、偏ってることについてはご容赦ください。 １．「ハンバーガーを待つ3分間」の値段―企画を見つける着眼術 以前、一緒に仕事してたシーマンを作った斎藤さんの本。ほぼ日の連載を中心にまとめた本なのだそうです。この本、インターネット的な話も、情報設計的な話も、ユーザビリティ的な話も、ゲーム的な話もコンパクトにまとまってて面白い。ただ理解するには少しハ
あなたは、どう考えるの？ | タイム・コンサルタントの日誌から
「佐藤さん、すみません、ちょっとご相談があるんですが・・」 若手社員が机の前にやってきて、顔を上げたわたしに、いいにくそうな声でぼそっときり出した。わたしが、ITリッチなプロジェクトをやっていた時代のことだ。 －－なあに？ 何か、いい話かな？ 「いえ、あの・・。例の中間在庫ロットなんですが、どうしようかと悩んでいまして。」 －－そこは新しいコード体系を使おうって、先週の打合せで決めたじゃないか。 「そうなんですが、注文書のシステムで、ちょっと困ったことが見つかりまして。あのままでは、番号がかち合ってしまう可能性があると分かったんです。」 彼は仕様書の該当箇所をわたしに見せて、問題を詳しく説明する。なるほど、先週の打合せでは、この点を見落としていたらしい。 －－つまり、このまま進めば、ユーザに運用を変えてもらって、少しだけ手間が増えるのを我慢してもらうか、さもなければシステムの設計変更をする
イノベーションのもう一つのジレンマ | タイム・コンサルタントの日誌から
数年前、「知的創造の現場―プロジェクトハウスが組織と人を変革する」という本の出版企画にかかわった。これは米国MITのビジネススクール教授でイノベーション研究の専門家であるトマス・アレンと、ドイツをリードする著名な建築家グンター・ヘンという、異色の組合せによる共著の本で、製品開発プロジェクトの組織設計とオフィスの作り方に関する最新の研究と実践例を述べたものだった。非常に重要なテーマであるにもかかわらず、日本では本書が注目されないばかりか、このようなテーマと問題意識が欧米にあることすら知られていないので、わたしの勤務先が監訳する形で訳書を出すことになった。 さて、翻訳作業がそれなりに進んだ段階で、訳書のタイトルをどうしようかと議論になった。原題は"The Organization and Architecture of Innovation"という、格調高くもアカデミックなフレーバーの漂う題で
プロジェクトは失敗するものである、という英国人の思想 | タイム・コンサルタントの日誌から
1993年3月、ロンドン証券取引所は、ビッグバンを背景に7年にわたって進めてきた、株式取引決済システム「トーラス」開発プロジェクトの中止を発表した。証券取引所はすでにこの事業に8000万ポンドの費用を投じており、人件費を含むシティ（ロンドン金融街）全体の投下コストは、総額5億ポンドに上っていた。証券取引所のＰ・ローリンズ理事長は、責任をとって辞任する。 「トーラス」は、株式売買のバックオフィス業務である株式決済処理の電子化・効率化を目的とした、英国金融界の共同事業で、中心的な推進役はロンドン証券取引所であった。トーラスは米国のパッケージソフト「ヴィスタ」をベースに開発されることになっており、本来ならば、'91年10月に稼働しているはずだった。それは一度、'92年夏に延期されていた。しかし、中止決定時点では'93年中の稼働すら危ぶまれる状況だった。 ちなみにこのプロジェクトは、ローリンズ理事
オーケストラの指揮者かジャズ・バンドのリーダーか － プロジェクト・マネジメントの４つの類型を知る | タイム・コンサルタントの日誌から
前回、「プロジェクト・マネジメントの教育について」（2014-01-27）で、“PM教育の第1ステップは、自分たちが持つべきPM能力がどんなものかを考える”ことだと書いた。あるべき姿が決まらなければ、成長の道筋も決まらないからだ。当然のことである。 ところが、自分の組織に必要な『PM能力』というものに関して、どうも誤解が多いようだ。世の中にあるPM標準、たとえばPMBOK Guide (R)や、それに準拠した資格であるPMP（Project Management Professional）の習得が、「あるべき姿」だと想定している人も多い。あるいは、英国発のPRINCE2や、日本のP2Mでもいいが、これら標準書を教科書のように思い込み、その教科書に自分の現実の方をあわせようとする。これは、プロジェクト・マネジメントの標準化活動がもたらした副作用かな、と感じる。 わたし自身もPMPの資格を持っ
原発 放射能は ジワジワやってくる - アンカテ
原子爆弾は爆薬ではない 原発の放射能は「ドカーン」と来ることはなくて「ジワジワ」来ます。安全厨にも危険厨にもここを勘違いしている人が非常に多い。 放射能を爆薬の超強力なやつと思ってるんですね。それが一番の間違い。これをなるべく簡単な言葉で説明してみます。 爆薬っていうのは、反応を止めることも加速することもできる。放射能はそれができない、超マイペースなんです。 たとえば地雷なら、分解するか爆破してしまえばいい。分解が反応を止めることで、爆破が反応を加速することです。放射能は(正確には放射性物質は)、そういう意味で、止めることも加速して無効化することもできません。常にマイペースでジワジワ熱を出し続ける。 この熱を止めることができるという話はドラエモンレベルのSFになります。本当に止められたらアインシュタイン10人分くらいの天才。放射能はそれくらい定評のあるマイペース。 「外で何が起きても一定の
ITエンジニアの『生産性』と、データ・サイエンスの微妙な関係 | タイム・コンサルタントの日誌から
ある、社外の人との集まりに顔を出した時のこと。IT分野の経験を積んだ人が多く、みな一家言持っておられる。わたしは昨年後半から、久しぶりに社内のIT関連業務を見るセクションに移ったばかりなので、最近の事情に疎い。なるべく拝聴する側に回ることにした。話は業界の技術トレンドから、クラウドやビッグデータといった最新のバズワードに向かい、日本のIT業界の現状をなげく論調にうつった。日本を代表する大手SIerたちの低空飛行ぶり、技術的イノベーションの不足、そして多重下請に象徴される業界の構造的問題。追い打ちをかけるように、オフショアとの競合による単価の下落。なんだか、あんまりエンカレッジされるような話題が出てこない。 －－だとすると、日本のSI業界というのは将来性があるのでしょうか？ わたしは思い切って、直球ど真ん中の質問をなげてみた。しかし返ってきたのは、苦笑いするように首を横に振る姿ばかり。 「情
デュルケーム『自殺論』に学ぶ、人間集団に必要な二条件 | タイム・コンサルタントの日誌から
PMOみたいな仕事をしていると、ときどき現場の実務者から頑強な抵抗に遭うことがある。PMOとはProject Management Officeの略で、組織の中にプロジェクト・マネジメントの仕組みや方法論、そして体制などを導入整備する仕事をする部署だ。いってみれば、プロジェクト遂行に関するカイゼンの専門家集団である。 PMOのメンバーは普通、自分自身ではプロジェクト遂行にタッチしない。あくまでプロマネ達に対して、助言や支援を行うだけだ。社内コンサルタントのようなものである。遂行に直接タッチしないのはなぜかというと、いったん実務作業を分担し始めると、結果に対する責任問題が生じるからである。プロジェクトの成果は、プロジェクト・マネージャーが全責任を負うのが原則だ。それなのに、第三者であるPMOが手を出してしまうと、責任の境界が曖昧になってしまうからだ。 ところがこのPMOという仕事、なかなか難
Drag Cost - 納期を加味した真のコストを考える | タイム・コンサルタントの日誌から
Liquidated damagesという英語をご存じだろうか。地震による「液状化の損害」、ではない。Damageはダメージ、被害だが、複数形でdamagesになると、損害賠償を表す契約用語になる。これは主に納期や性能など、請負側が保証すべき義務を果たせなかった際の損害賠償金のことで、あらかじめ契約で規定しておく。とくに納期遅れに対して科せられることが多く、商社やエンジ会社など、海外との契約を多く取り交わす企業では、略して『リキダメ』などと隠語風に呼ばれる。もし英文の契約書にこの言葉を見つけたら要注意だ。 納期遅れに対するLiquidated damagesは、日数に比例して計算する。1日10万円とか100万円で、遅れた日数分をかけて精算する。ただし、一定の上限を定めるのが普通である（たとえば受注金額の8%まで、等）。大型のプラント建設プロジェクトでは1日1億円近いケースもある。厳しい条件
納期が延びる要因を指標化する － スケジュールのDRAGとはどんな尺度か | タイム・コンサルタントの日誌から
久しぶりにスケジューリングの話を書こう。スケジュールがなぜ長くなってしまうのか、どこを攻めたら短くできるのか、それを数字で指標化できる手法についてである。 いま、あるシステム製品をおさめる仕事を考える。単純化のために、この仕事は以下の６つの作業項目（アクティビティ）のみからなると考える。 1. 基本設計 （推定所要期間＝20日） 2.1 ハード調達 （推定所要期間＝35日） 先行作業：基本設計 2.2 設置調整 （推定所要期間＝ 5日） 先行作業：ハード調達 3.1 詳細設計 （推定所要期間＝10日） 先行作業：基本設計 3.2 ソフト開発 （推定所要期間＝20日） 先行作業：詳細設計 4. 総合テスト （推定所要期間＝15日） 先行作業：設置調整、ソフト開発 さて、このお仕事の納期は何日かかるだろうか。これは、作業項目とその順序関係を図に書いてみると分かりやすい。仕事の全体像をネッ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
