Sier on yusuiked's blog

ディフェンシブな人たち

yusuiked@gmail.com (yusuiked) — Wed, 02 Feb 2011 10:49:21 +0900

先日，いつもの通りもやもやした気持ちをTwitterにpostしたところ，反応をいただいたので少し補足をしたいと思います。
経緯はこちら↓
そんなに悪い事ばっかりじゃないと思う - おろかな日々
日記まで書いていただいてありがとうございます。
まず，事の発端となった発言について，かなり煽った表現であることは間違いないです。人によっては見過ごせない表現でしたね。ただ，あえてああいう表現にしたのは意図はありました。それがこちら。

22:48 @rinta100 極論ですね。私はどちらかというと，疑ってかかるのではなくわかろうとする，責任範囲を広げようとする姿勢や努力をすべきではないか，という意図でした。 [in reply to rinta100]

日記の中で，id:Rintaさんの仰っていることは，私も正しいと思います。常々，そうありたい，そうあらねばと思って生きています。ただ，私の狭い観測範囲では，そう考えて行動できる人の方が少数派です。
id:Rintaさんも仰っているとおり，

まあ，程度の問題はあるんだよ。だけど，私はこれが全部ダメとは思わない。

多分，私が吐き出したかったのは，この部分なのかな，と思っています。つまり，程度が低すぎやしないかと。
挙げてくださった，以下の観点，

物事に対して客観的な事実とそれ以外を分けてとらえる姿勢を持つこと
自分の責任範囲を適正化すること
失敗を避ける努力をすること

これらは，別にSIerに限らず，何の仕事を行う上でも必須の意識だと思います。これらのバランスが崩れれば，結局のところ，

自分の仕事が増えてアップアップになる
人の仕事が増えて迷惑がかかる

という結果が待っています。
その文脈で，あえてSIer脳と言ったのは，「必要以上にディフェンシブになっている人」がSIerには多いと（私は）感じるのです。SIerのビジネスモデル上，責任範囲を狭くした方が結果的には得ですから，長く経験していれば自ずとそういう処世術を身に着けていきますし，間違いだとは思いません。ただそれが度を過ぎて，顧客に対する価値を落としたり，周囲のメンバーに対して迷惑をかけている，という意識に欠ける人が多いな，という感覚を受ける機会が多いです。
また，この「ディフェンシブになりすぎている人」たちが得てして，責任範囲を広げようとする努力，周りに対して協力しようとする意識もないと日頃感じることが多かったので，先日のTweetに至ったわけです。
あまり傾向で物を話すのは良くないと思ってはいますが，そういう人たちがこの「SI業界」の閉塞感を助長しているのではないかと思えてならないのです。
もちろん，適正な理由があるなら排除すべき，というご意見にも同意します。さらに言うなら，それを説明すべき。説明するには，材料が要ります。
id:Rintaさんも最後にそう括っておられます。

“意思決定するからには，もうちょっと調査して材料そろえてからにしたいものです。”

もし，その時点で何か足りないものがあって，リスクが大きすぎるのであれば，その時点で妥当な判断をすべきです。ただそれならあとでそれを補う努力はすべきだし，それをしない人が大半。私の今いる現場でも，上記のような「必要以上にディフェンシブな人」が大半です。その結果，いつまでも自分たちの得意な領域，できる範囲の仕事に固執して，顧客の要求からどんどん外れていき，仕事がどんどんなくなっていく現実を目の当たりにしています。
こんなんじゃ，いつまでも変わらないし，自分の時間がそれほど残されているわけじゃない。本来であれば，そこを変える努力，施策を考えて実行すべきだとは思いますが，自分の能力と残された時間，それに変える必要がある対象の大きさを天秤にかけて，私にはそこまで時間をかけられないと思えてしまうのです。
ここ数年，私の頭の中でそんな気持ちがグルグルと巡っています。

マネージャもコード書けた方が良いよね

yusuiked@gmail.com (yusuiked) — Sat, 29 Jan 2011 02:56:34 +0900

そして、Excelでチマチマと進捗管理したり、部門別の損益計算書をExcelで手集計したりするのはもはや時代遅れ。
特に昨今は工事進行基準やらJ-SOXやらで、プロジェクトマネジメントの精度の高さを要求させられている。
マネジメントもツールによる自動化が必須の時代になっているのではないか？
どの業界でも管理・設計支援ツールの重要性が増している: プログラマの思索

最近の流れでは自称「上流工程」ができる人よりも，自分で企画から実装までできるエンジニアの価値が上がっているけれど，同様に自分でマネジメントの情報を収集するために，ツールによる自動化やコードが書けるマネージャの価値が上がってくるんではないだろうか。

-—-

Software Designの特集「ITエンジニア生き残りの条件」を読んだ

yusuiked@gmail.com (yusuiked) — Sun, 28 Nov 2010 23:10:34 +0900

見出しに惹かれたので購入して読んでみました。

Software Design (ソフトウェアデザイン) 2010年 12月号 [雑誌]

出版社/メーカー: 技術評論社
発売日: 2010/11/18
メディア: 雑誌
購入: 4人クリック: 80回
この商品を含むブログ (15件) を見る

僕も30歳を前にして今後の身の振り方について考えることが多くなってきたので、食い入るように読みました。
内容は、システム開発の潮流がスクラッチ開発から、パッケージ／クラウド等の既存のサービスを利用する方向へユーザ企業の考えがシフトしてきたこと、さらにはリーマンショックの影響から、ユーザ企業のIT投資予算が抑えられるようになって、オフショア開発の利用が進んでSIゼネコン構造が崩れさろうとしている、といったところから、エンジニアのニーズが減少し、特にアラフォー世代の今後のキャリアについて岐路に立たされていることが書かれています。

書かれていることが実感として感じられるような状況に

僕が今常駐している企業でも、オフショア開発を盾にした要員の大幅な単価値下げ要求や、常駐している保守要員でのスクラッチ開発ではなくパッケージの利用、といった方向へ顧客の考え方がシフトしてきているので、本誌で書かれていることを実感として感じています。今までと同じような仕事のやり方では、3年後どころか来年度すら危うい、という感覚を覚えるのですが、悲しいかな今まで数十年とオンサイトによる保守開発に慣れたメンバーや現在のPMからは、現状がどういう危機にあるのかすら認識しようとはしていないです。むしろ目を背けようとしている感すら伺えます。

インターネット系企業の勢い

一方で、本誌の記事中では、楽天、DeNA、GREE、サイバーエージェントなどのインターネット系企業が自社でエンジニアを抱えてひた走っている、といったことを伝えています。こうした企業では、自分で「手を動かして」サービスを作れる優秀なエンジニアを多数集めて、短期間でサービスをガンガン出していく、というスタイルで仕事が行われています。ここでござ先輩が言っていることに同意しますが、自分で「手を動かす」ことを価値として認められないSIゼネコン業界からの転身は、難しいこと（特に管理／手配師業務が主だった場合）だと思います。

