WeBlowg Side

ほとんどの現場を「自社の人間は自分だけっ」て状況で渡り歩いてきたけど、今回の現場では自社の後輩 + 新人と働くことになりました。
後輩の方は、まぁ今まで微妙に現場が一緒だったこともあるし、そもそも後輩と言っても自分と大して職歴か変わらないんで、そんなに先輩面する事もないんです。
そもそも後輩の方は技術的に優れてたりするもんで。

でも、新人の方はそうはいきません。特に新人に対しては「質問ウェルカム」状態ってこともあり、色々質問してくれます。
そんな日々を過ごしてて、質問されるっていいことだなと思ってきました。
今回の新人は学生時代にプログラミングをやってて、意欲もあるので質問の質もいいんでしょうが、やはりいろんな視点を持ち込んできてくれます。
自分が捉え切れなかった視点をもってきてくれることで、自分の視野も広がった気がします。
私は技術的には独学の部分が大半なので、抜けている部分も多いんですよね。そういう部分を埋めてくれたりする場合もあります。

そして、分からない人に分かるように教える事の難しさを日々体験するわけです。
難しいことを如何に簡単に説明できるかってのが、自分の課題の一つなので、日々説明力を鍛えることができます。

今まで他社の人とは仕事を教えたり教えてもらったりしてきたけど、新人というのはあまり出会うことがありませんでした。
貴重な体験ができそうです。

ひょんな事から社内教育を行うことになった。
お題はWicket。
簡単なWicketの紹介をプレゼンして、実際にWicketでアプリを書いてもらうハンズオン形式の社内教育にしました。

レベル的にはあまりWebアプリを知らなくて、Javaはそこそこできる人間が対象でした。
そんなわけで、JavaでのWebアプリケーションの歴史を追う意味でも、Servlet、Struts、Wicket で同じ仕様のアプリをソースレベルで比較、解説してみるってコーナーも設けました。
私自身、Webフレームワークを使わないServletのみの現場と言うのは未経験ですし、
Strutsは経験あるけども、既にWicketで書いたコード量の方が多いぐらいでそんなに分かっていませんでしたので大変勉強になりましたね。

久々StrutsやServletでアプリを書いた経験は貴重でした。
「やっぱ設定ファイルだるいなー」とか、「やっぱJSP嫌いだなー」ってのを再実感できたし、
Servletのみの構成で作ってみると、「Strutsていいなー」とあらためて実感できたり。
技術の進歩をこじんまりと実体験できた気がします。
参加者もその辺を感じ取ってもらえたようです。

講師を引き受けてみて、こういうプレゼンとかセミナーでは一番講師が得している事が実感できました。
やっぱり人に教えるといういい意味でのプレッシャーがあるといいですね。
質問も違う視点での疑問点が聞けて非常にためになる。

Wicketを広めるという点では、JSP嫌いの子がかなり食いついてくれたようで好感触でしたので、ひとまず成功ということで！

Wii を買いました。Wii Sportsをやったら筋肉痛になっちゃいました。
どんだけなまってたんだろう。

さてさて、
Re: なんで好きでプログラミングをしている人があんまりいないんですかね

反応してもらったのでもう一度考えてみました。

プログラミングと言う工程にばかり目がいきすぎてた気がします。
システム開発でいうとプログラミングは長いサイクルの内の一工程であって、他にもいろんな工程があるのにね。
ただ、「プログラミングなんて誰でも出きるんだから、それより上流やろうぜっ」て風潮が回りに流れてたので、防御反応がでちゃっているかも。

思い起こすと今までの現場でも、コーディングはからっきしだけど、テストに凄まじい情熱をかけている人もいたし。
その方のおかげで随分いいシステムになった思い出があります。
以前コメント頂いた 通りPM、PG、SE誰が偉いとかにじゃないんですよね。納得してたつもりだったけど。

わがままといえば 「10年は泥のように働け」って話を企業の方がされているそうで。
年功序列の終演を説く本をよんだりしてると、すごく対局にある感覚ですね。
わがままなんて許されない感じ。
ただ、学生の方も企業に何かを求め過ぎのような気もするんだけどな。

と、同じ会社の後輩に言われました。悲しい現実ですわ。
好きでプログラム開発している訳ではなく、お仕事で嫌々プログラミングをやってる人とも一緒に働くことになる訳で。
それは仕方のない現実だと思ってるけども、やりきれないと思うこともしばしば。

それにもかかわらず彼のように高専で情報処理関係をちゃんと勉強してても、そのプログラミングが好きな気持ちを持て余しちゃうような暇な現場に行かされてるのは本当に不幸だと思います。
私なりに彼のために出来る限りの事はしたけども、結果が出ていない今日この頃です。

この前読んだ 3年で辞めた若者はどこへ行ったのか のあとがきの受け売りだけど、「もっとわがままになれば」とアドバイスしておきました。
実際私はここ数年、会社に対して私なりにわがままを言うようになってて、一つの言語をとりあえずみっちりやりたかったので「Javaの仕事しかしない」といってそれが通ったりしてます。
わがままを言うだけってのも気が引けるので、自然とそれなりの結果を出すように努めるようになっていいサイクルになってます。
そんな姿勢でやってきた結果、大好きな Wicket を仕事で使ったりできるラッキーまで巡ってきました。

