自動車オブジェクト
 日記

　オブジェクト指向がどうとか、ソースはきれいに書けとか。そういうことを必死でいう人たちだって、たぶん仕事で実践できてるとは限らない。
　むしろたいていは、いろんな事情で実践できていないからいうんだと思う。
　そりゃあ、いくらうったえても通じないことのほうが多いだろう。しかし、うったえ続けるしかないんである。

「横幅は80文字以内に」とか「１関数50行以内に」とか、そんなシンプルなルールでさえ、守ってもらうためにはそうとうの努力がいる。
　というか、そういうのこそが本当の技術なんだと、そのことに気づくまでに高い壁がある。

まず、はっきり言っておこう。IT土方ってのはプログラマではない。SIerの中ではPGとか呼ばれる人たちだが、仕様書という自然言語で書かれた文章を、プログラミング言語に訳すだけの簡単なお仕事である。このレベルの人間を100人集めたって先駆的なモノは生まれない。
SEと呼ばれる人間もプログラマではない。SEは仕様を詰める雑務をこなすだけで、システムを構築する能力を持つわけではない。SEを100人集めたって先駆的なモノは生まれない。
では、システムってどうやって作られるの、というとごく少数のプログラマによって作られる。プログラマという単語の意味がすっかり汚染されたのでわざわざアーキテクトという名称で呼んだりもする。

　まずはっきりいっておくけど、その立場の人が一人もいないプロジェクトだってある(笑)。いても、いろんなしがらみで力を発揮できなかったり。
　たいていの場合、ようやく動いたとか、よくわからないけどいろいろやってたら動いたとか、そういうレベルのプログラムが納品されている。それが現場の現実だろう。
　その段階のプログラマは、スケジュールぎりぎりで、残業して「ようやく動いた」というところまでしかいかない。だから、ソースをきれいにとか生産性を上げるとか、そういう発想にはなかなかならない。そんな時間はないから。経験が何年あってもそうだったりする。
　いっぽう、一度技術を身につけてしまった人は、もう決してあとに戻れない。オブジェクト指向やリファクタリング手法を実践すれば、こんなに速くきれいに書けるのにと。彼らにとってはもはや自明になっていることを、他の技術者にも伝えようとする。上の引用でいう「アーキテクト」の役割をこなしながらだ（そしておそらくは、小さなプロジェクトだと、同じ人がSEもやっているだろう）。
　けれど、その言葉は伝わらない。たしかに、直接成果物に関わる話ではないけど。「指示された機能が動くようにする」ことが技術なのだと、そう思っている限りは、その人にはどんな言葉も届かない。
「見解の相違」だとか「いろんな意見があるよね」とか、そういう話ではない。そんなおためごかしでごまかせる問題じゃない。技術の問題なんだから。技術力の高い意見のほうが、明確に正しい。
　でもそれは伝わらない。伝わらないけど、いいつづけるしかない。
　まあ、それをいってる人が本当に技術力を持ってるのかというのは判断が難しいけど。

　で、だから、少しでも伝わるようにとあがいた結果「自動車オブジェクト」なんて言葉になったりするんじゃないか。と思った。
　オブジェクト指向を勉強したときは、なんてダメな例えだろうと思ったものだけど。いまでは、ああいう言葉になってしまう気持ちが、わからないでもない気がしている。

kamata -2009/07/12 08:07
　認知科学と自動化技術の学徒としては、

仕様書という自然言語で書かれた文章を、プログラミング言語に訳すだけの簡単なお仕事
　これが一番、単独で自動化も手続き化もできない、人間がやらなければならない仕事に聞こえますけれどね。人間の世界では必ず誰かが自然環境と正規化データとのインタフェースをやらねばならない、それは我々全員がターミネータか何かになるまで必要なお仕事です。

　『＞一度技術を身につけてしまった人は、もう決してあとに戻れない。』という普遍技術駆動の現象が起きるのは、その人々の処理している実作業部分が本質的に高度な知能が必須ではない機械的な作業だからではないでしょうか。
　↑つまりアーキテクターが『先駆的』なのなら、もっと自律的にコード書いてくれるプログラム書いて下さい、そういう提言です。プログラマを育てない大学の計算機科学の研究室は、その研究に邁進してますし。

てらしま -2009/07/12 12:11
　すごく端的にいって、そんなレベルの話じゃないですorz

　↑つまりアーキテクターが『先駆的』なのなら、もっと自律的にコード書いてくれるプログラム書いて下さい、そういう提言です。
　それはそのとおりと思うし、じっさいやってる。
　現に、いろんなフレームワークとかはそういうものです。でも、そうして作ったモノは説明して導入してもらわなきゃいけない。フレームワークとかライブラリとかはどれも、それなりに機能を備えてるモノですが、使いこなせるのは技術がある人だけ。なぜなら、なぜそれが必要なのかを知るには技術がいるから。どんなにいいものでも、マニュアルが充実していても、一生懸命説明しても、その言葉は伝わらないです。
　技術といっても、本当はそんなに高等な知識が必要なわけじゃないけど。