この場にとどまっている理由はない

こうした状況の中、自分はどうあるべきか、といったことを最近常日頃考えています。僕が今行っている業務は、実質手配師のそのもので、到底エンジニアとしてのスキルが磨けている訳ではありません。このままぼーっと生きていれば、記事中のアラフォーエンジニアそのものになってしまうのはわかりきっています。
もちろん、この沈み行く船に乗ったまま朽ちるつもりはないので、自分なりに自分の明日に向けて動き出しています。

どうするか

手を動かし（コードを書き）、足を動かし（勉強会へ行き）、口を動かす（人へ発信する）。
これをどんどんやっていかなければいけないと思っています。

-—-

「僕はシステムの人間じゃないし」

yusuiked@gmail.com (yusuiked) — Wed, 03 Jun 2009 18:01:18 +0900

いや、某企業の情報システム部の方の発言なんですが。

元々営業畑出身らしく、言葉の端々に「所詮ITでしょ？」という意識がはっきりと感じられる。本人は無意識なんだろうけど。むしろそれを長所とすら考えている節がある。*1
立場がシステムを利用する側のエンドユーザーであるならその言い分も分かるんですけど、まがりなりにもIT部門担当者で、その企業のIT戦略における代表な訳です。システムが生み出す効果・価値とそれを運用・保守していくコストを正しく判断できていないと自分から言っているようなものだし、そんな人間を抱えている企業にとっては、損失でしかない。
あなたはエンドユーザーですか？そうじゃないですよね？じゃあ何のためにあなたはそこに居るんですか？と小一時間（ry

他のベンダー担当者とのやり取りでも

「設計書を読んでもさっぱり理解できない、もっと分かりやすく書け」とゴネまくったりもしているよう。だけどその前に、「あなた理解しようとする気ありますか？」と。
ベンダー側の「お客様に対する理解（∋業務知識）」が重要なのはごもっともですが、発注側の「システムに対する理解」も深めていかないと、本当の意味で価値を生み出す、使う人に喜んでもらえるシステムなんて作れるわけがない。
発注側がお客様気分で胡坐をかいていてはいけないと思うのです。自分たちが使うシステムなんですから。

というわけで

僕は、技術的な基盤がある人の「業務知識は重要」には積極的に耳を傾けたいと思うけど、技術を軽んじている（またはバックボーンのない）人の「業務知識の方が重要」とか「コミュニケーションの方が重要」は信用しないようにしている。*2

*1:ユーザー側に立っていますよ的な意味で

*2:※ただしエンドユーザーは除く

-—-

これは同意せざるを得ない

yusuiked@gmail.com (yusuiked) — Sun, 31 May 2009 15:16:39 +0900

エンジニアの未来サミットに行ってきた - 研究日誌
途中の会場アンケートで、SIerに勤めてる人ってのは激少だった。SEってのだってこういうコミュニティとは技術という面で強固につながっててもおかしくないはずなのに、実感としても、全然つながってるようには見えない。一応俺もそのSIerの中の人なんだけど、やっぱ技術としても方向性が違うのは感じる。会社には、行っても楽しめそうな人は・・・どうやら居ない。

平たく言うと、一人でいきましたよと。

基本大勢の関心事は結局、顧客に売り込みやすいBuzz Wordsと要件定義、設計なんだろう。それこそセッション中にもあったけど、これは無くならないだろうし絶対に今後も必要なことだろうが、俺はもういいやーと思ってる所があるし、やりたい人がやってよと。
まあこの業界、プログラミング一切できないSEってのも居るんだからやっぱりなんか違う。そんなこんなの思いもあって会社倒産に合わせてSI業界を辞めるわけですが。てか最初からSIやりたかったわけじゃないし・・・。技術主眼で就活すると、微妙に違っててもある程度は大丈夫なもんだね！

狂おしいほど同意。
自分もコミュニティや勉強会に行くけど、会社にはそういったものがあることすら知らない人ばかりで、知ったとしても「何それ？おいしいの？」という人ばかりです。
実際に何度か一緒に行こうと声をかけたことがあるけれど、「勉強会？なんで休みにそんなの行ってるの？お前変わった奴だなー」と言われ一蹴。
つくづく彼らはエンジニアではなく、サラリーマンなんだと感じたことがあります。

そんな環境に長い時間身を置くこともない。早いとこ抜け出さなきゃ。

-—-

エンジニアの未来サミットをUstreamで見た

yusuiked@gmail.com (yusuiked) — Sat, 23 May 2009 00:20:49 +0900

去年は参加したこのイベント、今年は参加は見送りました。開催概要を読んで、自分の置かれている状況とイベントのテーマにだいぶギャップを感じたので。
が、当日になったらやっぱり気になってしまったので素直にUstreamで視聴することに。といっても第2部だけなんですが。

第二部：弾 vs. 個性派エンジニア ─サバイバル討論

「新20％ルール」を掲げ，不況下のIT業界でのサバイバル術を説く小飼弾氏の元に，第一線で活躍するエンジニアたちが論戦を挑みます。激論の中に現代を生き抜くヒントは見いだせるのか？
パネラー（敬称略）：小飼弾，閑歳孝子，米林正明，山崎徳之，井上恭輔，高井直人，モデレータ：馮富久（技術評論社）

個人的な感想としては、技術や勉強法、自分の価値やそれを周りに主張（伝える）していくことなどが話題の中心で、今回の方が前回よりもエンジニア個人としての生き方や考え方にフォーカスが当たった内容だったかなと思います。なので私はお話を聞いていてだいぶよい刺激を受けました。やっぱり行けばよかったかな。

前回と今回で共通して言えることですが、やはり「自重しない」「アウトプット重要」「横のつながり重要*1」がこれから真のエンジニアとして生きていくには重要だなぁと改めて感じたというか。そして、これらを重要だと思えば思うほど、自分の身の回りの環境とのギャップを感じ、SI業界で生きていくことのしんどさというか、自分はマイノリティなのだ、ということを痛切に感じました。
ホントに居ないもの、自分の周りに。こういうイベント行ったり、勉強会行ったり、仕事じゃないコード書いたり、Blog書いたりする人。

早くゴルフ憶えて協力会社*2の社長とかと知り合いになれ、だとか、出来ないことはさっさと諦めて出来る人に擦りつけろ、とか言う上司はいるけど。
そのこと自体は間違いではないのかもしれないけど、それを技術者に対して言うのは間違ってるよなやっぱり。

