プロジェクト デザイン パターンを読んでみた
プロジェクト・デザイン・パターン 企画・プロデュース・新規事業に携わる人のための企画のコツ32
仕事でも新規事業を考えるみたいなことに関わっているので、参考になればなぁと思い読んでみました。
結論から言うと、ページ数が少なく読みやすく、分かりやすい本でした。
なので、気になる方は是非読んでみてください。
ストーリーとは別に、 具体的な企画創出の手法なんかを織り交ぜたサンプルが書いてあるとさらに良かったなぁと思いました。
「あるある」のストーリーのあとにそれを汎化したパターンを紹介するという構成なので、気になるところから読めます。
新規事業の企画をする場合の着眼から立案、プロジェクトの体制づくりと運用、
日頃の心がけなど３２のパターンで示しています。
せっかく読んだので面白かったパターンと気になることを備忘録的に残しておこうと思います。
あくまでも備忘録なので、認識が間違えていたらすいません。
いつもの通り、ご意見・ご指摘・アドバイスがある場合は、個人的にこっそり、かつ、優しく教えていただけると嬉しいです。
ちなみに今回は（も？）かなりの散文です。
構成も稚拙なのであしからず。
概要
書籍の中でも記載されていますが、パターンなので手順やマニュアルではありません。「あるある」の対策を共有するために「言葉」にしたものです。
本の構成は「あるあるストーリー」があり、それに対するパターンが1個以上書いてあるという構成です。
パターン化されているのもあって、Fearless Changeに似た感じですね。
内容は読みやすくて良いのですが、できればパターンを実行する際に使う企画のメソッドや手法、ツールみたいなものをもう少し具体的に知りたかったなぁ。
パターンの概念は理解できるけど、再現するツールがないといった感じ。
それは別途、デザイン思考とかそれ系のもので学べってことですね。
パターンは32個あり、5つのカテゴリーに分類されています。
CORE（哲学）、LEARN（情報収集のコツ）、CREATE（企画作成のコツ）、LIVE（企画人として生きるコツ）、PLEASURE（もう1つの企画の考え方）です。
面白かったパターン
個人的に「あるある」を強く感じたパターンを3つあげます。
- 相談の順番（CREATE No.16）
これは「あるある」ですね。
僕のような打たれ弱いあまちゃんには大事なパターンです。
相談の順番を間違えると、ガクってなっちゃいますので。
このパターンを僕の考えを例にして書いてみます。
アイデア発案当初、自信が持てないアイデアの場合は特に、僕はまず賛成意見やポジティブ意見を聞いて自信をつけたいと考えます。
それに発案当初はアイデアの説明も下手なので、つたない説明でも聞こうとしてくれる人に相談する方が気が楽です。
説明の練習にもなりますし。
説明がある程度できるようになりアイデアに自信がもてるようになってから、ガツンと指摘してくれる人に相談します。
自分とは別の観点や気付いていなかった弱点を鋭く指摘してもらうことで、アイデアの成長につなげようと考えます。
ただ、その頃にはアイデアへの自信もあります。
なので、意見を受け入れるか否かを自分で判断する精神力がついています。
あまりにも憶測ベースの否定意見であったり、そもそも基礎知識がなさすぎて話にならない意見の場合は、本当に参考程度に考えます。
これが、自信がない時点で同じことを言われると「うぅぅぅぅ〜そういう見方もあるかぁ〜」となってしまい、あーだこーだ考える時間ばっかり増えちゃいます。
なので、相談の順番はかなり大事。
ただ、人の意見よりも客観的な事実データが一番大事だと思います。
人の意見を聞くのはあくまでも参考（と言うと、誰も教えてくれなくなりますが）として、ベースは事実データで判断するように心がけています。
- 愛着が生まれる余地（CREATE No.17）
パターンの内容は、クライアントに隙のない企画をみせるよりも少しすきがあるぐらいの方が、クライアントも一緒に考えられて企画に愛着をもてるようになるといったものです。
これは、今の会社に入社してからずっと思っていたことです。
H/Wを主体に作ってきたメーカーは似た感じなのかもしれませんが、分業化がなされています。
企画 -> 開発 -> 品質保障 -> 運用
-> 販売
みたいな感じ。
もちろん開発の中でも、H/W、メカ、エレキ、S/Wのように分かれます。
さらにS/W開発の中でも基盤S/W開発、アプリ開発といったように分かれます。
何が分かれているかというと、セクションが分かれているのです。
これじゃあ品証や運用の人はコスト意識も製品への愛情もわかないよなぁ〜〜〜
企画はもちろん最後まで携わるとして、品証や運用はもっと早期から開発に参加すれば良いのになぁって思ってました。
同じことを言っているかもしれませんが、多能工なチームとかDevOpsとか、そんなことを言いたいわけじゃありません。
言いたいことは、チームの中に品証や運用の役割を担うってことじゃなく、一緒に考えれば良いってことです。
そのためのチーム構成とか開発モデルとか、そんなのはなんでも良いのです。
今のバトンリレーのような進め方だとサービスの開発はうまくいかないよって思っています。
もちろん事業採算やROIの観点で、企画から運用までをちゃんと把握・管理する人は必要だと思います。
トヨタでいう主査みたいな人。
しかし、いま言いたいことはそういうことではなく。。。
品証はお客さんに近い立場にいるわけで、色んな製品を見てきています。
どんなクレームがくるのかもよく知っています。
なので、顧客課題に対して最適なソリューションになっているかという観点から仕様に対して意見できるし、テスト容易性の高い仕様って観点でも貢献できる。
運用担当者はいわずもがな。
事業採算にみあった運用ができるようにインフラやシステム設計、運用設計に参加すべきだと思います。
DevOpsって言いたいわけじゃなくて、ROIを最大化するために必要な運用機能や仕組みをアーキテクチャに織り込むために、運用担当者の知見が必要なのです。
繰り返しますが、これってアジャイルだとかDevOpsだとかそんなことじゃなくて、愛着をもって製品を開発するという意味で、どんな開発モデルでも有益だと思うのです。
品証の人が自分の子供に「これってお父さんが作ったんだぜ」って言えるのって、格好良いと思うんですよね。
プログラムを書くだけが開発じゃないと思うのです。
（開発者はプログラムをかけないとダメですが）
こういうのって、これまでの僕のソフトウェア開発人生では当たり前だった気がします。
きっと、WEBアプリの開発なんかのソフトウェア開発に関わられている多くの方にとっても当たり前なんじゃないでしょうか。
しかし、H/Wが主流だったメーカーになると、おなじように分業化が進んでいる企業が多いんじゃないかなぁ。
そんな組織でサービスの開発に関わると、僕と同じことを思うんじゃないかなぁ。
- 楽しい記憶（PLEASURE No.32）
ありがちですがこれは大事ですね。
一緒に仕事をして楽しかったと思えると、作ったものへの愛着も増します。
また一緒に仕事をしたいとか、あの時と同じように楽しくしたいとか、前向きな考えになります。
自分のことをふりかえると、最初の会社、豆蔵時代、チェンジビジョン時代と、とても良い経験をさせていただきました。
もちろん、今の会社でもすごく良い経験をさせて頂いています。
そんな中でも、あの時期は最高に楽しかった！というのが何度かあります。
それは、すべて先輩方と仲間のおかです。
楽しい記憶があれば、またその時みたいな仕事がしたいと思います。
その時の先輩や仲間のように振る舞えるようになりたいと思います。
そのために、自分を高める努力をします。
そのために、仲間を作り、周りを巻き込もうとします。
そして環境を変革します。
そして、楽しかった時間と同じかそれ以上の時間をまた過ごすことができたら最高です。
これはすべて「楽しい記憶」に起因します。
もしこれまでに「楽しい記憶」を経験できていない人は、ある程度で見限って自分がいる環境をドラスティックに変える（つまり転職する）のもありかもしれません。
一緒に仕事をした方々の「楽し記憶」 に残れるよう精進しようなんて思う今日この頃です。
ということで、だらだらと思ったことを書きました。
ちょっとまとまりがないので読みづらいですが、個人の備忘録ということでご勘弁を。
ありがとうございました。
ラナイバ
バイナラ
