最後まで聴きたかった!
Takuto Inoueさん、コメントをありがとうございます!
ご評価を頂きとてもうれしいです。
「どうしても自分がやりたいことを企画書に書く、という発想になりがちだったのですが、最終的にその企画書を通すのは決裁者であり、彼女ら/彼らが何を望んでいるのか、そちらに考えを置いてロジックを考えるというのは、なるほどなと思いました。」
は、その通りなのです。結局、社長をはじめとする誰もが自分アやりたいことのために一日の大半の時間を割いて、場合によっては人生をかけているので、相手があり気で、それが自分にもプラスになるというくらいの考え方での企画立案がちょうどよいと思っています。
企画はシンプルですがシンプルが故に奥が深いです。
お互いに頑張りましょう!!!
sugoiyo72さん、コメントをありがとうございます!
また過分なお言葉を頂き、ありがとうございました。
とても励みになります。コメントを読んでいる私の心も熱くなりました。
来年もPHPカンファレンスでプレゼンできるよう頑張ります。
さて、今回の私のプレゼンの肝である
1) 上長や経営者の方針を理由付けの柱とする
2) プレゼンテーション内容をプレゼン対象者と共につくる
をご理解いただき、とても嬉しいです。
結局、企画は世のため人のため、そしてそれがひいては自分のためになると思います。
お互い頑張りましょう!
昨日はPHPカンファレンス2014にてセッションお疲れ様でした。
参加の動機は、企画書を作成する機会が増える見込みの中、そもそもどのように書くべきなのか指針が欲しかったからでした。
セッションの中では、企画書によってどのように相手を説得するのか、短い時間でしたがエッセンスを教えて頂きとても参考になりました。
どうしても自分がやりたいことを企画書に書く、という発想になりがちだったのですが、最終的にその企画書を通すのは決裁者であり、彼女ら/彼らが何を望んでいるのか、そちらに考えを置いてロジックを考えるというのは、なるほどなと思いました。
実際に講演者の方自体が企画書の力で法人・団体を立ち上げているため、話が具体的で最後まで引き込まれました。
今回のセッションで共有されたノウハウを実践し、通る企画書を作成していきたいと思います。
ありがとうございました!
セッションお疲れさまでした。そしてありがとうございました。
PHPの時流やHHVMが気になって初参加したPHPカンファレンス2014でしたが、昨年にVCさんなどで、事業計画をピッチしていた自分は、「企画書」という文字に惹かれて入室しました。
少し遅れて入室したのですが、運良く最後の席をゲットしました。
いろいろと学びや経験の再確認があったのですが、特に以下の2点に改めて留意しようと思いました。
1) 上長や経営者の方針を理由付けの柱とする
(・・・これはVCさん向けにも意識する点だなぁ。。)
2) プレゼンテーション内容をプレゼン対象者と共につくる
(・・・確かにキャピタリストさんからアドバイスいただくこともあったしなぁ。。)
自身が上長の立場だった時に、部下が自分がやろうとしていることを支援するような提案を持って来ると、我が意を得たりと嬉しくなったりしたものでした。
「理由付け」から「主張」への論理が滑らかであれば、その企画が通りやすいだろうことは想像できます。
これは、社内の話で、一見、私が対象としたいVCさんなどでは適用されないようにも思えます。
けれど、特にシード期などに投資されるVCさんにはそれぞれの投資哲学があり、その方向とマッチしないものをプレゼンしてもあまり意味が無いようです。
例えて言うなら、上長や経営者が考える方向を無視した提案をプレゼンするようなことでしょうか。
昨年の活動において、このVCさんそれぞれの方向性をきちんとリサーチできていなかった点は大きなミスだったことをはっきり自覚する良い機会となりました。
というのが、(1)の話で、(2)のほうはというと、
「100%のものを持って行かずに、相手の提案を取り込んで完成させることで、断りづらい企画書に仕上げる」といったものになります。
昨年は生まれて初めてVCさんにコンタクトしたのですが、一発で決めないといけないという勝手な思い込みがありました。
実際には、提案を頂いたり、書籍を勧めて頂いたりしたこともあり、継続的に足を運んで事業計画をブラッシュアップするといったことにチャレンジしてみても良かったのではなかろうかと思いました。
その他、いろいろとインスパイアされて書ききれませんが、何よりも熱く勢いのあるセッションで楽しかったです。
実際に出資を受けた事例なども紹介頂き、また、えっ?と思うような意外なエピソードなど、表層的なものでなく、生の情報を得られたのが大きな収穫でした。
こうした情報はやはりネットでなく、足で稼ぐものだと改めて意識できました。
ありがとうございました。
ストーブを囲んで聞きたい話でした。
ORMを気軽な気持ちで使いすぎると危険だということも
身を持って体感しています。
今回はLTだったので、解決策が抽象的な気もしました。
大体ORMやフレームワークにはSQLを出力する機能が
あったりするので、その機能があるよということを
紹介してもよかったのかもしれません。
個人的に、コードを変更するとSQLがどう変わったのか(増えたのか、減ったのか)
的な情報が最近欲しいと思っとります。
健康はだいじ!
Nice talk too bad there was more time.