私は環境が人を作る、というのは少なからずあると思っていて、そういう意味でこのまま今の環境に身を置くことは、今後自分がエンジニアとして生きていくにあたってプラスになることはもうないと感じています。遅かれ早かれ動き出すことにはなるだろうな。

*1:コミュニティ活動しかり、会社の中、外の繋がり

*2:もちろん下請け

-—-

20年先のシステムなんて実はどうでもいいことに早く気づけ

yusuiked@gmail.com (yusuiked) — Tue, 17 Feb 2009 01:05:21 +0900

タイトルはホッテントリメーカーより．

IT戦略を議論するときには、20年先を見据えた長期的な視点を入れて考えます。つまり「20年先」に世の中がどう変わっているか、お客さまがどう変わっているかをイメージしてシステムを考えるわけです。

　“現時点”を議論の出発点にしたのでは、個人的にも組織的にも、また技術的にも現在の延長となり、自由な考えができません。“5年先”でも同じでしょう。

　しかし“20年先”とすれば、「現状では……」という拘束を受けることなく、自由に考えること・議論することができるのです。現在、私どものビジネスで主流となっている対面営業もこれから相当変わってくるでしょう。インターネットももっと高機能になるはずです。自由な発想、議論なしに未来を描くことはできないのです。

日本のSI業界から斬新な発想や独自の仕組みが出てこない理由が，こういうところにあると思うのです．

ビジネスモデルの提案をしてください

個人的な話で恐縮ですが，昔，新人研修だったか，「Felicaを使った面白いビジネスモデルを考えてください」という課題を出されたことがありました．課題を出した講師は10年目くらいのエンジニアでしたが，どちらかというと営業寄りのスタンスで，新規ビジネスを提案する立場で仕事をしている人でした．
課題を出された側は，みんな新人ということもあって目の前の課題に一生懸命取り組んだけれど，目を引くような提案が一朝一夕で出るわけもなく，どこかで聞いたことがあるような発表ばかりが続き，研修は終わりました．その時，講師はこう言っていました．
「若い年代のフレッシュな感覚で，自由に考えてください．」

今思い返せば，出てくるはずがない．だって斬新な発想の基となる素材*1が何もないんだもの．
どうもビジネス寄りの考え方をする人達って，普段からネタがないかアンテナを張りめぐらせているからなのかわからないけど，「斬新なアイデア」というのは何もないところからふとしたきっかけでポッと湧き出てくるものと思っているらしい．

発想は引き出しの中のネタの組み合わせ

先のことを考えたり，これから起こりうることを想定したりすることは重要だという点については言わずもがな，ましてや経営の視点から見れば当たり前のことだと思います．
ただ，じゃあどうするかという段階での具体的なアイデアというのは，「今ある引き出し」の中のネタの組み合わせでしかない．
どんな発明家だって，自分の経験や知識という「引き出し」の中から様々なものを組み合わせて新しい発明をするわけで，全くの無から斬新な発明が生まれるわけじゃない．*2
じゃあその「引き出し」って？SI業界に身を置く私の立場で言えば，私は技術者の矜持でもある「技術」に他ならないと思っています．そしてその「引き出し」を広げ，「引き出し」にネタを詰め込んでいく作業を続けることこそが，斬新な発想や独自の仕組みを生み出していくのだと思います．
残念ながら日本のSI業界においては，この「引き出し」を広げてネタを詰め込んでいく作業が軽視されすぎているのではないか．結果として，日本独自のプロダクトやサービスが生まれてこない要因になっているんじゃないかと思うのです．
今色々詰め込んでも，数年経ったら陳腐化するから覚えても意味がない，とか歳を取ると覚えきれない，とかこの業界に居るとよく聞く話です．でもそれって，要は諦めたってことでしょ？*3と．
彼らは，id:higayasuoさんが言っていた

の予備軍だと思います.

エンジニアの未来サミットでid:naoyaさんは，

「世の中を変えるようなプロダクトを作るなら，技術を知らないといけない．知らなければ発想ができない」

と言っていました．私も全くそう思います．英語学習で言ってしまえば，英単語のボキャブラリが何にもないのに長文書けって言っているようなものです．発想のしようがない．

現状認識することで，発想の限界がある？

また，あの時同じく登壇していた学生から，「知っていることで逆に発想の限界を感じるのではないか」という正に上の引用元と同じような趣旨の意見があったけど，それに対してはid:hyoshiokさんが「できるかできないかはやってみないと分からない．できないかも、という限界は自分が決めている」と言っていました．
上記の引用で言えば，「20年先」と想定することで，現状から20年先の2点を線で結んだ範囲の中で変化をイメージする，と言っています*4が，そうすることで逆に発想の限界を決めてしまっているのでは？と思ってしまいます．イメージの範囲外なんて20年先だったら平気で起こりうる．例えばインターネットに取って代わる別の概念・手段が登場してきたら？RDBに取って代わるデータストアが出てきたら？
これが50年だろうが100年だろうが一緒です．むしろ先に設定すればするほど想像の範疇を超えていく確率が高くなるわけで，予言者の才能があれば別ですが，結局先のことを想定しようとしてもとてもじゃないけど想定しきれるわけがない．*5
だったら，その時々の変化を受け入れて，細かく対応していくほかないと思うのです．世の中の環境が変わることもあるだろうし，前提条件が変わることもある．でも短いスパンであれば，想定もブレが少なくて済む．
今ある「引き出し」の中で，ベストだと思われる組み合わせを見つけ出す，世に問う，フィードバックを得る．この繰り返しなんではないかと思うのです．自由な考えができないのは，ただ「引き出し」が足りないだけなんだと．

「引き出し」の中のネタは技術者の財産

だから私は，常に「引き出し」を広げ，その中にネタを詰め込み続けていきたい．それを続けることは並大抵のことじゃないのは分かっているつもり．けれど，私はそれを今のところ苦とは思っていない．むしろ楽しいとさえ思う．それはやっぱり好きだからなんだと思う．
結局，好きこそ物の上手なれとはよく言ったもので，そうじゃないと続けていくのは難しいでしょ．

*1:ここでは経験だったり，知識だったりする

*2:稀にそういう天才な人もいるかもしれませんが

*3:要は勇気が（ry

*4:ここで言っているのは，予算だったり，政治的な縛りだったりする拘束のことを言っている気もするけど

*5:推測でしかないけど引用元の担当者の方はシステム系の出身かな？ウォーターフォール的な考えが根底にある気がする

-—-

なんだか笑えない

yusuiked@gmail.com (yusuiked) — Wed, 31 Dec 2008 00:23:55 +0900

http://d.hatena.ne.jp/JavaBlack/20081231/p1

「現場のSE, PGが考えるデスマる条件とは」

自分の立場で1つ1つ確認してみた．ほぼ当てはまるんですけどｗ
思うことをつらつらと書いてみる．

