今回はストーリーフォーミュラのお話です！
前々回、記事の最後に、ちょこっと書いたこのネタ。
今回改めて、ご紹介してみようと思いました！
ただ、ストーリーフォーミュラは結構有名なので、既に知ってる方もいらっしゃるかもしれません。
もしご存じない方は、簡単で応用が聞きやすいネタなので、是非読んでみて下さい！
まずはざっくり教えて
ざっくり言うと【ストーリーフォーミュラ】は人に何かを伝えたいとき、有効なテンプレです。
伝えたい事を、ストーリーにすると、頭に残りやすく、かつ楽しく自然に覚えられるんですって。
つまり、伝えたい事をストーリー化する事で、イメージしやすくする。
ストーリーから感情に訴えて、気持ちを高ぶらせ、迷いを断ち切り背中を押す。
これがストーリーフォーミュラなんです！
なので、最近では、プレゼン、商談、ブログ、ちょっとした会話、などなど・・色々なシーンで、この手法がよく使われてます。
非エンジニアの方も、エンジニアの方も、人に何かを伝える場面、沢山あると思います。
そんなとき、もしかしたらこのネタ、役に立つかもしれませんよ！
もはや明日から使えるレベルだと思う。
ストーリーのテンプレはこれ
設定すべき、ストーリーの大まかな流れは以下の様になります。
- スタート地点（私は皆様と同じかそれ以下）
- 失敗と試行錯誤
- 突然の出会いや発見（できるだけリアルに）
- 成功体験
- 分析・メソッド化
- 他人の成功（私が特別ではない）
- 次は貴方！
ならない様、気を付けような！
では、大喜利感覚で、ストリーフォーミュラに沿ったストーリーを、試しに書いてみようと思います。
ささっとストーリー書いてみます
ストーリーのテーマとしては、あんまり面白くないですけど、解りやすさを優先する為、この目的をテーマとさせて下さい。
目的： エンジニアブログをお勧めしながら、あわよくば、よっしーTECHを宣伝。
そして、このテーマに「よっしーTECH」のテイストをほんの少しブレンドして書いてみます！
スタート地点
まずスタート地点として、聞く人が自分に置き換えて、見てもらえるようなきっかけを作ります。
「この人もこうだったのか！」みたいに、同じ仲間だと思ってもらう様な書き方が一番いいです。
読んでる人と同じレベルもしくは、それ以下だったんですよ、みたいな事が伝わればOK。
スタート地点（例文）
私が、駆け出しエンジニアの頃、SESのエンジニアとして、この業界に飛び込んだのですが、解らない事だらけでいつも悩んでいました。
案件のミーティングなどに同席すると、訳の解らない資料や、横文字が飛び交ってこんな状況。
そして、お客様はいつも怒っていて大騒ぎをしている。理由もぶっちゃけよく解らない。
こんな悩める日々を、毎日の様に送っていました。
失敗と試行錯誤
続いて「失敗と試行錯誤」を書きます。
「それはアンタだから出来るんだよ」って印象を持たれてしまうと「私にも出来る」って感覚がなくなってしまいます。
例えば、お金を稼ぐ方法を、金持ちの家で育った、人生順調そうな人が語ったとします。
こういう設定だと、「アンタは、恵まれた環境にいるから出来るんだよ」って思っちゃうのが人情というものです。
なので苦労話が必要なんです！
では試しに書いてみます。
失敗と試行錯誤（例文）
現状を解消する為に、本を買ってみたり情報収集をしてみました。
でも、結局ミーティングで、飛び交ってるような言葉が、そのまま書いてあるだけ。
パイセンに聞いてみたら「ググれカス」と言われ・・。
誰かが「出来るよ？」と言われた事を信じてやってみても、間違っていて、いつも想定通りにはなりません。
お客様へ、問題があったとき、頑張って調べて、状況報告をしていましたが、突っ込まれて言い返せない日々。
何が正解かも解らず、カオスすぎる状況が続く日々に、いつも絶望していました。
出会いと発見
次は、どうやってこの状況を乗り越える事が出来たのか？その「きっかけ」です。
ここを、鮮明かつ具体的に、話せるかどうかが、ストーリーフォーミュラの一番重要なポイントです！
出会いと発見（例文）
そんなある日、偶然ネットで、現役エンジニアの書いているブログを沢山見つけました。
そこには、いつも飛び交ってる謎の言葉が、かみ砕いて解りやすい表現で書かれていました。
ブログを読むと、同じ境遇のエンジニアは多く、こんなエンジニア達が、ブログで情報交換をしてたのです。
ブログの内容が、すごく面白かったので、寝る前に暇つぶしに読んで、読んだ内容を、PCで検証して遊ぶ事を覚えました。
すると、いつの間にか、技術的な話を理解できる様になっていたのです！
それだけはなく、会話を聞いただけで、頭の中に具体的な、絵が描けるようになっていたのです！
成功体験
次は「出会いと発見」によって何が起きたかを書きましょう。
いきなり飛躍した様な事を書くと、インチキ臭くなるので、ステップアップした感じが、出せると良いです。
今後どうなっていくかの予想も、できれば書けるといいですね！
成功体験（例文）
ブログから色々、具体的な情報をゲットして、理解したとき、そこで見えて来た事が沢山ありました。
いままで飛び交っていた、謎のIT用語。
実際に検証してみると「たったこれだけの話？」みたいな内容でした。
つまり解ったことは「こんな簡単な話しを、長々解りずらい遠回しな表現で、誰もが語っていた」という事。
そして、パイセンと上司を、質問責めにしたら、抽象的にしか、理解していなかった事も解りました。
ふわふわした状態で、なんとなく理解をしていただけ。
つまり、解るフリをしていただけだったんです。
お客様目線で、この状況を考えたら、そりゃ毎日大騒ぎするよなって・・事も、ようやく納得しました。
そう、ブログで情報を得る事により、自分の悩んでいた問題の全貌を、次から次へと、解明できる様になったのです！
これはすごい進化だ！
分析・メソッド化
次は、どうして成功したのか？などの理由や、具体的な方法論を書いていきましょう。
そして、読んでる人が「自分にも同じ事が実現可能」と思ってもらえる様、意識して書きましょう。
分析・メソッド化（例文）
IT用語や業界の話、技術的な話が理解できなかったのは、自分の理解度や、論理的な能力の低さが、原因だと思っていました。
でもそれは違いました。
内容がちゃんと整理されていて、表現が適切であれば、誰もが簡単に理解できるんです。
解りやすく書かれてる説明を読めば、エンジニアだけではなく、非エンジニアにも、理解できる事が沢山あります。
しかしながら、この問題により、不安や歪みを抱えてる方は、まだまだ多いようです。
こんな悩みを、駆け出しエンジニアの方や、非エンジニアの皆様が、少しでも解消できる様に、始めたのがこのブログ・・
「よっしーTECH」なんです！
余談ですが、うちのブログは、気軽に斜め読みが出来るよう「ネットゲーム」に利用されてる、ブログの手法も参考にしています！
他人の成功
これも「アンタだからできたんだよ」と思われない為の理由付けです。
伝えるべきは「みんなが成功出来るんだよ！」という事。
例えばこれが、企業が提供する、サービスの話だったら「他社での成功事例」みたいな感じですね。
これには、数値化された成果や、エピソードなどがよく使われます。
ただ「よっしーTECH」で成功しました！なんて人、ぶっちゃけいませんから、例文の切り口を少し変えます。
他人の成功（例文）
私のブログを読んだことで「今まで、理解できなかった事が理解できました」なんて、嬉しいコメントを頂いた事があります。
また、私の表現方法は「ブログ」という趣味の範囲だけではなく、本職でもずっと使ってきた、ノウハウです。
難しそうなシステム、プロジェクトの話でも、かみ砕いた表現方法で、多くの人に理解をしてもらっている実績があります。
そして、私の炎上経験を活かし、プロジェクトのリスク回避にも役立てています！
次は貴方！
最後に背中を押して、誰でも成功します！あなたも成功しましょう！という事を伝えましょう。
怪しい感じにならない様、細心の注意を払い、以下を伝えるのがコツです。
- 何故これを提供するのか？
- 何故次は貴方がやるのか？
今回の目的は、ブログの面白さを伝え、あわよくば「よっしーTECH」のファンになってもらう事です。
これを踏まえて例文を書いてみます。
次は貴方！（例文）
皆様も日々、技術的な提案、トラブル、エンジニアとの人間関係、コミュニケーション、などなど、様々な課題に直面してませんでしょうか？
「よっしーTECH」は技術的な話だけを、紹介しているブログではありません。
私が経験で学んだ、この業界で生きていくための処世術や、明日から使えるノウハウなども、紹介しています。
もしかしたら、私の経験した内容の記事が、あなたの悩みを解決するヒントになるかもしれません！
週1くらいのペースで更新していますので、暇な時間に斜め読みしてみませんか？
TwitterかFacebookで、フォローしていただくと、新しい記事が投稿された事が解るので、お勧めです！
私の記事をもっと解りやすくして、今度は皆様が情報を発信したら、面白いかもしれませんね＾＾
以上 例文でした
ストリーフォーミュラに沿って、例文を書いてみましたが、いかがでしたでしょうか？
例文は青字にしとくんで、時間があったら繋げて読んでみてください！
ここまで書いといてなんですけど、この手法は、色々と参考にしてますが、ここまでキッチリはめこむやり方は、普段あんまりやらないです🤣
なので、伝わってなかったら、ごめんなさいね！
最後に
こういうテンプレって「フレームワーク」とか言われてるんですってね。
最近は、こういう「型」が色々なところで、推奨されてると聞きます。
でも、私この「型」について、前から思うところがあるんです。
型を覚える事自体は、いいと思います。
でも、何も考えず、無理やり型に押しこもうとしたり、妄信したりするのは、とても危険に思えるんです。
フレームワークって「型」なので、相手をここに誘導するやり方が、進め方の基本になります。
この誘導が原因で、無理やり相手をここに押し込み、おかしな話を、無理やり進める様な「型」になってませんか？
また、型にハマりすぎて、交渉相手に手の内を読まれて、いとも簡単に切り返されたりしてませんか？
例えば、交渉や折衝が発生する場面では、協議を重ねるシーンが予想されます。
こんなやり取りをしてるとき、いつも思うのは、感覚がカードゲームに近いという事。
このカードゲームの手札になるのは、人や知識、感情であったりしますが、フレームワークも、その1つになると思います。
なので、フレームワークをちゃんと理解して、正しく使わなければ、有効な手段として使えません。
更に、フレームワークが通用しなかった時の奥の手を、用意しておくことも大事だと思います。
手強い人が、大体交渉の場面ではよく出てきますので
型に頼りすぎて、思考を停止させてはいけません。
関連書籍（今回のテーマに近い書籍）
