アウトラインプロセッサ、あるいはアイデアプロセッサ。
そういわれて、ああ、あれか。と思う人は問題ないけど、なにそれ？と思った方は読んでおくといいかも。

基本、アウトラインプロセッサはもともとストーリーテラーの思考を整理し、体系化するためのものでもあったのだけど、ロジカルシンキングにおいては非常に強力な武器になる。
使ったことの無い人はまあ使ってみるのもいいと思うよ。

沙耶です。

物語、とはロジカルシンキングの基礎でもある。
何かお話を書こうと思ったとき、導入部から書いたら間違いなく行き詰る。行き詰らないのは頭がおかしいか話が破綻しているかのどっちかだ。

お話は、始まって、終わる。書くときはほぼこの逆順でまず思考しなければならない。
つまり、最後にどうなるのか。が決まっていて、そこへの道筋を作っていく、というのがお話を作るときの基本作業だと思う。

たとえば、最後のシーンで主人公を殺そう。と決める。どうやって殺す？
雪の降る公園で寝て凍死？　浮気した女に刺される？　頭上から落ちてきた鉄骨の下敷きになって志半ばで死ぬ？　それとも突然の自動車事故？　自殺？　自殺なら何で？　首吊り？それとも拳銃自殺？
まずそんなとこから決める。

女に刺されようか。じゃあその女ってのはどんな女だったら刺すだろう。どんなことをすれば刺してもらえる？　刺される場所はどこがいいだろうか。どんなシチュエーションで刺されたい？
こんな感じでどんどんつなげていく。これに伴って、主人公ってどんなやつだ？　女はどんな人間だろう？ってのが整合性をもって現れ始める。

でもまあ、終わりだけ決まっててもしょうがない。女に刺されるようなチャラ男なわけだ。物語の始まりからチャラ男だったら別にチャラ男の一生。で終わってしまうので面白くもなんとも無い。

終わりがある程度見えたら始まりを作る。
女に刺されそうもない人がいい。善良で、優等生で、心優しくて、ちょっと不細工な男子がいい。そんな人普通は女に刺されたりしない。

この二つをどうつなげるか、を構成していくのが過程だね。

じゃビジネスでこれをどう使うか？
顧客からリクエストをもらった。なんか頭の悪そうなプロジェクト概要が営業から提示される。

こんなんじゃすぐ破綻する。とわかっているなら、覆そう。それが、プレゼンテーションというものだ。ここはMySQLじゃ駄目だ、PostgreSQLのほうが適切だ。とか、Oracleのほうがいい。とかDBをMessageQueueに使ってんじゃねぇ、MQならMQ使え。とか。

思うことはいっぱいあるけど表現できないから黙る。エンジニアにはそんな人も多い。というかそれはエンジニアと呼びたくは無いんだけど、僕的には。

そう思うなら提案書にしてしまえばいい。結論（終わり）は決まってる。終わりが決まってない調査研究の類でないなら、「自分はこうしたい」が終わりなのだ。
それ以外には無い。推して参る。無理を通す。そういうことなのだ。それをぶつけるのが会議というもので、人の話をふんふんなるほど。って聞いて言われたとおりにできるかできないか考えるのがエンジニアのお仕事とは言わない。

ある意味、それはSEの仕事だろ。って思うかもしんない。PGならなおさらだろうね。でもこれがちゃんとできるSEなんてほとんど居ない。基本PGあがりでふんふんなるほど。って言って終わる。お前何しに会議に出てんだ。と突っ込みたくなる。僕はインフラ屋なので、自分のやりたいこと、できること、できないこと、がある程度はっきりしている。というかできないこと、ってのはそう無いけど、あまり知らないミドルウェアとかあんま使いたくないわけ。
できるだけ自分の得意な土俵に引きずり込んでおきたい。もちろん、その得意な土俵の数が多ければ多いほどエンジニアとして上質、ではあるのだけど、世間に存在するすべてを網羅するなんて土台無理な話だ。

ならば、引きずり込まなければならない。

使ったこともないIBM DB2でやってくれなんていわれたって、チューニングも知らなけりゃノウハウだってない。ならばどうする。得意分野に引きずり込むしかないじゃないか。できなかったらしょうがないからDB2得意な外注探すけどね！ｗｗｗｗｗｗ
※DB2案件がその後も継続して発生するなら自分でやるけどさ。

終わり、がたとえばPostgreSQLのほうがよいです。にしたいなら、もうそのための組み立てをどうするか。なんだ。なぜいいのか。どこが優れているか？　どこが劣っているのか？　それはどうカバーする？　そういったものを組み立て、はじめと過程を組んでいく。
これはアシモフ先生のお得意だったやり方だ。もっとも、やつは結論は常に決まっているから、話をおっぱじめながら結論への組み立てをリアルタイムでやらかす基地外だが。なんで経済学の講義が生物学に摩り替わるのか。

そういう組み立てをしたら、あとはそれを提案にまとめるだけだ。

このように、ロジックで考える場合というのは、実際のプレゼンテーションの資料の順序どおりではないことも多い。そもそも結論ありき、での誘導資料だからだ。別にほかにベストな解はあるかもしれない。だけど、”自分にできる”という前提条件の上でのベスト解がほかにないなら、そのベスト解を提示すべきだ。だってそうだろ、なんかアプリ作って、そのメンテナンスもやらなきゃならない、ってなってる状態で使ったことがあるのはＰＨＰだけです。なんて人にアプリケーション書かせるとしたらＣＯＢＯＬは選ばないだろう？　ところが環境的にはＣＯＢＯＬ前提での環境でした。なんて状況で、はいはいわかりました。なんて言ったらデスマーチ一直線だろう。
ここまで極端ならば、営業レベルでも断れるけど、そうじゃなくて細かな部分とかでは営業にとっちゃどうでもいいレベルでどっちでもいいよ的な話は結構ある。
けど、そのどっちでもいいよ、の片方がまるで触ったことも無いものならば、避けたいのがエンジニアの心情だろう。チャレンジ精神？　そんなもん業務アプリケーション相手に発揮しなくていいよ。自己学習しろ自己学習。

ＰＧやＳＥやってるのに家にはＰＣ一台ございません、ってのは自己学習どうしてるの？とか思うことも多い。誰とは言わないがとくにＷｅｂアプリ屋でＰＨＰしか使えませんとかほざいてる連中だｗｗ
まーね。プライベートはプライベートだ！　業務に必要ならばＯＪＴなり教育なりをするべきだ！ってのはわかる。だが同時に、この世界って自分の知的好奇心がないと続かない分野でもある。ぜんっぜん関係ないのにとりあえずＦＯＲＴＲＡＮ走らせて見るｗｗｗｗｗとか、Whitespaceで何か書いて見よう！とか思い立つ人間でなくては、先が見えてこない側面があるのも事実で、そういう連中にしてみれば、それこそ、どうして俺がプライベートで身につけてきた武器をタダでお前に教えなきゃならんのだバカかお前。としか思わないわけだ。

教えて欲しい、と思うならそのための振舞い方ってのはあると思うんだよね。特に先人は先人でたいていの場合自腹でいろいろ身につけているからだ。特にエキスパート、なんて思われる人はね。

さて、話がそれた。要するに、クライアントを意のままに操るテクニック、というモノはエンジニアにも必要な技術だって事だ。
必要なら心理学やマジシャンズチョイスだって用いる。ぼくは理系だから手品なんて。って思ってるんじゃ駄目だぜ。
まあクライアントに見破られたらドしかられるので常用はしてはならないがｗ

しかられるで済めばいいけどｗｗｗｗｗｗ