ウォーターフォール・・・○
- 自分が見聞きした限りで，これ以外の進め方をしているSIプロジェクトを知らない．*1顧客フォーマットの開発計画書もこれが前提になっていて，要件定義，外部設計，内部設計，製造，テスト，移行，稼動って欄があって，それぞれに上長決裁欄にハンコが押されると，お金が入ってくる仕組み．だから戻りは“ありえない”という前提で物事が進む．でも現実はそれとは乖離しているからデスマる．
- 反復型開発とかウォーターフォール以外の開発プロセスでSIを行っているプロジェクトって，契約面では顧客とどう合意をとっているのだろう？機能とか要件単位（TracとかRedmineのチケット単位？）とか？自分ところの状況で言えば，顧客は機能単位とかの価格が高価なのか安価なのかなんて判断できないから，結局「これだけの予算を用意したから，その枠内であの機能とこの機能は必須で，これもつけてね」なんて感じで要求してきて，あとはそれと開発側の思惑とのせめぎ合い，なんてことばっかりで，他の開発モデルでやらせてくれっていってもコスト面で他社と比較できないから無理です，って言われるのが関の山なんですよね．顧客は予算内にやりたいことを盛り込んでできるだけ低コストに，ということが全てだから．その後の拡張性や保守性なんてのは二の次．
低スキル - 大人数開発・・・○
- 人数×単価が売り上げというビジネスモデルなところは，すべからくこれは当てはまると思うんですよね．ってことはSIという業態≒デスマ？低スキルな人は，1人月どころかマイナスに作用する*2人もいる．そういう人を派遣している下請け会社は，自社に篭らせても金食い虫になるだけなので，なんとかうまいことどこかに潜り込ませて1円でも稼いでくれば御の字，と思っている．元請けは設計・実装のスキルを磨くことよりも，そういう人を何とか上手く使って結果を出すことを求められる．こう見ると，最初から失敗するのは目に見えている気がする．
人月単価・・・○
- 上に同じ．
多重下請け構造・・・○
- 上に同じ．
時代遅れのスキル・・・○
- メインフレーム，COBOL，JCL，TSO/ISPF，ADABAS，Natural・・・などなど．マズいと思うのは，自社の新人研修もこれらがカリキュラムになっていること．危機感を持っている子は，自ずと違うことも自分から学習したりするのも稀にいるけど，殆どはこの世界しか教えてもらってないまま30歳，40歳となっていく．30〜40歳の先輩もそれが当たり前と思っているから，特に何か言うわけでもない．団塊の世代が居なくなっても，こういった団塊ジュニア世代が居る限りSI業界はドラスティックには変わらないと僕は思っている．*3
年功序列・・・○
- 技術スキルだけなら，正直言って若い人の方が何倍も高いと思う．けれども，「業務知識」という言葉を盾に，経験年数を積まないと「業務知識」なんて付かないから，経験が豊富＝年功が高い人が上，「業務知識」を知らない単に実装する人が下，という階層構造を上の人が作り上げる．そこに安住するためにね．でも，「業務知識」なんてのは若い人でもやらせれば理解するし，やらせないとわかるはずもない．大体，そんな何年もやらないと理解できないようなことだったら，ユーザ側の若手も業務が理解できないということか？実際に業務こなしているのってユーザの若手じゃないのか？一番難しいのは，そういう業務を実装レベルまで落とし込むのが難しいのであって，結局は“上”の人がそこに安住するために作り出している構造に過ぎない．
「設計工程」と「プログラミング工程」（製造工程）を分割する・・・○
- これも上に同じ．で，いつも違和感を感じるのは，コーディング作業を「製造工程」と呼ぶところ．どこのプロジェクトもそうなのかな？
「上流工程」という名目で時間と資金を浪費・・・○
- これも上に同じ．「上流工程」が完璧になされないと下流で手戻りが発生するから，と世間話や与太話が半分以上を占めるミーティングを何度も行って時間を浪費する．「上流工程」ができる人は単価も高いから資金も浪費する．
PMBOKやITSSが幅をきかす・・・○
- PMOなんてのが最近立ち上がったらしく，やたらと管理資料を作らされる．JavaコードのSTEP数を算出しろなんて依頼も日常茶飯事．
技術者の意見より管理職や営業の意見が優先される・・・○
- お金を動かしているのは我々だ，と思っているのだろうと．
コン猿が大きな顔をする・・・○
- 最近某社が入ってきて，勢力拡大している．やたらとPowerPointで資料を作っている．彼らは見せ方が上手いので，顧客も乗せられて大分お気に入りのよう．
実現可能性も分からないまま無理難題をふっかける顧客・・・○
- それを実現するのがあんたらの仕事でしょ？くらい思っているのだろうとつくづく思う．
しかもそれを断らない担当者・・・△
- これは自分の身を守るためにも心掛けていることではあるけれど，プロジェクトメンバーが満足しているほどかどうかというとわからないので，自戒したい．
鉄筋減らしてコストダウン・・・○
- 予算枠が決まってるから・・・云々．
機能が際限なく追加される・・・○
- 予算の権限がユーザではなくシステム部が持ってたりすると，ザラだ．
意味もなく頻繁に仕様変更・・・○
- 監督省庁の監査が入ったから，絶対に変更しないとダメ，とかザラだ．
しかも納期と予算はそのまま・・・○
- 業務改善命令で期日は決まってるから納期は延ばせない，年度予算もこれだけしかないからこの枠内でなんとかしてくれ，とかザラだ．
さらに人を追加する・・・○
- 管理職の人は人追加すれば終わると本当に思っている．

*1:自分の観測範囲が狭いだけかもしれないけど

*2:周りの人間の作業が増える

*3:数は確実に減るだろうから，緩やかに技術の移行は進むとは思うけど

-—-

似たような人を知っているけど・・・

yusuiked@gmail.com (yusuiked) — Sat, 27 Dec 2008 22:05:20 +0900

http://q.hatena.ne.jp/1230046414

ITコンサルタントを目指したいと思っています。
ITコンサルの業務をこなす上で有用なスキルや資格があれば理由と共にアドバイスいただけませんか？

釣りかもしれないけど，あえて一言．
僕の大学のゼミの同級に同じことを言っていた人が居ました．彼は優秀な人でしたが，システム知識はまったくなく，苦手だしそもそもそんなもの必要ないから勉強しない，とまで言っていました．
その人がどうなったと思いますか？辞めちゃいました．今は全く関係のないことをしています．
まず，なんでITコンサルをやりたいと思ったのか？ってところを聞いてみたい．
お金がたくさん貰えるから？SI業界入っちゃったけどプログラムなんて書きたくないから？
もしそういった理由なら，即刻違う業界へ行った方がよいです．お金がたくさんもらいたかったら，金融・マスコミ・商社，もっと貰えるところがあります．プログラムが書きたくない？あなたの提案した机上の空論を実際に形にする何人もの技術者が，不幸な思いをします．自分だけならまだしも，周りに迷惑をかけないで欲しい．

