見出し画像

from図書館返却本棚その24 「プロジェクト進行の技術が身につく本」前田考歩、後藤洋平。その1

私は個人的なプロジェクトをたくさん抱えている。


などと書くと仕事みたいにいやいや持たされてる感があるから、言い直そう。
個人的なプロジェクトがたくさんあって楽しいです\(^o^)/

だが「そのプロジェクト、なにか成果でてんの?」という質問はNGだ。

その質問は私に効きすぎる。◯す気かッ!

……冗談はさておき、もうちょっとそれぞれのプロジェクトをうまく進めて成果的なものがでないかなあなどとはいつも思っている。
そんな思いが、私にこの本を手に取らせた。





副題:紙一枚に書くだけでうまくいく


はいでました、紙一枚(笑)
みんなこれ好きだよね。もちろん私も好きだ。
ライフハッカーはみんな好きなんじゃないだろうか。知らんけど。

この本ではプロジェクトを「プ譜」という紙一枚にまとめることを推奨している。
まだ読んでいないからわからないが、「プ譜」とは多分「プロジェクト譜面」。
ふうむ、アマチュア音楽家でもある私としては、譜面と聞くだけでなにやら興奮するものがある。

あと私はかっこいいことをなんか間抜けな語感で表した言葉が好きだ(笑)

これは読み進めるのが楽しみになってきた。



著者はどんな人?


どちらもプロジェクトマネジメントの専門家。
前田氏は「プロジェクト・エディティング」と「プ譜」の提唱者。
後藤氏は「プロジェクト工学」の考案者でプロジェクト進行支援者。

なんだか全然よくわからないが、とにかくプロジェクトのプロということだろう。


基礎編:第1章 なぜプロジェクト進行が重要なのか?

そもそもプロジェクトとはなにか?

ここでプロジェクトとはなにかという問いに対して非常にユニークな答えが示される。

プロジェクトとは、やって見る前に何をしたらどんな結果が得られるのかわからない行動

という答え、定義だ。

対義語としては「ルーティンワーク」がある。
これはどうすればどうなるのかわかっていて行う行動ということになる。

個人的なプロジェクトの場合、例として私の場合の「ギター弾き語りができる人になる」で考えてみると、これは細分化して考える必要がありそうだ。

ギター弾き語りができるようになるには練習すればいい。
だからこの定義によるプロジェクトではない。

だがどのレベルに達すれば「できた」といっていいのか不明だ。
それにその弾き語りをどのようにアウトプットすればいいのかも一部不明である。

だから私の「ギター弾き語りができる人になる」はプロジェクトである。


第2章 プロジェクト進行の基本を抑える

プロジェクト進行の全体像


プロジェクト進行には以下の基本形があるという。

1 企画: こうなりたいという目的と制約の整理
2 要件定義: なりたい姿の具体像
3 設計: 計画作成
4 製造: 計画の実行
5 テスト: できたものが企画、要件定義と合致するか?
6 検収: テストに合格して完成させること

なお、:以降の解説は私が勝手に要約したものである。

これらの基本的なプロジェクト進行方法を「ウォータフォール型」のプロジェクト進行と言う。
水の流れのように上から下へスムーズに流れることを前提としているからだ。

だが当然現実はそうは行かないことも多い。
そんなときに使われるのが「アジャイル型」のプロジェクト進行だ。
これは最後まで計画が詰められてないけど、とりあえずやってみて修正していこうという開発手法だ。

私の個人プロジェクトは、期せずしてアジャイル型になっていることが多いと思われる。

だからいつまでたっても最終形態が見えてこないのかもしれない……。


それとどうでもいいが、「ウォータフォール」とか「アジャイル」とかカッコいいな(^o^)



第3章 プロジェクト進行における6つの落とし穴

やればやるほどうまくいかない


これはうまく行かないプロジェクトほど、その進行管理とか、記録とか、資料収集とか、こうした「管理のための管理」を一生懸命やりがちという問題を示している。

……ぐはあっ(吐血
これも私に効きすぎた。◯す気か!!


でもほら、うまく行ってないときでもこういうことしてると気が休まるじゃん?
ちょこっとでも何かした気になるじゃん?
つまり精神衛生上には効果があるってことじゃん?

だから全面否定はしないでほしい。
けどどう考えてもこんなことしてるから成果がでないんじゃ!という言には対抗するすべがない……。



決められた工程表は「正しい]とは限らない


プロジェクトを進めるうえでWBSという工程表を作ることが必須だという。
WBSとは得たい成果を分解して小さな作業レベルの落とし込んだ表のこと。

これは作成難易度がかなり高い資料だ。
そもそもこんなものがかんたんに作れるならば、かんたんに実行できるはずということでもある。

つまりとりあえず作っても「正しい」とは限らないのに、修正するのも難しいのでプロジェクトそのものが頓挫する原因ともなりうるというヤバい資料だ。

これはビジネスなどでの大規模プロジェクトならともなく、個人がこだわって作るものではなさそうだ。
そもそも一人でやっているので、小さな工程をいちいちそこまで明確化しなくてもいいと思われる。


はい、長くなったので以下次号!
  ↓↓↓





いいなと思ったら応援しよう!

この記事が参加している募集