ラベル 仕事 の投稿を表示しています。 すべての投稿を表示
ラベル 仕事 の投稿を表示しています。 すべての投稿を表示

2011年12月30日金曜日

おもくそクエストファイナルファンタジーファイナル-2

将来有望な若者の将来価値を毀損する、大きなワナ - Chikirinの日記
人気ランキングのトップに君臨する名だたる大企業から内定をもらった彼らは、なんの疑いももたずにそういう企業に就職していきます。自分達がそこで学ぶことになる「ビジネスの常識」が、世界のビジネス常識とは全く異質なものであることなど想像もしないままにね。

実は「完全に周回遅れです」みたいな場所で人生最初の「働く訓練」を受けることがどれだけ自分の将来価値を毀損する可能性があるか、よーく考えてみたほうがいいんじゃないか

その損害の大きさたるや実は、「なんだかんだいっても安定してるし」「福利厚生もしっかりしてるし」みたいなぼんやりしたメリットとではとても相殺できないくらい大きなダメージになるですよ。

おもくその転職活動冒険譚『おもくそクエストファイナルファンタジー』シリーズ。ついにシリーズ名が変わっちゃいました。
「XIII-2」的命名規則を使用すればまだまだ引っ張れますが、今回は本当に大メインクライマックス(by 世界のヘイポー)です。引越したいから荷物は早く片付けておきたいし(電子の世界では関係ねえよ)。

『安定』の定義って?