あなたがなりたいのは，ITコンサルタントじゃなくて，経営コンサルタントじゃないの？

-—-

首を縦に1000回位振りたくなった

yusuiked@gmail.com (yusuiked) — Sun, 09 Nov 2008 14:00:26 +0900

導入、周知、初期学習コストだけじゃん。

導入コストなんて、環境構築手順を確立して、場合によっては自動構築スクリプト化すればさくっと終わる話。

導入ノウハウなんて、みなさんいろんなところで公開してくれているわけだし。

初期学習コストなんて、初めて触る人だけの問題。

それよりも、その後のあらゆるコストの低減のほうが、よほどインパクトが大きい。
元請SIerがTracのような環境を提供できない３つの理由 - なからなLife

人は変化を嫌うもの。

新しいものがいかに作業効率に寄与するか、よりも、それを使う為の学習コストや、

それを運用していくコストのほうにウェイトを置いてしまう。

今までそれで済んできて、それなりに成功を収めたゆえに上のポジションに収まっている人なら、

なおさらのことである。

「所詮手段。何でやってもいいじゃん（否定的な意味で）」

「いまのやり方で十分なこと（と、発言者は勝手に思っていること）を、新しい手段を覚えることに力使うのって違うんじゃない？」
元請SIerがTracのような環境を提供できない３つの理由 - なからなLife

仰るとおりです．
ちょうど今のプロジェクトで，トラブル事例やここ気をつけなさいよ的なTips，あれはあそこにあるよなどの情報を共有するために，PukiWikiを導入しようと試みているのですが，汎用機開発のチームに普及させるのに手間取っています．
彼らは何でもかんでもExcelで仕事したがる世代．

ファイルサーバーに原本があるのにメールに添付して、

原本と添付と別々に更新してあとでマージがたいへんだー、

とか、

最新情報が伝わってこないまま開発進めて、後から「あれ見てないの？仕様変更になったよ？」

とか

いつまでやってんの。ばかなの？死ぬの？（って初めて使ったー。使ってみたかったー。）
元請SIerがTracのような環境を提供できない３つの理由 - なからなLife

とかホントに毎日こんな感じ．
彼らの仕事の道具は以下の3種の神器．

Excel方眼紙
Windowsのファイル共有
- しかも世代管理はフォルダで行うので，どれが最新かすぐわからなくなる
- 案件ごとにフォルダ分けをしているので，同じシステムの設計書なのに新旧入り乱れて散在している
Webメール

そんな彼らに，今ある資産を全てSubversionに移行したり，Redmine導入してプロジェクト管理したほうが良いよ，なんて進言しても

覚えるのが大変
若くないから覚えられない
能率が落ちる
今のままでも仕事回ってるんだから良いじゃん
所詮ツールでしょ？何使っても目的達成できれば良いじゃん

とか．使う前からこれだもんなぁ．
せめて情報だけでも共有しよう，ということでPukiWikiの導入を進言したのだけれど，

書き方わからない
覚えられない
勉強する暇あったら仕事進めたいよ
こういうのって若い人しか使えないよ

こういう負のフォースが蔓延しています．あんたら曲りなりにもエンジニアでしょーが・・・orz
とりあえず，自分が所属するチームから始めて，「あれって便利らしいですよー」とか言わせるように草の根活動をしていこうと思っていますが，普及までどれくらいかかるかな・・・．
こういう姿勢を上の人にされたら，若手は状況をよくしていこう！なんて思わなくなるはずだよなぁ．

-—-

『35歳定年説』諸々

yusuiked@gmail.com (yusuiked) — Sun, 02 Nov 2008 13:04:50 +0900

今にして考えるとあれって現場をドロップアウトした人間が、営業しかできなくなった今の自分を粉飾するために編み出した論理武装だったのかもしんない。
俺も上司から「いつまでも現場に居たのでは駄目だ、いつかは現場を離れて管理職としてマネージメントするのが、情報処理技術者の理想像だ」と説かれたクチだけれども、それって確かに「選択肢の一つ」ではあるけど、それこそが情報処理技術者の理想像だというのは少し違うんでは。
最近は、下流工程から上流工程へ移ることが情報処理技術者のキャリアップかのように語る人も増えたが、はぁ何それって感じだ。そもそもあんたらの言うところの上流・下流云々ってIT業界の理屈じゃなくてSI業界の理屈だろと言いたい。

IT技術者の「35歳定年説」が嘘くさい理由

狂おしいほど同意．
自分の上司は「技術なんてできる奴（協力会社）に任せておけばいいんだよ，早く管理者やってよ」が口癖．かくいう理由って，自分が技術をドロップアウトしたからなんだよな．そういう人間が結果的には出世もするし，給与も上がっていく．
でも，現状のIT業界，いやSI業界においては，彼の生き方が正解なんだろうなと最近つくづく感じる．
業界脱却の考えに行き着く一つの理由です．

３５歳定年説はＳＩ企業の事情、さらに突っ込んで言うと経営者の事情。
年功序列型が色濃く残る企業の経営者にとっては、ベテランは工数のかかる現場から引き離したい。
だから営業やプロマネのような仕事を技術者・技能者のキャリアの上位にある仕事なんだぞという雰囲気を盛り立て、職業に優劣をつけておきたい。一番の理由はそれ。
既に日経ＢＰのような雑誌を抱き込んでそういう雰囲気作りをしているよ。ただ今の大学生も馬鹿じゃないので、日本における上流工程がある種の「情報技術者の墓場」になっている面をきっちりと捉えているからなかなか乗ってきてくれないんだなこれが。
まあ、そもそもＳＩ企業がＩＴ企業と言えるかどうかだな。若者がＩＴ企業を敬遠しているという話、あれ正確にはＳＩ企業のことだよ。

http://anond.hatelabo.jp/20081102085404

営業やプロマネのような仕事を技術者・技能者のキャリアの上位にある仕事なんだぞという雰囲気を盛り立て

“盛り立て”どころか“洗脳”だと僕は思う．
よく，目標管理なんていう人事評価のモノサシがあるけど，その項目にもあたかもそれが決められたレールかの様に目標が設定されている．
そもそもSI業界中心に就職活動を行っていた頃から，どこの企業ブースに行っても「上流工程できます」「プロジェクトマネージャーを目指してください」と洗脳されます．
僕はその頃から何か違和感というか，疑念を感じたけれど，その違和感を理解するまで3年かかりました．*1

若者がIT企業を敬遠しているという話，あれ正確にはSI企業のことだよ．

