デリダの概念からプログラミングを考える

矢野健太郎『数学』の考え方のポストを書く上で、数の概念も身体性に強く紐付いていることを考える際に、パロール／エクリチュールの関係が援用できるのではないかと思い、面白い記事がない調べてみたところ、下記のものを見つけることができました。

エクリチュールとしてのプログラミング

このブログで、下記のカテゴリーでITと哲学に関するポストで考察してきたことと同様のことが上記の記事で言及されています。

http://fintechstrikesback.blogspot.jp/search/label/Philosophy

技術とソフトウェア開発手法

FinTechとアジャイル開発をポストした後、ソフトウェア開発の手法に関する記事をいくつか読んでいたのですが、ITと哲学や概念と言葉と課題と答え述べてきた私の考えとマッチするというか、よりわかりやすい説明が行われている記事を見つけました。

「現状のソフトウェア開発は間違っていないか？」（プロセス編） (1/3)
http://www.atmarkit.co.jp/ait/articles/0901/28/news151.html

上記の記事では（記事の執筆者が考える）ウォーターフォール開発の歴史が紹介されており、そこで「メインフレーム開発」という特定の技術と状況において使用され、かつマッチしていたと紹介しています。また、当時のシステムに対する要求というものが、そもそもシンプルであったことも指摘されています。

しかしながら、業務が変わったことにより今日の要求は複雑化するし、かつ技術もオープン系になっているため、必ずしもウォーターフォール開発の手法はマッチするわけではないというのは筆者の主張です。

さらには、要求(とくべき課題、what)とソリューション（how）の関係についても、必ずしもwhatからのみhowを考えるのではなく、howからwhatを考えるという双方向の視点も筆者は取り入れており、これが私がITと哲学や概念と言葉と課題と答えで述べてきたことと相通ずるものがあると考える点です。

ある手法を歴史的背景、その手法が使用され始めた状況や技術を踏まえて批判的に分析し、強み弱みを捉えるのは、開発手法のみならず、他の様々なフレームワークを分析する上でも有用かと思います。

そんな中ふと、以前に読んだ三谷宏治『経営戦略　全史』を思い出しました。

「SWOT分析」、「プロダクトポートフォリオマトリクス」、「Fice Forces分析」等の分析ツールやフレームワークがどのように生み出され、使用されかつ批判継承されていったのかが理解できる良書です。ソフトウェア開発でも同様の本があれば読んでみたいです。

概念と言葉と課題と答え

答えが問いを待っている（技術が課題を待っている）を読み、ITと哲学で私が考えている「ソリューションから課題を考える」という方法も有用に思う方は他にもいらっしゃるよね、ということを認識致しました。

以前、edXで受講した"User Innovation"というコースでも、(Re)frame your problem to fit your skillと、課題ありきというよりは、ソリューションを前提に課題を捉え直す（Reframe)するといったことが説明されていました。

User Innovation: A Path to Entrepreneurship | MITx on edX | Course About Video

自動車自動運転と倫理

Wiredの「MITが描く「クルマ・人・街」の新しいエコシステム」というレポートを読み、「自動車自動運転と倫理」について考えてみました。

自動運転はFinTechか

倫理について触れる前に、まずは、自動運転がFinTechに含まれるのかを考えてみたいと思います。

私はFinTechの使用のされ方として、以下の二つが代表的なものと考えています。

1. 金融会社のイベノーションを促す技術
2. 金融会社に限らず、事業会社/消費者/社会にも便益をもたらす、従来の金融サービス（投資アドバイス、送金、決済、経理、財務等）に代わる/改善するテクノロジー

広義には1、２の両方がFinTechにあたり、狭義には2のみになるかと思います。私としては、FinTechという言葉で示すのは2に限った狭義の使い方が適切ではないかと思いますが、詳細はまた別の機会に考察したいと思います。

ですので、自動車保険を主力商品として扱う損害保険会社のことを考えると、自動運転は1の使い方には含まれるものの、FinTechというくくりで自動運転を語るのは、私としてはあまり適切ではないと考えが。が、デロイトの保険業界におけるFinTechの潮流でも、自動運転は取り上げられていますし、このブログで取り上げる次第です。

自動運転と倫理

さて、「自動運転と倫理」を考えるにいたったのは、Wiredの「MITが描く「クルマ・人・街」の新しいエコシステム：「WIRED Future Mobility Session」レポートのなかでの、ダニエル・ベレリ氏の発言を読んでです。該当の箇所を引用してみます。

そこで考えなければいけないのは、倫理的な問題です。例えばMITのほかのラボでは、自律走行車の倫理的なジレンマについて研究しています。自律走行車が人を轢きそうになったときに、それを避けるためには犬を轢かなければいけないという状況で、クルマにどちらを選択させるべきか。デザイナーだけではこうした倫理問題に回答を出すことはできません。しかしシナリオを提示して、人々に問題について考えてもらうべく伝えていかなければいけません。

