プロジェクト管理」カテゴリーアーカイブ

忙しいときほど重要なのはチキンライスでもプロジェクトマネジメントでも段取り八分で

さらに第4弾な料理シリーズ。夕飯は近くのスーパーでコロッケを買ってきて済ませてしまったので、お昼のチキンライスを例に解説をします。 段取り八分 段取り八分ってのは確か建築業界の用語で、いろいろな業者が入ってくるときちんと段取りをしておかないと待ちが入ったりして全体が遅くなる、という意味だったハズなんですが、巷の「段取り八分」の解説サイトは間違ったものが多いですね…。現場監督の管理の基本「段取り八分」って何のこと? | 負けるな新人!目指せ所長!0から始める建築現場監督への道 あたりとか、建築系のブログを見ると正しいものが書いてあります。他のサイトは大抵ダメです。 建築の場合、材料と人を集めて順番にこなす、というのが重要になり(途中で「雨」がまじるので、プロジェクトバッファは必須なのですが、これは別の機会に)、それ以下に工程を短くすることができません(手抜き工事は別)。これがクリティカルチェ … 続きを読む

カテゴリー: プロジェクト管理 | 1件のコメント

失敗をリカバリするのはミートスパゲティもプロジェクトマネジメントも同じ

しつこいけど第3弾な料理シリーズ。単に、子供向けの夕食を作るのにモチベーションが上がらないので、あれこれやっているだけです。一人だったら外食とか弁当にしちゃうんですけどね。 失敗してもリカバリする 基本、料理は段取りと手順(料理本に書いてある手順)に沿って従えば、大抵「食べられる」ものができあがります。時には炭になってしまうこともありますが、まあ、それは完全に失敗なパターンですよね。でも、ちょっとした手順を抜かしたり、前後させてしまったような間違いの場合は、食材と時間がもったいないので「捨てる」ことはあまりないでしょう(客に出すものだったらそうかもしれないけど、家で食べるものだし)。同じようなことは、プロジェクトマネジメントにも言えて、ちょっと失敗したからといってプロジェクト全体を失敗(プロジェクトを停止するということ)させることはありません。なんとか完遂しようとするでしょう(間違った方向 … 続きを読む

カテゴリー: プロジェクト管理 | コメントする

PERT図とカレー調理の関係

チンゲン菜で作るおいしい餃子とプロジェクトマネジメントの関係 | Moonmile Solutions Blog の続きで、プロジェクトマネジメントと料理の関係です。いや、単純におらのカレーレシピですけどね。ちまちま、Windows 10 IoT Core Advent Calendar 2016 – Qiita を埋めつつ、中小規模のプロジェクトマネジメント案を練りつつということです。 タスクを並立させる 餃子料理の場合は、ひとりタスクになりますが、カレーの場合はいくつかのタスクが平行して動きます。複数名でプロジェクトを動かせば途中のマイルストーンがネックになり、ひとりでプロジェクトを動かしてもお客が絡めば応答時間によってマルチタスク的に動かせるという話です。ラピッドプロセスやJIT的に応答を返すのではなく、むしろ、その時間差を利用するという方法ですよね。どれだけ急いでも必ず時間が掛かる … 続きを読む

カテゴリー: プロジェクト管理 | コメントする

パタンランゲージとアジャイルの関係を再考する

「パタン・ランゲージによる住宅の生産」の序文に「1. 建築と施工は分離されていてはならない。(アーキテクトビルダー)」とある。何処かで聞いたようなことがあると思う。アジャイルソフトウェア開発宣言 に「プロセスやツールよりも個人と対話を…」とあるのと非常に似ている。 引用として、生産プロセスの基本条件を抜き出すと、 建築家と施工は分離されてはならない。(アーキテクトビルダー) 生産システムは、地域の高度に分散化された職人群(拠点)を利用する。(ビルダーズヤード) 共有地はユーザーによって最も大切な場所であり、彼らの管理下にあるべきである。(共有地の共同設計) ユーザーは、自分自身の住まいの間取りについて、現代建築のような受け身の姿勢ではなく、核家族によってそれぞれ異なる間取りができるような積極的な姿勢で参加しなければならない。(個々の住宅のレイアウト) 施工のシステムや技術やディテールは、プ … 続きを読む

カテゴリー: プロジェクト管理 | コメントする

追悼 デスマーチ

「デスマーチ」の著者 エドワード・ヨードン氏が亡くなったそうなので、追悼記念に書き下しておく。ちなみに、ツイッターでも書いたけど「デスマーチ」は「終わりなき行軍」を意味するので、現在の短納期(半年ぐらい)のプロジェクトは当てはまらないと思う。そういう場合は、すでに精神が「デス」か「Dead」してしまう場合が多いので別なラベリングが必要だろう。「お前は既に死んでいる」…でもいいけど、意味が違うから別なのを考えよう。 「デスマーチ」を手に取った頃 私が「デスマーチ」を知ったのは、まだ阿佐ヶ谷に住んでいたころだから一人暮らしで寝て起きて渋谷だったか新宿だったかに通っていたころだ。20年前になると思う。DoCoMo のプロジェクトで i-mode の前身を作っていたころだ。いまでこそ i モードを知っている人は少なくないけど(つーか、終わっているから知らない人のほうが多いかも)当時、なんだかわ … 続きを読む

カテゴリー: プロジェクト管理 | コメントする

計画を見直せない病、という点で国立競技場の件を考える

すわ、例の中抜き構造ですか?と思っていた国立競技場の予算超過の件ですが、新国立競技場の工事費が下がらない理由|建築エコノミスト 森山のブログ を通読していくと(「~めぐる議論について」も全て読む)、概算をせずに決定をしているのではなく、コンペの後に概算が来るというコンペ後の決定プロセスの問題みたいです。まともに作ろうと思えば 3,000億円、という価格(?)は正当なもののようです。ちなみに、森山さんのブログは進撃の巨人あたりから読んでいるので、読者としては古参です。 コンペをした頃の予算が不明なのですが、新国立競技場 – Wikipedia によれば、当初見込みが 1,300億円となっています。他競技場が500億円ぐらいなので、見込自体も高いし、その後の全部のせ状態で3,000億円という見込みも相当高いです。高いです…が、これは中抜き構造ではなくて、先のブログにあるように正当に建設したとき … 続きを読む

カテゴリー: プロジェクト管理 | コメントする

小学三年生の夏休みの宿題を10日間で終わらせる計画

「夏休み 宿題」あたりで、小学1年生でもわかる7月中に夏休みの宿題を終わらせる方法 – Moonmile Solutions Blog にたどり着く方が多いみたいなので、今年の夏休みの計画編を書いておきます。 娘も小学三年生になったので、宿題も多くなっています。うちは共働きなので夏休みも学童に行くことになるのですが、せっかくの「夏休み」なのだから、他の子の夏休みと同じように勉強時間と遊びの時間を分けておきたい、と思ったのが目的です。まあ、プロジェクト管理(プロダクト管理じゃないよ)の基本でもありますが。 例によって、東京の小学校では夏休みが8月末ではありません。日数にして約30日、土日を除くと約20日になるので、丁度、会社務めの8時間×20日間=160時間勤務と同じになります。ええ、基本は「160時間勤務」ですからねッ!!! ■計画を立てる さて、今回の夏休みの宿題は主に4種類あります。 … 続きを読む

カテゴリー: プロジェクト管理, 雑談 | コメントする

Visual Studio 2010 で TFS 2012 Express を使う

素直に Visual Studio 2012 を使えばよいのですが、メインマシンには VS 2010 を残しておこうかなと思ってちょっと試してみました。 以前、Team Founcdation Server 自体が高くて手が出なかったのですが、2012 からは Express 版として5人ならばフリーで使えるバージョンがあります。まあ、つまりは個人的に使うならば自由だよ、という意味ですね。以前から、VSS を使っていたのですが、途中で cvs やら subvertion やら git とやらを使ってしまっていたので、TFS はほとんど手を出していませんでした。 Microsoft Visual Studio TFS Express 2012 | Microsoft Visual Studio http://www.microsoft.com/visualstudio/jpn/product … 続きを読む

カテゴリー: プロジェクト管理, 開発 | 2件のコメント

のだめカンタービレに学ぶソフトウェア開発プロセス(音合わせ中)

「のだめカンタービレ」というのは、一斉を風靡した(したのか?)クラッシック・ギャク漫画ですが、ギャグというか正統な音楽漫画なんですけどね。ホントは。 実写のほうはさておき…、原作漫画とアニメのほうをベースにして、ソフトウェア開発プロセスを解説/考察していきたいと考えています。実は、ソフトウェア開発組織はオーケストラ:柴田 芳樹 (Yoshiki Shibata):So-netブログ な話で、オーケストラとソフトウェア開発の類似点は考察に値するなぁ、と漠然と考えていた(第10巻ぐらいを読んだあたりで)のですが、アジャイル開発とのバッティングがって思考停止しておりました。 が、最近、ブログテーマ[とある現実な掌握術]|システム開発の見積もりブログ をぽちぽちと書いていて、なるほど真面目にアニメとの組み合わせでソフトウェア開発プロセス自体を考察するのも良いかなと思い始めました。まあ、この「と … 続きを読む

カテゴリー: のだめ開発プロセス, プロジェクト管理 | コメントする

中国オフショアな話

前記事で価格競争な話が出てきたので、勢いでオフショアな話も書いておきます。 開発分野を中国にオフショアする場合には、 日本の案件を、大手SIerが取りまとめ 設計書を日本で記述 実装、試験を中国オフショア 最終試験を日本で行う という形になります。まぁ、3 のところが、日本の「協力会社」でも変わらないわけで、いわゆるゼネコン式になりますね。ここで、「ゼネコン式」が良い悪いかは別にして、かつ「オフショア自体は効率的かどうか」も別として、中国オフショアの成功率を高める方法を列記しておきます。私の経験から来るものなので、オフショア先によって違いは出るかもしれませんが、大体同じだと思います。 中国オフショアをするときには、第1に「単価が安い」ということでコストカット的な意味あいで出すことが多いのですが、中国のIT会社からすると、物価の差から結構な金額が入ってくることになります。なので、中国IT会社 … 続きを読む

カテゴリー: プロジェクト管理 | コメントする