僕もそう思います．はてなインターンとかに参加している学生のレポートを見ても，とても楽しそうだもの．

35歳定年説って、35くらいになると能力が落ちて若い奴に勝てなくなるよ、と言うことではなかったような気がする。俺が理解している35歳定年説とは、こうだ。

(人月単価の業界で)エンジニアやってて、普通に給料が上がっていくのは35歳までだ。

つまり、それ以上エンジニアとして働くことも可能だが、給料は上がらない。というか、正確に言えば上がる可能性が少ない、が正しいかな。しかしこれはエンジニアであっても単価で働いていない人には関係のない話。おもにSI業界の話だと理解している。
なんで給料が上がらないか？話は簡単。「単価＞報酬」だからである。エンジニアの単価とはそのエンジニアが生み出している利益そのもの。給料は自分たちが生み出した利益を原資に支払われるわけだから、これを超える給料になることは原則的にはない。つまり乱暴に言うと自分の単価が100万円から上がらないような会社にいて、それ以上の給料になることは不可能なわけ。35歳くらいになるとだいたいリーダというような役割になり、単価が上限までいってしまう。いくらがんばろうと一山いくらの世界では顧客はそれ以上払わない。あなたが優秀なエンジニアであっても、隣の席のボンクラと評価は一緒。こういった感じで、給与があがりにくくなる最初の波が35歳くらいに訪れるわけだ。若い人はわからないだろうが、35くらいになると家庭をもっていたり、子供がいたり、親が病気がちになったり・・・とにかく自分だけ食えればよいということではない事情があったりする。当然、給料が上がらないような仕事を続けるのは難しくなる。このような仕組みの中で働いている人がこの法則から抜け出すために一番簡単な選択肢が、「管理職になる」ということだ。ここでいう管理職は現場リーダではなくて、人月で稼動する人員を動かす側の人間。このポジションは単価＞報酬という法則の外に出れる。よって『35くらいになるとエンジニアをやめて管理職かなにかにでもならないといけない』ということになる。元記事で”50歳でCOBOL PGでも食える”とあるが、そりゃあ食おうと思えば食えるだろう。ただし年収500万台でできる範囲で、だ。著名なプログラマーでもない限り、これが現実。

35歳定年説の実際

学生時代に，この記事を読みたかったなぁ．*2
SI業界に興味を持っている来年就職活動の学生さん，これをしっかり頭に焼きつけて，就活してください．人事担当者にこのことについて質問してみると良いかも．きっと奥歯にものが挟まったようなものの言い方をして，消化不良な返答しか得られないと思います．

*1:僕の愚かで無知な点…orz

*2:こういうことを調査するのが，本来の業界研究なんだろうなぁ．僕はこれができなかった．

-—-

それなんて俺？

yusuiked@gmail.com (yusuiked) — Sun, 19 Oct 2008 15:25:12 +0900

確かに、プログラミングができるようになるのに必要なことって何なんだろう、と思うことはある。既に書けるようになっちゃった人の「今」だけを見ると、なおさら良くわからんくなるよなぁ、とも思う。
というわけで。とあるプログラマーこと俺がどんな風に育ってきたか……大学生活 4 年間を振り返ることで、プログラムを覚えるのに必要な一例を示す。ま、履歴書みたいなもんですな。
とあるプログラマーの追憶 - kagamihogeのblog

きっかけからバックボーンまで，それなんて俺？って感じです．他人とは思えないｗ

似ている点

ゲーム好きからプログラミングに入った
文系科目で受験できてコンピュータサイエンスを勉強できる大学*1を選んだ
プログラミングのとっかかりがPascal*2
タッチタイピングをチャットで覚えた*3
経営学の方はほったらかし*4
3年次からJava勉強し始めた
3年後半，就活が終わり卒論書き始めなきゃーといった時期にネトゲにハマった*5
卒論は，Webアプリケーションフレームワーク*6について書いた*7
etc…

ぼんやりと

ただ，受託開発については興味を失いかけている自分がいます．
受託開発の極意―変化はあなたから始まる。現場から学ぶ実践手法 (WEB+DB PRESS plusシリーズ)
も読んだけど，そうそうそう，その通りだよなと思いつつも，新人の頃の情熱を取り戻すまでには至らなかった．
なんだろう…変えるためにはまず自分から，っていうのは至極その通りなんだけど，対峙する相手がゾーマ*8みたいのが100人1000人居るくらいな感じで，もちろんそれをやっつけるのが本筋なんだけど，自分が動いていられる期間にそれが果たせるのか？ということを考えたときに，それと環境を変えることを天秤に図ると，やっぱり環境を変えることの方が目的地にたどり着けそうな気がするんだよなぁ．

*1:経営情報学部

*2:自分の場合はDelphiだったけど

*3:よく喋ってた相手がものすごくレスが早かったのでついていくために必死だった

*4:統計学とか高校で数II，数Bまでしか勉強していない人間には辛かった…今思うとちゃんと勉強しておけばよかった

*5:ディプスファンタジアってSQUARE ENIX（当時ENIX）のMMOに入り浸ってました

*6:Struts

*7:量は書いたけど，今思い返すと大したこと書いてない…でも，これやってなかったら，今もまともな文章書けてないけど，文章なんて書けるようになってなかったと思う

*8:威圧感，圧迫感的な意味で

-—-

エンジニアの未来サミットで学生が得たかったもの

yusuiked@gmail.com (yusuiked) — Thu, 18 Sep 2008 01:51:26 +0900

アルファギークが空回り - ひがやすを blog
http://d.hatena.ne.jp/higayasuo/20080915/1221440227

前回のエントリを読み直してみたのですが，ログに対する自分の感想がなんだか普段溜まってるものも力の限り投影しながら書きなぐってしまったために，大分ネガティブ&攻撃的なエントリになってしまいました．あまり建設的な内容ではないなぁと再度読んでみて思ったので，少し時間を置いた今，もう一度冷静に振り返ってみようと思います．
naoyaさんが言っていた，学生はどんな情報が欲しいのかについて，SIerに就職した自分視点で分析してみました．

前提として

学生時代から起業したり，なんらかのサービス作ったりしているマッチョな人は以下には当てはまらないと思いますし，そういう人は誰に言われなくても，実際に自分で情報は得ていると思います．ここでは，SIer中心に就職活動をした経験を持つ人間として，IT業界に興味を持っているけどイマイチイメージ湧かないよっていう学生を対象として書きます．

3K，3K，っていうけど実際のところどうなのよ？

