つらつら思い出すこと。

「みんなで何かする」事について思い出すのは、嫌な思い出しかない。今さらどうこうという訳でもないけど。
中学生の頃美術部に所属していた。その美術部では、運動会の時に毎年運動会の看板を描いていた。それはベニヤ板数枚を貼り合わせたもので、当然2-3年全員で手分けして描くものだった。
当時1年の自分は、傲慢にも「自分なら手伝える」と自惚れてあるパーツを手伝ってみた。
で、見事に失敗した。
ところが当時の自分は失敗というのを知らなかった。あやまる方法を知らなかった。
どうしたかというと、うやむやにしてその場から逃げた。
数日して先輩に「ここ描いたの誰」というわけでしっかりあやまらされた訳だが。

小学生時代は「よいこ」で通っていた為、「自分が失敗したので他人に謝る」という事を知らなかった。サイアク。
結局チキン野郎なんですけど。

高校・大学時代は嫌な思い出は・・・うーん、「みんなで何かする」事については何も、無い。
高校時代は必ず集団の隅っこに行くようにしてたし。大学時代は「みんな」という単位自体がなかったし。

会社に入ってからを思い出す。
ああああああああああああああ畜生、ここからが嫌な思い出の本番だよ。

伏線となる2004末-2005年初めの仕事

きっかけは2004年-2005年初めの仕事だった。例のお客様の所。
このお客様のところには弊社から2-3名、常駐メンバがSEとして張り付いていた。
その時の仕事では、契約の問題で新規開発担当メンバは持ち帰りで開発ということになっていた。
ところが新規開発担当メンバは4人いたが、内2人(自分とAさん)はそのお客様のシステムは初めてだった。Aさんは2004年の中頃くらいに中途入社されたベテラン。他2人はそのお客様の業務経験者だった。
Windowsプラットフォームで、OracleとC, Java。今回のメンバでJava部分の開発は当時1年目だった自分一人。まぁWeb開発といってもPOSTされたデータを受けてOracleに書き込み、同時に外部システムにソケット通信でデータを投げる、今で言うWebAPIの形を取った中継アプリだ。
たださすがに1年目の人間一人だけというのは無理があったので、外注さん(Bさん)を一人お願いしてJava担当分は2人で作業した。

このときはトラブルこそ発生しなかったが、2005年後半の仕事でのごたごたの伏線が張られた仕事でもあった。

お客様の所でもシステム開発要員が居る場合はよくあることと思うのだけれど、「お客様の所のSEでも理解可能なソースコード」を求められるケースがある。今回がこれに該当していて、しかも「お客様の所のSE」というのには弊社の常駐メンバも含まれる。
自社メンバが見てくれるのだから安心感はある・・・筈だったのだけれど。
耳に残っているのが自社メンバからの「作りは変えるなよ」という文句。
そして自社メンバから送られてきたのは、改修するたびに以前のコードがコメントされて、何重にもネストされたコメントだらけの現行ソースコード。これを参考に新規分も作りなさい、というお達し。
それが悪いわけではない。見づらいのは確かだけど、そこはポリシーの問題だ。

自分は、「何だこりゃ？」とまず思った。で、ソースコードも読んでみたのだけれど・・・。そもそもそのお客様のシステム自体が初めてで、どういう類のアプリケーションなのかも理解していなかった為、現行ソースの理解などできよう筈もない。
結局ほぼ現行ソースは棚上げにして、(さらにもう一人入ってくれた)Cさんにクラス設計を担当して貰い、実装をJava担当のBさんと2人で実装した。設計書はAさんが書いてくれていた。その流れで、単体テスト項目もAさんに書いて貰った。
そしてJavaの一部機能は、お客様のSEのD様も実装していた。

当時お客様のSEのD様と、常駐していた自社メンバの間でJavaのソースについて如何なる会話が交わされていたのかは知らないけれど、すくなくともD様にとっては、てっきり現行と同じ作りのソースが来ると思っていたのに、全然違うクラス構造のソースが来てしまったので相当困惑されたと思う。電話で何度もD様から、今回のクラス構造ではD様の担当分をどうコーディングすればよいのか問い合わせが来て、その度に1年目の自分では対応しきれなくてAさんに代わって貰ったりした。そしてプロジェクトが終わった後、常駐していた自社メンバの一人から「だから作りは変えるなって言っただろう」というような言葉を聞いた気がする。

