- | 次の10件
Xcodeの愚痴 [iOSアプリ開発]
このところiOSアプリ開発に取り組んでいるのですが、苦戦中です。CoreDataフレームワークの扱いの大変さに加えて意外にメモリ管理に苦戦しています。C++でポインター使ってライブラリを組んだりもするので、これでもスクリプト主体のライトプログラマーに比べればメモリ管理に気を使う方なんですが、参照カウンターの扱いがライブラリ関数でも自動だったり手動だったりマチマチなのでその扱いに苦しんでいます。リファレンスのどっかに書いてあるのかなぁ？とか思うのですが見当たりません。その上、autoreleaseですらC++::Boostのスマートポインターより扱いがシビアで、さらにデバッカも不親切なので、メモリの過解放はメモリリークよりデバッグが厄介です。いっそのこと、メモリ解放なんてまったく気にしないで後から解析ツールのお世話になった方がよっぽど楽かもしれません。
それから、デバッカが不親切な件についてですが、ポインタ型の値（つまりオブジェクト全て）の中身を表示してくれないので、とくに文字列型のNSStringを扱っている時に面倒です。ちょっと前まではNSLogを書き足しては再ビルドの繰返しでした。昨日ようやくコンテキストメニューからポインター先の値をコンソール出力できることを見つけて、無駄なLog出力や再ビルドは減りましたが、今度はiOS SDK 4.3にするためにXcodeを４にアップグレードしたらデバッカがどこにあるかすらわからなくなりました。コンソールは出てくるのでそれで作業を進めていますが、他にも言語が日本語に変えられなかったり、プロジェクト設定がメニューから消えて、探すのに苦労したり、MS-Office2007の悪夢再びって感じです。機能が豊富になってくるとインターフェースの刷新をしないと収拾がつかなくなるのは自分もGUIデザインをやってますからよく分かるのですが、それにしても限度と言うものがあります。Xcode4ではもちろん便利になった点もあるので大分相殺されているのですが、旧来ユーザにはちょっと微妙です。
しかしそれにしても、ジリ貧状態に加え、開発が既に１週間遅れてて、その上バグで先が見えないと、ほんと、気分的には最低最悪です。ですが何とか前に進めています。新しいことがうまく行った時の快感はあるんですが、それでもせめて仲間が欲しいところ。とはいえコミュニティに出没する余裕もないんですよねぇ。ふぅ。
がんばれ〜、おれ〜
それから、デバッカが不親切な件についてですが、ポインタ型の値（つまりオブジェクト全て）の中身を表示してくれないので、とくに文字列型のNSStringを扱っている時に面倒です。ちょっと前まではNSLogを書き足しては再ビルドの繰返しでした。昨日ようやくコンテキストメニューからポインター先の値をコンソール出力できることを見つけて、無駄なLog出力や再ビルドは減りましたが、今度はiOS SDK 4.3にするためにXcodeを４にアップグレードしたらデバッカがどこにあるかすらわからなくなりました。コンソールは出てくるのでそれで作業を進めていますが、他にも言語が日本語に変えられなかったり、プロジェクト設定がメニューから消えて、探すのに苦労したり、MS-Office2007の悪夢再びって感じです。機能が豊富になってくるとインターフェースの刷新をしないと収拾がつかなくなるのは自分もGUIデザインをやってますからよく分かるのですが、それにしても限度と言うものがあります。Xcode4ではもちろん便利になった点もあるので大分相殺されているのですが、旧来ユーザにはちょっと微妙です。
しかしそれにしても、ジリ貧状態に加え、開発が既に１週間遅れてて、その上バグで先が見えないと、ほんと、気分的には最低最悪です。ですが何とか前に進めています。新しいことがうまく行った時の快感はあるんですが、それでもせめて仲間が欲しいところ。とはいえコミュニティに出没する余裕もないんですよねぇ。ふぅ。
がんばれ〜、おれ〜
ひと区切り [雑記]
このところ、資金が底をつきかけ、ケツに火が着きかかって全く余裕のない日々を送っています。
何とかリリースにこぎ着けようと奮闘している自社製品もまだ先が見えません。
そんななか、一段落したこともあります。
一つが奨学金返却の完済です。もう大学を卒業してどれぐらい経つのか自分でも忘れてるんですが、時間が経つのは速いですね。とにかく借金が一つ減りました。
もう一つがReTeMoのアニメーションシステムの特許査定が降りたことです。2005年10月に出願してから５年半以上経過しました。審査請求してからは２年７ヶ月、去年の暮れに拒絶理由通知が来て、年明けに特許事務所に頼み込んで意見書と手続補正書を駆け込みで間に合わせてからは４ヶ月かかりましたがとにかく一区切りです。「特許出願済」と「特許査定済」あるいは「特許登録済」ではまったく世間体が違います。私自身はあまり世間体を気にしない質なんですが、それでも話の勢いは変わりますからねぇ。で、当面の課題は特許事務所の成功報酬をどう捻出するかですね。（笑）
後はプロトタイプでどうしても試しておきたいことをやっつけたいのですが、まあ、こちらの時間も捻出しないといけません。それが終わったら本格的に売り込み開始です。さぁやるぞ〜。
後もう一個、何かあったはずですが、いざブログを書き始めると思い出せません。何やら気持ち悪いのですが、とにかく開発に戻ります。
そうそう、それとは関係ないけど弊社のwebサイトを現在改装中です。5/19の未踏交流会で話しきれなかったこととかも、掲載する予定です。
何とかリリースにこぎ着けようと奮闘している自社製品もまだ先が見えません。
そんななか、一段落したこともあります。
一つが奨学金返却の完済です。もう大学を卒業してどれぐらい経つのか自分でも忘れてるんですが、時間が経つのは速いですね。とにかく借金が一つ減りました。
もう一つがReTeMoのアニメーションシステムの特許査定が降りたことです。2005年10月に出願してから５年半以上経過しました。審査請求してからは２年７ヶ月、去年の暮れに拒絶理由通知が来て、年明けに特許事務所に頼み込んで意見書と手続補正書を駆け込みで間に合わせてからは４ヶ月かかりましたがとにかく一区切りです。「特許出願済」と「特許査定済」あるいは「特許登録済」ではまったく世間体が違います。私自身はあまり世間体を気にしない質なんですが、それでも話の勢いは変わりますからねぇ。で、当面の課題は特許事務所の成功報酬をどう捻出するかですね。（笑）
後はプロトタイプでどうしても試しておきたいことをやっつけたいのですが、まあ、こちらの時間も捻出しないといけません。それが終わったら本格的に売り込み開始です。さぁやるぞ〜。
後もう一個、何かあったはずですが、いざブログを書き始めると思い出せません。何やら気持ち悪いのですが、とにかく開発に戻ります。
そうそう、それとは関係ないけど弊社のwebサイトを現在改装中です。5/19の未踏交流会で話しきれなかったこととかも、掲載する予定です。
ソフト開発とビジネス その論理思考のちがい [ソフト開発者の視点]
さて、気付けばだいぶ間があいてしまいました。
このブロブの記事はEverNote上で書いているのですが今回の記事を作成したのが4/2になっているので２ヶ月も熟成させたことになります。なにぶん背伸びをしながら書いているので自分でも腑に落ちるまで時間がかかるんですよね。では、お待たせしました。（待ってた人がいるかはわかりませんが）
--------
「わかりやすく説明してください。」
ビジネスシーンで時折耳にする言葉です。特に事前配布した資料が難解だと、まず間違いなく誰かにいわれるでしょう。話が細切れだと「論理的にわかりやすく」という条件がさらに加わるのですが、今回のネタはその「ビジネスの文脈で、わかりやすく説明するための論理」と、「ソフトウェア開発で使う論理」の違いについてです。
私もソフトウェア開発で論理思考に慣れてますし、「理屈っぽい」と揶揄される人間なので（笑）「論理的」というのをわかった気でいたんですが、コンサル系や知財系の人からは「開発者（プログラマー）なら分かるかもしれないけど....」と、作った資料にNGを食らうことも多いし、....どうも非プログラマーの言う「論理的」ってやつを良くわかっていない様です。
でもねぇ、ソフト開発と他分野の「論理思考」の違いを上手く説明してくれているドキュメントって見た事無いんですよね。仕方ないんで自分の脳みそを使ってみましょうか。まずはソフトウェア技術者に取っては一番、違和感を覚える「フレームワーク」から行きましょう。
フレームワークという異物
「経営」とか「マーケティング」といった、いわゆるビジネスの世界の「論理思考（＝ロジカル・シンキング）」についての書籍で、昨今は「フレームワーク」という言葉が踊ってます。この「フレームワーク」がクセモノです。非IT系ビジネスパーソンは「思考の枠組み」という意味でこのフレームワークという言葉を使いますが、ソフトウェア技術者はこの言葉を別の意味で使います。それにビジネスの文脈での「フレームワーク」というのはソフトウェア技術者から見ると「パターン化された分析手法」に見えるんですよね。正直言って「分析パターン」と呼んでほしいところです。（ビジネスパーソンも個々のフレームワークを「SWOT分析」とか「４P分析」とかいう言い方もしますが、それでも全体ではフレームワークと言い切ってます。）さらに困った事に、この分析パターンを用いる事を「論理思考」と言い切っているフシもあります。これがソフトウェア技術者としては不思議なんです。
ソフトウェア開発者にとってフレームワークというのは、それに細かいソフトウェア部品を組込めばソフトウェアを完成させることができるものです。そうした意味ではビジネスの文脈でのフレームワークとは「思考のピースをはめ込んで思考を完成させるもの」ということになります。ロジック（論理）は「思考フレームワーク」のなかに折り込み済みって訳ですかね？こう考えるとビジネスパーソンの思考パターンがおぼろげに見えてきます。でもやっぱり、やってることは「分析パターン」を使って考えたり、説明したりですので、そもそも分析パターンと呼ばない理由がわかりません。
ここで私なりに「分析パターンとは何か」を説明すると、対象を観察・分析する際によく使われる分類・分析手法のことです。ビジネスパーソンのフレームワークは論理より「高度なモノの見方」が重要な部分占めています。これって「分析パターン」です。しかもそこで働く力は論理と言うより自然の理（ことわり）と言った方が腑に落ちるものです。この感覚はおそらくソフトウェア技術者だけでなくエンジニアや科学者全般に共通するものではないでしょうか？百歩譲って「論理思考をするための「材料の切出し」も論理思考の一部」って発想は理解できるとしても、そもそもソフト業界では同様のことをやっている「ドメイン（領域）分析」や「オブジェクト指向思考」をわざわざ論理思考とは言わないですよねぇ。そんなことしたらソフトウェア工学全体が論理思考になっちゃうから。........「論理」が工学の中心であるソフトウェア工学の方が特殊なのかもしれませんが..........これもギャップを生む原因でしょう。それから彼らは「思考の枠組み」を単なる分析に使うのではなく、自分の主張を通すための道具として使います。現実を知るために枠組みを使うのではなく、ブッチャケた話、我を通すための理論武装に利用するのですから分析パターンという受動的な呼称を使わないのは、まあ、納得ですね。
このように用語の使い方からだいぶ違うのですが、扱う対象もちがうので、IT技術者が彼らの「フレームワーク（＝分析パターン）」を使うのには、かなりの慣れが必要です。ソフト開発って「現場レベル」っていうか、具体的な仕事について扱うことがメインですが、ビジネスの世界って売込みとか提案とか、商売や経営に絡む内容がメインなんですよね。（勿論、技術系プレゼンもたくさん行われていますが、マイナーというか、視野外というか....）
で、彼らの「3C」とか「4P」とかのフレームワークを実際に使ってみるとやっぱり違和感を覚えます。はっきり言えばリアリティを感じないんです。これも多分、ソフト開発者が見ている部分と経済専門家が見ている部分が違うからでしょう。一人一人のユーザーや、個々の操作状況を思い浮かべる比重が高いソフトウェア技術者に対して、経済の専門家は「どれぐらいのユーザーが喜ぶか？」といった大きな反応に意識が集中します。売上とか利益とかを気にする立場だからリアルに感じるものが違うんでしょうね。（それとも私が彼らより馬鹿なだけ？）
論理思考と抽象思考
話はそれますが、じつは同じIT系でもインテグレータ（統括者）系のコンサルタントでは似たようなギャップが見受けられます。彼らは情報工学の高度な教育を受けていますので一流のソフトウェア開発者ということになるのですが、じつは現場での開発経験に乏しいので総じて概念的な思考に走りがちです。プログラマー出身の開発者は驚くでしょうが、彼らは所謂「手続き型」の思考が得意ではありません。ロースペックなプログラマーだと手続き型の思考しかできないのと対照的です。
「手続き型」の思考で一般にも馴染みがあるのは業務マニュアルの作成でしょう。つまり、仕事の手順を作業内容（＝手続き）ごとに分割して考える、その思考活動をソフトウェア業界では「手続き型」の発想とか思考と呼びます。これは初歩的なものなら人間なら誰でもできます。プログラマーがやっている「手続き型思考」はこれをそのままプログラムに落とし込むだけです。ただし手順や事実関係が入り組んでくると熟練したソフトウェア技術者でも理解が難しくなります。現場のユーザーは日々細かい判断を求められますから、手続き型の論理思考に結構ついて来れるのですが、日頃、概念的な事しか扱い慣れていないインテグレータ系コンサルは複雑な手続き型論理思考について来れない様です。彼らはそうしたケースにぶつかると「もっと、わかりやすい切り口があるはずだ」と考えてしまうのです。大抵の場合、その判断は正しかったりしますが、それが彼らの論理思考力の高さを証明する事にはなりません。どちらかというと「抽象的な思考力」の高さの証明と言えるでしょう。彼らが「プログラマーなら分かるかもしれないけど我々にはわかりにくい」とクレームを付けてきたら、そうした抽象的な切り口での整理を望んでいるサインでしょうね。
これとは逆にプログラマーや現場の開発者は具体的な設計とか実装レベルで考えるのに慣れているので、「何でそんな概念的な話をするのか！」と抽象思考に付合ってくれないこともあります。彼らにとって概念的なものは思考を刺激しないのです。それどころか拒絶反応さえ起こすこともあります。IT業界と言うのは何とも業の深い世界です。そしておそらく、こうした状況を見ているから私にはビジネスパーソンが言う「論理思考」が「抽象思考」にしか思えないのでしょう。
強過ぎる武器は封印すべし
さて、ビジネスの論理思考に話を戻しましょう。
先ほどビジネスパーソンのフレームワークは「論理より「高度なモノの見方」が重要な部分占める」という話が出ましたが、これは言換えると「論理は極力シンプルに抑える」ということでもあります。まずはその話からしましょうか。色々調べたんですが実際、ビジネスで使われる論理というのはそれほど多くありません。
1.「AだからBである」と理由をはっきり述べること
2.三段論法とも呼ばれる理由の組み合わせから結論を導く演繹法
3.反対事例を述べて逆説を否定する帰納法
4.論理を組み合わせる時は「真か偽か」の2値論理が基本だが、曖昧さや重複を避けること（つまり集合論）の方が重要であること
5.文章間の接続詞を的確に使って、話の流れを明確にすること
これぐらいしかありません。（これでも多いと感じる人も多いでしょうが、笑）間違っても四段論法とか五段論法とか使っちゃいけません。「かつ」とか「または」を使って複雑にし過ぎてもいけません。場合分けも1、2回が基本です。ましてや論理パズルを仕込むなんて論外です。
例えばSE上がりの起業家がビジネスプレゼンをするとしましょう。その時に「事業内容」や「製品の原理」について馬鹿正直に「論理的に、」秩序立ててプレゼンしてもまず話が通じないでしょう。元々ソフトウェア技術者が扱っているのはコンピュータに処理させるための非常に高度な論理体系です。ちょっとぐらい簡略化しても一般人の手には負えません。それに、ITコンサルタントと違い、投資家などの非IT系ビジネスパーソンは専門知識がありませんし、抽象的な思考を共有するための土台がありませんから、彼らに高度に抽象化された概念を理解してもらうのは不可能です。学生が相手でも然り。ソフトウェア技術者の最強の武器は、プレゼンでは強力すぎて相手を沈黙させる効果しか持たないんです。
逆に、目の着けどころさえ間違えなければ、プレゼンで要求される論理思考なんてソフトウェア技術者にとっては朝飯前のはずです。でも、「目の着けどころ」が以外に難しいんですよね。もともと超難解なものを超簡単にしたら突っ込みどころ満載になるのは目に見えています。それでもやれって言うのは、私らに言わせれば「だましてください」って言ってるのと同じです。でもまあ、お望みならダマして差し上げましょう。こう言うと聞こえが悪いのですが、要はソフトウエア技術者にとって「真実」と等価な「論理の積上げ」を全部端折ります。（これを端折ることは技術者にとってダマしていることとほぼ同義です）その代わりに述べるのは「問題」と「解決策」と「効果」の３つについてです。解決策や効果には理由の説明が必要ですが、先ほど述べた様に演繹法か帰納法をいくつか並べる程度に抑えましょう。そして、あまり抽象的な概念を使ってはいけません。どうしても話が抽象的になるなら具体例を挙げましょう。
え？何か違う？いやいや、そもそもソフトウェア開発とビジネスは全く粒度が違うんです。フラクタル図形の２、３階層ちがうところを見ているようなもんです。この説明もわかり難いのかな？ともかく気持ちと視点を切換える必要があります。
以上、強引にまとめると「論理的に」という言葉に惑わされるな！ってことです。
蛇足
こんなところにも論理思考
そういえば論理思考の使い方の一つにプレゼンテーションの「ストーリー」として使うというのがあります。日本ではプレゼンテーションのストーリーにも物語のストーリーと同様に「起承転結」を適用することが多いようですが、マッキンゼーとか米国の経営コンサル系では「論理思考」がプレゼンのストーリーなんです。なんか、いかにも知能レベルの高い人たちが考えそうなことですね。.......でもねぇ、今更ですが、わかりやすくする工夫が「論理思考」と言うと矛盾しているような.....確かに工夫というのは、工夫する側にとっては難しいものですが........というか論理思考は難しいだろ！（怒）
これで本当にわかりやすくなるのか
ビジネスにおける論理は「視点」が大事だと何度も述べてきました。それを使えばプレゼンがわかりやすくなるかと言えば、目が覚めるような明確な視点を打ち出せたなら、もちろんわかりやすくなるでしょう。ですが論理そのものはそれが苦手な人にとって難解な物だし、論理思考が得意な人でも今まで考えたことも無かった観点から物事を考えるのはやはり難しいものです。それでも自分の頭の整理ができるなら論理思考すべきだし、プレゼンでは伝える情報を整理するために論理を使うし、相手に論理構造そのものを伝えるためにも論理が必要です。プレゼンテーションのストーリーを論理構造にするのが常にベストとは限りませんが、元々難しいものを少しでもわかりやすく整理するために論理を使うことはできます。
ただし多少わかりやすくなったとして、それで伝わりやすくなるかどうかはまた別問題です。論理は聞き手も頭を使う必要があるので、上手く伝わらないケースも出てきます。そう、プレゼン等のコミュニケーションでは「わかりやすく」という意識設定は副次的なもので、本当は「伝わりやすく」というのが一次命題のはずです。ですが、この話は今回のテーマから外れるので別の機会にしましょう。
さて、そろそろ終りです。
私自身まだ戦い始めたばかりですから、上記の内容がどれほど役に立つかはわかりません。ご意見をお待ちしております。
このブロブの記事はEverNote上で書いているのですが今回の記事を作成したのが4/2になっているので２ヶ月も熟成させたことになります。なにぶん背伸びをしながら書いているので自分でも腑に落ちるまで時間がかかるんですよね。では、お待たせしました。（待ってた人がいるかはわかりませんが）
--------
「わかりやすく説明してください。」
ビジネスシーンで時折耳にする言葉です。特に事前配布した資料が難解だと、まず間違いなく誰かにいわれるでしょう。話が細切れだと「論理的にわかりやすく」という条件がさらに加わるのですが、今回のネタはその「ビジネスの文脈で、わかりやすく説明するための論理」と、「ソフトウェア開発で使う論理」の違いについてです。
私もソフトウェア開発で論理思考に慣れてますし、「理屈っぽい」と揶揄される人間なので（笑）「論理的」というのをわかった気でいたんですが、コンサル系や知財系の人からは「開発者（プログラマー）なら分かるかもしれないけど....」と、作った資料にNGを食らうことも多いし、....どうも非プログラマーの言う「論理的」ってやつを良くわかっていない様です。
でもねぇ、ソフト開発と他分野の「論理思考」の違いを上手く説明してくれているドキュメントって見た事無いんですよね。仕方ないんで自分の脳みそを使ってみましょうか。まずはソフトウェア技術者に取っては一番、違和感を覚える「フレームワーク」から行きましょう。
フレームワークという異物
「経営」とか「マーケティング」といった、いわゆるビジネスの世界の「論理思考（＝ロジカル・シンキング）」についての書籍で、昨今は「フレームワーク」という言葉が踊ってます。この「フレームワーク」がクセモノです。非IT系ビジネスパーソンは「思考の枠組み」という意味でこのフレームワークという言葉を使いますが、ソフトウェア技術者はこの言葉を別の意味で使います。それにビジネスの文脈での「フレームワーク」というのはソフトウェア技術者から見ると「パターン化された分析手法」に見えるんですよね。正直言って「分析パターン」と呼んでほしいところです。（ビジネスパーソンも個々のフレームワークを「SWOT分析」とか「４P分析」とかいう言い方もしますが、それでも全体ではフレームワークと言い切ってます。）さらに困った事に、この分析パターンを用いる事を「論理思考」と言い切っているフシもあります。これがソフトウェア技術者としては不思議なんです。
ソフトウェア開発者にとってフレームワークというのは、それに細かいソフトウェア部品を組込めばソフトウェアを完成させることができるものです。そうした意味ではビジネスの文脈でのフレームワークとは「思考のピースをはめ込んで思考を完成させるもの」ということになります。ロジック（論理）は「思考フレームワーク」のなかに折り込み済みって訳ですかね？こう考えるとビジネスパーソンの思考パターンがおぼろげに見えてきます。でもやっぱり、やってることは「分析パターン」を使って考えたり、説明したりですので、そもそも分析パターンと呼ばない理由がわかりません。
ここで私なりに「分析パターンとは何か」を説明すると、対象を観察・分析する際によく使われる分類・分析手法のことです。ビジネスパーソンのフレームワークは論理より「高度なモノの見方」が重要な部分占めています。これって「分析パターン」です。しかもそこで働く力は論理と言うより自然の理（ことわり）と言った方が腑に落ちるものです。この感覚はおそらくソフトウェア技術者だけでなくエンジニアや科学者全般に共通するものではないでしょうか？百歩譲って「論理思考をするための「材料の切出し」も論理思考の一部」って発想は理解できるとしても、そもそもソフト業界では同様のことをやっている「ドメイン（領域）分析」や「オブジェクト指向思考」をわざわざ論理思考とは言わないですよねぇ。そんなことしたらソフトウェア工学全体が論理思考になっちゃうから。........「論理」が工学の中心であるソフトウェア工学の方が特殊なのかもしれませんが..........これもギャップを生む原因でしょう。それから彼らは「思考の枠組み」を単なる分析に使うのではなく、自分の主張を通すための道具として使います。現実を知るために枠組みを使うのではなく、ブッチャケた話、我を通すための理論武装に利用するのですから分析パターンという受動的な呼称を使わないのは、まあ、納得ですね。
このように用語の使い方からだいぶ違うのですが、扱う対象もちがうので、IT技術者が彼らの「フレームワーク（＝分析パターン）」を使うのには、かなりの慣れが必要です。ソフト開発って「現場レベル」っていうか、具体的な仕事について扱うことがメインですが、ビジネスの世界って売込みとか提案とか、商売や経営に絡む内容がメインなんですよね。（勿論、技術系プレゼンもたくさん行われていますが、マイナーというか、視野外というか....）
で、彼らの「3C」とか「4P」とかのフレームワークを実際に使ってみるとやっぱり違和感を覚えます。はっきり言えばリアリティを感じないんです。これも多分、ソフト開発者が見ている部分と経済専門家が見ている部分が違うからでしょう。一人一人のユーザーや、個々の操作状況を思い浮かべる比重が高いソフトウェア技術者に対して、経済の専門家は「どれぐらいのユーザーが喜ぶか？」といった大きな反応に意識が集中します。売上とか利益とかを気にする立場だからリアルに感じるものが違うんでしょうね。（それとも私が彼らより馬鹿なだけ？）
論理思考と抽象思考
話はそれますが、じつは同じIT系でもインテグレータ（統括者）系のコンサルタントでは似たようなギャップが見受けられます。彼らは情報工学の高度な教育を受けていますので一流のソフトウェア開発者ということになるのですが、じつは現場での開発経験に乏しいので総じて概念的な思考に走りがちです。プログラマー出身の開発者は驚くでしょうが、彼らは所謂「手続き型」の思考が得意ではありません。ロースペックなプログラマーだと手続き型の思考しかできないのと対照的です。
「手続き型」の思考で一般にも馴染みがあるのは業務マニュアルの作成でしょう。つまり、仕事の手順を作業内容（＝手続き）ごとに分割して考える、その思考活動をソフトウェア業界では「手続き型」の発想とか思考と呼びます。これは初歩的なものなら人間なら誰でもできます。プログラマーがやっている「手続き型思考」はこれをそのままプログラムに落とし込むだけです。ただし手順や事実関係が入り組んでくると熟練したソフトウェア技術者でも理解が難しくなります。現場のユーザーは日々細かい判断を求められますから、手続き型の論理思考に結構ついて来れるのですが、日頃、概念的な事しか扱い慣れていないインテグレータ系コンサルは複雑な手続き型論理思考について来れない様です。彼らはそうしたケースにぶつかると「もっと、わかりやすい切り口があるはずだ」と考えてしまうのです。大抵の場合、その判断は正しかったりしますが、それが彼らの論理思考力の高さを証明する事にはなりません。どちらかというと「抽象的な思考力」の高さの証明と言えるでしょう。彼らが「プログラマーなら分かるかもしれないけど我々にはわかりにくい」とクレームを付けてきたら、そうした抽象的な切り口での整理を望んでいるサインでしょうね。
これとは逆にプログラマーや現場の開発者は具体的な設計とか実装レベルで考えるのに慣れているので、「何でそんな概念的な話をするのか！」と抽象思考に付合ってくれないこともあります。彼らにとって概念的なものは思考を刺激しないのです。それどころか拒絶反応さえ起こすこともあります。IT業界と言うのは何とも業の深い世界です。そしておそらく、こうした状況を見ているから私にはビジネスパーソンが言う「論理思考」が「抽象思考」にしか思えないのでしょう。
強過ぎる武器は封印すべし
さて、ビジネスの論理思考に話を戻しましょう。
先ほどビジネスパーソンのフレームワークは「論理より「高度なモノの見方」が重要な部分占める」という話が出ましたが、これは言換えると「論理は極力シンプルに抑える」ということでもあります。まずはその話からしましょうか。色々調べたんですが実際、ビジネスで使われる論理というのはそれほど多くありません。
1.「AだからBである」と理由をはっきり述べること
2.三段論法とも呼ばれる理由の組み合わせから結論を導く演繹法
3.反対事例を述べて逆説を否定する帰納法
4.論理を組み合わせる時は「真か偽か」の2値論理が基本だが、曖昧さや重複を避けること（つまり集合論）の方が重要であること
5.文章間の接続詞を的確に使って、話の流れを明確にすること
これぐらいしかありません。（これでも多いと感じる人も多いでしょうが、笑）間違っても四段論法とか五段論法とか使っちゃいけません。「かつ」とか「または」を使って複雑にし過ぎてもいけません。場合分けも1、2回が基本です。ましてや論理パズルを仕込むなんて論外です。
例えばSE上がりの起業家がビジネスプレゼンをするとしましょう。その時に「事業内容」や「製品の原理」について馬鹿正直に「論理的に、」秩序立ててプレゼンしてもまず話が通じないでしょう。元々ソフトウェア技術者が扱っているのはコンピュータに処理させるための非常に高度な論理体系です。ちょっとぐらい簡略化しても一般人の手には負えません。それに、ITコンサルタントと違い、投資家などの非IT系ビジネスパーソンは専門知識がありませんし、抽象的な思考を共有するための土台がありませんから、彼らに高度に抽象化された概念を理解してもらうのは不可能です。学生が相手でも然り。ソフトウェア技術者の最強の武器は、プレゼンでは強力すぎて相手を沈黙させる効果しか持たないんです。
逆に、目の着けどころさえ間違えなければ、プレゼンで要求される論理思考なんてソフトウェア技術者にとっては朝飯前のはずです。でも、「目の着けどころ」が以外に難しいんですよね。もともと超難解なものを超簡単にしたら突っ込みどころ満載になるのは目に見えています。それでもやれって言うのは、私らに言わせれば「だましてください」って言ってるのと同じです。でもまあ、お望みならダマして差し上げましょう。こう言うと聞こえが悪いのですが、要はソフトウエア技術者にとって「真実」と等価な「論理の積上げ」を全部端折ります。（これを端折ることは技術者にとってダマしていることとほぼ同義です）その代わりに述べるのは「問題」と「解決策」と「効果」の３つについてです。解決策や効果には理由の説明が必要ですが、先ほど述べた様に演繹法か帰納法をいくつか並べる程度に抑えましょう。そして、あまり抽象的な概念を使ってはいけません。どうしても話が抽象的になるなら具体例を挙げましょう。
え？何か違う？いやいや、そもそもソフトウェア開発とビジネスは全く粒度が違うんです。フラクタル図形の２、３階層ちがうところを見ているようなもんです。この説明もわかり難いのかな？ともかく気持ちと視点を切換える必要があります。
以上、強引にまとめると「論理的に」という言葉に惑わされるな！ってことです。
蛇足
こんなところにも論理思考
そういえば論理思考の使い方の一つにプレゼンテーションの「ストーリー」として使うというのがあります。日本ではプレゼンテーションのストーリーにも物語のストーリーと同様に「起承転結」を適用することが多いようですが、マッキンゼーとか米国の経営コンサル系では「論理思考」がプレゼンのストーリーなんです。なんか、いかにも知能レベルの高い人たちが考えそうなことですね。.......でもねぇ、今更ですが、わかりやすくする工夫が「論理思考」と言うと矛盾しているような.....確かに工夫というのは、工夫する側にとっては難しいものですが........というか論理思考は難しいだろ！（怒）
これで本当にわかりやすくなるのか
ビジネスにおける論理は「視点」が大事だと何度も述べてきました。それを使えばプレゼンがわかりやすくなるかと言えば、目が覚めるような明確な視点を打ち出せたなら、もちろんわかりやすくなるでしょう。ですが論理そのものはそれが苦手な人にとって難解な物だし、論理思考が得意な人でも今まで考えたことも無かった観点から物事を考えるのはやはり難しいものです。それでも自分の頭の整理ができるなら論理思考すべきだし、プレゼンでは伝える情報を整理するために論理を使うし、相手に論理構造そのものを伝えるためにも論理が必要です。プレゼンテーションのストーリーを論理構造にするのが常にベストとは限りませんが、元々難しいものを少しでもわかりやすく整理するために論理を使うことはできます。
ただし多少わかりやすくなったとして、それで伝わりやすくなるかどうかはまた別問題です。論理は聞き手も頭を使う必要があるので、上手く伝わらないケースも出てきます。そう、プレゼン等のコミュニケーションでは「わかりやすく」という意識設定は副次的なもので、本当は「伝わりやすく」というのが一次命題のはずです。ですが、この話は今回のテーマから外れるので別の機会にしましょう。
さて、そろそろ終りです。
私自身まだ戦い始めたばかりですから、上記の内容がどれほど役に立つかはわかりません。ご意見をお待ちしております。
10年ひと昔 [雑記]
さて、いよいよブログを初めて見たわけですが、
実際公開してみて、自分でも意外な事でショックを受けました。
久しぶりのブログというか、web上での情報公開に、まさかビジネス関連の用語解説をやるなんて。（笑）
私とインターネットの付き合いは、もう10年以上になります。
最初は仕事でwebサイトのデザインから入ったのですが、すぐに自分のwebページや掲示板とかも立ち上げるようになりました。その時の話題は趣味と実益を兼ねてやっていたコンピュータグラフィックスか、写真、仕事のデザインの事が中心でした。仕事で簡単なプログラムを組むようにもなっていたので、そうした話題もありましたが、それでも話題の中心はCGかCGアニメ関連だったんですよねぇ。
このブログでもCG関連の話題は上げていくと思いますが、今のところ公開したい長文のストックはプレゼンテーションとか論理思考についてとか、ビジネス関連の話題ばかりです。なんかホント、遠くに来ちゃったなぁって感じますね。しみじみ。
さて、次回は「ソフトウェア開発とビジネスの論理思考の違い」について、公開する予定です。
実際公開してみて、自分でも意外な事でショックを受けました。
久しぶりのブログというか、web上での情報公開に、まさかビジネス関連の用語解説をやるなんて。（笑）
私とインターネットの付き合いは、もう10年以上になります。
最初は仕事でwebサイトのデザインから入ったのですが、すぐに自分のwebページや掲示板とかも立ち上げるようになりました。その時の話題は趣味と実益を兼ねてやっていたコンピュータグラフィックスか、写真、仕事のデザインの事が中心でした。仕事で簡単なプログラムを組むようにもなっていたので、そうした話題もありましたが、それでも話題の中心はCGかCGアニメ関連だったんですよねぇ。
このブログでもCG関連の話題は上げていくと思いますが、今のところ公開したい長文のストックはプレゼンテーションとか論理思考についてとか、ビジネス関連の話題ばかりです。なんかホント、遠くに来ちゃったなぁって感じますね。しみじみ。
さて、次回は「ソフトウェア開発とビジネスの論理思考の違い」について、公開する予定です。
パラダイムシフト [専門用語]
そもそも、このブログを立てようと思ったキッカケは随分前、2/4のFridayKohmi（広瀬香美氏のUstearm放送）にある。この回の特集は「facebook」だった。
詳しくは録画を見てもらうとして、おおよそ次のようなやり取りがあった。
まず、facebookを広めるためにやってきたゲストの仲暁子氏が使った「パラダイム」と言う言葉に「パラダイムってな〜に？」と香美さんが食いつたのだが、仲さんは上手く説明しきれなかった。それに対して勝間和代氏が「世間一般に広く浸透している常識や固定概念」がどうのと優等生的な補足をした。それでも香美さんは今一納得してなさそうだったけど、その場はそれで終わった。
そうしたやり取りを聞いて、こっちもなんとなく分かった気になっていたのだが、それから程無くして自社の資料用に専門用語集を作ることになり、改めて「パラダイムとは何か？」について調べることになった。が、調べただけではわかりやすい解説は出てこなかったので、結局は自分で説明を考えることになる。調べるだけならともかく、考察までしておいて、ほとんど誰も読まない自社文書の片隅に書くだけでは、何とも、もったいない話だ。せっかくだからwebで公開しよう。...ということで、長文を発表すべく、このブログを開設することにした。「FridayKohmi」での御三方のやり取りがなければ、多分この記事はどこにも公表しなかっただろう。彼女らが読んでくれるかどうかは知らないが、とりあえず感謝の意を表する。
さて、長過ぎる前置きが終わったところで、いきなり結論から言おう。
「パラダイムシフト」という表現を使って「パラダイムって何？」と聞かれたら「パラダイムシフトで一つの用語だから、分けちゃダメ」と答えよう。もし自分が「パラダイム」と単体で使って、突っ込まれたら、まずは「お手本のこと」と本来の意味で答えよう。
そもそも今時「パラダイムって何？」と聞いてくる人はITやビジネス用語に疎い人たちである。（ゴメンなさい）そうした人たちに「世間一般に広く浸透している常識や固定概念」と説明しても腑に落ちるわけが無いのだ。（重ねてゴメンなさい）こうした相手には自分がお手本としてきたものが、いきなり「マチガイでした。こっちが新しいお手本です。」と言われた時のことを想像してもらおう。それが歴史的一大事として起った時に「パラダイムシフト」という学術用語を使うのである。
さて、ここに至る過程だが
調べる、と言っても今の時代、ググれば大抵のことは分かってしまう。実際、ウィキペディア等で詳しい解説がなされており、それによるとパラダイムというのは元は「模範」とか「代表例」という意味らしい。これは辞書にも載っている。それがなぜ「世間一般に広く浸透している常識や固定概念」という大仰な意味になるのか？その歴史的な流れについては、ここでは面倒なので書かない。だから自分でググってみてほしい。ウィキペディアには何が原典かまでバッチリ書いてある。
それらを読んで私が感じたのは「定番とパラダイムの違いは何だろう？」という疑問だった。
じつはビジネス系の文脈で「パラダイム」という言葉が使われている時は「定番＝スタンダード」という言葉で置換えられることが多い。置換えられるというより「スタンダード」という表現の方がしっくり来るのに、新しい専門用語を使いたいがために「パラダイム」と言っているケースも多いのではないだろうか？
まあ、新しい用語をカッコいいと思って、つい使いたくなる気持ちは分かる。だけど誤った使い方をすれば結局後々恥をかくのは自分である。「若気の至り」という言い訳をとっくに使えない身としては両者の区別は気になるところだ。
さて、「定番」と「パラダイム」いや、ここは「お手本」と言換えておこう。両者に共通するものは何だろう？どちらも人から注目されており、人々に影響を与える力を持っていて、その力で元の混沌とした状態から一歩抜け出すことができる。ちがうのは伝わり方だ。定番はどんなに広まっても元が分かるが、お手本は広がるにつれて大本が分かりづらくなる。お手本はそれをお手本とした人たちが新たなお手本になるからだ。定番はそのまま使われるが、お手本は習得したり複製されたりしながら利用される。そしてお手本は何時しか本人の一部になる。
どちらも社会の変化や科学技術の進歩に伴って変化するが、変化による影響が予想外に大きくなるのはお手本の方である。第二次世界大戦直後の日本など、お手本が変わる事により社会全体が変わった例はたくさんある。お手本は吸収し終わると、その存在を忘れがちなので、変わった時の心理的衝撃も大きい。
定番が変わる時ですら、大きな変化にはパラダイムシフトが付き物である。例えばデジタルカメラは今日ではすっかりデジタル家電の定番だが、これが普及することでアルバム作りの手順が大きく変わってしまい、現像関連の仕事を中心に大きなパラダイムシフトが発生した。それまではフイルムや印画紙メーカの方を向いていた写真の小売店はプリンターメーカの方を向かざるをえなくなったのだ。
パラダイムシフトというのは、こうしたお手本が変わる事に伴う構造変化を指す専門用語である。パラダイムを「ある時代や特定分野において、世間一般に広く浸透している常識や固定概念」と拡大解釈するのもここから来ている。ただし（ここからが重要！！）「パラダイムシフト」自身が象徴的な言葉であって、現象を説明した言葉ではない。だから、そこから一部を取り出して単語の意味を定義しようとすると、かえって焦点がぼやけて、意味が分かりにくくなってしまう。それに、もとの「お手本」で十分に意味が通じるのだから、わざわざ専門用語化する必要もないだろう。....まあ、既に時おそし。パラダイムも専門用語化しちゃってる。だから、どうしても専門用語としてのパラダイムについて説明する必要があれば、私なら「お手本が新たなお手本を作り、それが連鎖して巨大な共通意識が出来上っている様子」と説明する。
「パラダイムシフト」についての解説は以上である。そうそう、facebookは定番だけど、お手本の連鎖も起きている。そういう意味ではfacebookを「新たなパラダイム」と言っても間違いではない。でも私なら「新たなスタンダード」と表現する。そのほうが競っている現状に合っているから。
それから、誰も気にしていないと思うが、うちも一応パラダイムシフトを狙っている会社である。（だから専門用語集に入れる必要があった。）一企業としての力は無きに等しいが、そのうち何らかの形でパラダイムシフトに関わるつもりでいる。....それが何かは、いずれ、このブログで.....。
詳しくは録画を見てもらうとして、おおよそ次のようなやり取りがあった。
まず、facebookを広めるためにやってきたゲストの仲暁子氏が使った「パラダイム」と言う言葉に「パラダイムってな〜に？」と香美さんが食いつたのだが、仲さんは上手く説明しきれなかった。それに対して勝間和代氏が「世間一般に広く浸透している常識や固定概念」がどうのと優等生的な補足をした。それでも香美さんは今一納得してなさそうだったけど、その場はそれで終わった。
そうしたやり取りを聞いて、こっちもなんとなく分かった気になっていたのだが、それから程無くして自社の資料用に専門用語集を作ることになり、改めて「パラダイムとは何か？」について調べることになった。が、調べただけではわかりやすい解説は出てこなかったので、結局は自分で説明を考えることになる。調べるだけならともかく、考察までしておいて、ほとんど誰も読まない自社文書の片隅に書くだけでは、何とも、もったいない話だ。せっかくだからwebで公開しよう。...ということで、長文を発表すべく、このブログを開設することにした。「FridayKohmi」での御三方のやり取りがなければ、多分この記事はどこにも公表しなかっただろう。彼女らが読んでくれるかどうかは知らないが、とりあえず感謝の意を表する。
さて、長過ぎる前置きが終わったところで、いきなり結論から言おう。
「パラダイムシフト」という表現を使って「パラダイムって何？」と聞かれたら「パラダイムシフトで一つの用語だから、分けちゃダメ」と答えよう。もし自分が「パラダイム」と単体で使って、突っ込まれたら、まずは「お手本のこと」と本来の意味で答えよう。
そもそも今時「パラダイムって何？」と聞いてくる人はITやビジネス用語に疎い人たちである。（ゴメンなさい）そうした人たちに「世間一般に広く浸透している常識や固定概念」と説明しても腑に落ちるわけが無いのだ。（重ねてゴメンなさい）こうした相手には自分がお手本としてきたものが、いきなり「マチガイでした。こっちが新しいお手本です。」と言われた時のことを想像してもらおう。それが歴史的一大事として起った時に「パラダイムシフト」という学術用語を使うのである。
さて、ここに至る過程だが
調べる、と言っても今の時代、ググれば大抵のことは分かってしまう。実際、ウィキペディア等で詳しい解説がなされており、それによるとパラダイムというのは元は「模範」とか「代表例」という意味らしい。これは辞書にも載っている。それがなぜ「世間一般に広く浸透している常識や固定概念」という大仰な意味になるのか？その歴史的な流れについては、ここでは面倒なので書かない。だから自分でググってみてほしい。ウィキペディアには何が原典かまでバッチリ書いてある。
それらを読んで私が感じたのは「定番とパラダイムの違いは何だろう？」という疑問だった。
じつはビジネス系の文脈で「パラダイム」という言葉が使われている時は「定番＝スタンダード」という言葉で置換えられることが多い。置換えられるというより「スタンダード」という表現の方がしっくり来るのに、新しい専門用語を使いたいがために「パラダイム」と言っているケースも多いのではないだろうか？
まあ、新しい用語をカッコいいと思って、つい使いたくなる気持ちは分かる。だけど誤った使い方をすれば結局後々恥をかくのは自分である。「若気の至り」という言い訳をとっくに使えない身としては両者の区別は気になるところだ。
さて、「定番」と「パラダイム」いや、ここは「お手本」と言換えておこう。両者に共通するものは何だろう？どちらも人から注目されており、人々に影響を与える力を持っていて、その力で元の混沌とした状態から一歩抜け出すことができる。ちがうのは伝わり方だ。定番はどんなに広まっても元が分かるが、お手本は広がるにつれて大本が分かりづらくなる。お手本はそれをお手本とした人たちが新たなお手本になるからだ。定番はそのまま使われるが、お手本は習得したり複製されたりしながら利用される。そしてお手本は何時しか本人の一部になる。
どちらも社会の変化や科学技術の進歩に伴って変化するが、変化による影響が予想外に大きくなるのはお手本の方である。第二次世界大戦直後の日本など、お手本が変わる事により社会全体が変わった例はたくさんある。お手本は吸収し終わると、その存在を忘れがちなので、変わった時の心理的衝撃も大きい。
定番が変わる時ですら、大きな変化にはパラダイムシフトが付き物である。例えばデジタルカメラは今日ではすっかりデジタル家電の定番だが、これが普及することでアルバム作りの手順が大きく変わってしまい、現像関連の仕事を中心に大きなパラダイムシフトが発生した。それまではフイルムや印画紙メーカの方を向いていた写真の小売店はプリンターメーカの方を向かざるをえなくなったのだ。
パラダイムシフトというのは、こうしたお手本が変わる事に伴う構造変化を指す専門用語である。パラダイムを「ある時代や特定分野において、世間一般に広く浸透している常識や固定概念」と拡大解釈するのもここから来ている。ただし（ここからが重要！！）「パラダイムシフト」自身が象徴的な言葉であって、現象を説明した言葉ではない。だから、そこから一部を取り出して単語の意味を定義しようとすると、かえって焦点がぼやけて、意味が分かりにくくなってしまう。それに、もとの「お手本」で十分に意味が通じるのだから、わざわざ専門用語化する必要もないだろう。....まあ、既に時おそし。パラダイムも専門用語化しちゃってる。だから、どうしても専門用語としてのパラダイムについて説明する必要があれば、私なら「お手本が新たなお手本を作り、それが連鎖して巨大な共通意識が出来上っている様子」と説明する。
「パラダイムシフト」についての解説は以上である。そうそう、facebookは定番だけど、お手本の連鎖も起きている。そういう意味ではfacebookを「新たなパラダイム」と言っても間違いではない。でも私なら「新たなスタンダード」と表現する。そのほうが競っている現状に合っているから。
それから、誰も気にしていないと思うが、うちも一応パラダイムシフトを狙っている会社である。（だから専門用語集に入れる必要があった。）一企業としての力は無きに等しいが、そのうち何らかの形でパラダイムシフトに関わるつもりでいる。....それが何かは、いずれ、このブログで.....。
- | 次の10件