先輩、後輩の間柄といっても、現場も違うし派遣みたいな形態の仕事がほとんどなのでなかなか難しいけど、
私程度の能力でもそれなりに楽しい仕事に巡り会えるわけだから、彼のように能力のある人間がもうちょっと幸せな仕事が出きるようにフォローしていきたいもんです。

去年の夏頃から参加してた大規模開発の案件がようやく終了した。
その前の案件が4人程の小規模開発だったので、思う所もいろいろあった。
そういえば「小規模と大規模を繰り返し経験するのがいいよ」って聞いたことがあります。

さてさて、大規模開発を終えてみて、、、、
悪い点

• 政治に走る人が出てくる
• 当たり前だけど小回りきかない
• 保身に走ってしまう

良い点

• いろんな観点からの意見がでてくる
• きっちりゴールが示せればパワーは絶大！

「保身に走ってしまう」っていうダークサイドには自分も随分引きずられた気がする。
反省。

今回思い知ったのは、

• ソースレビュー重要
• バグトラッキングシステム便利！

ゴリゴリソースを書くことがあまりなかったけども、
暇があれば人のソースはチェックしまくった。
本当は公にソースレビューとかできればいいんだけど、
この業界お得意の「タイトなスケジュール」でできなかった。
大規模だと様々なスキルレベルの人がいて、もちろんレベルの低い人もいる。
Stringの比較を == でやっちゃってるなんてザラにある。
まぁそこまでひどいのは置いといても、言語仕様に照らし合わせるだけどもおかしなところは、
結構発見できるし、それで救われた所も大きかった。ソースのチェックは非常に有用ですね。
あと、ソースのチェックをする上で、EclipseのPlugin、FindBugsは必須ですね。

あと、今回、バグトラッキングシステムの威力を思い知った。
タスクがわかりやすく割り当てられるんで、いちいち仕事を振らなくても、
各人が自主的に動きやすい。
今後のプロジェクトでは大小問わず導入を検討してみます。

トム・デマルコの本は前から気にはなってたんだけど、
今の現場の人が「Slack ゆとりの法則」を貸してくださると言うことで、読ませてもらった。
2001年に初版なようなので、だいぶ遅れをとった感があるけど。

テーラーによる製造業管理手法がそのまま適用できない、
いわゆるホワイトカラーな仕事の特徴とその管理に関する論点は、
ダニエル ピンクの「フリーエージェント社会の到来」や、
P・F. ドラッカーの著書にもよく書かれている内容。
そこに本書のタイトルである「ゆとり」による変化の醸成をプラスして、
効率化の罪悪を突いていくところは、効率化という言葉に悪いイメージが一切なかったため、
なかなか衝撃的だった。

もう一つ、品質管理という言葉にも悪いイメージはなかったのだが、減点法による品質管理に終始して、
創造性から来る高品質を殺してしまう様を説明してくれる。

効率化、品質管理という今までマイナスイメージのなかった言葉に変わって
本書では効果的という言葉が強調されてる。そして効果的を狙うとリスクが立ちはだかる。

この本で感銘を受けたのは、上記を踏まえて、
いかにリスクを取っていくかと言う点をわかりやすく示してくれた所。
リスクを取るメリットとリスクを取らないデメリットを示し、
本当のリスク管理とは何かを示してくれる。
自分はこの本は「ゆとり」というより「リスクの楽しさ」に関する本だと感じた。

自分の周りの企業や、自らの生き方を深く考えさせられる書でした。

各所で話題になってるIT業界不人気の記事。
コミュニケーション能力の必要性とかなんてのは、経営層の人から散々聞かされてきた内容で、
新しさもなく何とも思わなかったけど、記事では触れられてない部分で、
プログラム技術がいらないっていってたそうで。
なんか同じIT業界なのに遠い世界の話みたいで、まったく理解できない。
IT業界の重鎮たちと自分との距離があまりにも離れてるんだろけど、
重鎮たちの思い描く世界では、IT技術ってのが軽視されているのがよーくわかった。

すでに大手はパートナー企業の技術者がいないと、立ち行かない状況になってるのは明白で、
さらにコスト安ってことでオフショアやって、それにより技術がどれだけ空洞化するのか。

さらにニッポンIT業界絶望論とそれに続くIT業界進化論： 絶望する前に”SIer 2.0”を目指せを読んで。

大手はどんどんさらなる上流へ軸足を移して言っているということ。
これからさらに軽視されるであろう下流の「大手のパートナー企業」と言う立場は、どうなるのか。
「大手のパートナー企業」の一員である自分としては、悲観的になってしまう。
まぁ、パートナー企業として歩んでいく以上、その組織には技術の蓄積はほとんどなくなると言う点で既に悲観的だけど。