この時、「お客様の理解できないソースコードは作ってはならない」というのを覚えたのだが、同時にお客様（と自社の常駐メンバ）に萎縮してしまった。お客様のSEが絶対で、少しでもお客様側のSEが眉をひそめるようなソースコードはNG、という意識が植え付けられてしまった。つまり、お客様のSEと自社の常駐メンバが「怒らせては/怒られてはならない、大人/先生」という存在に自分の中ではなってしまった。
実際のところは、お客様のSEとしてはむしろ新しい作りを（きちんと納得できれば）歓迎する方向だったらしい。自分が勝手にそう思いこんでしまっていただけのようだ。今となれば。

自分の中での勘違いに基づく萎縮が、2005年後半の仕事のごたごたの伏線となる。

2005年後半-2006年前半の後悔まみれの仕事

この仕事はぶっちゃけ盛大に人から怒鳴られた初めての仕事だったわけだけど、今までの3年間ほど何故怒鳴られたのかが分からなかった。ここ1ヶ月ほど適応障害の関係で自分の人生を棚卸ししたりしていて、ようやく分かってきた。

例のお客様のところで、このときはSESとして常駐メンバと一緒に張り付いて作業した。
担当部分は前回と同様に、Windows,Oracle,JavaでのWebAPI的な中継アプリで新規開発。一部HTML画面有り。そして、このときは外注さん(Eさん)に手伝って貰った。Eさんはベテランの方で、Javaでは主にStrutsを使ったWeb開発をこなしていたらしい。今回はそういったフレームワークなど使わない開発ということで最初は戸惑っていたようだったがすぐ慣れたようであった。自分達は内部設計からコーディング、単体テスト、結合テストまでを担当した。

Eさんは貸与されたクライアントPCの遅さでよく文句を言っていた。お客様の所ではJavaの開発にIDEを使わず、テキストエディタとMakeコマンドでのコンパイルを行っていた。EさんはずっとEclipseを用いた開発をしていたらしく、どうにかクライアントPCにEclipseを入れられたものの、256MBのメモリでJavaのAPサーバも動かさなければならず、相当フラストレーションが溜まった事だろうと思う。これについてはその後改善されつつあるようで、512MB-1GB越えの増設メモリなどがちゃんと確保されるようになった。開発こそEclipseを使えたが、結合テスト以降の開発サーバでのコンパイルは依然としてMakefileだった。
当時の自分にはAntのbuild.xmlを書くだけのスキルは無かったし、自社の常駐メンバはそもそも「そういうものだ」という考えで、Antという存在すら知らないか、知っていても使えない・使わない(=お客様を説得するのに過去失敗した経験があるらしい)ようだった。

Eさんはよく、「普通はこんな作りしないよ」と言っていた。それを聞く度に申し訳ない気持ちで一杯になった。Eさんの言う「普通」は、Strutsを用いたWebシステムで、EclipseやEclipse上のプラグインを活用した世界の「普通」だった。
一方こちらの世界は、2000年当時に構築された時点で世界が止まっていた。テキストエディタの開発、デバッグはデバッグprintで。コンパイルはMakefileか手動でのjavacコマンド。
HTMLもJSPなど使えず、Servletクラスの中でHTMLタグを文字列連結して出力していた。
業務ロジックの詳細まで内部設計に書き、内部設計の章立てや構成を実際のJavaのクラス構造と摺り合わせ、さらにお客様側のSEにそれを説明するのに頭を捻った。