　なので、フレームワークやライブラリの開発で足りないのだとしたら、それは「技術者の仕事じゃなくす」「マニュアルが一切不要なくらいわかりやすいGUIが必要」というレベルの話になってしまうのです。もちろん試みられているけど、そういうものでユーザからのあらゆる要件を満たすのはむずかしい。
　それに、それで納得するユーザなら既存のパッケージでもいいだろうから、そっちを薦めるのが正解という気もする。

　まあじっさい、Googleがいろんなモノ作るので、技術者の仕事じゃなくなっていく部分は増えていくのかもしれないけど。

kamata -2009/07/12 22:20
　うわぁ。

それは「技術者の仕事じゃなくす」「マニュアルが一切不要なくらいわかりやすいGUIが必要」というレベルの話

　こういうのはインタフェース研究者の間では、もうその筋の専門家ならケースワークでも汎用フォーマットでも任せてくれりゃいくらでも作れるよ！って状態です。ただ大企業がそれに金と時間を出した例がない（良くてAppleや一部のUnix/Linux屋さんぐらい）上に、連中はうちらの研究成果と提言の真逆をひた走るのが大好きらしいんで……MSの窓とか。多分奴らはPCを使いやすくすると顧客の総需要が下がると思ってる。
　結局、全ては「PCを使うのはまず中身を理解した奴からでいい」という昔の計算機科学の因習によって、『万人向けの利用』という発想が業界で死んでるからだと私も諦めてます。けど、

なぜなら、なぜそれが必要なのかを知るには技術がいるから。

　我々インタフェース関係者は、現代の民生・個人用コンピュータの利用形態はまだ『A．未熟者向けの誘導・教育効果を持つインタフェース』が必要とされてる段階、だと思ってました。でも、たかが一機10万円台のハードウェア環境が航空機・宇宙船・原発並みに『B．既にエキスパートのオペレーターを補助・教育するインタフェース』のパッケージを必要としてる、ってんなら確かに想定外かつ大問題ですね。今のフライ・バイ・ワイア制御の航空機は通常のフライトなら、離陸以外は全部自動操縦できるので。
　一応後者Bも作れるでしょうけど……高いですよ。小型旅客機一つを丸々設計するぐらいかかるんじゃないかと。で、構想と仕様と構成を決定するのはわしらですが、実際に制御システム作ってるのはSEから土方までIT技術者の人たちなのに、というオチ（笑）。

　やっぱり「この世には『モノを分かりやすく／使いやすく作る』ための汎用技術がある」っていうことが、世間に全く知られてないってことでしょうか？ゲームデザインぐらい、と反省。↑を『分かりやすく』伝える技術、というのもまた難しいメタ問題なんです。

てらしま -2009/07/12 23:25
　まあ簡単にいえば「レジに客が立ってるのに気づかない店員ってなんなの？」という話と同じ。
「技術」とあえて書いてますが、じつはその程度の話だろう、と個人的には思ってます。だからそんなに大変な話じゃないと思うけど、簡単に教育できることでもない。
　レジ打ちは誰でも使えるインターフェースだけど、客が並んでることに気づくには技術がいる。いちど気づけるようになったらもう客を並ばせるわけにはいかなくなるから、気づかない同僚の仕事にはストレス溜めてると思う。
　じっさい、客の動きがちゃんと見える店員は、いいプログラマになれるんじゃないか。と、さっきすき家で思った(笑)

てらしま -2009/07/13 00:04
　あとたぶん、若干勘違いがあるような。
（そうでもなかったらすみません）

　これが一番、単独で自動化も手続き化もできない、人間がやらなければならない仕事に聞こえますけれどね。人間の世界では必ず誰かが自然環境と正規化データとのインタフェースをやらねばならない、それは我々全員がターミネータか何かになるまで必要なお仕事です。

　ここでいう「仕様書という自然言語で書かれた文章」というのは、それこそプログラム１ステップ単位で書かれた（病的な）詳細設計書のことです。たぶん。それを書くのはSE。あと、データを正規化するのもSEです。
　上の引用でいうIT土方は、本当に比喩でもなんでもなく、書かれたとおりにプログラム言語に訳していく仕事をしています。
（まあ、そういうのはプロジェクト次第なので、じっさいはいろいろありますが）
　なので、ここは本当に自動化できます。というか、そんな設計書つくるヒマがあったらプログラム書けば？バカなの？という世界の話……だと思います。

　で、でもそんな仕事だけではシステムは動かないです。IT土方が簡単なお仕事をすれば動くようにシステムを作るのがアーキテクト。上の引用元はたぶん、そういうイメージで書かれてると思います。
　だからその意味では、IT土方を全員解雇してもシステムを作れるようにするのが理想という話になるか(笑)

kamata -2009/07/13 14:08
　いや、多分てらしまさんと私と、大体勘違いせずに理解できてると思います。大丈夫ですよ。

