今回はITと哲学についてのポストです。
大学生の頃、哲学についても学んでいたので、プログラミングの勉強をしているときや、仕事をしているときに、哲学的概念との関連を思い浮かべたりします。
ここでいう哲学とは、分析哲学というよりは大陸系哲学に分類されるものです。分析哲学に分類されるものは、論理学に基づいていますし、Inofrmation Technologyの起源を語る上でも不可欠なものなのですが、私が学んでいたのは、主に大陸系に分類されるポスト構造主義とかフランス現代思想と分類されるものなので、これらに関連する概念を思い浮かべたりします。
ひとつ例をあげると、フランスの哲学者ジャック・デリダが提唱したパロール（話し言葉）とエクリチュール（書き言葉）の関係です。
西洋では伝統的にパロール（話し言葉）がエクリチュール（書き言葉）に先立ち、優位に置かれてきたとされるが、そのような単純な二項対立ではなく、両者は複雑に関係している、とデリダは主張していた、というのが私の理解です。
パロール：エクリチュールは、概念：言葉という組み合わせにも置き換えられます。概念というのは、言葉に先立って存在し、言葉はあくまで「先に」存在している概念を表現するためのものだ、と考えることが普通かと思いますが、そうとは限らないのではないでしょうか。
英語、日本語での言葉の違いを考えてみるとわかりやすいと思います。日本語では「えび」と表示するものが、英語ではサイズによって、ロブスター、プローン、シュリンプと分けて表現されます。日本語でもロブスターは使用するかと思いますが、プローンとシュリンプは区別されずに「えび」になるかと思います。あとは、tuna(ツナ)という言葉ですが、我々はtuna (=マグロ)と理解していますが、tunaにはカツオも含まれるんですよね。
ここで伝えたいのは、ロブスター/プローン/シュリンプという概念（区分）が予め存在したのではなく、何らかの理由（文化的、歴史的背景）があって、それぞれを分ける言葉が使用されるようになり、その言葉に従い個別のものとして理解されるようになった、ということです。
さて、ではこの概念：言葉という組み合わせを、どのような関わりでITにおいて思い浮かべるかといいますと、「解くべき課題」と「ソリューション」との関係においてです。あるいは、システム開発における「業務要件」と「ソリューション」といってもいいかもしれません。
いわゆる「業務要件」を考える際、「ソリューションありきではなく、「何がしたいのか、どういう課題を解決したいのか」を先に考えよう、決めよう」といったことが言われますし、それは正解ではあるのですが、あるソリューションを前提としていない、業務要件は考えにくとと思います。
我々が考える「業務」は基本的には、「紙」というソリューションに負うことが多いですし、もしくは当たり前すぎと忘れてしまいますが、Microsoft Word / Excel / PowerPointといったソリューションを使用して現在の業務を行っているかと思います。
ある業務（＝概念）が先に存在し、それに対応するソリューション（＝言葉）が後付けされるのがすべてのケースではないということです。
特にPowerPointが顕著かと思いますが、「プレゼンテーション」という業務を考える際に、PowerPointを代表とした、プレゼンターションツールなしで、プレゼンテーションの方法や内容を考えることは難しいのではないでしょうか。
ここで伝えたいのは、ゴールは「要件（= 解くべき課題の解決）」であっても、方法として「ソリュショーンありきで考えてみる」というのも有用ではないかということです。
解くべき課題というのが、すでに存在しているソリューションと密接に絡みついているのであれば、逆に新しいソリューションから、どのような課題が解決できるのか、と考えるのは重要かと思います。結果、解くべき課題があたらしく発見できるかもしれません。
実務レベルで、「これつかってなんかできないかな」というのは行われていますし、FinTechでいうと、各社がラボ形式で新技術に取り組む等、どのように活用できるか試行錯誤をしたりしているので、改めてこのように考えなす必要もないかと思いますが、誰かと議論をする際に哲学における「概念：言葉」の関係を援用すると面白いかもしれません。
大学生の頃、哲学についても学んでいたので、プログラミングの勉強をしているときや、仕事をしているときに、哲学的概念との関連を思い浮かべたりします。
ここでいう哲学とは、分析哲学というよりは大陸系哲学に分類されるものです。分析哲学に分類されるものは、論理学に基づいていますし、Inofrmation Technologyの起源を語る上でも不可欠なものなのですが、私が学んでいたのは、主に大陸系に分類されるポスト構造主義とかフランス現代思想と分類されるものなので、これらに関連する概念を思い浮かべたりします。
ひとつ例をあげると、フランスの哲学者ジャック・デリダが提唱したパロール（話し言葉）とエクリチュール（書き言葉）の関係です。
西洋では伝統的にパロール（話し言葉）がエクリチュール（書き言葉）に先立ち、優位に置かれてきたとされるが、そのような単純な二項対立ではなく、両者は複雑に関係している、とデリダは主張していた、というのが私の理解です。
パロール：エクリチュールは、概念：言葉という組み合わせにも置き換えられます。概念というのは、言葉に先立って存在し、言葉はあくまで「先に」存在している概念を表現するためのものだ、と考えることが普通かと思いますが、そうとは限らないのではないでしょうか。
英語、日本語での言葉の違いを考えてみるとわかりやすいと思います。日本語では「えび」と表示するものが、英語ではサイズによって、ロブスター、プローン、シュリンプと分けて表現されます。日本語でもロブスターは使用するかと思いますが、プローンとシュリンプは区別されずに「えび」になるかと思います。あとは、tuna(ツナ)という言葉ですが、我々はtuna (=マグロ)と理解していますが、tunaにはカツオも含まれるんですよね。
ここで伝えたいのは、ロブスター/プローン/シュリンプという概念（区分）が予め存在したのではなく、何らかの理由（文化的、歴史的背景）があって、それぞれを分ける言葉が使用されるようになり、その言葉に従い個別のものとして理解されるようになった、ということです。
さて、ではこの概念：言葉という組み合わせを、どのような関わりでITにおいて思い浮かべるかといいますと、「解くべき課題」と「ソリューション」との関係においてです。あるいは、システム開発における「業務要件」と「ソリューション」といってもいいかもしれません。
いわゆる「業務要件」を考える際、「ソリューションありきではなく、「何がしたいのか、どういう課題を解決したいのか」を先に考えよう、決めよう」といったことが言われますし、それは正解ではあるのですが、あるソリューションを前提としていない、業務要件は考えにくとと思います。
我々が考える「業務」は基本的には、「紙」というソリューションに負うことが多いですし、もしくは当たり前すぎと忘れてしまいますが、Microsoft Word / Excel / PowerPointといったソリューションを使用して現在の業務を行っているかと思います。
ある業務（＝概念）が先に存在し、それに対応するソリューション（＝言葉）が後付けされるのがすべてのケースではないということです。
特にPowerPointが顕著かと思いますが、「プレゼンテーション」という業務を考える際に、PowerPointを代表とした、プレゼンターションツールなしで、プレゼンテーションの方法や内容を考えることは難しいのではないでしょうか。
ここで伝えたいのは、ゴールは「要件（= 解くべき課題の解決）」であっても、方法として「ソリュショーンありきで考えてみる」というのも有用ではないかということです。
解くべき課題というのが、すでに存在しているソリューションと密接に絡みついているのであれば、逆に新しいソリューションから、どのような課題が解決できるのか、と考えるのは重要かと思います。結果、解くべき課題があたらしく発見できるかもしれません。
実務レベルで、「これつかってなんかできないかな」というのは行われていますし、FinTechでいうと、各社がラボ形式で新技術に取り組む等、どのように活用できるか試行錯誤をしたりしているので、改めてこのように考えなす必要もないかと思いますが、誰かと議論をする際に哲学における「概念：言葉」の関係を援用すると面白いかもしれません。