転職活動開始前、当時の所属会社で上司に辞意を伝えたとき、上司は言った。
「うちみたいな楽な会社はそうそうないよ。ミスしても減給とかまず無いし。他は厳しいよ~」(※1
会社を辞め、現在無職で転職活動中であることをお袋に報告した時、お袋は言った。
「公務員にしときなさい。まだ年齢大丈夫でしょう?」
要するに、両名とも「『安定』して『楽』な会社がイイゼ!」って言いたいのだろう。
そもそも『安定』の定義って何なのか。現代においては
「収入を継続的に得られる事が保証されている」
ってところでしょうか。ではもう一歩突き詰めて、何故公務員は「収入を継続的に得られる事が保証されている」のか。
「解雇や倒産が無いから」
…確かに、今まではそうだったかもしれない。でも、この状態がずっと続くか?流石に続かんでしょ。橋本氏のような「まともな政治家」が今後増えてくる(増えて欲しい!)と、間違いなく粛正されると思うけど(ていうか今月早速切り込んでたしね)。そして、今年になって(特に3.11以降)、非公務員はかなり怒りが溜まってるから、いくら大人しい日本人といえども、いつか暴動起こるぞ。

「解雇や倒産が無い企業」なんて存在しないと思っておいた方がいい。そうなると、「収入を継続的に得る」方法は一つしかありません。
「継続的に職にありつく=突然、会社が潰れても、すぐに次の仕事にありつけるくらいにスキルをつけておく」
そうなると、会社の選考基準は
「どれだけスキルが身につくか」
ってことに尽きると思います。
公務員って、スキル身につきますか?ぬるま湯環境に慣れきっちゃうと、いざ改革だか革命だかで放り出された時点で死亡フラグだと思いますよ。そうなる可能性を少しは考えてますか?それとも、まだ「公務員は安泰」神話はずっと続くとお思いですか?
「ゆっくり走るのが安全運転だと思うなよ」by 松本人志
「ゆっくり=安全」とは限らないのです。
ちなみにこういう人達の世界です
大阪の労連って本当に凄いな: やまもといちろうBLOG(ブログ)
人事評価結果の給与反映はやめろ

中途採用を行ってない会社は危険な香り

これは新卒者向けのお話になりますが。僕は新卒の頃、会社選びの基準の一つに「中途採用していない」というのを持ってました。理由は、「中途採用せず=離職率低い」と思ってたから。

これ、大間違いでした。どんなに良い会社だとしても、退職者ゼロなんてあり得ません。必ず一定数は発生します。そして減った分は穴埋めしないといけない訳ですが、中途採用していない会社の場合、新卒が穴を埋める事になります。もちろん、退職者(経験者)の穴が新卒(未経験)で埋まる訳がありません。よって、新卒採用しかしていない会社は、会社全体のスキルは下がり続けていきます。僕の前の会社なんかまさにそれで、一番脂が乗ってくる30代前半の比率が極端に低く、人口ピラミッドは平子理沙ばりのくびれのナイスボディーです。

という訳で、「中途採用を行っているかどうか」というのは、その会社の力を知る一つの指標になるかなと。企業のWebページに、中途採用ページが用意されてるかどうか確認してみてください。そもそもページ自体が無い会社は、中途採用の文化が無いと思ってよいかと。

※1
ちなみに、このやりとりあった直後くらいにリストラ開始w
仕事が楽(気楽)なのは確かだけど、アラサーで基本給手取り17万…同じ「気楽」なら派遣の方が稼げるんじゃ(年金とか考慮しても)。




2011年12月29日木曜日

おもくそクエストファイナルファンタジーファイナル

ゲリラ的雇用面接のすすめ - The Joel on Software Translation Project
我々の欲しているのは「才能 」に溢れた逸材であり、特定のスキルを持つ技術者ではない。どのようなスキルも技術的に数年すれば時代遅れとなる。重要なのはどのような新技術でも習得する事の出来る人を採用する事であり、たまたまちょうど良いタイミングでSQLを知っていた人を採用する事ではない。

おもくその転職活動冒険譚『おもくそクエスト』シリーズ。
転職活動を終えてから年をまたいで1年以上経過、下手すりゃ2回目の年跨ぎを迎えてしまいそうな状況でしたが、今回で本当にファイルです。もうこれ以上タイトル思いつかないし。

使用した媒体

エージェント2社を使用しました。転職サイトやスカウトサービスは未使用。
またエージェントは、大手1社、ITに強そうな中小1社という構成としました。
理由としては、選定にあたっていろいろネットを調べてると
  • キャリアコンサルもピンキリ。外れの場合もあれば、外れではなくても得手不得手があったりするので、エージェントは複数利用した方がよい。
  • 大手は、キャリアコンサル一人あたりの担当人数が多いので、アクションが遅かったりおざなりにされる場合がある。
というような意見を随所で見かけ、まあそうだろうなと納得したので。
ちなみに僕が調べた限りでは、電車の広告などでよく見かけるR社やI社はあまり評判よろしくなさそうです。もちろん、実際はどうかは分かりません。きっとこれもコンサルによるのでしょう。
おすすめエージェント
僕が利用した「大手1社」というのはパソナキャリアなんですが、ここお薦めです。「顧客満足度No1」ということで選んだのですが、本当良かったです。担当コンサルは合計で3人ついてくれて(メイン1名+サブ2名)、前述した「大手はアクションが遅い」は皆無でした。また会社に関する情報は「ここは激務です」「あまりいい噂は聞きません」などと包み隠さず正直に教えてくれた。面接の傾向と対策などの有益な情報やアドバイスも膨大でした。

唯一注文をつけるとすれば、応募した企業一覧、選考の状況などをシステム化してくれてたら尚良かったかな。面接終わった後に、どんな質問があったかなどを担当コンサルに報告するのですが、手段がメールなんですよ。報告内容はおそらくコンサルがコピペしてどっかに記録しているのでしょうけど、システム化してそこに入力して報告するようにすれば、転記の手間が省けると思いますよ。ちなみにもう一つの中小エージェントはそうなってて、非常に便利でした。

一応、中小エージェントについても触れておきましょう。正直、あまり良い印象は持てませんでした。別にコンサルの人柄とかアクションの速さとかには問題なかったですけど、明らかにブラックだろって求人をポンポン持ってくるんですよね(光系列とか)。その会社の内情について質問しても、回答は「そんな事ないですよ」的に浅いもので、パソナキャリアの時のような「包み隠さず」感が感じられず、不信感が募っていきました。情報・アドバイス量もパソナに比べたらずっと少ない。唯一勝ってると言えるのは、前述した転職活動管理をシステム化してることくらい。

まあ、結局は中小エージェントの持ってきた求人に決めちゃったんですけどね(というかそれしか無かった…)。ちなみにその求人の会社(ていうか今の会社)は以前も述べた通りブラックの噂あり(実際どうだったかはこちら)。

ていうか、世の中はすっかりソーシャル転職の普及期ですなぁ。できる人間はエージェントすら必要としない時代となるのか。

数字の報告

自社サービスを持っている企業を中心に挑戦した、今回の転職活動。各種通過数などは以下の通り。
  • 書類選考
    • 応募:21
    • 通過:11
  • 面接(一次、二次)
    • 社数:9
    • 通過:5
  • 最終面接
    • 社数:3
    • 通過:1
結局、1社っす…。書類選考通過率は大体3割くらいらしいのですけど、ご覧の通り僕は5割超え。書類選考通過したってことは、一番の懸念であった「業務系しか経験無い」って経歴でも一応問題なしと見なされたって事で、経歴突破できたのなら割とすんなりいけるんじゃね?と早々に思ったものだけど、そう簡単にはいきませんな。

総括

最初に言いたいのは
「応募資格は満たせてても、結局は経験者有利」
ってことです。結局、中途採用では即戦力が求められますよ、と。「人柄、コミュニケーション、向上心などは問題無い。けど、他の応募者の方が経験豊富なので…」というパターンの多いこと多いこと。冒頭のジョエルのように「才能(≒ポテンシャル)」で選んでる余裕は無いのか…

前述の通り、自社サービスを持ってる企業を中心に応募したのだけれど、質問はどこも似たようなもんでした。サービスに関する質問は「見てみた感想は?」レベルの浅いものが多く、深い・細かい所まで突っ込まれることは殆ど無かったです。僕、面接前には滅茶苦茶使い込んで長短所列挙したりとかなり時間費やしてたのですけど、これには正直拍子抜け。

そういえば、有名企業よりは、非有名少数ベンチャーの方が不通過が多かった。倍率的には非有名の方が低いだろうから難易度も低いかなと思いきや、意外な結果に。ある非有名ベンチャーの面接で「うちはこの通り人数少ないから、フォローする余裕はないので、自分で学習・解決してもらう必要がある」というような事言ってたので、要するに「フォローできないから経験者の方が安心」ってことなんでしょう。

最後の最後に

最後ではないという事を再度お伝えします。結局、収まりきらんかった…
タイトルとの矛盾に関しては「ファイナルファンタジーなんか『ファイナル』とか言っときながら続編出まくってるじゃねぇか!ていうか『XIII-2』とか何だよ!『XIIII』でいいじゃねぇか!」という小学生レベルの回答を送ときます。
ということで、次回作のタイトルは
「おもくそクエストファイナルファンタジーファイナル-2」
で決定。




2011年12月25日日曜日

おもくそクエストファイナルファンタジー

おもくその転職活動冒険譚『おもくそクエスト』シリーズ。
前回の終わりに「次回、完結編。」とかほざいてから7ヶ月強、転職活動終えてからは実に1年以上経過というフレッシュさの欠片も無い状態ですが、物書きのリハビリがてらまだ引っ張ります。つってもいい加減に今回で終わらせますけど。ほら、タイトルをご覧なさい。今までのドラクエにちなんだタイトルと違うでしょ。「終わり」を表す単語でしょ。決して、前回の「Ⅶ」に続く「Ⅷ」の「空と海と大地と呪われし姫君」にちなんだ言葉を思いつけなかったからではありません。

で、結局転職は成功したのかよ

一応成功しました。今回の冒険のそもそもの目的を簡単に纏めると
「向上心が高く、市場価値のある技術を使った仕事に携われ、自分がより成長できるような会社で働きたい」
というもの。
LAMPの仕事させてもらえてるし、みんなめっちゃアンテナはってて勉強してる会社…ということで、目的は達成できました。それに、目的には無かったけど収入も増えたし(※1)。

ただまあ…勤務形態は派遣みたいなもんで客先常駐(大抵1人で)なので、自社社員が優れているかどうかという要素は、一緒に仕事する機会が基本無いから正直あんまり関係無いですけどね。結局は常駐先次第です。この辺の所があるので「一応」成功としました。

ところで、前作でちらっと触れた、会社のブラック説。実態は…僕にとってはブラックではなかったです。ていうか、僕は先にも述べたとおり客先派遣者なので、自社の労働環境は関係ない。「いやいや、IT業界で派遣(人貸し)なんて大抵ブラックな仕事だろう」という意見があるかもしれませんが、案件は誰もが知ってるWeb系企業の直請けが多く、訳分からん会社が間に挟まっている○次請けみたいなのはあまり無く、割と健全な仕事が多い(※2)。実際、ほぼ定時帰りのはたくさんいる(ちなみに僕もその一人)。まあ、立場上どうしても有給休暇はとりづらいですけど(月140時間下回るな圧力)…

「『僕にとっては』ブラックではない」ってことは…

自社勤務である営業や他事業部の人達は、結構な長時間労働&一部ポジションでは半強制?の休日出勤もあるようで、確かにブラックと言われる側面はあるかもしれません。でも仕事=趣味という人が多いようで、みんな好きで働いている模様。それに、不毛に時間を浪費しているのではなく、働いたら働いた分得るものはあるようなので、本人が好きで働いてるならいいんじゃないの。
僕の中でのブラック企業の定義は、
「費やした労力に対するリターンが限りなく少ない」
というものです。その定義から鑑みると、ブラックとまで言うのはちと違うのかな、と。
まあ、仕事≠趣味の人にとっては、得るものがあるとしても長時間労働は堪らないでしょうけど(ちなみに僕はこっち側)。

最後に

これが最後じゃないということをお伝えします。
数字報告やお薦めのエージェントとかいい会社の見分け方とか、もうちょっと書きたい事があるんですけど、もう既に結構な文字数となってしまったので…
次はいい加減本当にファイナライズします。

※1
まあ前の会社が安すぎたから、どこ行っても大抵UPだろうけど。30近くでも基本給の手取りが17万ですからね…

※2
ちなにみ業務系の案件は大抵燃えてます。流石にこれ系での直請けは「上流」会社のもので無理っぽい。この現実を見て、業務系SIerを脱出して本当に良かったとつくづく思った。

2011年5月5日木曜日

おもくそクエストⅦ 停電したし

この頃確か1回停電があったんですよ。サブタイトルがもう全く転職と関係なくなってきたということは、終わりが近づいてきたということです。
おもくその転職活動冒険譚『おもくそクエスト』、第(7 - 2)回。
※第1回を「Ⅲ」にしちゃったからね

2010年11月 第3週 ~ 歴史は変えようがない

さて、前回の冒険でお伝えしていたが、この週は第一志望の最終面接があった。結果は…まあ前回のサブタイトルや結びを見れば明らかですが、玉砕しました。。不通過の理由は、
「その会社の運営サービスで扱っているもの・業界に対する興味が感じられない」
という、根本的な部分に対するもの。…流石、鋭い眼力をお持ちだ。ただ正直、興味が無いということはなく(というか誰しも興味を持つような分野)、行動に移せていないだけだったのだが…「『できる』『できない』じゃなくて『やる』『やらない』」なんて言われるように、行動してないなら「ない」と同義だから仕方がない。

最初の3つの質問で早々に見切りをつけられたのか、面接官5人もいたのに約20分で終了。事前に練っていた運営サービスの改善案やら企画案、競合に勝つための方策をアピールしきる事はできなかった…2週ちょっとで転職活動終焉の妄想は、妄想のまま終わった。

まあこの会社が全てではないし、転職活動なんてこんなものだろと気を取り直し、引き続き他社の選考を進めていった。この週は新たに5社の一次面接を受けた。結果は…先週とは打って変わり、通過は1社…。ちなみにその通った会社はLAMP環境ではなくJava系。結局、LAMP系の会社は全滅だった。どの面接もうまくいって手応えを感じていたのにもかかわらず…不通過の理由はどこも
「向上心があり、人柄が良く、コミュニケーション能力も問題無い。しかし、総合的に比較検討させて頂いた結果…」
というものだった。十中八九、職務経歴(LAMP系の実務経験が無い)が足かせとなっているのだろう。そりゃまあいくら応募資格は満たしていたとはいえ、LAMP系の実務経験ある人間の方がいいよね。上記理由はお愛想の可能性もあるけど、もし真意だとしたら…どうしようもないじゃないか。経歴なんて変えようがないもの…

2010年11月 第4週 ~ 冒険の終わり

この週開始時点での状況は以下の通りだった。
  • 一次面接予定:1
  • 二次面接予定:1
  • 最終面接予定:1
第2週に通過した1社が最終で、第3週で唯一通過した1社が二次。ちなみに第2週に通過した3社の内の残り1社は、技術スキルが圧倒的に足りない事を認識していたので辞退した(会社様には申し訳ないですが、面接慣れ用に応募してました…)。

僕は参っていた。希望していた「マイナーでない技術を使用した自社サービス運営」の会社が全滅してしまったからだ。上記の3社中、2社はそもそも自社サービス運営ではなく受託開発or派遣。その上1社はJava系で自社の独自パッケージ利用が前提。もう1社はLAMP系なのだが、というかLAMP系に限らずいろいろな案件扱っているのだが…って、これどう見ても派遣だろ、ってな会社。しかも会社名で検索すると「ブラック」の噂あり。そう言えばこの会社の一次面接、保有スキルの確認が殆で『面接』というよりも『面談』という感じだった(深く突っ込まれることも無かったし)。というか、この会社を紹介してきた所とは別のエージェントに聞いてみたところ、「いい噂は聞かない」とのお返事。確定じゃねぇか…

残った1社は唯一自社サービス運営してるけど、利用技術がJava系でフレームワークは独自のものを使っているとのこと。そのサービスと会社はかなり有名で、やり甲斐はありそうだけど…独自技術はもう嫌だ。それで今苦労しているようなもんだから…

この週の結果は…唯一の自社サービス運営会社は落選。Java系独自パッケージの会社は一次面接通過し、唯一のLAMP系で人売り臭がする会社からは内定いただいた。

これまでの経緯を鑑みると、これ以上活動を続けても希望の「マイナーでない技術を使用した自社サービス運営」につける気がしない。僕は剣を大地に置いた。


次回、完結編。転職活動の総括、感想と現状報告を行います。
果たして噂通り会社は黒かったのだろうか?

2011年5月3日火曜日

おもくそクエストⅥ 幻の第一志望

新年度明けましておめでとうございます。つっても既に、堪え性のない新入社員が辞める時期である5月ですが。

さて今回は、以前からお伝えしています転職活動記録の続きです。もういい加減にそろそろ書いておかないと、記憶が完全に揮発してしまいそうだ。黄金週間のこのチャンスを逃すと、前回エントリの結びの「また4ヶ月後にお会いしましょう」が現実のものとなりかねない。

2010年11月 第1週 ~ 転職エージェントとの邂逅と希望の光

さて、どう進めていこうか。最近の進め方といえば、大半が以下のどちらかor併用でしょう。
  • 求人情報サイト(リクナビNEXTなど)で自分で探して(orスカウトされて)自分で応募
  • 転職エージェントから紹介してもらう
転職エージェントの場合、非公開求人紹介してくれたり、アドバイス・サポートが受けられたりという恩恵に与れる。けど、企業側からしたらエージェント経由だと手数料払わなくちゃいけないから通常応募の方が有利だとかいう声がある。また、クソなコンサルに当たるとノルマ達成の出汁にされる可能性もあるとか。

僕はとりあえず2社のエージェントに登録し(1社に絞って前述したような『クソなコンサル』に当たったら堪らんので)、並行して転職サイトの情報も追い…というつもりだったが、活動開始してすぐにエージェント一本の路線に変更した。というのは、エージェントから紹介されるお仕事の数だけでもうお腹一杯に…。計40社くらい紹介されたっけな。以前述べた通り、希望はWeb業界で、Web業界と言えばLAMP。それの実務経験が全く無い僕は、応募できる所あるのだろうかと不安で仕方がなかったのだが、蓋を開けたらあら意外、別にPHPやRubyでなくとも「Webアプリケーションの開発経験」が2・3年あればOKという会社が結構多かった。何だ、結構望みはあるんじゃないのか。

最終的に、紹介された中から21社をチョイスし、書類選考に応募。多すぎじゃね?と思ったが、書類選考通過率は大体3割程度だそうなので、これくらいが妥当だそうな。

2010年11月 第2週 ~ 一次面接、襲来。

第1週の段階で、書類選考の結果がいくつか返ってきた。さすがWeb業界、動きが速い。
ちなみに書類選考通過したのは最終的に11社、通過率は5割を超えた。平均以上というのはちょっと嬉しい。

この週の前半は、応募企業の運営サービス(+競合サービス)の研究や、エージェントとの面接対策など、ウォーミングアップを入念に行い、後半に3社の一次面接を受けた。その内の1社は、一次面接完了後2時間もしないで通過の連絡があり、早くも最終面接セッティング。その会社はたくさんのサービスを運営しており、マッシュアップアワードにAPI提供しており、開発合宿を行っているという(その上、Web業界では珍しく残業時間が少なくて有給消化率が高いとか)。面接での印象も良かったし、2chとか検索しても黒い噂は出て来ない。もし最終面接通過したら、もうここに決めてしまおうという心境に。

ちなみにこの週の面接は全て通過!自分で言うのも何だが、俺、面接は結構得意みたい。
何だ、転職活動、意外とイケるんじゃね?


転職活動開始前の不安は何だったんだと思わせるような順調な滑り出し。しかも開始早々、良さ気な会社に出会った。それからというもの、多大な時間を費やしてその会社の運営サービスを研究して改善案・企画案などを練った。そして前述の通り、他の会社の面接も負け無し。マジでこのまま決まってしまうんじゃないかという勢いを我ながら感じていた。というか、「やれやれ、2週間で終わりか」など、既に決まったていで妄想を繰り広げまくっていた。しかし現実はそう甘くはないね…(つづく)

バックナンバー

おもくそクエストシリーズ

2011年2月27日日曜日

おもくそクエストⅤ 転職の鼻っ柱折れ

サブタイトルが何のこっちゃ分かりませんが(ていうかメインもな)、春一番が観測された今日この頃、みなさま明けまくりましておめでとうございます。おもくそは元気です。ここをほったらかしてTwitterの方で述べていますが、転職活動はとっくに完了してます。Web系へのコンバートを目指した今転職活動、その全貌をいま白日の下に。

ちなみに退職したのは2010年9月末日、辞めてから転職活動する道を選びました(参考エントリ)。

2010年10月

最初に起こした行動…それは国勢調査。国民の義務ということで、ちゃんと対応しないと罰則もあるらしいからしょうがないよね。前述の通り既に退職していたので、無職でカウントされるのか~としみじみ思っていたが、どうやら9月最終週時点での状況を記入するとのことで、晴れて『正規の職員・従業員』と回答することに。こうして矛盾が作られていくのか。

次はハローワーク。やはりまだまだ景気は悪いようで、溢れんばかりの人。お役所とは言え業務が業務、来る人の事情が事情なだけに、お役所名物の愛想の悪さ丸出しは見受けられなかった。ただし『対面では』って条件付きだけどね。電話した時の対応の悪さはやはり役所だ(てかそもそも電話に中々出ない。「繋がらない」のではなく「出ない」。「トゥルルル…」までは辿り着けてるから。)。

ちなみにハロワ初日の帰り、昔懐かし(といったら失礼?)auのAndroid端末『IS03』を予約(※1)。その旨をTwitterでつぶやいたところ、それまで1年近く使っててフォロワー20人だっだのが、2・3日で100人突破。ピーク時は160人まで増えた。無条件フォロー返しはしない主義なので、現在は130人程度に落ち着いているけど、時事ネタワードを含めるとこういうことになるんだなということが分かった。

その次に着手したのは…映画鑑賞。以前のエントリで嘆いている通り、日本の労働社会に身を置いていては、映画をのんびり見る時間は中々取れない。だがこの時の私は違う。そのような楔など存在していないのだ。そう言うわけで、TSUTAYAディスカスとDMM.comの1ヶ月無料キャンペーンを利用し、それぞれで8枚ずつ計16作品を鑑賞した。いや~実に幸せなひとときでした。こういう時間はやっぱり必要だよね(※2)。

以上が無職1ヶ月目の活動です。勘の良いあなたならお気づきかと思いますが、転職活動は全く行われていません。この章必要なかったね!

2010年11月

無職期間2ヶ月目。遂におもくそが動き出す。
いよいよ本題に突入…と言いたいところだが、ここまでを振り返ると既に文章量が結構なことになっているので、次回エントリに続かせます。

「この章必要なかったね!」どころか、「このエントリ必要なかったね!」

それでは皆さん、また4ヶ月後にお会いしましょう。

自己フォロー

もちろん勉強はちゃんとしてましたよ。

※1
ちなみにIS03は結局購入してません。Xperiaを待て、待つんだジョー!!

※2
本当は思い切って日本一周とか旅行してみたかったけど、流石にそこまで貯金を切り崩す勇気は無かった…


2010年10月18日月曜日

おもくそクエストⅣ 打ちひしがれし者たち

前回のつづき。前回、以下のような形でエントリを締めた次第であるが…

転職活動という名の冒険へと旅立った勇者おもくそ。
次の城ロマリアに辿り着くには、レベル10は必要だ。
だが、今の僕は…

この場合のロマリアは一体何を意味するのか。転職活動のゴール?いやいや、それなら普通に考えると「ゾーマをぶっ倒す」だろうが。全く、我ながら全く意味が分かりません。エントリのタイトルをあんな風にしてしまったので、ちょっと絡めてみたんだけど、何かに例えて綺麗に纏めるって難しいね。まあ、結局何が言いたかったのかというと
「現在の僕は低レベル」
ということです。まだアリアハン大陸すら脱出できない程に。

僕のスペック…その前に、やりたい仕事は?

希望の職種は今までと変わらず『システム開発』です。やっぱり好きだから。どんな会社で働きたいかは、前回述べた通り『やる気・向上心が高い会社』だ。ここは絶対に譲れない。

次に業種。前回ちらっと述べたが、できればSI業界ではなく、Web業界に行きたい。今までいろいろなIT系企業の仕事内容紹介の記事や、IT業界人のブログを読んだり、あるいは直接話を伺うなどして集めた情報によると、どうもWeb業界の仕事の方が面白くてやり甲斐ありそうだ。以下、それら情報を基に、それぞれの業界に対する僕の印象。

要素SI業界Web業界
市場の行方縮小は確実。要因は以下。
・SaaSやERPパッケージの普及
・オフショア企業の台頭
拡大。ソーシャル系サービスの需要が増える。スマートフォン、iPad等のタブレットPCの普及が進めば、さらに拡大するか。
仕事内容 総じて、上流か下流かの2択(そうじゃない場合もあるだろうけど)。
今後、上流は要件聞いてそれに適したサービス選定や、経営戦略などの超上流にシフト?
下流は…仕事あるのか?
企画発案からプログラミング、運用、改善など、一気通貫
開発プロセス ウォーターフォールがメイン
※アジャイルも増えてきてはいるようだが…
アジャイル(でないと捌けない)
最新技術に対する
積極性(※1
総じて低い?
リスクは少しでも抑えたがる。
SIerよりは高い?
ということで、
僕にとっての
やり甲斐は…
無さ気。
上流会社だとプログラミング機会少ないし、下流だとそもそも生きられなさそう…
SIよりは確実にありそう。

まあ、SIerでも全工程担当&最新技術に積極的な会社はあるだろうし、Web業界でも実装は外注&最新技術に消極的な会社ってのは絶対いるだろうから、結局ピンキリだろうけどね。でも大体は上記のような傾向だと思う。
 
最期に、扱いたい技術。ぶっちゃけ『話のネタになる・技術を通じて人脈拡大できるような有名どころ』であれば何でもいい。大きな括りだと、RIA、クラウド、スマートフォンアプリ…など。小さな括りだと、Ruby on Rails、Flex、AIR、Silverlight…など。とにかく「何それ?」って言われるようなマイナーなものでなければ何でもOKです。「『何でもやります!』と言うのはダメ。ゼッタイ。」というのは心得ているが、実際どの技術にも興味があるのでしょうがない。まあでも1個決めろと言われれば、Androidアプリ開発かな。

ここで本題。僕のスペック

実務経験年数
4年6ヶ月
年齢
28 ※早生まれなので、今年度29
リーダー経験
無し。それどころかSE経験も碌に無し(4ヶ月のみ)。
主な経験言語(事情により、全て手続き型実装) ※単位:ヶ月
Java 1.4:33.5
Java 5.0:6
C# 1.1:3
C# 2.0:2
VB 2008:4
主な経験FW ※単位:ヶ月
某商用Javaフレームワーク:37.5
.NET Framework 1.1:3
.NET Framework 2.0:2
.NET Framework 3.5 SP1:4
その他補足
実務におけるOOP、デザインパターン利用経験なし
必然的にUML作成・閲覧経験もなし
実務におけるTDD経験なし
Trac Lightningのディープな利用経験なし ※プラグイン作成とか
太字の部分に注目してください。どうですか?お客さん。市場価値ないでしょ?僕のキャリアの殆どは、某商用Javaフレームワークです。打ち込んできたJavaコードの殆どは、フレームワークに依存したもの。フレームワークが有名で普及しているモノであればいいんだけど、勉強会などで同業他社の方に尋ねても、まあ知ってる人はいなかった。一人だけ(マジで一人だけ)使った事あるという方が見つかったのだが、一言「使いにくい」。高評価をくだした人間には、結局会うことは無かった。話やブログのネタにもできないし(ブログに載せたら確実に正体ばれる)…「マイナー技術は嫌だ!」と嘆くのは、こういう訳です。

そして何よりも致命的なのは、オブジェクト指向プログラミング経験が皆無ということ。前に自分でも書いたが、オブジェクト指向してない内はJava初級だ

これが、まだアリアハン大陸を脱出できないと嘆く所以である(※2)。


さて、嘆いてばかりいても仕方がない。レベルが足りないならレベルを上げるしかない…ん?またまた声が聞こえる。
「今の時代、PCとネット環境あれば自宅で勉強できるだろ?今までやってこなかったのか?」と。
これ言われると、弁明の余地はありません…いや、断言する。勉強はたくさんしてきた。Googleリーダーの統計情報や、Googleウェブ履歴がそれを証明してくれる。ただ…「実際に手を動かしてコードを書く」ことを殆どしてこなかった。これはよくなかったかもしれない。別に面倒臭いとかいうわけじゃなく、単に効率的に時間を使いたかったからだ。前述の通り、いろいろな技術に興味があるので、RSSで熟読する記事も多岐にわたる。手も動かすとなると、とてもじゃないが時間が足りない。それに、手を動かしてきっちり身につけたところで、変化の早いIT業界、すぐに陳腐化してしまう可能性大だ。それならば、とりあえずは概要・文法・思想といった部分を広く浅く把握しておき、実務で使用するタイミングになったら深く学習する方が効率的でいいのではと思うのだが…どうなんでしょう。間違ってますかね?

※1
この辺に関しては、SonicGardenの倉貫氏の以下エントリに非常に感銘を受けました。

※2
自慢じゃないけど、こんな僕でも、驚く事に会社の中ではエース級だったんですけどね。何らかの技術系コミュニティで有名というわけでも無く、ブログの技術記事のレベルが高いわけでも無い、こんな僕が…。プログラマという職業、人によって100倍以上の生産性の開きがあるという話は有名だが、これはきっと会社単位でも当てはまるのだろう。


2010年10月14日木曜日

おもくそクエストⅢ そして転職へ…

9月末をもって退職した。転職先が決まる前に辞めた。
というわけで現在、いわゆる無職である。

退職理由としては、「Web業界で働きたい」というのが一応メインではありますが、もう一つの理由として
「仕事に対してモチベーション低く、技術に対する興味や向上心が無い(必然的に技術スキルも低い)、こんな会社では成長できない!」
というものがある。他人の言葉を借りると「『熱い人』がいない。」

決定的な決め手となったのは『クラウドやAndroidが何かすら知らない上司』『SQLインジェクションを知らないベテラン技術者達』だ。あれで完全に踏ん切りがついた。他にはこんなのも。転職活動において「後ろ向きな退職理由はダメ。ゼッタイ。」というのが基本なので、前向きな理由に置換しますと
「仕事に対してモチベーション高く、技術に対する興味や向上心も高い、そのような会社で切磋琢磨して永遠に成長していきたい!」
といった所だ。
いや、正確には後者の前向きな気持ちが先にあったからこそ生じた「こんな会社でやってられるか!」である。

おや、声が聞こえる。
「周りのせいにするな!」「周りを変えようと頑張ったのか?」と。
はい、ごもっともです。不肖おもくそ、少しは頑張りました。ですが、人の心を動かすのは非常に難しいのです…(※1)。時間をかけて粘り強く頑張り続ければ、確かにいつかは変えられるかもしれない。その時の達成感は、きっと筆舌に尽くしがたいものがあるだろう。だが、変えられないかもしれない。そして、時間(人生)は有限だ。日々、少しでも楽しく生きていきたい。僅かな変化の可能性に賭けて数年の時間をその会社のために費やすのは、イヤだ。僕はその会社のために生きているのではない。

ところで、転職する時は「決まるまで辞めるな」というのがセオリーという意見はよく聞く。僕は別に『セオリー』だとは思わない。使い古された言葉だが、仕事というものは人生の大半を占めるものであり、それが人生に与える影響は甚大だ。その仕事を探す作業である転職活動というもの、片手間に行うべきではなく、じっくりしっかり取り組むべき。僕は常々そう思っている。

というわけで、転職活動という名の冒険へと旅立った勇者おもくそ。
次の城ロマリアに辿り着くには、レベル10は必要だ。
だが、今の僕は…
(つづく)

ところで

君は勇者に「うんこす」と名付けたことがあるかい?


※1
参考エントリ
ドラクエⅢ貼ろうと思ったけど、DSあたりで発売されてるモノと思いきや無いんですね。
では「次のステージッに~ゆきましょう♪」ってことで。

2010年8月16日月曜日

オラ、焼け野原しんのすけだゾ! その5(完) Trac横転

炎上プロジェクト記録、完結編。

Trac、稟議通らず

当プロジェクトの作業場所は客先。よって、ハードウェアは客先のものを利用することになるので、Tracのようなサーバソフトウェアのインストールには申請が必要(※1)。セキュリティに五月蠅い企業なので、こういった申請のフローは複雑・面倒で時間がかかり、散々待たされた挙げ句NGということが屡々。しかし、Tracに関しては、別会社主導のプロジェクトで利用実績があったので、すんなり通るだろうと皆高を括っていた。それでも申請してすぐOK出るかというと流石に厳しいので、それまでは僕のPCにインストールして利用することとなった。

結果…何とNG。情報共有ならグループウェアNがあるし、タスクリストはExcelでいいじゃないですかとのこと。Excelで情報共有する事の愚かしさなんて過去に語り尽くされたし、グループウェアNは全文検索ができない(※2)。今時、Webで情報検索する時、カテゴリ辿りますか?キーワード検索でしょ?キーワード検索の方が遙かに楽でしょ?
上記の事を(勿論大人の対応で)伝えて頑張ってみたが、玉砕。某社はOKだったのに…会社力の違いか?それとも俺の力不足か?
一応、現状の環境(僕のPC上で稼働)を利用する許可は頂けたのだが…何だかなぁ…(※3

Trac < Excel

今年の1月の私。
・仕事が楽しくなってきた。『Trac Lightning』を利用して開発プロセスのChange(死語)に取り組んでいるからだ。
・懸念していた「面倒くせ~」といった反発もなく、むしろ積極的に利用してくれており…
・非常に充実している
この頃はまだ平和だったからなぁ…

プロジェクト序盤は、上記の通りそれなりに利用されていた。しかし火を噴いた中盤以降、
「Excelの方が記入楽。チケット登録するのって面倒臭い。」
「口頭の方が速い」
「チケットだと集計がしづらい。Excelならマクロが使える。」
等の難癖をつけだし(上も下も)、殆ど利用されなくなった。
人間の本質は、やはり追い込まれてから現れる。

「チケット登録の手間とExcel記入のそれの間に大きな差があるとは思えない。」
「Tracには集計に利用できるクエリ機能というものが備わっている。SQLを使えるので、マクロ組むよりは絶対簡単。どうしてもExcelで欲しいという場合でも、Excel形式でダウンロードできるので、チケット登録しておいて損はない。」
「今回、Tracによる管理に取り組んでいる第一の目的は、ノウハウ蓄積。やり方戻したら、今まで通り何にも残りませんよ!」
そしてここでもExcelで情報共有することの愚かしさと共に、上記事項を伝えて頑張ったが、再び玉砕。中盤以降は、質問は殆ど『口頭』、Excel管理すらされていない状況。バグ一覧表とかは流石にExcel作っていたが(それこそTracの役割なのに…)。てか、あんだけ「Excelじゃないと集計できない」とか言ってた癖に、出来上がったExcelファイル見た限り、集計なんてしてる気配が全くない。あの啖呵は一体何だったのだ?

口頭至上主義

その2その3でお伝えした、DBアクセスロジックの仕様分裂問題。この問題の対応がどうしても納得いかず、はらわた煮えくりかえっていたので、プロジェクト完了後に改めて直訴した。こちらの最大の主張は、
「『意見があれば言ってください』と伝えており、さらに使えない旨を伝えて向こうは『了解した』と言ったにもかかわらず、勝手なことをしていた」
という点。ちなみにこの遣り取りのメールは、本文冒頭に「マネージャー陣も含めて全員必ず読んでください」という一文を赤太字で含めていた(レビュー時のリアクションを考えると、ここまでしても読んでなかったようだが)。
するとマネージャーは
「口頭で遣り取りしなかったからだ。」
…わからん。世の中、そういうものなのか?その時も、こうして文書書いている今も、これに対して何て返事していいかわからない。
「読字障害をお持ちなんですか?」という言葉が危うく喉から出かけた。
てか、フロアが結構離れてるっつーの。一々口頭でなんて、非効率すぎる。

まあ、殆どのメンバーはその『口頭』方式を実践してましたが…
うちの会社、分散開発は絶対無理だなと実感した次第。それとノウハウの蓄積・見える化も。
「どんなにすぐれたツール・システムを導入した所で、使う人間に使う意志が無ければ…」という、ありがちな台詞がこの身を貫く。

※1
ちなみに、PCの場合は「Vector・窓の杜で公開されている『フリーウェア』は自由にインストールしてよいが、それ以外はNG」という、厳しいんだか厳しくないんだかよく分からんというもの。とにかく、どんなに有名・信頼のおけるツールであろうと、上記サイトで公開されてなければNG。秀丸もATOKもNG。ギークがキレる職場。

※2
或いは備わっていたのかもしれないが、少なくともその顧客は利用していなかった。

※3
僕のPCのパフォーマンス悪化を懸念していたが、後述する通りTracは殆ど利用されなかったので、それ程支障は無かった。嬉しいような悲しいような…


ガキの頃よく唄ってた初代オープニング、唄うは亀田誠治の嫁。

2010年8月15日日曜日

オラ、焼け野原しんのすけだゾ! その4 プログラミング力≒片付け力

気がつけば本日は終戦記念日。そんな日にこんなタイトルのエントリ、不謹慎か?



さて、これまで3回に分けて行ってきた、炎上プロジェクトの1人ふりかえり(その1 その2 その3)。致命的レベルの問題のふりかえりは粗方完了した。私の仕事力・文章力不足もあり、Tryの内容・表現がショボかったり、そもそもエントリ自体が愚痴っぽくなっているかもしれないが、それは追々改善していこうと思う。

当エントリからは、プロジェクトに対するその他の考察・感想・愚痴などを記す。

プログラミング力≒片付け力

プログラマに対して、私はある偏見を抱いている。それは
「デスクトップやブックマークが汚い者は、総じてソースコードも汚い」
というものだ。
プログラミングは、結局は『整理整頓』作業の連続だ。固定値の定数化、何度も使用するロジックの関数化・クラス化、関数化・クラス化する際はどのように分割するのがベストか、無駄・冗長な記述を如何に抑えるかetc…。よって、僕が思うに、プログラミングで一番必要なのは、『整理整頓力』とか『片付け力』とでも言う力だと思う(※1)。
そしてこの力の有無を如実に露わにしてくれるのが、デスクトップやブックマークだ。『片付け力』の無い者は、フォルダやタグで系統立てて整理することを碌に行わず、混沌と化している(フォルダの命名も分かりにくかったり…)。

『片付け力』という力。この力は、向上させるといういう意識を持って取り組まなければ、向上するものでは無い。人生経験、仕事のキャリアを積んでいけば自動的に向上するというものではないのだ。皆も今までたくさん見てきたことであろう、部屋を『片付けられない大人たち』を。
プログラミングも同じで、整理整頓された綺麗なコード書いてやるぞ!という意識が無い者は、いくらプログラミング経験を積んだところで、生み出すコードは汚いままだ(※2)。

以上より、『Problem6:技術力はキャリアの長さに比例するという認識』には、大いに異を唱えたい。

上記偏見、僕の少ないキャリアで見てきた限りでは大体当たっていると思うが、皆さんの周りではどうだろうか?


※1
この理屈だと、「ソースコードが汚い人間は、デスク周りや部屋も汚い」という事になる。確かにその通りの者は多い。そうでは無い者、つまりソースコードの割にデスク周りなどは綺麗な者は、得てして『八方美人』が多いというのが僕のもう一つの偏見だ。現在のプロジェクトにもそういう輩がいる。目に付く範囲ではきちんとする、普段は遅刻してる癖に、マネージャーがいる日だけは遅刻しないという…それも1人だけではない…鼻折りたい。

※2
経験を積むことで、既存のライブラリだけでどれだけの事ができるかという知識が蓄積され、所謂『車輪の再発明』をやってしまう可能性は減少し、「無駄・冗長な記述を抑える」に繋がる事は確かにある。
が、根本的に『片付け力』が備わっていなければ、焼け石に水だろう。

2010年8月14日土曜日

オラ、焼け野原しんのすけだゾ! その3 技術力∝キャリア?(後)

前回のあらすじ。
DBアクセスロジックに関して、どのように実装するかの方針を開発者全員で打合せを行い合意形成。その後に意見は何も出なかったのでフィックスし、製造フェーズが開始された。
製造フェーズが開始されて数日後、メンバーの1人から「DBアクセスの仕組みを作った」との連絡が。内容を確認した所、致命的な問題も含まれており、そもそもフィックス済みの方針と異なるので、採用できない旨を伝える。その後、了承した旨の返事を受け取る。これで一件落着かと思われたが…
メールの遣り取りがあった次の週、コードレビューが実施された。内容は、コーディング・命名規約等が遵守されているかどうかをチェックするというもので、「ここはこう実装した方がいいんじゃない?」というようなリファクタ目的ではない。
※ちなみにコードレビューは結局この1回限りだけだった。何だかなぁー…

今回のシステムは、大きく分けて画面系とバッチ系に分かれていた。プログラマは全6名で、その内2名がバッチ系担当、その他4名が画面系担当だ。全てのソースコードをレビューする時間的余裕は無かったので、画面系・バッチ系それぞれから代表して1つの機能を抜粋し、それに対してレビューを実施した。画面系の代表は私が製造した機能だ。まず私のコードのレビューを行い、つづいてバッチ代表の番となった。途中まで淡々と進んでいたが、DBアクセスロジック部分で問題発覚。バッチ側のコードが、開発者間で合意形成した決定事項を遵守していない。 先週のメールで遣り取りした「採用できない」仕組みのままだ。
同席していたリーダー(以下、L)が

L「何で分裂しているの?統一してください。」

とごもっともな一言。いや、ごもっともじゃないな、ここは違反している側に対して「規約を遵守してください」じゃないのか?
「統一せよ」ではなくて「違反している側は遵守せよ」が正当である旨と、そもそもこの仕組みは「採用できない」旨を伝えたところ、その仕組みを作った人物(以下、X)曰く

X「致命的な問題は修正したので問題無い。」

との事。どうやら、SQL文実行クラスを、Java標準のものから、フレームワーク標準のDBアクセスクラスに変更した、これで要件満たせるとの事。いや、もうそう言う問題じゃ無いんですけど。約束事を守っていないんですよ。
すると、

L「何でちゃんと話し合っておかないの!とにかく統一してください。」

私「こちらはその話し合った末の結論に従っています。それに、結論出た後も度々『意見があれば言ってください』って伝えてましたが、このような仕組みを作っている事に関して、何も連絡ありませんでした。致命的な問題の修正に関してもそうです。」

約束事は度々破るわ、技術的にも使えるものでは無いわ…折衷案があるような問題でも無いし、こちらとしては全く譲歩する気は無い。その旨伝えた所、

X「こっちの修正は無理。もう大分作り込んであるから。」

…わからん。何ですか、この威風堂々っぷりは。
しかし、もっとわからないのは、リーダー陣はどうもXの方を支持しているらしいという現実だ。
その心は、前回エントリで挙げた
Problem6:技術力はキャリアの長さに比例するという認識。つまり、キャリアが短い者の言うことよりは、長い者の方が正しいという価値観。によるものだ。
5年目の若造よりも、10年以上の付き合いがあって仕事も速く(※1)て信頼できるベテランの方が正しいと考えてる感がひしひしと伝わってくる。「Xさんが言うなら間違いない!」という台詞を何度聞いたことか。実は、「致命的な問題は修正した」と言っておきながら、相変わらずPreparedStatement使ってなかったので(※2)、この点に関して突っ込んだのだが、ここでも終始「Xさんが言ってるんだから…」という感じだった(※3)。

結局、約束事を守っていたのは画面チームの3人で、画面の1人とバッチチームは例の「採用できない」仕組みを利用していた。再度話し合って決定しろという事になったが、そこでの遣り取り・雰囲気を考えると、「話し合え」なんて只のポーズであることは明らかだ。結論なんて、既に決まっている…結局、約束事を守っていた3人が、血を吐く羽目となった。



後で聞いた話だが、バッチチームが独自の仕組みを作ったのは、マネージャーの命令だったとのこと。バッチ系プログラムは、将来的にフレームワークを変更した場合も利用できるように、フレームワークに依存しない作りにしたかったそうだ。
…いやいや、それなら、画面系と統一させる必要なんてないじゃないか…ったく、リーダーは偉そうに「ちゃんと話し合え!」と言っていたが、そっちだってマネージャーと意思疎通できてないじゃないか。
それに、「フレームワークに依存しない作り」なんてものは、顧客は望んでいなかった。一応、プログラマ・リーダーという立場のため、クラス構成の説明等を顧客に説明しなければならない機会があったのだが、
「何でこんなややこしい作りにしてるんですか?」
「フレームワークに依存しない作り?でも結局フレームワークのライブラリ使ってますよね?」
「ハッキリ言って非常にわかりづらくて、保守しづらいです。」
と、散々だった。はい、全く仰る通りです…
マネージャーはその旨伝えてあると言っていたが、この時の遣り取りを鑑みるに、全然伝わってないことは明確だ。YAGNIの原則について勉強してください。




さて、今回のProblemをおさらい。
  • Problem5:開発者間で決定するように指示した事項に関して、その決定事項の内容確認、及びそれらが遵守されているかどうかを確認しなかった。
  • Problem6:技術力はキャリアの長さに比例するという認識。つまり、キャリアが短い者の言うことよりは、長い者の方が正しいという価値観。
これらを解決するためにTryしなければならないことは?
  • Try5:
    …わからん。確認してもらったところで、Problem6が存在する限り、覆る可能性は常に存在する。
  • Try6:
    価値観を変えさせるのは非常に困難。よって、「技術力がある」と思われるようになるしかない…のか?

※1
確かに仕事は速い。だが質はどうかというと…↓

※2
PreparedStatement使わない理由を尋ねると、「SQLがキャッシュされると、大量のSQL実行した場合、サーバーのメモリ食い尽くして落ちる」とのお答えが。いやいや、キャッシュしない(使い回さない)方がメモリ食い尽くすと思うが?それ以前に、メモリ食い尽くす程の量のSQLをPreparedStatement使わないで実行してたら、パフォーマンスの面を絶対クリアできない。
ちなみに、SQLインジェクション脆弱性に関しては、「エスケープ処理は(パラメータ)渡す側の仕事」だそうだ。絶対間違っている。PreparedStatement使う方が、遙かに簡単・安全・確実だ。

※3
この遣り取りで、開発チームの誰もがSQLインジェクションを知らないらしいという事実が判明。



懐かし。『ESCAPE』よりは『アネモネ』の方が好きだったなー

2010年8月13日金曜日

オラ、焼け野原しんのすけだゾ! その2 技術力∝キャリア?(前)

「燃えるゴミのほうに燃えないゴミ入れたらダメですよ。
でも燃えないゴミのほうに燃えるゴミ入れるのは別にエエやん」
~ by 松本人志 at 松紳とか放送室とか
松ちゃん、それは屁理屈だ。

さて、前回に引き続き、ふりかえりを行う…って、1ヶ月近く経ってるじゃねぇか。この間一体何してたのかというと、ロシア状態ですわ、また…
  • Problem5:開発者間で決定するように指示した事項に関して、その決定事項の内容確認、及びそれらが遵守されているかどうかを確認しなかった。
  • Problem6:技術力はキャリアの長さに比例するという認識。つまり、キャリアが短い者の言うことよりは、長い者の方が正しいという価値観。
詳細設計フェーズも終盤に差し掛かった頃、DBアクセスロジックの実装の規約・方針を決めておくように上から指示された。

Java言語(というよりオブジェクト指向言語)でDBアクセスといえば、DAO・DTOと呼ばれるクラス群(+ORマッパー)で行うのが一般的だ。開発を何年も行っていれば、どこの会社も大抵はプチフレームワークとでも言うような仕組み・パターンを構築しているものだろうが…うちの会社はさにあらず、全社標準の規約というようなものは存在しない。コーディングは疎か、仕様書のフォーマットなども、プロジェクトによってまちまちだ。外部から参画している1人のメンバーは「(全社標準規約的なもの)無いの!?駆け出しの会社じゃあるまいし、普通作るよね…」と呆れ顔だ。
※規約が無い事もさることながら、その現実に対して何ら疑問を持ったり改善しようとしてこなかった古参社員にはもっと…

閑話休題。さて、話し合い、今回のプロジェクトではどうするか…ぶっちゃけ、特に話し合うことなどは無かった。どういう事かというと、
  1. 当プロジェクトで利用するフレームワークのライブラリに、DBアクセスクラスは用意されている。
    ※SELECT・FROMといったSQLの要素をプロパティとしてセットし、それを元にSQL文を生成し、SELECT文であれば検索結果をHashMap的なオブジェクト(の配列)で返すといったクラス。
  2. このフレームワークのシステムでは、1.のクラスを用いるのが一般的というか当然。
    同じフレームワークで構築した他のシステムにおいても、勿論上記クラスを使用している。
  3. 1.のクラス使用すると、ログ出力・主キーにセットするシーケンスの採番等、『おまけ』処理も自動で行ってくれる。
  4. 3.のおまけ処理に関して、顧客から要望が挙がっている。つまり、顧客も1.のクラスを使用するものだとの認識でいる。つまり、「1.のクラスを利用する」ことは、暗黙的ではあるが顧客の要件である。
  5. 作ったシステムを保守するのは顧客自身。顧客(情シス部門)はSIerと異なり、保守的なスタンスであり、あまり新しい事にチャレンジしたり覚えたりしたがらない。
    よって、2.で述べた他の既存システムとあまり外れた方法をとるべきではない。むしろ揃えるべき。
と、言うわけで、選択の余地など無い。DAOやらDTOやらクラス設計どうするというような大規模な取り決めなど不要。こちらで出来ることと言えば、上記DBアクセスクラスをラッピングすることくらい。
結局、上記5項目を全員に伝えた上で、どういう単位でラッピングするかという事だけで終了。話し合いは意見が衝突するようなこともなく、「意見は?」の問いに誰も挙手せず。話し合い終了後も意見は出ることもなかったので、フィックスし、数日後に製造フェーズは開始となった。

製造フェーズが始まって数日、あるベテランプログラマから連絡が入った。
「DBアクセスを行う仕組みを作った、概要・使い方を説明したいので、時間取れないか?」と。
…はて、フィックス済みだが。ユーティリティー的なものを作りましたってことなのか?でもそれにしては「時間取れないか?」って大袈裟だよな。
この時点で進捗に遅れが発生していたこともあり、あまり時間をかけたくなかったので、とりあえずソースコードを見せてもらった。

…結果、絶句。 本当に仕組みを0から作ってやがる。
SELECT・FROMといったSQLの要素を引数で渡し、それを元にJava標準のStatementやResultSetを使用してDBアクセス、SELECT文であれば検索結果をHashMap(の配列)で返すといった仕組みだ。
前述の1.のDBアクセスクラスと、内容どんがぶりである。激しく無意味だ。そして、無意味なだけでなく、致命的な問題点も含んでいる。
  • 致命的な問題
    • 顧客の要件を満たせない(ログ出力等)
    • PreparedStatement使用していないので、SQLインジェクション脆弱性が存在!
  • 致命的では無いが…
    • インターフェイスをテーブル単位で作成する必要があるなど、クラス数が増大する。 今までのやり方と異なる事もあり、顧客からクレームが来る可能性大。
      ※フレームワーク標準のDBアクセスクラスは、DB情報は設定ファイルから取得するので、このような余計なクラスは不要。
    • SQLの要素を渡す手段が引数だと、その組合せの数だけ引数違いのメソッドを用意しなければならない。
      ※SELECT、FROM以外は必須じゃないからね。必要無い場合はNULLで渡すなんてイケてないし。
    • そもそも、この仕組みで行えることは、フレームワーク標準のDBアクセスクラスで全て実現可能。しかも、より簡単かつスマートに。
PreparedStatement使ってないのは本当にビックリした。『いろはのい』だぞ?何年やってんだ…
上述の通り、採用できないのは明らか。加えて、そもそも既にこれに関してはフィックス済みで、その決定内容で製造フェーズが開始されてしまっている。このような案があるなら、何故事前に連絡をくれなかったのか?
そのような事も添えて、この仕組みは採用できない旨をメール送信。ここでも「意見があれば言ってください。」の一文と共に。結果、「了解した」との素っ気ない返事。ちょっとイラっとしたが、取り敢えず一件落着…と思っていた…

そのような遣り取りがあった次の週、我が社では珍しく(というか恐らく初の)コードレビューが実施された。 そこで明らかされたのは、開発者間打合せ、上記のようなメールの遣り取りを経たにもかかわらず、決定事項が守られていないという現実…しかも、6人中3人も。

思ってた以上に長くなったので、エントリ分ける。つづく。


ちなみにCoccoで一番好きな曲は『寓話。』です。

2010年7月18日日曜日

オラ、焼け野原しんのすけだゾ! その1 基本設計=画面「のみ」設計?

「『燃えない』ゴミの収集日、何でよりにもよって火曜日やねん!」
~ by 千原ジュニア at 人志松本のゆるせない話

あー疲れた。かねてから述べていたプチ炎上プロジェクトがようやく鎮火した(まだ燻ってはいるが)。これでやっと開発フェーズは完了となった。

さて、プロジェクトが一段落ついたら、KPT方式などでふりかえりを行い、仕事をカイゼンしていくといった活動を普通は行うものなのだが…うちの会社はさにあらず。正確に言うと、その文化は全く無いわけではないのだが、弱い。実際、今回のプロジェクトでは実施されていない。プロジェクトが炎上したにもかかわらず、である。プロジェクトが大成功したわけでもないのに、である(てか、成功したとしても必要だ)。

今回のプロジェクトの炎上原因は、見積もりが甘かったとか要件肥大化したなど、よくありがちな要因によるところもあるのだが、最大の原因は、そもそも仕事の進め方・考え方が根本的に間違っていたことである気がしてならない。いや、「気がする」ではなく「間違っている」と断言できる自信はある。
しかし前述の通りふりかえりは行われず。そして(あまり言いたくないけど)周りは殆ど職業プログラマばかりで、議論をして進言して現状を変えていこうという気概のある者がいない…

というわけで、自ブログにて1人でひっそりとふりかえりを行うことにした。
問題の雲散霧消を防ぐためにも、そして自分の考えが本当に正しいかどうかを記録に残しておくためにも。そのうち@IT会議室とかに投稿して、集合知の意見を聞いてみようと思う。

  • Problem1:基本設計=画面「のみ」設計であるという認識
  • Problem2:メンバーの成長のために仕事を任せるのは良いが、その仕事に必要な準備・情報が全然足りていない。
  • Problem3:そんな状態なので、当然いろいろと意見を述べた所、マネージャーは「(悪い意味での)思ってた通りの反応だ!」「もう知らん!」ってな具合になったらしい。
  • Problem4:では一体何がいけなかったのか、どう進めていくべきだったのかなどの、フォロー・フィードバックが結局無い。
    ※3の件は、マネージャと同じフロアで仕事していた人から、プロジェクト完了『1ヶ月後』に聞いた。
私が参画したのは詳細設計フェーズから。詳細設計を行うにあたり渡された資料は、画面イメージHTML『のみ』。入出力項目定義や業務フローの資料は一切無い。ER図は一応あったものの、テーブル・フィールド・リレーションどれをとっても明らかに不足しており、明らかに未完成だ。
料理を作るのに、完成図だけ見せて「これ作って」と言われても、何を望んでいるかが分からなければ、お口に合うものなど作れるわけがない。お客さんはどんな料理を欲しているのか、どんな材料を使うのか、そういう情報が必要だ。

基本設計書の有無・DB設計の状況をマネージャーに確認したところ、彼はこう言い切った。
「基本設計工程では、画面『のみ』を設計する。業務フローなどは詳細設計フェーズで行うことだ。」
「テーブル設計も詳細設計と並行して行う」
いやいや、その認識、絶対間違ってると思うんですけど!?
…まあ、よかろう。認識間違いはとりあえず置いておくとして、要は我々に『一般的な意味』での『基本設計』をさせようということですね? それならそれで問題が多々あります。マネージャー・リーダー陣は「この進め方で問題あるなら伝えてください」と言っているので、以下のような事を伝えた。
  • 今回実現する要件を纏めた資料が見つからない。今ある要件定義書は、元々の肥大化しすぎた状態のまま。これでは、我々は結局どういったものを作ればよいかが分からない。
    ※今回のプロジェクトは、元々大手ベンダーが要件定義を行なっていたが、肥大化しすぎて見積金額が膨大となりお客さんが怒ってしまったので、(単価の安い)私の会社が引き継ぎ、要件は取捨選択することとなった。
  • 機能毎(詳細設計の単位)で各人がDB設計を行うやり方だと、DB定義に矛盾や重複などが発生する可能性大。
    また、重要度が低い機能は、他の機能の製造・テスト完了後に詳細設計を行う予定となっている。これでは低重要度機能の詳細設計時、その機能の都合でDB定義が変更される可能性があり、もし発生した場合、当然影響範囲の機能の手戻り修正が発生する。これは凄く非効率。
    せめて『DB設計』というサブフェーズを設け、そこで一斉に行うべき。
  • そもそも工数が足りていない。『基本設計』も行わせるのなら、それ用の工数も盛り込んでおいてもらわないと困る。
で、マネージャー陣からの回答。
  • 「元々の要件定義書から自分で考えること。不明点は質問してくれれば対応する。」
  • 「DB定義に関しては、矛盾が生じないように、ちゃんと開発者間で話し合うこと」
…うーん、やっぱり何か違うと思うが。 時間が潤沢にあるなら、もちろん勉強になるので全然こんなやり方でも良いのだが。 てか、やっぱり工数に関しては何にも無しか。

そういうわけで、進め方に関していろいろと意見を述べてたら、前述のProblem3発生ですよ。プロジェクト中は全く知る由も無かったけど。

また要件に関しては、「要件に関しての不明点は質問しろ」と言っているので、(もちろん、ちゃんと考える事を行った上で)遠慮無く質問投げていると、いつしか
「詳細設計レビューでまとめて回答する」
との流れに。いやいや、詳細設計行うのに必要な情報を尋ねているのに、回答が詳細設計完了後に行う工程て… 結果、詳細設計レビューは、(マネージャー陣に対する)要件の確認から始まったため、殆どの機能で1人日を超える工数を消費。そしてそれだけ時間をかけてレビューを行っても、要件漏れ多発。これまたマネージャー陣の『頭の中』にしか無かったもの大半。特にエラーチェック。どういう場合にエラーにするかなんて、要件定義書も概要設計書も無く、お客さんと遣り取りする権限も無いのに、分かるかっ!!
またDB設計も案の定、フェーズ後半で詳細設計着手した機能の都合でそれまでのDB定義が変更され、テスト完了済みの機能で手戻り発生…

このマネージャー、今までもずっとこんなやり方をしてきたのだろうか。だとすれば、よく今までやってこれたなと、逆の意味で感心した次第である。 僕の認識では、以下の設計は基本設計工程で行うものだと思っている。
  • 業務フロー作成
  • 画面設計(入出力項目定義、画面遷移)
  • DB設計
分かり切ってはいるものの一応ネット等で改めて調べてみたところ、僕の認識は間違ってはないと思う。V字モデルでは、総合テストは基本設計と対応するとされているし。これに準じた場合、うちの会社の定義の基本設計だと、総合テストのテストケースは画面レイアウトの確認だけとなってしまう。そんなバカな話があるか。
さて、では上記Problemを解決するためにTryしなければならないことは一体何なのか。
  • Try1:システム開発に関して勉強し直してください。もうホントに根本的に間違ってるから。
  • Try2:必要な情報を準備してくださいとしか言いようがありません。
    錬金術師をもってしても、『無』から『有』を作り出すことはできません。
  • Try3:
    Try4:
    何故『見限る』ということになるのか、およそ管理職らしからぬ行動は全く理解できません。我々に不備があったのならば、それを指摘・叱責するなどしてフィードバックしてくださいよ。
    これでは、我々も会社も成長できませんよ。


↓大人が観ても面白いと、松本・高須がラジオで絶賛してた作品

2010年4月4日日曜日

僕なりに波紋は起こしているつもりなので、今はご容赦…

~孫正義 LIVE 2011~
世の中が悪いとか、政治家が悪いとか、景気が悪いとか、そんな言い訳を言うとったんじゃ、そんな愚痴を言うとったんじゃ、しゃあないぜよ。

愚痴を言ったら、自分の器を小さくする。

愚痴なんか言うとっても、なんも世の中ようならん。

愚痴を言う暇があったら、自分ひとりの命でもいいから、命を投げ捨てる覚悟があれば、波紋は起きはじめるということです。

3月の終わり、上司と年度末の面談を行った。2009年度の目標管理の実施結果の確認や、会社に対する質問・意見などを伝える場である。新年号その2でお伝えしたが、今年から我が社はクラウド(Google App Engine)及びAndroidに力を入れるとのことなのだが、仕事が無くて自社で待機状態となっている同期に聞いたところ、それらの勉強や研究を(会社レベルで)全く行っている様子が無いとのことなので、実施計画・本気で取り組む気があるのか?等を尋ねた。すると、上司曰く
「そもそも『クラウド』とか『Android』って何なの?」
…ご存じありませんでした。
他には、2009年度目標に「簿記資格を取得」を掲げていたことと絡めて『IFRS』を口にしたところ、上司曰く
「それってLinuxの資格試験だっけ?」
…それはLPICです。
こんな感じだったので、RIAの話もしたかったのだが、これ以上ストレス溜めたくないので引っ込めた…

どの用語もトレンドで、浅い内容ならITニュースを斜め読みしてれば猿でも知ることができると思うし、しかもこの先IT業界で食っていくには避けては通れないものなのだけど、この現実、マジか!?これからの厳しい時代に我々PGを率いていくPL・Mgrという立場の人間が、業界の動向を全く分かっていないというこの現実は。そしてさらに絶望的なのは、私と同じ現役バリバリのPGやSEという立場の人間に関しても同様であるということ。少なくとも、私の知る範囲では。

証券マンであれば株式などの動向をチェックするだろうし、
モデルであれば規則正しい食生活・寝起きを心掛けるだろうし、
スポーツ選手であれば肉体維持のためのトレーニング・栄養管理を行う。
それと同様に、IT業界に身を置くのであれば、技術動向のチェックは最低限の義務だろう。しかも、ただでさえ技術の移り変わりは早く、他の業種よりもたくさんの勉強が必要と言われるくらいなのだから…

何で勉強しないのだろうか。1秒でも多く、プライベートの時間を確保したいからなのだろうか。
であれば、なおさら勉強するべきだと僕は思う。
『一番効率的に人生を送りたいのなら、程々に勉強することだ』というのが持論だ。
全く勉強しない場合、見かけ上は勉強する場合と比べて自由時間をより多く確保できるように見えるが、実際は違ってくると思う。例えば毎日1時間勉強すれば、単純計算ではプライベートの時間が1時間減ってしまうが、勉強の効果で仕事の効率は確実に向上し、きっといつか必ず1時間以上早く仕事が仕上がるようになり、時間の元は取れると思う。当然スキル・成果物の品質も上がるし、それに伴い評価も上がることだろう。
かといって勉強やりすぎるのは精神衛生上よろしくない(勉強が好きで堪らないのであれば話は別だが)。

と言うわけで、程々に勉強するのがベストだと私は思う。
所帯持ちの場合、勉強する暇があったら家族サービスに費やしたいのだろうが、勉強していつ会社が潰れてもすぐ仕事見つけられるくらいの力をつけておき、家族を安心させておくこと、それが一番の家族サービスでは?

まあ、現実はスキルをつけて早く仕事を終えたところで、他人の尻拭いさせられるのが常ですが…これが評価(具体的には給与)に反映されていればそれでもいいのだが、少なくともうちの会社には『生産性』や『ソースコードの品質』という評価指標は無いようだ(あるかもしれないが、実感できない)。



はぁー…また愚痴ってしまった。冒頭の孫社長の言葉は仰る通りで、自分でもイケてないのは重々承知の上だ。ただ、私は何も改善しようとせずに全てを周りのせいにしている訳ではない。私なりに波紋を起こしてきた上で、IT技術者としての義務を放棄して『志』も見受けられないような者に対して愚痴っているのです。
そういうこともあり、内に溜めておくのは精神衛生上宜しくないということもあるので、今は勘弁してください…
ソフトバンクの純有利子負債と同様に、2014年度まではゼロにしますので…



↓波紋といったらこれだけど、スタンド登場でお役御免

2010年1月31日日曜日

僕歪新年号 2010~ワーク その2 UIだけでもリッチで行きたい

新年号その2。本業のプログラミングに関する目標を掲げる。

いい加減にRIAスキルを身に付けないと

今後はバックエンドのクラウド化が加速していくだろうから、フロントエンドで差別化を図らないといけないと思う。そうなると、RIAの利用は必須。只のHTML+Javascirptでは、確実に段ボールハウス行きであろう。

しかしうちの会社、その1でも述べた通りRIAを扱った経験が全く無い。親会社の基幹システムはColdFusion 8を使っており、何ヶ月か前から再構築の話が持ち上がっていたので、そのシステム担当している同僚にFlex紹介して「Flex採用された暁には俺呼んで!」と言っておいたが、結局ERPパッケージ使う事に決定したらしい。個人的にも会社的にも残念…

ちなみに、今年年頭の挨拶で聞いた会社方針では、クラウド(Google App Engine)及びAndroidに力を入れていくとの事。ITニュースをコピペしたような内容で、具体的にどうするか、例えばクラウドなら提供する側なのか利用する側なのか、と言った事が全く見えず、行く末に不安を感じた。話が長くなるから簡単にしたのであって、具体策はこれから追々伝えていくという事であって欲しいと願うばかり。

ところで、昨年にはWindows Server 2008によるActive Directoryを導入する等、基本的にマイクロソフト文化なのに、クラウドはAzureじゃないのかよ。ちなみにGAEを選択した理由は「Javaが使える」との事らしいが。全く、相変わらず目標に一貫性がない。Azureなら、既存の.NETアプリはそのまま流用できるよな、確か。やっぱり費用の問題だな。Azureだと、Visual Studioとかのライセンス費用が発生するのがキツいのだろう、きっと。
いや、思い返してみると、マイクロソフト文化と言っても、そう言えば殆どVB6以前だった…

ちなみにここ数年力を入れていた事業は、長らくそして現在私が担当しているマイナーな商用Javaフレームワークであった。力を入れると言っておきながら、使えるレベルに達している技術者は私を含めて3人。10人作るという目標を達成せぬまま、計画終了。結局、元々信念や志があって始めたのではなく、最重要顧客がそれを使うと言い出してそれに迎合しただけだったので、こんなものだろう。

それ以前に、先ず『分割』スキルだろ

うちの会社、『分割』スキルが弱い。『MVC分割』とか『クラス分割』とか『メソッド分割』とか。一例を挙げると、JSPにロジック埋め込みまくったり、基本1画面1クラス(VB6の感覚)で作るので数千~数万行にメタボ化し、他は以前も愚痴ったように数千行のメソッド、数百行のifブロックetc…
以前、ある勉強会に参加した際、Flex開発で有名な某ベンダの方と懇親会でお話ししたのだが、「会社が中々RIA開発に移行しない」と嘆いた所「Java扱っているなら、Flexへの移行は別に難しくないですよ」とお話ししてくれた。いや、うちの会社の場合は、非常に難しいのですよ…前述の通り、JSPにロジック書いちゃったりしてるもんだから、フロントだけFlexに交換と言うことすら厳しい。そして、うちの会社の感覚では、JavaとAction Script 3.0は完全なる別言語扱いなのです。

もう一つ、適切に分割されていないと言うことは、バックエンドだけクラウドに交換する事も難しい事を意味する。私が携わっているフレームワークは、MVCなんて概念が無い(ロジックもORマッピング情報もView部品に埋め込まれているetc)。
うーむ、出航前から座礁してないか?


プロジェクトの進め方を(少しだけ)変える事は何とかできたが、まだまだ課題は満載だ。
個人的なことであれば、少しでも前進しているので慌てないでコツコツ行こうぜという姿勢でもいいが、ビジネスではそうは言ってられない。果たして生き延びることができるのだろうか?

僕歪新年号 2010~ワーク その1 Trac野郎に俺はなる

もう1月も末日だというに新年号などと、相変わらずのマイペース及びKY(死語)っぷりを絶賛発揮中ですが、今年もこんな感じで人の目気にせず慌てずに生きていこうと思っています。今年もワールドカップ期間中はダウンタウン・松本人志のDVDを観ていることだろう。僕にとってワールドカップは「テレビ番組のダイヤを乱し、善良な市民を非国民へと変化させる黒ミサ」でしかないのだ。

さて、景気が底を打つと言われている2010年。今年の目標でも立てておこう。まずは仕事編。

トラックに乗ってから赤い地雷を踏みに行く

社会人4年目終盤の現在、やっと仕事が楽しくなってきた。というのは、以前のエントリで述べた通り、今回のプロジェクトから『Trac Lightning』を利用し始め、開発プロセスのChange(死語)に取り組んでいるからだ。懸念していた「面倒くせ~」といった反発もなく、むしろ積極的に利用してくれており、良い意味で拍子抜け。当初は、タスク管理・QA管理は従来通りExcelのままの予定であったが、使っている内に「1箇所で管理・参照できる方がいい」という事になり、結局それらもTrac上にご在住。
久しぶりの一次請け&新規案件で、客先との窓口の一部等、仕事もいろいろと任せて貰えており、世間の景気とは裏腹に非常に充実している(いや、うちの会社も景気は悪いですよ。例に漏れずボーナス大幅カットだったし…)。
ちなみに現在の私の役割は、『Trac管理者』及び『PL』です。前にも言いましたが、『PL』つっても『Programmer Leader』ですけど。

2008年末にRedmine紹介した時は「機能が多すぎる」と却下(どこが多すぎるというのだ?)
2009年春のプロジェクトでは、Subversion利用するならと『Trac Lightning』を導入したが、サブちゃん以外は一切利用されず。
2009年夏、セキュリティが物凄く厳しい客先での膨大な量の入場手続き・各種申請作業の手順が一切文書化されていなかったので、トーンダウンしてWikiだけでもと導入提案したが、「Excelでいいじゃん」と却下…
※ちなみにその現場、議事録すら書く文化が無く、恐らくお客さん側の責任であろう問題も全て押しつけられ、現在炎上中…

上記以外にも、カテゴリは違うが『Adobe AIR』がまだ『Apollo』だった頃に紹介した事もあったけか。ちなみに2010年現在、うちの会社はAIRどころかFlexもSilverlightもAjaxも全く扱った事がありません…
こんな感じの超保守的な会社なので、今回の動きには大変感慨深いものがある。よくここまで辿り着いたなと(何様)。まあ、さすがにこの不景気に危機感を感じてケツに火が付いただけかもしれんが。
否、俺の意見・説得がようやっと通じたと思おうじゃないか。たまには自分を褒めようではないか。

…とは言うものの、世間的には「今更w」「遅ッ!」なんでしょうけど。
しかも、もう何年も前からTracに手を出しているような先駆者の方々に言わせると、「これから使うならRedmineの方がいい」。
これは僕も同感。まあ、Redmineもそんなに深い所まで使ったこと無いので、何となくの感想ですけど…それでもTracを選択したのは『Trac Lightning』の簡便さには勝てなかったからなのですが、Trac導入が決定して利用ルール等を纏めて纏め終わろうかという2009年12月、まさかのRedmine簡単パックの登場。これ以前もいくつかあったみたいだけど、どうも運用していく自信が無かったので流していたのだが、これは非常に良さ気。
「こっちの方がいいです!」と伝えたが、突然すぎるのでこれは流石に却下。まあ、今回のTrac処女喪失でまずは『見える化』開発に慣れて、「Tracでは難しいがRedmineでは簡単」というような機能要望が発生したらすぐ移行できるように準備をしておこう。

と言うわけで今年の目標その1、TracとRedmineを使いこなすってとこかな。

本業のプログラミングに関しては…長くなったのでエントリ分ける。

2009年12月31日木曜日

僕歪年末号 2009~ワーク

我が輩はプログラマである。市場価値はまだ無い。

IT業界に就職して今年で4年目。4年目ともなればSEという肩書きの元、お客さんとの折衝・交渉を行っているのが一般的なキャリアパスでしょうか。僕は冒頭の通り、未だにプログラマです。まあ間接的にSEっぽいことを行ってはいますが(自社の人間を間に挟んでのお客さんとのやりとりetc)。

冒頭の言葉は半分本気で、半分嘘。
「自分は努力してるし、日々の業務もただ漫然と言われた通りにこなすだけでなく『もっと効率化できないか?』等考えながら仕事をし、開発プロセスの改善を提言する等している。それに比べて周りを見てみろ。他にこういう事している人間いるか?殆どいないだろう。オフショアやらSaaSやらの台頭で淘汰の時代に入ったけど、俺なら大丈夫だろう。SEの仕事も多少場数を踏めばすぐそれなりのレベルに達する自信はある。何よりもこれからも努力していくし!」
と、自分に自信を持っている反面、
「そうは言っても、4年目27歳にしてお客さんとの交渉経験殆ど無し。プレゼン経験も無し。工数見積もり自分の作業分以外は無し。基本プログラミング以下の作業のみ。プロジェクトは短期間でころころ変わるので、『経験豊富です!』と胸を張れる業務知識も無し。仕事の殆どがJava案件であるにも拘わらず、オブジェクト指向プログラミングやテスト駆動開発の適用は皆無。フレームワーク経験は商用のマイナーなやつのみ(俺様フレームワークよりはマシだろうけど)。そんな俺に市場価値なんてあるのか?」
と自信の無い自分もいる。

.NETとかFlexとか、トレンドだったり市場価値があったり、そしてブログのネタにもなりそうな仕事がしたいとずっと思っており、上に希望は出してはいるものの、現実は厳しい…確かに前述の商用FWを深いレベルで理解できている人間は僕しかいないのだけど…

そんな状況でしたが、念願叶って、今年前半は.NET三昧でした。幸か不幸か、この不景気によりお客さんも「お金がないから簡単な所は自分たちでやる」と言いだし、前述の商用FWの仕事が無くなってしまったので(そのFWは内製向け。『オブジェクト指向無くても作れる!』が売り。その為OOP経験を積めなかった)。
最初の2ヶ月はASP.NET 2.0のアプリ。WEBサービスクライアントや、パーシャルクラスによるTableAdapterの拡張等、中級以上?の事も行った。市場価値のある技術なので、それはそれは仕事してて楽しかったです。
それが終わると、次は.NET 3.5のC/Sアプリ。当時としては最新の.NET Frameworkで、うちの会社としても初めての技術。そして何より、要件定義から納品までうちの会社が担当するという、これぞシステムインテグレーションという仕事に、モチベーションはだだ上がり。まあ僕はここでもプログラマなので、担当したのは詳細設計以降でしたが、システム環境のセットアップからリリース作業までを任された。これまでは既に用意された環境で個々のプログラムを作成するだけだったが、セットアップ作業を経験することにより、インフラの視点が少し身についた。プログラミング作業に関しても、ReadOnlyのセルにフォーカス移らないDataGridViewを自作したりと、非常に充実したものだった。

そして2009年後半。まあ、再び商用JavaFWの仕事が始まりましたが…
前半の.NETでの経験でエンジニアとして自信を持ったので、前々から参加したいが自信が無くて二の足を踏んでいた勉強会参加を実行。そして玉砕…世間のレベルは高かった。これを機に再び自信喪失…勉強会参加が再び億劫になる。

気温と共に気持ちが落ち込んだ状態で到来した10・11月。過去最悪と言っていい仕事のやり難さ。情報伝達がテキストファイルに追記て、いつの時代だ!?プログラム品質も悪いし。
でも悪いことばかりではなかった。ある金額を計算するモジュールを一から作り直す作業の担当となったのだが、クラス設計を自由にやらせてもらえたので、継承等オブジェクト指向を使用した(多少の制限事項はあるが)。『オブジェクト指向プログラミングをしないうちはJava初級!』と言われているので、この経験を活かして早く中級に上がりたい。また、実業務では初めてJUnitを使用した。ありがちな話ではあるが前述の計算モジュールは仕様変更が多発したので、JUnitでテストケースを書いておいて本当によかった。これが単体テスト仕様書として見なされれば文句無しなのだが…

12月。再び商用JavaFWの案件。結構でかい。来年後半までスケジュールが引かれている。
僕のポジションはPL。PLといっても『Programmer Leader』ですけど。メンバーにはFWの潤沢な経験者が殆どいないので、彼らを導けとの事。ぶっちゃけ今までずっとそんな感じの事はしてきたので特に感慨は無いが、正式に任命されたのは初めてなので、正直悪い気はしない。まあ『プログラマ・リーダー』自体が正式なものではないですが。
一番モチベーションが上がったのが、今回のプロジェクトでは『Trac Lightning』を使用し、これまで行ってこなかった情報共有・ノウハウ蓄積をしていく事。これまで旧態依然とした非効率な仕事のやり方にうんざりしており、ちょくちょく提言を行っていたのだが、ようやく伝わったようだ。あとは、どれだけメンバーが積極的に使ってくれるかだな…

2009年11月22日日曜日

スードラの下のバリア、プログラマの下のコーダー

現在社会人4年目、27歳。今のところプログラマとしてのキャリアのみで、SE経験を中々積む事ができておらず、自分の行く末を非常に危惧している。以前からのオフショア化の波に加えて、昨今のクラウドやSaaSの台頭により、プログラミング以下の仕事すらどんどん減少していく状況である。エンドユーザーとの交渉スキル等、SE経験で得られるスキル無しでは生き残れないだろうから。

うちの会社、SEのパイは一応あるにはあるのだけど…少ない。プライム案件で直接エンドユーザと遣り取り可能なポジションであれば尚更(大抵は、プライムであってもお客さんの情報システム部までしか接触できない模様)。さらにその少ないパイは、どうも社員の大半を占めるおっさんCOBOLerに優先して割り振っているみたいなんだよな。実際、上期の中間面談で「枠は無い」って言われたし、同期や1~2年上の先輩の様子見てても難しそう…。周りを蹴落とすぐらいの力がお前に無いからだ!と言われれば返す言葉も無いですが…ただ、一つ言い訳させて貰いますと、

若い社員にSE枠を付与

あぶれたおっさんCOBOLerはプログラマ枠へ

しかしこの人達、年功序列制度のせいで現在高給

さらに、オープン系言語等の再教育コストがかかる。
てか基本的に勉強する気がない。

追加コストを払ってまで、高給取りを単価の安いPGとして働かせるのは利益率悪すぎ

SE枠はおっさんで

…多分、こういう事情もあるのだと思います。
他には、僕はプログラマとしては(うちの会社の中では)かなり生産性が高いので、お客さんやプライムベンダのペースに振り回されるSEとしてより、プログラマのままとしておいた方が全体最適だ、というのもあるかもしれない。

はい、前述の通り、僕はプログラマとしては(うちの会社の中では)いい仕事してきたんです。また、SEが作ってきた仕様・スケジュールに対し「このA機能を先に作った方が、かくかくしかじかで効率いいと思いますよ」とか「B機能の○○ロジックは規模がでかいので、1機能として切り出して分業させた方がよいのでは?」等、周りに比べたら積極的に発言してきた方だと自負していますし。「これでもまだ足りないのか?」「相当パイが少ないのか?」とずっと思い悩んでいた最中、最近ふと疑心暗鬼に取り憑かれた。
「できる人間だからこそ、SE経験積ませて貰えないのでは?」と。

というのは、僕が新人の頃の新人歓迎会にて、つまり歓迎されてた時「できる人間はすぐ辞めるんだよね~」と言われたからだ。新人研修での成績がズバ抜けていたらしく、また入社前にソフトウェア開発技術者資格を取得済みだったこともあり、『できる人間』と見なされたらしい。「何でうち(の会社)来たの!?」ってのもあったな。もうホント度肝抜かれましたよ。新人歓迎会でそんなこと言うか!?
つまり、僕が思うに「いつ辞めるかしれない『できる人間』に、貴重なSE経験を積ませるのは勿体ない」という考えが根底にあるのではないかと。
完全なる僕の思い込みであれば、それは本当に会社に対して申し訳ございません!って話ですが、でもそういう思い込みが発生してしまっている時点で、会社を信頼できていない事が浮き彫りに…

ということで、そろそろ転職を考えないといけないのかなと思い始めている。まぁ、この大不況にSE経験無しが飛び出した所で仕事なんて見つかるわけないだろうから、すぐには動くつもりはないですが。ただ準備だけはしておこうと、最近、これまでの技術経歴の棚卸しをしました。で、それによって発覚した驚愕の事実。

「俺、Java初級じゃねぇか!」

よくよく考えたら、仕事ではオブジェクト指向プログラミング(以下、OOP)した記憶が無く、手続型ロジックしか経験無いことに気付いたんですよ。で、Javaプログラマの初級・中級の定義を調べてみたら、わんくまの方がこう言っています。
「Javaはコーディングができるという初級者と、プログラミングができるという中級者の間に大きな壁があります」
「…クラスを利用できる初級者とクラスを作れる中級者・上級者との間の壁…」

どうやら、OO使ってクラス設計してない内は初級だと。Javaで手続き書いているだけなら初級だと。そういう内はプログラマではなくコーダーだと。
はい、僕、クラス設計したことなく、手続き書いているだけの、コーダーです…

この3年半、様々なJava案件を行ったり来たりしてきたのだが、殆どの案件が「プログラミング不要!」「OO不要!」を謳っている内製向け商用フレームワークを適用した案件だった。OOPの概念は無く、ただ手続きを羅列していくだけの作業。UMLとかの『クラス図』を見た事がないという事実が、OO使ってない事を物語っている。ていうか、FWに依存する画面系はともかくとして、共通部品くらいはOOで作ればいいものを、設計担当者が悉くOOを使おうとせず(そもそも分かってない?)。部品のロジックパターン毎にクラス分割して多態性使って呼出部品切り替えればいいところを、分割単位はメソッド、呼出切替はif文…

フレームワーク特有のスキルはかなり身についたが、スキルって言っても『可能・不可能なこと』『向き・不向きなこと』は何かとか、あとは設定パラメータをどれだけ知ってるかってなもんで、とてもスキルなんて言える代物じゃない。それに何より、マイナー(※1)。上司は「マイナーだから競合相手がいなくて良い!」って言ってたけど…単純に情けない話だと思うし、それに繰り返すが『内製向け』FWなので、お客さんも徐々に内製にシフトしており、確実に発注減ってきてますよ!今年夏の現場なんか、詳細設計すらやらせてもらえなかったんですけど!
※1:懇親会とかで聞いてみるんですけど、まあ知ってる人いませんね。唯1人知ってた方は「使いにくい!」って仰ってました…

実務経験   :3年半
経験言語   :Java 約3年 ※但しOOP、クラス設計、5.0以上の経験無し
他は.NET系を少々
フレームワーク:それどこの?

何てこった、俺、空っぽじゃねぇか。市場価値なんて無いに等しい。SEはおろか、プログラマですらなく…スードラの更に下に実はバリア(アンタッチャブル)という最下層階級がある事を知った時並の悲しみ、と言ったら大袈裟だけど…

果たして俺は這い上がれるのだろうか?



そんな俺にも、やっと中級者へのステップアップのチャンスが。今月仕事はピュアJavaによる計算ライブラリの基本設計~単体テスト。基本設計にはクラス設計も含まれている。バージョンも初めての5.0。よっしゃ!計算ロジックは5パターンあり、全パターンで共通のロジックもあるので、これは継承と多態性の使い処だ。計算パターン毎にパラメータが異なるので、それらはそれぞれBeanクラス作って…といった感じで、今月はいつになく張り切って楽しんでいます。

ただなぁ…プロジェクト規約でクラス名を『ABCDX(0~9の連番)』とIDみたいにしなきゃいけないんですけど、その『0~9の連番』ってあるように、クラス数10個以下に抑えないといけないっぽいんですよ。前述の通り、計算パターンで5あり、それぞれのパラメータ用のBean作ったらもう在庫切れちゃうんですけど…『規約』というより『制約』だなこりゃ。全く。制約があって燃えるのは恋愛だけだっつーの。
あと単純に、Beanのクラス名がIDみたいな名前だと、分かりにくいったらありゃしない。『囚人クラス』と呼んでますよ。

ちなみに、JUnitも初めて仕事で使いました。やっぱり再テスト時は物凄く便利ですね。心置きなくリファクタしまくれる。けど、テストコードは単体テスト仕様書とは見なされない…

2009年8月30日日曜日

最近読んだ@IT~常駐者のフリーダム

以下、てんじゃ氏のコメントの抜粋
・与えられたテストの仕事をきっちりこなしてください。
・余った時間で、テスト環境の効率化について考えてください。
--手作業でしてる作業を自動化できないか?
--テストの情報を管理するツールは必要ないか?
・余った時間で、テスト支援用の小物ツールを作る。

僕の会社は客先常駐派遣がメインです。今までに何カ所かに派遣され、キャリアの半分以上の期間、常駐作業をしてきました(現在もまさにそう)。
そんな常駐作業で共通して言えることの一つに、「『余った時間』を作れない!」というのがあります。
頑張って仕事してスケジュールを前倒ししたとしても、当初のスケジュールに無い作業を勝手にぶち込まれるんです(今年の6月にも似たような事が発生)。しかも、その作業というのは、契約したプロジェクトの作業に限らず、別の会社が担当している全然関係無いプロジェクトの作業も多々ありました(最近はさすがに無いけど)。一度、客先の営業か総務かが使っているExcelファイルのデータ入力といった、完全なる事務作業をやらされたこともありましたよ。

「いろいろな経験を積むことができるので、良い勉強になる」と最初はプラスで考えてましたが、時を経るにつれ、正直「いいように使い回されている」感が大きくなっていきました。それに「いろいろな経験」と言ったところで、使ってるフレームワークはどのプロジェクトも一緒だし、プログラマで契約してるから基本設計にはタッチできないし、高パフォーマンス発揮しても単価はプログラマ一律で上がらないし(SEで契約してもらうしか方法は無い)、しかも、僕の会社が特定派遣事業の届け出する前だから委任契約だった筈だけど、直接指示されてたし・・・
※ちなみに、ある客先では『レンジャー部隊』って呼ばれてました。呼んだ後「一人なのに」とツッコむのがお決まり。

以上より、もし僕が冒頭のリンク先記事の方の立場に立ったとして、引用のアドバイスを実施しようとしても、まあ無理です。テスト自動化ツールの作成等、間接的に作業効率の向上につながるようなことであったとしても。余程説得力のある資料や話術でもって、定量的効果を示すことでも出来ない限り。で、結局資料作る時間が無いという・・・

したがって、残された唯一の方法は、スケジュール前倒しして早めに完了させた上で、「完了してないです」と嘘の進捗報告をし、そうして確保した時間を使って、こそこそと内職するしかない。まぁこれも、プロセス監視してる所ではアウトですけど。前述の『レンジャー部隊』の客先では、プロパー社員が定期的に見回りしてディスプレイ覗いてくるし(信用されてねぇー・・・)
そしてそれ以前に、因果応報を座右の銘としている僕としては、このような嘘をつくのは気が引けてしまうので、不向き。そして、もし「本当に?」といった感じで突っ込まれた場合、平然としていられる自信が無い。

現在の僕は、さらに広い因果応報の考えでもって、「自分の『余った時間』を犠牲にして他の人手伝っているのだから、その内言い事あるさ」と頑張っている次第です。
※別に仏教徒ではないです

2009年8月29日土曜日

最近読んだ@IT~新入社員のメリ&ハリ

今年、新入社員研修のVisual Basic教育にサブ講師として参加した。といっても、教育カリキュラムの策定には参加していないが。

会社としては数年ぶりに新入社員の人数が2桁ということもあり、1人くらいは「自作ツール公開してます」「Linuxカーネル読んだことあります」レベルがいるかなと少し期待していたが、さすがにおらず。それくらいのレベルの人間は、やっぱり大手or有名処ベンチャーに行っちゃうのかな?
全体的なレベルとしては、Integer型変数に実数や文字列セットしているロジックを指差し「エラーの原因と直し方が分かりません」質問してくる人間が10数名中数名いるという状態。VBの前にC言語教育行っているので、変数の型については教育済みの筈なのだが・・・この10数名中数名という割合、業界一般的にはどうなんですかね?多い?少ない?

ところで、上記の質問を受けて思ったことがある。「ちょっとは予習しようという気にはならなかったのかな?」と。これは僕が新入社員の頃に、同じく10数名中数名いた、前述の新人と同レベルの同期を見た時にも思ったことだ。

SE・プログラマ職の募集要項には、大抵「文系理系不問」「プログラミング経験不問」を掲げている。実際、入社前の経験有無で仕事の品質・スピードに差が出るのは、最初の半年~1年程度だと思う。という訳で、未経験者も遠慮せずにどんどんWelcomeである。ただ、入社を決めたなら、「未経験者でもきっちり教育しますので大丈夫です!」といくら謳ってはいるものの、これからプログラマとして働いていく訳なんだからさ、ちょっとは入社前に手を出してくれてもいいのにと思うんです。完全に受け身にならないでよと。
まあ見方を変えればメリハリがある人間だと言えるので、配属後もそれを遺憾なく発揮して、勤務中はしっかり仕事をしてくれればそれで良いのだが。

あと、
言語などの場合は演習を入れます。演習もただ、考えて作るだけでは面白くないので、お題を出して作成してもらい、何人かの人にそれを発表してもらいます。それを材料に全員で良い部分、悪い部分などを討論します。ここで気づいたと思いますが、これはソースコードレビューです。
コードの発表と討論。これはすごく必要だと思う。ちなみに我が社の研修では、行っていません・・・
ソースコードの添削はもちろん行っているが、フィードバックするのは基本的に作った本人にだけ(もちろん、多数が共通して躓いてる箇所があった場合等は、ちゃんと全員に向けてフィードバックするが)。また、理想的なソースコードの紹介・配布等も無し。

時間的な制約があるので、討論まで行うのは難しいかもしれないが、せめてサンプルソースの配布は行うべきだと思った次第であった。
※上記の事、実は自分が新人の頃に、研修完了報告書で指摘したんですけどね・・・