炎上プロジェクトの火消し術『プロジェクトのトラブル解決大全』
飛び交う怒号、やまない電話、不夜城と化した会議室。 集められたホワイトボードが衝立のように立ち並び、全員が立って仕事をしている（座る間が無いから）。週をまたぐとメンバーの疲弊が目に見えはじめ、月を跨げば一人二人といなくなり、仕事場はお通夜となる。 トラブルの無いプロジェクトは存在しない。炎上するかボヤで済むかの違いなだけで、大なり小なりトラブルは付きものである。 自分が所属する部署は大丈夫かもしれない。だが、隣のブースだとか、同期がいるチームで炎上しているのを横目で見ながら仕事する、なんてことがある。ホワイトボードは目につくし、大きな声はイヤでも耳に入ってくるので、プロジェクトが炎上⇒鎮火するパターンなんてものも、なんとなく伝わってくる。 消火作業のイロハとか、怒った客をあしらう方法、リカバリ計画の立て方なんてのも、肌感覚で分かってくる。 そして、トラブルの扱いが分かってくる頃には、「応援
GitとGitHubの機能をひとつのバイナリに詰め込んだ「Fossil」レビュー
ソフトウェアのバージョン管理といえば、GitとGitHubを用いるのが主流。しかし、バージョン管理システムにはCVSやSubversion、Mercurial、GitLab、Bitbucketなど、「GitとGitHub」以外の選択肢も存在します。そんな「GitとGitHub」とは別の選択肢のひとつが、データベースのSQLiteと同じくD. Richard Hipp氏によって開発された「Fossil」です。 Fossil: Home https://www.fossil-scm.org/home/doc/trunk/www/index.wiki FossilはLinuxやmacOS、Windowsに対応しており、ソースコードから自分でバイナリをビルドすることも可能。今回はUbuntu 20.04上でFossilを利用してみます。 まずは下記コマンドを実行して、Fossilのバイナリを実行可
PMBOK Guideに欠けている、３つの重要事項 | タイム・コンサルタントの日誌から
春である。4月の花咲く頃になると、今年は何人くらい受講生がいるかな、とそわそわした気持ちを抱えながら、つくばエクスプレスに乗る日が来る。東大の柏の葉キャンパスで「プロジェクト・マネジメント特論」の開講日を迎えるからだ。まだ働いた経験のない学生たちに、PM論を教えるのは、あまり簡単でない。それでも柏の葉キャンパスは大学院なので、皆、とりあえず自分の卒論で多少は苦労した経験を抱えて、入って来る。つまり小さくて個人的ながら、プロジェクト的な取り組みをした訳だ。だから学部生よりは、少しだけ教えやすい。 PM論を教えるにあたって、どんな構成・体系で説明を進めるべきかも、悩ましい。大学で講義を持っている、というと、「じゃあPMBOKを教えるんですね」とたずねてくる人が時々おられる。こういう人は、PMBOK Guide®︎が『教科書』だと信じているのだろう。だがあれは、いくつかあるガイドブックの一つにす
モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか - プログラマの思索
モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか 下記の記事で、モデルの粒度とトレーサビリティの問題はモデリングツールではなくUMLそのものに真因がある、という事実に気づいたのでメモ。 以下、ロジカルでないラフなメモ書き。 【参考】 プロジェクトを成功させるモデリングの極意（3）：UMLやSysMLなどのモデリングは“いつ”“何を”“どうするのか” (1/8) - MONOist（モノイスト） akipiiさんのツイート: "「UMLの使いにくいところと開発現場での実際的対応」の内容が本当に同感。UMLそのものが大規模案件で使うことが想定されてない問題があると思う。プロジェクトを成功させるモデリングの極意（3）：UMLやSysMLなどのモデリングは“いつ”“何を”“どうするのか” (1/8) - MO… https://t.c
データフローダイアグラムではプロセスは一番最後に書く - プログラマの思索
データフローダイアグラムの書き方について、良い記事があったのでリンクしておく。 記事を読んで、まだ修行が足りないと感じたので、自分用のメモ。 【参考１】 データフローダイアグラムの書き方 (引用開始) プロセス，データの発生源・行き先，データの保管元・保管先全てに名前がついているにもかかわらず，データの流れにだけ名前がついていないDFDを見かけることがあります． これらはDFDの役割を果たしていません． DFDが表現しなければならないのは，プロセス，データの発生源・行き先，データの保管元・保管先を行き来するデータなのです． データの流れに名前をつけないのは，DFDが最も表現しなければならないものを表現していないということです． 図6.プロセス名は最後につける (引用終了) (引用開始) 入出力するデータからプロセスの内容の推測が困難な場合，原因はプロセスの機能分割が適切ではないことが多々あ
チケット駆動の罠～複雑さはチケットの粒度に関連している - プログラマの思索
チケット駆動の罠の記事をメモ。 【参考】 JIRAに死を | TechCrunch Japan (引用開始) ここで強調したいのは、悪いのは必ずしもJIRA自身ではない、ということだ。 ここまで書いてきたことはすべて、ソフトウェアのアーキテクチャと開発を“チケット”の集合に還元する、という考え方に由来している。 JIRAの最大の罪は、それが、もっとも成功し広く普及しているチケットシステムであること、それだけだ。 ソフトウェアプロジェクトをチケットの集合で表す、という考え方そのものが、真の敵だ。 (引用終了) tadashi-aikawaさんのツイート: "本文にも書いてあるけど JIRAをディスっているのではなく JIRAの使い方をディスっているだけ。 Confluence使えばおけ JIRAに死を | TechCrunch Japan https://t.co/pNEqwe12Ex vi
ソフトウェア工学は未成熟なプラクティスによって重大な阻害を受けている - プログラマの思索
平鍋さんの資料にある「ソフトウェア工学は未成熟なプラクティスによって、重大な阻害を受けている」の文言にビビッときた。 以下は思いつきのメモ。 特に主張はなし。 【参考】 SPI Japan 2016 | イベント | 日本SPIコンソーシアム 現場から始めるアジャイルの技術プラクティス ソフトウェア工学の方法論と理論 1. 目的とスコープ(Purpose and scope) SEMAT “Call for Action” の日本語訳 - とあるソフトの開発記録 アジャイルは”再び"死んだ (引用開始) ソフトウェア工学についての後悔 Tom Demarco ソフトウェア工学、そのときは去った。 Ed Yourdon ソフトウェア工学に大切なことは？ Barry Boehm あの指数曲線は間違いだった。 Ivar Jacobson ソフトウェア業界は、ファッション業界のようだ。 Tom G
OSSのMSProjectクローンProjectLibreの使い方 - プログラマの思索
OSSのMSProjectクローンProjectLibreの使い方に関するWebページを見つけたのでメモ。 【参考1】 ProjectLibreのインストールと使い方、基礎、入門 - SEO対策 大阪 OSSのMSProjectクローンProjectLibre: プログラマの思索 づめメモ Projectlibreで日付の書式を変える方法 MS Projectの基準計画の使い道: プログラマの思索 ProjectLibreを使ってみたら、MSProjectとほぼおなじアプリと考えていい感じだ。 実際、ProjectLibreでガントチャートをXML出力すれば、MSProjectで読み込んで開ける。 つまり、プロジェクトリーダーはMSProject、MSProjectのライセンスを持たないユーザはProjectLibreで使い分ける、という運用は可能だ。 僕が使う操作はこんな感じ。 Exce
不安とストレスから解放される見積りとスケジュール方法 - Qiita
エンジニア組織を強くするための本を出版しました Qiitaでエンジニアリングをめぐる様々なコミュニケーションの問題とその解決策や考え方を書いてきた。それらの背後にあるエッセンスをこの度書籍として出版するに至りました。 エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング この書籍は、エンジニアリングを「不確実性を削減する」という第一原理で捉え直し、様々なエンジニアリングとその間のコミュニケーションをめぐる現象を説明していくものです。 はじめに 何かはじめてのことをする場合、人はとても「不安」を感じます。人は未来を考えることができる生き物です。その特異な能力ゆえに、未来に起こるかもしれないよくないことを考えると「不安」を感じてしまうのです。 仕事のプロジェクトなどは、「間に合わなかったらどうしよう」とか「この仕事はちゃんと終えられるのだろうか。」など、未来のことを
マイクロソフト、軽量なプロジェクト管理ツール「Office 365 Planner」を正式公開
マイクロソフトはチームの共同作業や個人のタスク管理などを効率的に行う軽量なプロジェクト管理ツール「Office 365 Planner」の正式公開を発表しました。 Office 365 Plannerの紹介動画（英語）から、いくつか機能を見てみましょう。 Office 365 Plannerでは、自分が関与しているプロジェクト（のうちの好みのプロジェクト）の一覧と、プロジェクトごとの進捗状況が円グラフで色分けされて表示されます。 円グラフ内の黄色が未着手、赤が遅延、青が順調、緑が完了のタスクを示しています。青や緑が少ないプロジェクトは注意すべき、といったことが一目で分かります。 いずれかのプロジェクトをクリックすると、そのプロジェクトの「ボード」が表示されます。ボードには、そのプロジェクトで実行すべきことを大きく分類した縦長の「バケット」が表示され、バケット内にはToDoとなるタスクが示さ
ガントチャートの光と影 - プログラマの思索
プロジェクト管理といえば、ガントチャート。 ガントチャートの良い部分と悪い部分についてメモ。 【参考】 下記の連載記事は、初心者向けのガントチャートの記事で読みやすい。 初めてのガントチャート（1）：ガントチャートって何ですか？ - ＠IT 初めてのガントチャート（2）：いまさら聞けない8つのガントチャート基礎用語＆タスクを洗い出すときの注意点 (1/2) - ＠IT 初めてのガントチャート（2）：いまさら聞けない8つのガントチャート基礎用語＆タスクを洗い出すときの注意点 (2/2) - ＠IT 初めてのガントチャート（3）：Excelガントチャート作成の基本＆関数とグラフで負荷状況を「見える化」する (1/2) - ＠IT 初めてのガントチャート（3）：Excelガントチャート作成の基本＆関数とグラフで負荷状況を「見える化」する (2/2) - ＠IT 【1】ガントチャートは、作業が予測
小さいプロジェクトのほうが炎上したあとリカバリーが効かない件 - やまもといちろうBLOG（ブログ）
全国の200万人デスマーチファンの皆さん、こんにちは。 ２年越しのでっかいほうのプロジェクトは期日前納品とかして余裕ぶっこいていたと思いきや、4ヶ月のちっこいプロジェクトは凄い勢いで炎上して申し訳ない気分でいっぱいになりました私でございますが、スパゲッティが大きかろうが小さかろうが、こんがらがったら「かかる手間は一緒」ということを思い出すのに時間がかかってしまいました。 珍しく、工数読みを間違え、また立ち直ろうにも役員一同納品やら新規開発案件の調整やら納税やらで東京から出払っていたということで、多方面に迷惑をおかけしてしまいました… 申し訳ございませんでした。 議事録やら報告書やら読み返していて思ったんですが、やはり最初の工数計算を間違えてしまうと小さい案件のほうがバッファがない分、取り返しがつかなくなるという法則に改めて気づかされるのであります。かなり個々人が頑張って挽回はしておったので
なぜITS導入は失敗したか？あるいは僕のがっかりメモ - ハードコイルド・ワンダーランド
出張してもどってきたら社内Tracが残念なことになっていた 最近、もともと所属していたチームをはなれて外で開発をしていた。 久しぶりにもどってきてTracを覗いたところ、非常に残念な感じなっていて、有り体に言えばゴミタメになる寸前だった。 （今現在も解決していない） ほかのチームでRedmineを展開してそこそこ上手くいっていたので、 なんでこんなことになったのか？どうすれば防げたのかをいろいろ考えた。 個人的なメモ。 何がいけなかったのか 個人的に思うところは以下の３点 ・マイルストーンの役割を誰も理解していない ・バグ表を作る人（≒リーダー）がTracを使えない、使う気がない ・求められる機能とTracの機能に乖離があった マイルストーンの役割を誰も理解していない 「ソフトウェアのリリースとITSのマイルストーン、リポジトリのブランチはそれぞれ同期する」なんて ITS使ってる人には常識
PHP製の高機能プロジェクト管理·jotBug MOONGIFT
プロジェクト管理はオープンソース・ソフトウェア、パッケージソフトウェア、Webサービスと無数に存在している。どれが自分たちに合っているのか分からなくなってくるくらいだ。一つの選択肢として、使っているプログラミング言語に合わせてみるのはどうだろう。 リポジトリブラウザ 普段使っているプログラミング言語であれば、気になったところを自分で修正したりカスタマイズすることができる。PHP開発者の方はjotBugを試してみよう。 今回紹介するオープンソース・ソフトウェアはjotBug、Zend Frameworkを使ったプロジェクト管理システムだ。 jotBugはPHP製のプロジェクト管理で、複数のプロジェクトを管理することができる。主な機能はリポジトリビューワー、ダウンロード、ロードマップ（マイルストーン）、チケット、Wikiとなっている。管理画面も提供されており、実用性の高いシステムになっている。
バグ！ボンバイエ！バグ！ボンバイエ！·BUGS MOONGIFT
開発者にとって何よりも怖いもの、それがバグだ。だがバグの発生を個人の責任にしていては、決して改善されることなく、ずっと生み出され続けるだろう。そう、バグは開発プロセスの問題（開発自体、またはテスト過程など）なのだ。 PHP+MySQLのバグトラッキングシステム バグを見つけ出す作業およびそれをつぶしていく作業はプロジェクトチーム全員であたっていく必要がある。そのための管理インタフェースとしてBUGSを紹介しよう。 今回紹介するオープンソース・ソフトウェアはBUGS、Webベースのバグトラッキングシステム（BTS）だ。 BUGSは継続的なバグトラッキングを見据えている。マイルストーンを設定したり、ビルドのバージョンを記したりして管理することで、いつどのような状態において見つかったバグなのか分かるようになっている。 入力画面 初期設定項目を含め、入力項目は数多い。そのため、ライトに作業を進めた
実践バグ管理（ソシム刊）
2009年3月17日 ■著者 クジラ飛行机／あかさた ■定価 2,940円（本体価格 2,800円） ■プロジェクトに失敗は許されない！根性だけでバグはなくならない。デスマーチが始まる前に絶望を希望に変える管理術。 はじめに 本書はバグ管理に関する本です。システム開発におけるバグ管理の重要性と、そのやり方に関す るノウハウを共有する目的で書きました。 最近では、使いやすいオープンソースのバグ管理システム（BTS）が複数登場しています。それ により小さな開発プロジェクトや個人でつくっているソフトウェアでも、バグ管理システムを活用 するようになっています。そこで本書では、バグ管理システムを利用して、どのようにバグの管理 を行っていくのか、バグレポートをどのように書いたらよいのかなど実践的な内容を扱います。 本書では著名なバグ管理システムの使い方を紹介することよりも、ツールに依存しない本
そろそろバグ管理についてひとこと言っておくか - 平凡なエンジニアの独り言 はてなブログ出張所
ひとことどころか、バグ管理について367ページにわたって書いてしまいました。「実践バグ管理」です。なでしこなどで有名なid:kujirahandさん（クジラ飛行机さんのブログ）との共著です。 実践バグ管理―プロジェクトを成功に導くための 作者: クジラ飛行机,あかさた出版社/メーカー: ソシム発売日: 2009/03メディア: 単行本購入: 6人 クリック: 148回この商品を含むブログ (21件) を見る 本書の特徴 本書の特徴を伝えることには非常に苦労しています。「バグ管理なんて何について書くの？」とかよく言われるわけです。バグ管理のやり方なんてあたりまえ・・・なのかもしれませんが、大抵のプロジェクトに参加すると以下のような現象に遭遇するものです。 Tracなどの運用を始めると、「バグレポートに何を書けばいいのか？」と質問される バグレポートに書かれている内容が意味不明 とある案件では
トヨタが気前よくカイゼンを教える本当の理由（1/3） ― ＠IT MONOist
本連載ではソフトウェア開発／運用でのCO2排出量見える化と、製造業における取り組みのポイントや算定における留意点を3回にわたり解説する。第1回となる今回は、そもそも製造業がなぜCO2排出量算定へ取り組まなければならないのかを解説しよう。
第3回 「本質的な解決ができない（上）」
遠藤 紘一 リコー 取締役副社長執行役員CSO兼全社構造改革担当 私は小集団活動でよくテーマにされる「2S（整理・整頓）」や「5S（整理・整頓・清掃・清潔・しつけ）」活動が嫌いである。確かに作業現場をきれいな状態に保つことは大事なことだ。しかし現場リーダーには、ただ単に掃除を徹底すればそれでよしと考えてほしくない。汚れがついたり、ゴミが出ないような仕組みを考えることに知恵を使ってほしい。 処置と解決は異なる 今回は、現場改革において「本質的な解決」とはどういうことかについてお話したい。 私は、現場リーダーに「『処置』と『解決』を取り違えるな」という話を、折に触れてしている。 まず例え話をしよう。家の中でお年寄りがつまずいてケガをした時に、手当てをして包帯をまいたりするのが「処置」。家をバリアフリーの構造にしたり、目が悪い人にもつまづきやすい場所が分かるようにしたり、そもそもつまづくような個
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
はてなブログ | 無料ブログを作成しよう
