|
１．システム・エンジニア（System Engineer）
日本にはシステム・エンジニア（System Engineer）という職がある。これが和製英語であることは気にしない。プログラマとの違いも気にしない。関心事は何をする者たちであるか、である。Wikipediaには以下の様に記されている。
私がシステム・エンジニア職に就いたのは、いろんな人たちの考えを聞き、論理的に整理し、ソフトウェアという形で表現するというシステム開発が知的で芸術的であったためだ。
入社してからは設計、プログラミング、テストに励んだ。
いろんな方法論やツールを活用し、より短期、高品質なシステムを作ることに励んだ。
自分の担当分は速く終わらせ、他の人の担当分の作業をたくさんやった。残業、徹夜、休日出勤もやった。
リスクにも敏感になり、影響範囲や対策の提案を行うことにより、顧客の評価も得てきた。
さて、これが私がやりたかったことだったのだろうか。 これはこれでよい。
しかし、次のプロジェクトに参入したとき、みんなが前述のことをやらないのは何故だろう。やるのは残業、徹夜、休日出勤のみであり、それらをしなくて済むよう効率的な作業をやろうとはしない。知は蓄えられず、そもそも知を得ようともしない文化だった。そこで、私はそこの文化レベルを上げるべく努める。
さて、これが私がやりたかったことだったのだろうか。 これはこれでよい。何度もこの繰り返しであっても・・・
しかし、削減出来るべき作業時間、残業、徹夜、休日出勤を削減せず、お金を請求してよいのだろうか。私はこの問題に対して、どのように努めればよいのだろうか。
答えを求めるべく、哲学を学び、知働化を学び、ソフトウェア開発のあるべき姿とは何か、を考えてきた。
けれど、「あるべき姿」とは何だろうか。そもそも、私が「あるべき姿」を語れるのだろうか。リアルに存在する今の業態を否定し、リアルに存在するのかどうかわからない業態を肯定することが私にできるのであろうか。そこで私は今の業態を認めることにする。私がこの業態を好むか好まないかは別問題として。現に、発注側がそれを求めるケースがあるのだ。認めざるを得ない。そのうえで、あるべき姿だと思うものを別に定義する。
これに従い、システム・エンジニアを次のように区分ける。
２．システム・クラーク（System Clerk）
狭義のシステム・エンジニアであり、私が現在目の当たりにしているシステム・エンジニアのこと。
クラーク（Clerk）とは事務員、書記官などの意味を持ち、仕事内容から命名する。
クラークは主にドキュメントを作成することを仕事とする。
Excelで作りたいものをまとめ（設計）、プログラミング言語という文字（コード）で動作させたいことをまとめ（製造）、Excelで動作させたいことをまとめる（テスト）。
工学性に従い、「誰でも同程度の効果を発揮できる」こととする。すなわち、ひとりのエンジニアの能力の高さよりも、人数で見積もられる。
人数で見積もるため、ひとりひとりの評価は平均的になる。どんなに高い能力を持ったエンジニアがいたとしても、他のメンバの補佐作業を行うため、速度・品質は同程度と評価される。仮に評価されたとしても、効果分評価されることはない。なぜなら、評価される以上、社会人であったとしても、100点満点で評価されるからである。
このような業態から、エンジニアと称するよりも、サラリーマンと称する方が合っている。
３．システム・アーティスト（System Artist）
エンジニアの中で一際能力の高いもの、またはそれに見合う働きをするもののこと。
アーティストとは、芸術家、達人のことであり、仕事ぶりからそれが伺える。
サラリーマンと違い、人に依存する能力を考慮するため、タレントと称する。
設計書はただ書かれたものだけでなく、要件、コード、テストとの連動性が考慮されて読みやすく、変更時の影響を最小限にできる。
コードはプログラミング言語とは思えないような美しさがあり、あたかも設計書の翻訳書のようだ。
また、処理速度やコード量の低減など、あらゆる面で達人だといえる。
しかし、芸術は表現側（アーティスト）と受手側がそろって、はじめて完成する。
アーティストは常に最善を目指すが、顧客はそこまで求めていないことは間々ある。それどころか、アーティストの作品の良さが分からず、有能ではなく低能だと評価されてしまうこともある。
そのため、アーティストであるシステム・エンジニアは顧客に対して、もっと理解するための努力を求めることがある。しかし、そんなことはおこがましい行為ではないだろうか。
４．システム・エンターテイナー（System Entertainer）
アーティストと同様、タレントだが、アーティストが発信（技術提供）のみに対し、エンターテイナーは送受信（コミュニケーション）を主目的とする。エンターテイナーとはもてなしをする人のこと。
アーティストは顧客に関係なく自身の能力で作り上げた作品を提供し、顧客は自分が評価できたぶんだけ評価する。
エンターテイナーは顧客が求めるものだけを提供する。エンターテイナーに求められるのは、顧客から何を求めているかを引き出す能力と、その問題に対応する能力である。
この能力は「何を言ったかではなく、誰が言ったかが重要である」という事実がヒントとなる。
この言葉は通常、逆が正しい。権力が強い方が正しいのではなく、内容が正しい方が正しいからである。
しかし、それは「いつ言うか」という文脈情報が抜けている。
誰かが言った影響力の強い言葉を適当なタイミングで言っても仕方ない。それは「いつ、どのような順番で語るか」という文脈がないからだ。
エンターテイナーはそれをわきまえたうえで行動する。
顧客に理解するための努力を求めるのではなく、顧客が理解できる分だけ、顧客の理解を促進できるよう考慮した上で、システムを提供する。
エンターテイナーはシステム開発の際、知働プロセスにて行う。
５．知働プロセス
知働とは以下の通り。
知働プロセスとして検討することは以下の通り。
設計、製造、テストのセットをイテレーティブに実行する。
６．知働と哲学の関係
知働は思考を表現するため、思考を捉える必要がある。
システム開発において、思考の元は主に３つある。顧客、設計書、プログラムである。実際にはもっとたくさんあるだろう。とにかく、作りたいものが異なるフォーマットで多元的に定義されている。そのため、差異が生まれる。差異とは、情報の欠如、情報の変形、関係ない（システムの都合）情報の混在、などである。差異がないことを確認するためにテストをする。そして確認しきれず、バグが発生する。バグとは考えていたことと違う結果が起こったことである。
それならば、思考を一元的に管理し、我々が扱うものはすべて、その副次的なものとしようと考える。この一元的に管理するものを「Philosophy Agent（真理を代弁するもの）」と称し、関係を以下に示す。
哲学とは、どのように考えていくか、その思考の正しさをどのように論証するか（何を根拠とするか）、を議論する学問である。哲学は知働のように、知働よりもより原理的に思考を捉える。
東洋哲学において、因果関係は成り立たず、因と果の間に縁が働くことによって成り立つとする（因縁果）。つまり、因と縁が混在して因と認識されてしまっている。この例としては次の通り。顧客のヒアリング内容から設計書が書かれることはなく、顧客のヒアリング内容にプログラマの解釈を混在させることで設計書が書かれている。顧客のヒアリング内容と、プログラマの解釈が識別できるのであれば問題ないのだが、大概これは併せて、顧客のヒアリング内容として認識される。そして、これが積み重なることによって、まったく別のものが生み出されることとなる。そのため、前述のような仕組みを考えた。
他にも哲学から学ぶことは多々あるが、別記することとし、本文を結ぶ。
知働は知の活用の仕方であり、哲学は知の認識・証明であり、二つは知で結ばれる。すなわち、以下の通り。
|