てきぱきプロジェクトの作り方（概要編）
前提として、プロジェクトのスコープやゴールは一応定まってるものとする。揺れてたら揺れてるのを押さえるのが先。その辺は前捌き編（発表未定）にて。
１）プロジェクトの重要目的、ゴールを絞って押さえる。なんとなく作業してはいかんよいかんよ。ポイントは絞って要点化することね。
２）形式手続きは一旦全部忘れて要点化したゴールへの最短ルートを見通す。なるべくショートカットルートを描いてみる。いろいろな意味で余力を作りだすのが目的。項目を全部書き出さないのが混乱しないポイント。シンプルにシンプルに。
３）その他必要な作業やタスクを並べて積み上げる。優先順位は当然のごとく必須。
４）ついでに、「これも出来たらいいよね～」ということを積み上げておく。
５）２をざくざく進めて、プロジェクトの主要目的を押さえてしまう。
６）５）で心の平穏を得た後、３～４を積み上げてアップサイドを取っていく。
ってな感じ。特別なことじゃなくて基本だけれども、１～２ってのは結構忘れさられる。特に始まっちゃったあととか。煮詰まってくると何がなんだか分からなくなるものなので。 この進め方がどうやっても取れない、積み上げ重視の場合もありますけどね。でも概ね何がしか構図とか構造とかはあるものなので（だってプロジェクトだもん）、そこを突くと。
落ちはもちろん、概要編の続きが待てど暮らせど来ないことである。そして書いてみて思うですが、秘訣とかそんなものは欠片も無いですね。ざっくりと丁寧の切り分け感覚と予測力くらいかな。でもそれも文字通りのもの。
こういう現場ノウハウを重要ってことでReblog。うん、確かに1と2が忘れがちですよね。
僕的には応用範囲は広めで、設計段階での「粒度をそろえた主成功シナリオと例外の整理」なんつーのにもいいとおもう。これ、確かに切り分け感覚と予測力で、経験とコツが必要。
これ、ノウハウ記述化しづらいんですよね～。筆者の整理力と頭脳力が足りないのもあるでしょうけど。でもなんていうか、いろいろと書けば書くほど本質から外れる。それこそ、コーディング規約のごとく。
PMBOKの体系をちょっと眺めたこととかもありますけど、なんちゅうか、それはそれこれはこれという感は否めない。駄目ってのではなくて。
結局は、１）勝ち筋条件の把握、２）筋から外れてる状況へのセンシティビティと勘所把握、３）戻し方のシナリオ設計とベストモデル選択、とかいう話になって、後半になればなるほど交渉調整設計みたいになってきて見事にプロマネメソッドから外れる、と。最後は広義の政治交渉になるので、とりあえずゲーム理論を一通り読んで理解した上で全部捨ててみよう、みたいな世界に。
あ～～～、書いてて一個分かった。決まりきったことを取り決め手続き通りやって収めておしまい、という仕事を最近やってないんだ。はじからはじまで非定型飛び道具みたいな日々だからこんな記述傾向が強まるのかも。
でも、新しい課題設定とか、複雑な問題解決とか、現実のテーマを取り扱うとそうならざるを得ないはずなんだよな。新規事業の見通し設計とかってのは、よほど掴みきった特殊なものじゃない限りは、模索する要素が入るのが本来なので、そこを全部分かってるなんて言ったらそれこそペーパー上の嘘になる。計画は立てられるけど、オペレーションのところが読めないとか、需要のペースが読めないとか、技術安定の速度が読めないとかなんかあるもんですよ。初期だとパートナー企業の意向が読めないとか。組む相手によってモデルが変わる、とか。
PMBOKって、プロセス定義もあるんですが、静的でストラクチャラルな体系化なんですよね。「こういうことも考えた方がいいよ」みたいな受け取り方でいいんだと思います。で、いちおう非定型プロジェクトにも応用できるんですけど、最低でもゴールは決まっていて、そこに近づけるために変化する状況に適応するっていうのが基本。
SWさんが相手にしているような、「建前ゴールがありながら、日々、ゴールが変わる」なんて場合には「ここは抑えとけ！」っていうゴールそのものというよりも、ゴール条件みたいなものが大事。いざとなったら「ここがゴールぅー」みたいな、あえての小学生プレイも必要なのでは。そうしないとExitできないですからね。
あと人数も関係するかな。大人数だと、なんだかんだと組織論が入ってきてPMBOK的な「宣言」が大事ですし。なので、タイトルは「ゆるふわプロジェクトの作り方」というほうが正解ではｗ