3K については，完全に言葉のイメージが先行していて，それを鵜呑みにしちゃってる人は勿体無いなぁとは思います．3Kかどうかは主観的なことで，ある人にとっては3Kだし，ある人にとっては1K*1だし，3K？どこが？な人もいると思います．少なくとも，第2部でパネラーとして出ていた人たちに聞いてみたら，3Kだからやめといた方がいいよ，なんて言う人いないんじゃないかと思います．
僕はSIerに入って4年経ちます．今，学生に4年経ってどうですか？と言われたら，「会社は良く選んでね，仕事自体は面白いよ」と言うだろうと思います．だって正直面白いもの．でもそれは，僕の主観であって，もし誰かがしばらく同じ業務やってみたとしたら，「無理」っていう人もいると思います．やっぱり僕にとっては，コードを書くことを仕事にできることが，何よりも面白いと感じます．
父親は運輸業に従事していますが，毎日ダイヤに合わせた生活で，可能な限り正確に定められた時間で人を運ぶことが最大のミッションです．それが全てで，それ以上でもそれ以下でもありません．加えて人命がかかっていますから，社会的責任の大きさたるや僕とは比べ物になりません．
でも僕は，父親と同じ仕事をしたいかと問われれば，答えはNoです．変化がないこと（≒事故がないこと*2）が父親の仕事にとってもっとも重要なこと*3ですが，僕には，日々同じことの繰り返しこそが貴ばれる世界は耐えられそうにありません．
この業界は，絶えず変化していて，しかも激しいです．サボったら置いていかれます．でも，やればやっただけ何かしらの変化があって，結果が返ってくる．良いものも悪いものも含めて．それが僕にとってとても楽しいことなんです．

会社良く選んでね，って言われてもどう選んだらいいのよ

SIerで働いている人が実際業務で何をやっているのかといった部分については，漠然としたイメージしか持てず，自分で色々動いている積極的な学生にとっても情報として得ることが難しいと思います．もちろんOB訪問とかインターンとか手立ては色々ありますが，これもマッチョな人以外は，自分が参加してもいいものだろうかとか，参加して余りにもイメージと違うと時間もったいないし・・・とか思って二の足踏む人は結構居ると思います．
とはいえ，これから人生の大部分を占める，従事する職業を決めるに当たって，実際/現実の生の情報として何をやっているのかは学生にとってとても気になるところです．

自分が学生のときに就職活動をやっているとき，何が一番知りたかったか

顧客の要望を聞いてそれを提案・具体化して実際にシステムを構築する仕事です
主に上流工程を担当します，下流工程の仕事は下請けの会社を使って行い，それをマネジメントするのが仕事です
…etc

そんな抽象的なことじゃなくて！

例えば…

一日どんな過ごし方してるの？

よく企業のリクルートページに「先輩社員の一日」とか載ってるところありますよね．一日の時間配分，とかって円グラフ載ってたり．就職活動をしていた頃，あれって結構興味があって読んでました．勤務終了の時間とか，帰ってからどんなことをしているのか，休日は何をやっているのか，とか結構気になります．
自分がその会社に入った場合，自分の余暇に使える時間はどれくらいか，自己投資に使える時間はどれくらいか，その上で対価となる報酬はそれに見合っているのかとか，結構学生はしたたかに考えているんだと思います．それを考えるのも，自分の人生設計の一部なんです．
学生だって，仕事なんだから忙しいことがあるのはよくわかってるし，定時で帰れない日があるのだってわかってるはずなんです．ただそれが毎日続くのか，そういう時期もありますよ，ってことなのか，そこの実際のところを知りたいのではないかと思うのです．

実際にどんなコードを書いているの？

学生時代から趣味でコードを書いている人なんかは，実際に社会で動いているコードはどんなコードなんだろう，どんな高度なアルゴリズムやテクニックを使っているんだろう，個人レベルじゃないんだから可読性も考慮されてるんだろうな，とかどんどん想像が膨らんでいってると思います．
実際はメンバーが入れ替わり立ち代わりで継ぎはぎだらけ，工数が無いので場当たり的なコードがあちらこちらに，DRYて何ですか？なコードが溢れかえっているわけですがwただこればっかりはオープンソースとかでないと，実際のコードを見せるのは難しいのかなぁと思います．

コード書くのは好き，だからコードガリガリ書きたい．でも何がやりたいのかまでは漠然としててまだわかんないよー

まさに僕がこのパターンだったんですが，このパターンの人は，SIerに行くと悶々とすることが多くなる可能性が高いと思います．というのも，残念ながら現在のSI業界の構造では，コード書ける人は「早くそんなの卒業してプロジェクト管理やってよ」と言われるからです．もちろん，運良く周りの理解が得られて，ハッピーなSIer生活が送れる人も中にはいるとは思いますが，それはマイノリティな方だと思います．
SIerではPG＜SE＜マネージャというカースト制度でなりたっています．コードをかけない人がプログラマ（というかコーダ，言語文法だけ知っていて，設計書の通りプログラミング言語で翻訳するだけの人）をやり，コードを書ける人が納品という建前の元でメンテナンスされないExcel設計書の作成，顧客との折衝やメンバーの進捗管理，レビュー，果てはスキル不足の要員の尻拭いなどに忙殺されます．
「プロジェクト管理」なんて言うと聞こえがいいですが，内情は要員の計画を立てて，メンバー集めの為に人の面接したり，上長に報告する為の数字合わせの資料を作ったり，といったことが主な業務*4です．そういうことが好きな人がいるのは事実ですが，コードを書く人が好きな人は往々にしてこういう類の業務は肌に合わない人が多いのではと思います．
そもそもコードを書くという行為に卒業する？という概念を突きつけられること自体，理解しがたいのですが，残念ながらSIerに所属する多くの人にはそれが常識のようです．こうなっている理由，いきさつにかんしては僕がここで説明するよりも，ひがさんのBlogなり Blog検索で"SIer"とか検索すればたくさん出てくると思います．
ちなみに金融機関向けの大型汎用機のシステム開発ではどんなことをやっているのか，ということを知りたい学生さんには，以下のエントリを．

3年泥のように働いてみました - Life goes on.

入った後の3年〜10年くらいのキャリアパス