2005-2006年当時、既にStrutsを用いたMVC構成は一般的になり、JSPは普通に使われていた。
ところが、「現行JSPを使っていないから、そのソースコードにお客様が慣れているから」という理由でJSPは使えず、HTML画面は現行と同様にHTMLタグの文字列連結、出力というやり方でやる事になった。
Eさんが反対していたのは覚えている。
自分も、反対した「フリをした」のは覚えている。
でも結局お客様のSEの要望と、自社の常駐メンバからの意見でJSPは使わない事になった。
かなり厭な気分だったのを覚えている。自分としては「あり得ないだろう」という判断で自分としては明らかにJSPでやった方が手間がかからないことは確実だった。特に難しいJSPタグを自作するような場面もない。基本のJSPタグだけでどうにかなる(Strutsの提供する補助JSPタグも不要だったろう)程度のHTML画面だった。
でも、JSPは使わない事になった。
多分理論ではなく感情が大きな理由だったのだろう。
お客様としてはこれまでServlet内でのHTMLべた書きのソースがあるので、徒に方針を変えるわけにはいかなかったのかも知れない。
自社の常駐メンバとしては、その中に過去やはりEclipseやJSPなど世間一般のやり方をお客様の所に導入しようとして失敗した方が居たのだが、その人の感情もあったのかもしれない。過去自分はそれで痛い目に会ったのだから、今さら止めておけ、と。

自分はJSPを使いたい、でも絶対であるお客様側のSEや自社の常駐メンバが使うなと言っている。
自分は、本来味方するべき外注のEさんではなく、お客様と自社の常駐メンバに尻尾を振った。

どういう理由でEさんにそれを伝え、説得したのか覚えていない。
自分自身納得できていない決定事項を、どうして伝え、説得できようか。しかもEさんは自分より数十年も経験を積んだベテランなのだ。たかだか2年目の自分がどうして正当な理由を見つけられよう。だって本当はEさんの言うとおりJSPを使いたかったのだから。
最後は自分はこう言ったような記憶がある。
「すみません、でもこれがここのやり方なんです。」
最低だ。巫山戯ている。自分はどっちの味方だったんだ。全然理論的じゃない。ただただお客様と自社の常駐メンバの言う事をEさんに伝言するだけの糸電話だった。

書いていて思い出したが、Eさんにこんな科白を言われたような気がする。
「向こうの言い分はわかったよ。で、あなたはどうしたいのよ？あなたはどういうシステムを作りたいの？」
全く以てその通りだった。自分はひたすらお客側のSEと自社の常駐メンバに萎縮し、ご機嫌を伺っていただけだった。言われるままにしていただけだった。そして、上の質問に対して自分はまともに答えられなかった。答えを用意していなかった。そんなものは考えた事すらなかった。

自分はどういうシステムを作りたいのか。
そんな事はその時は全く考えていなかった。強いて言えば、
「お客様と自社の常駐メンバが厭な顔をしないシステムを作りたい」
というのが本音だったのだろう。萎縮して、絶対的とし、決して逆らってはならない畏怖すべき対象だった。

仕事の半ばから、Eさんが怖くなった。「お前はどうしたいんだ」と問われるのが怖かった。お客様のSEと自社の常駐メンバを怒らせてはならないのは当然として、Eさんも外の人として「上手く」つきあう必要があったが、既にこの時点で破綻していたのだろう。
Eさんも仕事の後半から、自分にその類の問いかけはしなくなったような気がする。
自分がただ糸電話としてお客と常駐メンバの要望を伝えると、ただ「・・・そう。わかりました。」とだけ言って作業にとりかかったような気がする。

こんなこともあった。そのアプリではHibernateなどのO/Rマッパーは使用せず、JDBCを直接呼んでいた。SQLもJavaのソースコード中にベタで書いていた。Eさんは、「ソースコード中にSQLを直接書くよりは、XMLなりで外出しにした方が良いですよ。」と言い、簡単なXMLにSQLを埋め込めるように調整してくれて、コーディング作業を進めていた。
自分は、確かに、お客様に「Eさんの提案でXMLで外出しにします」と言った筈だった。少なくとも作りとしてはそれなりに重要な部分になるし、Eさんがその部分を作ってくれたコーディング開始時点ではまだ関係は穏やかだったので伝えた筈だ。
しかしコーディング終盤、正確には覚えていないがとにかく一通り出来上がった時点で、お客様からNGが出た。理由はよく覚えていないのだが、お客様なりの理由があった事は確かだ。お客様側のSEのリーダーが直にEさんにお願いしていった。
Eさんはかなり抵抗したようだが、結局最後は折れた。
目の前でそのやりとりが行われていたのだが、詳細は覚えていない。ただ戦々恐々として、生きた心地がしなかった。「なんで？最初の頃に確かにお客様に伝えて、了承もらえた筈なのになんで今頃・・・」という疑問と、Eさんへの申し訳なさと、Eさんがこの後どういう質問を自分にするのか、どう答えるのかで頭がいっぱいだった。
そのやりとりの後、Eさんが自分に何をどう言ったのか覚えていない。
自分は、Eさんの目をみることが出来ず、小声で震えながら「すみません。」と言うのが精一杯だったような気がする。

