003-プロジェクト管理は難しい【仕事】

まいど。
ちょっと全編仕事のメモとして。
ほとんどの人に意味がないので、あの、普通のマイミクさんは読まないでください（笑）

【プロジェクト管理がまだまだまだまだ……（エンドレス）】

今週一番痛感したのは、自分が始めたプロジェクト管理の甘さ。
スケジュールが押したり変更になるのは仕方ないにしても、見通しが甘いというか。
色々な不足が結局自分にかえってくるな、というのがありました。

管理がおかしくなる原因として

・スコープ計画（WBS）の不十分さ
・それによる計画外の作業発生
・ワークフローの割当の甘さ

があったと思います。

ワークフロー割当の甘さと、スコープの計画の不十分さは密接に関係していました。
今回反省すべきは、まずワークフローの認識がアバウトだったことだと思います。

自分でこれをいってはおしまいなのですが、例えばwebを作りに当たり、自分一人であれば、
コンテンツの内容などは、デザインしながらコーディングすることって、結構あったのです。
自分一人でやるなら、

・コンテンツのデザインを一通り作成→コーディング→お客様に提出

よりも

・デザインしつつコーディング→お客様に提出

のほうが、工程数自体は減ります（ちょっと乱暴ですけど、そうやって今まで処理してきました。)
一人でやるには、その方が効率的だったのですね
（と、同時に顧客不在かな、と思う部分も今はあります）

ですが、このやり方で二人、あるいは複数人体制で行おうとすると無理が出てきます。
というのも、もう一人は僕ではないからです。
複数人で仕事をやる、ということは、得意分野を集めて仕事をする、ということです。
言い換えれば、それぞれが苦手分野を持ち合わせている、ともいえます。

今回コーダーさんにはできるだけデザイン的な要素を排除して仕事を割り振りしたつもりですが、
結果としては指示が中途半端、かつ、工程が思った通りに動かない、といった結果になりました。
かつ、あたらためて自分にタスクが集中しすぎているな、と感じました。

自分にタスクが集中すると、デザインが遅れる。そうなると後工程のコーダーさんが待つ。
待ってると空きができるので、中途半端な指示で仕事をお願いする。
できあがったものは、当然製品として足りないものになる。
自分がそれを補完する時間はとりにくい。

…書いていて思ったのですが、工程に人が沿うのでなく、俺の都合に工程を添わせていますね……。

こういう状況でしたので、今回思い切って知りあいのwebデザイナーさんにコンテンツ部分のデザインをお願いしました。
そしてあがったデザインから順序よくコーディングしてもらったのです。

するとどうでしょう。
コーダーさんとしては、素材はきっちりできているのですから、作業に迷いがなくなります。
はた目から見ていても「集中しているな」と見て取れる作業でした。
また、自分自身も、言い方は悪いですがコーダーさんのための素材を作ることに焦らなくてすみました。
結果として、自分のタスクに集中することができたのです。

この流れが3日ほど続いたのですが、本当に気持ちよかった。
ああ、うちはこういう流れでやらないともうだめなんだな、と心から思いました。
すごくすっきり、先が見えた、というのか。
結局、仕事に無理するのではなくて、見積もりを頑張れ、ということなんだと思いました。

今回これがうちにとってすごく大きな収穫でした。
今後はできるだけこの流れでできるように、仕事を見積もっていくつもりです。

で、話が元にもどると、結局スタッフの選定で僕は間違いました。
誰が何をやるのかが明確でないから、工程があいまいになりました。
そのくせ、スケジュールをタイトに組んだため、予想外のスケジュールをこなす余裕がなく、スケジュールが遅れました。

スタッフの選定ミスとそれによるスコープ計画の不徹底さが、今回の失敗の原因でした。

【プランニングの内容をもっと詳細に＋テンプレート化】

思うままに書いているので、内容がぐだぐだですが…。

そしてomniplanでスケジュールをある程度管理したのですが、これも破綻しました。
破綻の原因は簡単でスコープ計画があいまいだったからです。
その結果、思ってもない作業がでてきて、それがスケジュールを圧迫しました。
繰り返しになりますが、そのために工程へのスタッフ割当もおかしくなっていました。

まー、おかしものにおかしいものが、かけ合わさっているのですから。まともに動くはずないんです。
それを僕は今まで「自分ががんばる（＝無理する）こと」で解決してきました。
ですがとうとうそれも破綻した訳です。

omniplan→iCal（あるいはomniFocus）に展開する時に、あまりに工程がアバウトでした。
（例として「ホームページ制作」などと、なにに対して作業するかが曖昧）
なので、これを排除しなければいけません。そのあたりが、スコープ計画に繋がってきます。

あと、これはこのところいつもいっているのですが、omniPlanでもなんでもいいので、基本の工程を持つこと。
工程のテンプレートを持つことが、まだまだ不十分だな、と思いました。
新規物件発生時にはこのテンプレートから作業をする。そうしないと、効率良く細かいスコープ計画は立てられない。
つくづくそう感じました。

僕の場合はプロジェクト管理だけをやっているわけではありません。
であれば、尚更。です。

ただ、自分自身にはっきりさせとかないといけないのは
「今やろうとしているツールの選定自体は、まったく間違っていない」
ってことです。

omniPlanからの一連の流れは、自分が今までやってきたプロジェクト管理よりも、Todo管理よりも効率的で共有しやすく、変更がきちんとどの方面にも反映します。

問題なのは、僕の管理能力。

そのあたりについて、もっともっと磨きをかけて、考えて、手法を変えて、結果を出していかないと、いけないな、と感じました。

ここは絶対にものにします。

---