じっさい、客の動きがちゃんと見える店員は、いいプログラマになれるんじゃないか。と、さっきすき家で思った(笑)
　認知方面からのインタフェース研究の目標は長年、多段構造なシステムについて内部のオペレータが
　－認知（外界・他ブロックからのインプット回り）
　－作業（外界・他ブロックへのアウトプットや伝達）
　－意識上の思考（『今、客が来そうな時間帯なのかな？来てたら何してるだろう？』局部状況での作業効率化）
　の全部をだいたい一緒に（平行か一体か切り替えでか）やれる仕事環境／システム作りを進めてきたわけです。で、大規模なものなら原発・航空機から列車などへと、段々低コストなニーズへも応用が進められてます。だから『バイトを客を見られるコンビニ店員に育てるシステム』を社内に作ることは、おそらくIT業界でだって可能です。大手スーパーはその教育・研修システムがありますし。
　多分IT土方だってまだ人間だもの。

それを書くのはSE。あと、データを正規化するのもSEです。
　上の引用でいうIT土方は、本当に比喩でもなんでもなく、書かれたとおりにプログラム言語に訳していく仕事をしています。
　それはSE（顧客、つまり自然環境の側）と土方（データ処理世界の側）の両方が、『仕様書』という半自動化されたシステム／プロトコルを間に挟んだ引き受け作業ブロックの、インタフェースの両界面に当たるケースだと、うちらの研究なら考えます。
　この処理構造でのどの段階のデータも、飛ばして次のステップに送ると作業ができない／大変すぎる、ということで人力インタープリターを抱えてる。理想的にはSEも土方もアーキテクターも（あと営業も？）全部できるプログラマだけ人員にして、あとは全部自動化できれば嬉しい……と思われるかもしれない（先述の『B．』はその環境を作るシステムですし）。機内側ではそういう超人オペレータ三人だけで飛ばしてるジャンボジェットみたいに。でもすると、今度は
『C．自動プロセスに処理できない作業の兆候を、オペレーターが自発的に発見できるインタフェース』
　という悪夢の監査問題を惹起することに。

　だから現在のIT産業の開発は、各人員がヒューマンファクターとしての思考能力を分け持って、オブジェクト指向式に分散（低負担・低リスク化）作業している、という風に私には見えます。
　他の部署にいるからって、土方の仕事しながら自分の作業する二人羽織はできないでしょ？プログラマはもうちょっと人間力（マンパワー）を大切に扱いなされ、というのが一つ。もう一つは各人員の認知負担を作業プロトコルのインタフェース回りで改善すれば、もっと作業を効率化できるのに、という提言です。多分私の言いたかったことはこの二点で......でも土方をバカにするアーキテクトは、アーキテクトの存在を設計するヒューマンマシン・ワークデザインの存在を嫌がるだろうなぁ。

てらしま -2009/07/13 22:57
　ようやく話が見えてきた気がしますが、いろんな話が混ざっててまだわかりません。
　けっきょくのところ、いいたいのは「教育の必要なくまともな開発させることができる体制をつくれ」ということ？

↑つまりアーキテクターが『先駆的』なのなら、もっと自律的にコード書いてくれるプログラム書いて下さい、そういう提言です。
　これは自動化しろということではなく、なんの訓練も受けていない人でも自律的にまともなコードを書いてくれる仕組みをつくれということ？
　それなら、たしかにそういうアプローチも考えていいと思います。
　その上でマンパワーを大切に扱うということになると、ようするに、PGの仕事はさらに誰でもできるようになるからもっと給料を下げろという話になる（単価が安いほうが多くの工数を確保できる）。現状から考えるなら、おそらくは自社員を解雇して外国人を大量に雇うことになる。のかどうか。
　それでまともな成果物ができるようになれば、もちろんそれでいいです。アーキテクトが失職するならそれでかまわないでしょう。いや失職したくないからああいうこといってるのかもしれないけど。

もう一つは各人員の認知負担を作業プロトコルのインタフェース回りで改善すれば、
　じっさい、インターフェースがEXCELではなあというのはたしかにある(笑)。まあ、EXCELから脱却しようとすると冷たい反発を受けるのが実情ですが、それは画期的にいいものがまだないという意味でもあるのかなあ。
　エクストリームプログラミングとかがたぶん、kamata氏のいうような試みの一つだと思う。個人的には、あれでうまくいくなら苦労しないという気がしているけど、やってみたくはある。

まつざわ -2009/07/14 01:15
開発効率あがったら人月減るから売り上げも減るじゃない、ってなこと言うと袋叩きにされたりしますでしょうか。

原価割れギリギリまで値下げ要求するお客さんに
「それ以上値段下げたら赤字ですわ～」
と説明するために原価＝人件費を前面に押し出してるという商売のやり方が諸悪の根源なんですきっと。
世間の相場って言うか標準価格が無い商品はつらいですね。

てらしま -2009/07/14 02:06
　どうもですー。
　そうですねえ。人月で計算すると、チンパンジーでもハッカーでも同じですからねえ。
　もちろんチンパンジーはサルより人に近いので、何人と数えます。
　たぶん必要なのは、人月じゃない値付けした上で1000万円じゃなくて998万円にするとか、10%のポイント還元！とかそういう商売なんじゃないか。と最近真剣に思う。