確かに自分は技術が目的化しすぎている嫌いはあって、
お客さんと一緒に物を作っていくと言う視点にやや欠けている点はあると思う。
そういう意味で、上流の人のような視点での仕事は尊敬するけど、
下流というものを軽視するってのはまた別の話。

まさに「大手のパートナー企業」ってところで仕事をしている現在、
仮に転職を考えたとしても選択肢が非常に少なく感じる。
妻子を養う身としてはお金も大切。
そうなると、Sierの傘の下ではあるけど、

• 企業の研究開発部門等の狭き門をねらうか、
• 「スーパー技術者」としてフリーを目指すか、

もしくは

• 起業するか、

どの選択肢も自分のスキルではなかなか茨の道やね。
いずれにしてもこの業界に入ったころの、「作ったシステムが動く喜び」を忘れないようにはしたい。

特にここ最近、技術と言う点で「この人はすごかった」と言える人と、
一緒に仕事をする機会に恵まれなかった。
技術的に優れた人はいつもインターネットの向こう側にいる事が多く、
そこから学ぶことは多大だったけど、やはり一日の内の多くを過ごす職場で、
優れた人に巡り会えないってことは、さみしかった。

そしてこの業界にはいって5年、特にここ2,3年はアンチパターンが目につくようになったってのは、
以前書いたとおり。

で、会社辞めるったってどうすんのよって感じで、もやもやしてた今日この頃、
ついに「この人と仕事がやれるなら、今の会社も辞めれる」と言える人に出会えた。

自分が多くの時間を過ごす職場で、素晴らしい技術力を駆使して問題を解決するさまは、
まさに羨望の眼差し。

まず引き出しの多さが違う。
今までいろんな言語を嗜んでいるらしく、視点が凝り固まっていない。
特にC++の知識量はすさまじく、それをJavaにうまく昇華している。
特に自分はJava以外の言語が手薄なのは自覚してたので、余計に多言語を学ぶモチベーションが上がった。

そして、なんてったって注意力が違う。自分だと見過ごしてしまうような潜在的なバグを、
ソースを眺めててしっかり見つける。
ここでいうバグってのは、設計書と実装の乖離って意味じゃなくて、
例えば変数のスコープ等の技術的な視点から。

というわけで、自分が思う「出来る技術者」リスト。

• 様々な言語知識を習得して視野が広い
• 気づき、注意力が優れている
• プログラミングだけでなく、環境もある程度構築できる

現場も変わって心機一転、一見大丈夫そうに思えたけどそれは極一部で、
タイトルどおりやっぱりひどいソースだった。オフショアってやつ。
基本的にはこの前の現場と同じような内容で、ながーいメソッドのオンパレード。
人間やることは同じやね。

今回考えさせられたのはコメントについて。
ソースを修正とか削除した部分について、「誰が」「いつ」「どの部分」を修正したか分かるように、
コメントがいれてあるんだけど、これが著しくソースの可読性を下げる。
例えばこんな感じ

    if (hoge) {
// 2007.09.25 mod tma start
//        fuga();
        moge();
// 2007.09.25 mod tma end
    }

自分もこの業界に入って、一番最初の現場ではこのコメントをよく書いたけど、
それはソースをバージョン管理してなかった頃の話。
バージョン管理するようになってからは、見ることもなかったので懐かしい気分になった。
確かにヒストリーを辿ることなく、一見して誰が何をしたかが分かるというメリットがあるけど、
可読性をさげるデメリットの方がでかすぎると思う。
そもそも、バージョン管理の意味が薄れるし、コメントのおかけで、メソッドがながーく感じたりするし。

ただ、そういう感覚の人が少ないようで、
上のようなコメントが量産されていくんよね。。。。

アンチパターンだらけのプロジェクトからもようやく脱出し、
新たなプロジェクトに参加することになった。また途中のフェーズからだけど。

一見してヤバそうな前回のソースとは違い、
今回はまだマトモそう。
色々話できる人もいるし。
自分の会社をどうするかってのも考えんといかんけど、
目の前のプロジェクトにもモチベーションを維持せんとね。

今回はstrutsにDIコンテナって組み合わせ。
DIコンテナってのは、何となく敬遠してきたし、
Strutsってのも今更あえて自分からやらないと思う。

これらは自分から進んでやる技術ではないわけだけど、
不思議とモチベーションが下がらず、やっていけてる。
どんな仕組みなのか結構ワクワクしながら追えてる。
決して自分からはやらないこれらの技術の、いいとこ悪いとこを見極めたくてしょうがないって感じ。
以前までどうしてこういう気持ちにならなかったのか不思議だけど、同じ働くならこの方がいいわな。

閉じこもらずにいろいろな技術に触れるってのはいいことだと思う。
この前、OpenBSDのPortsやpkg_addに触れたのもいい経験だった。
パッケージ管理といえば、Gentoo Portageな自分としては、なかなか新鮮だった。

この歳になってどんどん貪欲になってる気がする。
っていうか今までが浅かったのか。