コーディング終盤、既に自分はEさんとまともに会話できなくなっていた。Eさんの契約が切れる締め切りまであと何日かを、トイレで籠もる度に携帯を開いて確認する毎日が続いていた。

打ち合わせでもトラブルがあった。
自分はどちらかというと頭の回転は遅い方で、「これこれこうです。」と言われてからその真意を把握したり、疑問を呈するまでにかなり時間を要する。フランスのユーモアでは「階段で気づく人」という言い方があって、パーティ会場で誰かが面白いユーモアを披露する。周りのみんなは直ぐにユーモアの本意に気づいて笑うのだが、「階段で気づく人」はその場では気づけない。とりあえずみんなにつられて笑う。パーティが終わり、会場から階段を下りる時になって初めて「あ、あの時のアレはこういう意味だったのか」と気が付くので「階段で気づく人」。
自分はまさにこのタイプ。人の発言の真意や、それに対する自分なりの疑問が出てくるのは大抵会議が終わった後や、非道い場合は家に帰って風呂に入っている時だったりする。

そして、システム開発における打ち合わせというのにその時点での自分はまだまだ不慣れだったように思う。というか、何を質問すればよいのかすら分からない部分が多かった。
幾つか疑問や意見が出てきても、みんなが揃っている場で発言する事に対し気後れがあった。自社の常駐メンバと意見が衝突するのが厭だった。Eさんと意見が衝突するのが厭だった。
会議中では八方美人に徹した。
では疑問や意見はどう処理したか？
会議が終わって、常駐メンバやEさんが会議室から出て行った後、自分達も戻ろうとするお客側SEをつかまえて疑問を解決したり、意見を通して貰った。
なにしろ長い会議が終わってようやく戻れるのだから、みんな浮き足立っている。その隙を突こうとしたわけだ。
最低だ。
心理学的には有効な作戦ではあるが、システム開発において取るべき手法ではない。
そして、遅れて自席に戻り、Eさんに「さっき戻り際に確認したのですが・・・」と糸電話の口が動く。
何度かそれが続いた後、怒鳴られた。
「そういうのは打ち合わせの最中に言ってくれよ！」と。
当然だ。自分がやった事は不意打ちに等しい。Eさんに対しては誠意ある対応とは言えない。

基本的に自分は趣味のプログラミングが高じて現在の会社に入ったわけだが、「システム開発」においてどういうセンスが必要か、という点について今でも悩んでいる。プログラミング言語であったりXMLやHTTPやマルチスレッドなどの要素技術に対するセンスが必要か、と問われると有るにこしたことは無いと思うが、今までの仕事で感じるのは「データの意味や出所、そしてタイミング」に対するセンスが必要な気もする。
例えばあるデータがある。この意味は何か？どこから入力されるのか、誰がいつ入力するのか？タイミングは？一度だけか、頻繁に変更されるのか？変更する人間は必ず一人だけか？同時に複数から異なる値で変更される可能性はあるのか？変更履歴は管理する必要はあるか？その場合に「誰が」や「いつ」はどの程度詳細に残すべきか？
これはプログラミングなどの技術的なセンスというよりは、もっと広い意味での「業務のシステム化」に対するセンスというような気がする。データに対するINとOUT、そしてそのタイミングや多重度について考えなければならない。
「システム開発」のベテランとして、最初の頃にちらりと書いたAさんはまさにこれが得意中の得意で今も現在進行形で敬意を表するのだけれど、頭の中でDBのレコードがシステム全体のI/Oを含めてエミュレーションできているとしか思えない洞察を良く披露する。誰もがそれを聞くと、「ああ・・・それは考えていなかったけど、あり得ますね。」と感嘆する。
自分としては「システムエンジニア」においてより重要なのはこうしたセンスではないかと考えている。ぶっちゃけ個別の要素技術なんぞその時その時きちんと理解できれば良いだけの話で、お客様にとってはシステムの入力と出力がきちんと安定して動作する事のほうが重要。そういう局面では、Aさんのような洞察力が必要だろう。