なるほど、自動運転をプログラミングする際に、「犬か人か」どちらかを轢かなくてはいけない、という状況でどちらを選択すべきかは倫理的に考えなくはいけない問題ですね。人間が運転をするケースでは、その人個人の倫理的判断に基づけば、いいのですが「自動運転」させる場合は、何が「正しい運転」、「望ましい運転」かを人が決めアルゴリズムを組むわけで、そのアルゴリズムが社会一般の通念や倫理に反していてはいけないですよね。

取り上げられたケースの場合、人と犬であれば、まだ考えやすいかと思います。議論はあるものの「犬」を轢く方に選択するのが社会的通念に則ったものではないでしょうか。

それでは、人一人と人二人はどうでしょうか、この場合はプログラムではどちらかを明示的に選択せずに、ランダムに選ぶというのも、一つの倫理的な解決かもしれません。

それでは、末期ガンを宣告された人一人と、小学生二人はどうでしょうか。まもなく死ぬ人間一人と未来ある子供二人のケースです。

あくまで上記は例で、「正しいこと」をアルゴリズムとして組み込む際には、このようにどちらかを選択しがたい状況での倫理的問題を考えざるをえないですね。

ITと哲学

今回はITと哲学についてのポストです。

大学生の頃、哲学についても学んでいたので、プログラミングの勉強をしているときや、仕事をしているときに、哲学的概念との関連を思い浮かべたりします。

ここでいう哲学とは、分析哲学というよりは大陸系哲学に分類されるものです。分析哲学に分類されるものは、論理学に基づいていますし、Inofrmation Technologyの起源を語る上でも不可欠なものなのですが、私が学んでいたのは、主に大陸系に分類されるポスト構造主義とかフランス現代思想と分類されるものなので、これらに関連する概念を思い浮かべたりします。

ひとつ例をあげると、フランスの哲学者ジャック・デリダが提唱したパロール（話し言葉）とエクリチュール（書き言葉）の関係です。

西洋では伝統的にパロール（話し言葉）がエクリチュール（書き言葉）に先立ち、優位に置かれてきたとされるが、そのような単純な二項対立ではなく、両者は複雑に関係している、とデリダは主張していた、というのが私の理解です。

パロール：エクリチュールは、概念：言葉という組み合わせにも置き換えられます。概念というのは、言葉に先立って存在し、言葉はあくまで「先に」存在している概念を表現するためのものだ、と考えることが普通かと思いますが、そうとは限らないのではないでしょうか。

英語、日本語での言葉の違いを考えてみるとわかりやすいと思います。日本語では「えび」と表示するものが、英語ではサイズによって、ロブスター、プローン、シュリンプと分けて表現されます。日本語でもロブスターは使用するかと思いますが、プローンとシュリンプは区別されずに「えび」になるかと思います。あとは、tuna(ツナ)という言葉ですが、我々はtuna (=マグロ)と理解していますが、tunaにはカツオも含まれるんですよね。

ここで伝えたいのは、ロブスター/プローン/シュリンプという概念（区分）が予め存在したのではなく、何らかの理由（文化的、歴史的背景）があって、それぞれを分ける言葉が使用されるようになり、その言葉に従い個別のものとして理解されるようになった、ということです。

さて、ではこの概念：言葉という組み合わせを、どのような関わりでITにおいて思い浮かべるかといいますと、「解くべき課題」と「ソリューション」との関係においてです。あるいは、システム開発における「業務要件」と「ソリューション」といってもいいかもしれません。

いわゆる「業務要件」を考える際、「ソリューションありきではなく、「何がしたいのか、どういう課題を解決したいのか」を先に考えよう、決めよう」といったことが言われますし、それは正解ではあるのですが、あるソリューションを前提としていない、業務要件は考えにくとと思います。

我々が考える「業務」は基本的には、「紙」というソリューションに負うことが多いですし、もしくは当たり前すぎと忘れてしまいますが、Microsoft Word / Excel / PowerPointといったソリューションを使用して現在の業務を行っているかと思います。

ある業務（＝概念）が先に存在し、それに対応するソリューション（＝言葉）が後付けされるのがすべてのケースではないということです。

特にPowerPointが顕著かと思いますが、「プレゼンテーション」という業務を考える際に、PowerPointを代表とした、プレゼンターションツールなしで、プレゼンテーションの方法や内容を考えることは難しいのではないでしょうか。

ここで伝えたいのは、ゴールは「要件（= 解くべき課題の解決）」であっても、方法として「ソリュショーンありきで考えてみる」というのも有用ではないかということです。

解くべき課題というのが、すでに存在しているソリューションと密接に絡みついているのであれば、逆に新しいソリューションから、どのような課題が解決できるのか、と考えるのは重要かと思います。結果、解くべき課題があたらしく発見できるかもしれません。

実務レベルで、「これつかってなんかできないかな」というのは行われていますし、FinTechでいうと、各社がラボ形式で新技術に取り組む等、どのように活用できるか試行錯誤をしたりしているので、改めてこのように考えなす必要もないかと思いますが、誰かと議論をする際に哲学における「概念：言葉」の関係を援用すると面白いかもしれません。