2000年代オブジェクト指向は絶対の正義だった。つまり僕は洗脳を経験している - レベルエンター山本大のブログ
私がIT業界の片隅に所属をし始めた2000年ごろ、Javaエンジニアはスーパースターだった。Javaエンジニアを名乗るということは、秘奥義オブジェクト指向を習得していることに他ならないからだ。 「オブジェクト指向こそ正義」だった。 Javaとオブジェクト指向を身につければ、20年は食っていけると言われたものだった。 あれから20年。たしかにJavaとオブジェクト指向で20年は食えた。が、もはやオブジェクト指向は絶対でも正義でもない。 僕は、IT講師として新入社員にJavaを教える仕事もしているが「オブジェクト指向こそ正義」と無垢な生徒達に教えなければならない時に、苦痛を覚えるようにすらなってしまった。 2000年代から、新人教育のテキストは変わっていない。継承は積極的に使っていくべきで、オブジェクトは現実世界を模した仮想現実世界をコンピューター内に生み出す技術とされている。Strutsだけ
８つの質問で、Java SI業界の現状を知る - レベルエンター山本大のブログ
Webサービス系の会社の隆盛があって、人材流出が騒がれたのが１−３年ぐらい前だろうか。 SIの産業の人材動向が、今どうなってるかって？ 大方の予想より凄惨ですよ。 それが分かる方法がある。JavaWeb技術者に技術力を問う８つの質問によってだ。 SI業界のエンジニアの平均レベルを知りたくって、いろんな会社さんのJavaWeb開発者（経験者）向けに以下のような８つの質問を継続的にしている。 対象者としては、Java経験３から１０年ぐらいの現役バリバリのはずのJavaエンジニアだ。 その８つの質問というのはこんな問題だ。 JavaWeb技術者に技術力を問う８の質問 インターフェイスのメリットを一言で表して下さい。（筆記解答） HttpRequestオブジェクトからPostされたデータを取得するServletのメソッドは何ですか？（筆記解答） Sessionのスコープを端的に説明してください。（
エンジニア人月０円セールと、ござ先輩に見た未来 - レベルエンター山本大のブログ
今日はid:gothedistanceと飲んだ。１年ぐらい前から飲もう飲もうといっていてようやく実現。 さすがはござ先輩。いろいろと教えてもらった。 その中で、SIおよびSEのこれからに暗い影を落とす話をした。 これはウチの関西側の営業担当が聞いてきた、あるSE派遣の企業の話。（とはいえ関西企業に限った話ではない） 何十人もの新人さんを集めて、無料でいろんなプロジェクトに派遣するビジネスモデルが台頭してきているらしい。 何十人の内、数名でも生き残って、その後定期的な売り上げになれば良いという、携帯の新規契約無料みたいなモデルだ。 経験者も言い値で出すという。 新人さんに経験を付けてもらうためにお試しで出向することは百歩譲って良いとしよう。 いくらなんでも新人ばかりで上手くいくと思っているような 受け入れ側もプロジェクトもさすがにないから、 こういう新人さんを受け入れるのも1つのプロジェクト
人月は悪どころか、ものすごい善かもしれない - レベルエンター山本大のブログ
人月計算は、悪だ。 という話はソフトウェア産業にいるエンジニアだったら、誰でも聞いたことがあるだろう。 よく言われる人月計算の悪とは、管理者の意識から個人個人の能力差などの情報が失われることが根本だと僕は考える。 悪影響の一例としてエンジニア単価に能力差が反映されないという点がある。 また別の例として「10人月の工数の作業も20人でやったら0.5ヶ月で終わるんじゃね？」 という単純計算による安易な管理が横行しデスマを生む原因となる。 「人月」の捉え方はともかくとして、すくなくとも良い評判を聞いたことがない。 しかし、僕は最近、人月計算とはとてつもない善ではないかという考え方になっている。 とくにエンジニアに対して「善」、というよりもエンジニアに対して優しさをもって考えられた仕組みだと感じて仕方ない。 人月の神話 作者: フレデリック・P・ブルックス Jr.,滝沢徹,牧野祐子,富澤昇出版社/
ただの作業者（ワーカー）と呼ばれないための、たった1つのやるべきこと - レベルエンター山本大のブログ
エンジニアであるかどうかに関わらず、どんな仕事であっても 作業者(ワーカー)と、それ以外を分ける基準は一つだと思います。 それは判断することです。 僕は、判断する量が多いか少ないかで、その人の仕事上の価値が大きく変わると考えています。 もしも、まったく判断をせずに仕事をしているなら、その人の価値はワーカーです。 ワーカーが悪いわけではないですが、ワーカーはいつもたやすく取って代わられます。 優秀なワーカーもいます。それはそれで価値があります。 でも、ある人が自分で判断をするたびにその人の価値は上がります。 「権限も役職もないから、判断なんてできないよ」 と言う人がいます。 たしかに判断は責任を伴います。責任者が判断するべきというのは正論のように見えます。 でも別の見方をすると「役職を与えられたら、いきなり良い判断ができる」というものではありません。 そう考えると、判断できる人に権限があたえ
ルーチンワークじゃあるまいし、効率や生産性を上げたからって残業はなくせんよ。 - レベルエンター山本大のブログ
今の勤務先では毎週水曜日、定時退社日となっていて ドアの前に張り紙が貼られる 「今日は定時退社日です。仕事の効率を上げて定時で退社しましょう」 と いやいや。効率上げても残業はなくせないよ。 ルーチンワークなら、効率を上げたから早く帰れるだろうけど、 エンジニアの仕事は、結局はモノづくり。 時間があれば、より時間をかけて良いものに仕上げるべきだ 時間があれば、より素早く先のリスクを摘んでおくべきだ という考え方になる。 定時退社したいなら、やるべきことは4つだけ 見切りを付ける やらないでいいことはやらない 時間泥棒にかかわらない 時計を中心に置く 見切りを付ける 約束や締切りが迫っている仕事以外は、見切りをつけてOKだ。 緊急だと思ってる仕事は、焦ってやっても上手くいかない。 長時間かかる仕事は、あと２時間や３時間やっても、大差ない。 やらないでいいことはやらない 効率を上げてゴミを掃除
エンジニアにとっての会社の意義 - レベルエンター山本大のブログ
以前、エンジニアは「営業からテストまで一巡してみろ」ってエントリしたところ 「それができたら会社はいらない」とかいうコメントが多くついた。 こういうコメントを個別に相手にするつもりはないけれど 1つ考えておかなくてはならないと思ってるのはフリーランスのエンジニアという存在だ。 たしかにエンジニアは、腕があれば会社に所属せずフリーランスでもしばらくは食っていける。 それが良いと感じる人も居るし、フリーランス自体を否定するものでは決して無いが、 じゃあ、皆が皆フリーランスで幸せにやってられるかというと、そんなことはない。 ある知人のフリーランスエンジニアの話から、会社の意義について考えよう。 彼は言った「フリーになってはじめて仲間の有難さがわかった。俺は会社にいるときどれだけ甘えてたか良くわかったよ。」と 彼は会社に所属しているときは、所謂「一匹狼」タイプで、組織に対しては常に一線を引いていた
はよプログラマとかエンジニアとかから脱却せんかい。 - レベルエンター山本大のブログ
プログラマの誇りがどうこうと書いていていうのもなんだけど、 プログラマが下手に誇りを持ちはじめた昨今。 いい加減、うんざりしてきた。職業ぷろぐらまな面々に。 作る技術がスキルのすべてだと勘違いしてるぷろぐらまに。 誰をターゲットに吠えるわけではないけれど、 我慢してることを言います。 仕事＝きれいなコーディング 仕事＝疎な設計 仕事＝きれいなドキュメント とか、そんなことで満足してんなって。 作る技術をバックボーンにして、 話をまとめる力をつけて、 要件をまとめる力をつけて、 交渉をまとめる力をつけて、 費用抑える力つけて、 お客さんの要件を引き出して、実現して、貢献して、 初めて仕事が成り立ってるんだろうが、 ビジネスが成り立つんだろうが。 目指さんかい、営業からテストまで1人で全部実現できるぐらいの境地を。 一周して来いって。 それができるまではずっとワーカー。 #追記 ワーカーは煽り
越権行為のすすめ - レベルエンター山本大のブログ
ぶっちゃけ僕は越権行為が好きだ。 なぜなら、それは自分の運命を自分で握ろうとすることだから。 そもそも、僕らは大手SIerから切り出しで仕事を貰うことが多い。 しかし正直言って1次受けの会社の人たちが、プロジェクトを上手く回せないことも多い。 それは仕方ない。それを掘り下げても業界の構造の問題を憂うことになるだけだ。 だからといって「あの会社がへぼだからこんなデスマなんだ」とかは言わない。 仕事をくれたときから、その会社には恩がある。 頼られてるんだから仕事で返さなくてはいけない。 だからプロジェクトが失敗したら常に自分のせいだと思ってる。 頼られてるのに返せなかった自分のせいだ。それがプロじゃないだろうか。 それに人任せにしておけば、自分の仕事を自分でコントロールできない。 それはイライラしてしまう。 今回の仕事も初日の時点で、ほっとくとプロジェクトがボロボロになりそうだった。 というこ
安全策が後手後手を生む - レベルエンター山本大のブログ
場当たり的な対応で工数が少なくてすみ、影響範囲も少ないが、コードは汚くなるという案と 影響範囲が広いし工数も掛かりそうだが、コードは綺麗になるという案があるとき、 僕は、よほどの差でない限り、コードが綺麗になるほうを選ぶ。 ここで場当たり対応を選んでしまうことは、 「現実をみた大人の意見」のように思えるかもしれないが、 僕からすると、大事の前の小事にこだわるという、本末転倒の考え方にしか見えない。 保守で、既存プログラムの修正をやろうという後輩から相談を受けた。 既存プログラムのSQLの一箇所が違うだけのメソッドを作る必要があるとのことだ。 メソッドをコピーして重複したコードを書くことに後輩は納得がいかず、うまい方法は無いものかと僕に相談をしてくれた。 僕は、このメソッドの引数を追加して条件分岐できるようにし、元のシグネチャオーバーロードとして別途定義する案を上げた。 後輩は、我が意を得た
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