僕もそうだったのですが，入った後の3年〜10年くらいのキャリアパスも気になっていると思います．今の学生は，最初に入った会社にずっと残ろうと思ってる人はそれほど多くないのではと思っています．
もちろん条件が良かったり，入った後で考えが変わることはあると思いますが，如何にその会社で経験を積んで，それを活かして本当に自分がしたいことへ繋げるか，そういったことを考えているので，新人から30歳までのキャリアってものすごく大切に，慎重に考えたいと思っていると思うのです．転職するにも年齢って一番武器になりますし．
努力は自分次第でどうにもなりますが，年齢は取り戻せないとっても貴重なものだと学生は考えています．だからこそ，先の「10年泥」発言は，そういう学生にとっては長すぎるのだと思うのです．ちょうどバブルの終わり頃に生を受けた今の世代は，親が苦労している姿はよく知っているし，一つの会社に寄りかかっていられるほど甘くないということも知っているので，如何に早い段階でどこに行っても通用するスキル・キャリアを得られるか、ということを重視するのだと思うのです．
終身雇用の時代では，如何に倒産しないしっかりした企業に入るか，大企業に入るか，が学生にとってその後の人生の大きな「安心」を得ることに繋がったのだと思うのですが，今の時代の学生は，如何に早い段階で「どこに行っても通用する，食いっぱぐれないスキル・キャリアを身につけるか」がその後の人生の大きな「安心」*5を得ることに繋がるんだと思います．またその中で，仕事を通じて社会に対して貢献したい，自分が生きた証を残したい，とも考えてると思います．だからこそ，経営的視点にもなるしテクノロジよりもプロダクト重視になるんだろうと．

こういったことを踏まえて，IT（SI）業界が学生に対してすべきこと，アプローチ

リアルな情報を伝える

まずは抽象的なことではなく，実際の仕事のアウトプットを見せること(可能な範囲で)や，こんなネガティブなことがあるんだよ，といったことも素直に伝えることからはじめた方がよいのでは．

成功体験をさせる

もちろんネガティブな情報だけでは離れていってしまう一方なので，実際に学生に成功体験をしてもらう，というのも重要だと思います．
エンジニアやってて何が一番嬉しい・楽しいかといえば，月並みなことを言えば自分が作ったもので誰かが喜ぶ，ということもあるのですが，僕の場合は正直なところ自分が勉強すればするほど返ってくるし，それが仕事に活かせるということだと思っています．やればやるほど，知っていること・やれることが増えていって「俺ってスゲー」と感じられること*6だと思うのです．
第2部でプライベートと仕事をあまり分けないタイプもいる，という話がありましたが，正に僕はそのタイプで，自分の成長に繋がっている，興味を持てる，と思えたことに関しては，たとえ土日だろうが考えてしまうし，やってしまいます．
自分の好きなこと，興味あることが仕事とリンクしているところが，エンジニアやってて一番楽しいし面白いところだと思うので，そこを少しでもいいから実体験させる場を提供することが，重要なのではないかと思うのです．

具体的には？

こういったことを学生に提供するには，自分が思いつく範囲ではインターンなのかなぁ，やっぱり．長々書いた割に，結論に面白みがない．
これが残糞感か…ｗ

*1:キツくないし帰れるけど給料安いなぁ的な意味で

*2:決して事故起こしたいと言っているわけではございませんw

*3:もちろんお客さんに感謝されたり，怒られたりすることもあるし，日々が何もかにも全く同じといっているわけではないです．

*4:所謂スーツな仕事

*5:更には可能性

*6:もちろん「俺ダメだー」も倍ぐらいありますけど

-—-

3年泥のように働いてみました

yusuiked@gmail.com (yusuiked) — Mon, 02 Jun 2008 01:40:49 +0900

ひが氏のBlogで僕のコメントが取り上げられていました．
SI業界の老害が若手と下請けを蝕む理由

汎用機の開発現場ですと，プログラミングに付加価値はありません．それこそ誰でも書ける，と信じて疑われません．というか，書く人によって生産性に差が出るほど自由度があったりいろんな事ができるわけではないんです．やれることが固定長のファイルの中身をいじくってDBに突っ込むだけなんです．
意外な歴史 - シークの日記
という意見も汎用機やオフコンのプログラミングは差別化が難しく価値が低く見られたということを良くあらわしていると思います。

ひが氏も汎用機の経験があったということを知り，共感とともに自分の進むべき道に少し光が差したような気がします．
僕自身，学生時代にJavaを独学で習得して，アルバイト先の社内システムを一人で作ったり，分散オブジェクト技術（当時はEJBが流行っていた時でした）について卒論を書いたりして，夢を持ってIT業界に飛び込んだはずでした．
ところが，新人で配属された現場は，バリバリの汎用機．
そこでは，Javaもオブジェクト指向もIDEも必要なく，ただ黒い背景に80文字×32行の緑の文字の画面に向かい，諸先輩方が作ったJCLをコピペし，入出力のファイルを間違いがないように書き換え，JOBをSUBMIT（実行すること）し，得られたHEXダンプをリモートプリンタで打ち出し，固定長のDBレイアウトが記載された古びて黄色く変色したキングファイルと照合し，該当箇所が正しく修正されているかを蛍光マーカーでマーキングする作業を黙々と繰り返す日々．
やっとプログラムを組ませてもらえるようになったと思ったら，商業高校で習うようなフローチャートと記号で書かれた内部設計書を元に，IF文のand条件をひとつ追加するだけ．
高尚なアルゴリズムやデザインパターンなどは必要なく，キーブレイク，マッチングさえできればいい．それよりも業務知識が必要だ，と口酸っぱく言われました．
コンパイルして実行ロードモジュールを作成したらまたJCLをコピペして結果の確認．この程度の作業でも，「バグを出さないために」単体テスト，結合テストを長い期間かけて行います．
やっとこさシステムのリリース，となっても，ユーザーからの感謝の言葉を聞くこともなく次々と違うプロジェクトへアサインされる．こんな作業を2年弱続けました．
これが「金融システムなど企業の大型システムに従事する人間」を欲する現場の実態です．僕はこんな作業を「10年泥のように働け」と言われて続けなければならない状況だったら，どんなに我慢強くても「無理です」と言っただろう．
仮に10年泥にまみれて続けたとしても，その後求められるスキルは，協力会社の要員をスケジューリングし，管理し，プロジェクトを回す能力で，使えないと判断した要員を切り捨て，また新しい要員を面接してどんどん人を増やし，売り上げを上げることこそが会社が求めていることなのだ．
入社して3年経った今，上司にそろそろそんな仕事をやってみないかと言われている．
会社に入って間もない頃は，20代はバリバリプログラミングして技術力という背骨をしっかり作るぞ、と意気込んでいたけれど，結局コード書いた時間より，Excelでコピペの設計書を書いた時間の方が絶対に多い．最近，これが自分のやりたい仕事だったのかと途方にくれることばかり．
これ，最初読んだとき自分かと思った．

人月計算とExcelとスーツの世界より

紛れもなく，これが汎用機開発現場の現実です．汎用機開発の現場は20年前から時が止まっているのです．
今，この状況から如何に抜け出すかを考えています．そのためには，コードを書き，モノを作り，人に知ってもらう・使ってもらう．アウトプットしていくしかないと思う．
幸いだと思うのは，今は昔のエンジニアとは違いネットという武器があること．
自分の成果物をみんなに知ってもらうことができるんだ．
社内に篭っていないで，もっと色んな人たちとコードで何かできたらいいな．

-—-