・・・というのも2007年頃にようやく思い至った次第で。2005-6年当時はまだそういう事には考えが至らない。「プログラミングの延長」という感覚が随分残っていた気がする。

話を戻すと、コーディング終盤に至り自分とEさんとの信頼関係は破綻していたと思う。
そんな中、スケジュール調整の打ち合わせの席だったか。
自分が分担や分量の調整をまず考え、お客様に提示する流れだった。
Eさんが自分を怒鳴った。
何を言われたのか覚えていない。
それと同じ日だったか、別の日だったかは覚えていないが、とにかく打ち合わせが終わって自席に戻って、例の如く糸電話の口が何かしゃべった後、また怒鳴られた。
これも何を言われたのか正確には覚えていない。
ただ、
「それがプロのすることか！」
と言われた事は記憶している。
何も答えられなかった、言い返せなかった、なぜならそもそも何も考えていなかったから。
とにかくお客様と常駐メンバを絶対視し、彼らが厭な顔をしないシステムを作るのを優先した。
自分はどうしたいのか、何を作りたいのか、どう改善したいのか。
全部押さえつけて、考えないようにした。それをすると、お客様のSEや自社の常駐メンバからまた「だから作りを変えるなと言っただろう」と言われるから、と。
自分は結局、Eさんの事をこれっぽっちも大切にしていなかった。口先ではEさんの意見を尊重するようなそぶりをするが、最終的にはお客様側のSEと自社の常駐メンバの要望を糸電話で押しつける。

その時は、何も考えられなくなっていた。頭が真っ白になって何を言おうか頭に浮かばず、Eさんとまともに会話できなくなっていた。
八方美人も破綻していた。

確かにマネジメント、というか管理面での問題はあったと思う。そもそも2年目に分量の見積もりや分担や内部スケジュール調整というのも至らない点はあったのだろう。
しかしそれはそれとして、自分があまりにもEさんを蔑ろにした事は否定できないと思う。
この仕事で「よいこ」を演じようとしたとき、自分は最終的に「お客様と自社の常駐メンバ」に対して「よいこ」を演じようとした。Eさんに対しても「よいこ」を演じようとしたが、結局それは破綻した。

幼稚園〜小学生時代は、勉強ができれば「よいこ」だった。自分の世界を構築して自分のペースで知識を蓄え、与えられた問題に回答していれば「よいこ」として認めて貰えた。自分で考えた回答が「よいこ」の根拠になった。

この仕事では、自分で考えたソースコードは「よいこ」の根拠にならなかった。
自分で考えたソースコードは、お客様側のSEや自社の常駐メンバから「作りが分からない」「なんで作りを変える必要があるの」と言われた。
多分その辺りで、既に破綻していたのだろう。
高校・大学時代は「よいこ」になろうという対象自体がなかった。人間関係が希薄で、集団からはぐれて隅っこで自分のペースで勉強なりプログラミングをしていれば良かった。
会社に入り、評価という形で再び「よいこ」を演じる必要が生じた。
そしてそれは今までのやり方で自分の世界を構築するだけでは「よいこ」とは見られない世界だった。

・・・もう、充分だろう。
高校・大学時代の平和があって初めて、ここまで分析する事が出来た。
自分が生きてきた過程の殆どの「何故そうしたのか」「何故そうなったのか」を解説できてしまった。
自分を動かしてきたギミック、仕組みをようやく、解明できた。

これからを、考えないと。