2000年代オブジェクト指向は絶対の正義だった。つまり僕は洗脳を経験している - レベルエンター山本大のブログ
私がIT業界の片隅に所属をし始めた2000年ごろ、Javaエンジニアはスーパースターだった。Javaエンジニアを名乗るということは、秘奥義オブジェクト指向を習得していることに他ならないからだ。 「オブジェクト指向こそ正義」だった。 Javaとオブジェクト指向を身につければ、20年は食っていけると言われたものだった。 あれから20年。たしかにJavaとオブジェクト指向で20年は食えた。が、もはやオブジェクト指向は絶対でも正義でもない。 僕は、IT講師として新入社員にJavaを教える仕事もしているが「オブジェクト指向こそ正義」と無垢な生徒達に教えなければならない時に、苦痛を覚えるようにすらなってしまった。 2000年代から、新人教育のテキストは変わっていない。継承は積極的に使っていくべきで、オブジェクトは現実世界を模した仮想現実世界をコンピューター内に生み出す技術とされている。Strutsだけ
前時代的セキュリティ滅ぶべし - レベルエンター山本大のブログ
セキュリティ事故ってもう日常茶飯事で、萎縮ムードは常識化してる。 大きな組織になればなるほど、もう社員のことは信用しない。 それってSIerが死にゆく理由だと感じてしょうがない。 社員さんよ、「信用してないけど結果残せ」って言われてる感じじゃない？ それってちゃちな話じゃない。 例えば、DropBoxが使えないからリアルタイムな情報共有ができないとか 社外とのGitのやり取りができないから、ソースの共有で手間食うとかそれだけの話じゃない。 SIerが「IT企業」の枠にいるくせに 「情報技術には保守的です」って言ってるってことで 「医者だけど、医術は信じてません。まじないで病を直します」って言ってるような感覚を受ける。 IT業界と言ってるくせに、情報を扱う姿勢が保守ってどう？ 例えば以下３つの事例はなぜ毎年おこるのか？ 1. セキュリティーカード紛失によるセキュリティー事故 もう1５年も同じ
８つの質問で、Java SI業界の現状を知る - レベルエンター山本大のブログ
Webサービス系の会社の隆盛があって、人材流出が騒がれたのが１−３年ぐらい前だろうか。 SIの産業の人材動向が、今どうなってるかって？ 大方の予想より凄惨ですよ。 それが分かる方法がある。JavaWeb技術者に技術力を問う８つの質問によってだ。 SI業界のエンジニアの平均レベルを知りたくって、いろんな会社さんのJavaWeb開発者（経験者）向けに以下のような８つの質問を継続的にしている。 対象者としては、Java経験３から１０年ぐらいの現役バリバリのはずのJavaエンジニアだ。 その８つの質問というのはこんな問題だ。 JavaWeb技術者に技術力を問う８の質問 インターフェイスのメリットを一言で表して下さい。（筆記解答） HttpRequestオブジェクトからPostされたデータを取得するServletのメソッドは何ですか？（筆記解答） Sessionのスコープを端的に説明してください。（
アジャイルは大変2 - レベルエンター山本大のブログ
前回アジャイルは大変だという話を書きました。 今回は続きですが、そろそろプロジェクトも佳境を超えて安定してきたので、振り返りに近くなりました。 管理単位は粒度を粗くとらえる 管理単位の粒度を粗くとらえておくことが、顧客側・開発側の双方の首を絞めない秘訣です。 ちょっと語弊があるかもしれませんが、機能単位に管理するのではなくユースケース単位で管理するという感じです。 見積もり時点からユースケースドリブンですすめます。 例えば見積は「顧客検索機能」「顧客メンテナンス機能」「見積作成機能」ではなく 「ユーザは自分の担当顧客の情報を閲覧・編集できる」とか、 「ユーザは自分の顧客に対する見積書を作成することができる」というように、 利用用途を中心に割り出した要件をあらゆる管理のベースとして利用します。 このようにちょっと粗めの管理単位を設けておくと、アジャイルらしさが際立ちます。 特徴的なメリットを
IT業界に現れた第６の世界 - レベルエンター山本大のブログ
Joelの5つの世界というのをご存知だろうか。 （知らなければ是非、一読を→Joel on Software - 5つの世界） ５つの世界というのは −パッケージ −インターナル −組み込み −ゲーム −使い捨て の５つである。 このところは、スマートフォンアプリ開発という第６の世界が出現していると僕は考えている。 先日のエントリ「人月は悪どころか、ものすごい善かもしれない - 山本大の日記」のブコメで、上述の５つの世界を例にあげて、もっと考察が必要だと指摘してくれた人がいる。 僕はスマフォ関連の開発は５つの世界のどこにも当てはまり、どこにも当てはまらない世界だと思う。最近は、どういう切り口でIT業界を切ったとしてもどこにもホットトピックとしてスマフォが出てくる。パッケージだろうが、ゲームだろうが、SIだろうが、無差別であり、当然組み込みの世界にとても近い。どの世界の専属でもないが、Joe
結局ギークでスーツが最強だろう。エンジニアキャリアパスの行き着く先には経営が待ってる - レベルエンター山本大のブログ
エンジニアのキャリアパスの果てには、経営が待っている。 すべてのエンジニアは、経営者となるべきであり経営者にとって必要な資質は、 プログラミングスキルばかりではない。 営業、マーケティング、リーダーシップ、統制。 中途半端な開発者でこれからも居たいなら、技術だけでいい。 しかし、エンジニアとして大成を目指すなら、営業やマーケティング、大きな意味での経営を無視することは出来ない。 エンジニアの大成とは何か？といえば、僕は「そのエンジニアと同等に語られるプロダクトを持つこと」ではないかと思う。 ゲイツのWindows ジョブズのMac、iPod、iPhone ザッカバーグのFacebook 世の中は、属人性の排除から、属人性特化の時代にだんだんと変わってきていると思う。 古い体質のSIerではいかに属人性を排除して、誰でも均質なものづくりが出来るかを常に追い求めていた。 その結果、設計書ベース
誰でもアーキテクトになれるかもしれない48手 - レベルエンター山本大のブログ
アーキテクトへの道という講習会を依頼されている。 結構なお客さんが予約してくれているようだ。 最近のアーキテクト案件では上手く振る舞えなかっただけに恐縮だ。 ということでアーキテクトの特徴を考えてみる。 アーキテクトは、 実装と業務設計のクロスチェッカーである ルールとポリシーの番犬である ソフトウェアとミドルウェアのチューナーである 担当者の不在領域の掃除人である トラブル対応の生きたデータベースである 斥候（先回りする人）である 古い慣習を覆して、新しい慣習をつくる老害予備軍である 期待と失望を一番最初に受ける窓口である よくわからないことを、よくわからないと言っちゃえる特権階級である スポークスマンである 講師である 独裁者である 自動化ツールの製造工場である Google検索役である 環境構築のパシリである 本番環境バグが出た時のしかられ役である 常に被告人側（バグを埋め込む側）の
【有能リーダの鉄則】同コンテキストでの有能リーダ vs 無能リーダ - レベルエンター山本大のブログ
今僕らのプロジェクトは大きな危機に直面していると言える。 なぜなら、商流の変化からワケの分からない人が大量に流入してきているからだ。 それも、プロジェクトマネージメントメンバーとしてだ。 今、僕らが参画しているプロジェクトは、 某大手メーカーさんの優秀なエンジニアをかき集めた一大プロジェクトだ。 しかし、どれだけ優秀なメンバーを集めても、リーダシップをとるべき人たちがダメだと プロジェクトは烏合の衆にならざるを得ない。 羊がライオンを率いる状況のまずさを実感する。 しかし、このプロジェクトの面白いところは、 過去の巨大なプロジェクトで功績のあった優秀なリーダ（AさんとYさんとYさんの3人）が サブリーダ的なポジションにいて、リーダーの 無能 vs 有能 の比較が同一コンテキストで測れることだ。 プロジェクトは上流工程段階ですでに壊滅的だが リーダーの資質についてエッジの効いたエピソードを集
信じられないDB文化「Join禁止」に「固定長DB」、、でも、合うんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はRDBやフレームワークを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止」と「固定長DB」だ。 ありえない。 とはいえ、正直に言えば「またか、、、」という感想でもある。 RDBを知らないレガシーな人たちが設計したDBではよくありがちな設計だからだ。 と僕は早々にこの文化と戦って、絶対に覆してやろうと考えてた。 過去の経験上それはたやすいハズだった。 しかし、この文化と戦うこと3ヶ月間。 屈した。初めて屈した。いや、屈したというよりは理解した。 大規模コンシューマ向けサービスのRDBという
エンジニアにとっての会社の意義 - レベルエンター山本大のブログ
以前、エンジニアは「営業からテストまで一巡してみろ」ってエントリしたところ 「それができたら会社はいらない」とかいうコメントが多くついた。 こういうコメントを個別に相手にするつもりはないけれど 1つ考えておかなくてはならないと思ってるのはフリーランスのエンジニアという存在だ。 たしかにエンジニアは、腕があれば会社に所属せずフリーランスでもしばらくは食っていける。 それが良いと感じる人も居るし、フリーランス自体を否定するものでは決して無いが、 じゃあ、皆が皆フリーランスで幸せにやってられるかというと、そんなことはない。 ある知人のフリーランスエンジニアの話から、会社の意義について考えよう。 彼は言った「フリーになってはじめて仲間の有難さがわかった。俺は会社にいるときどれだけ甘えてたか良くわかったよ。」と 彼は会社に所属しているときは、所謂「一匹狼」タイプで、組織に対しては常に一線を引いていた
エンジニアにとって３５歳とは定年ではないが、真価が問われる時ではある。 - レベルエンター山本大のブログ
３５歳には３５歳なりの成長の仕方というものがあります。 ３５年、着実に１年１年、前に進んでいる人と、 確実にどこかで足踏みしてたなぁという人は、はっきりとわかってしまいます。 年齢というのはただの数字だけど、数字には魔力のようなものがあります。 というか、単純でわかりやすいということだけなんだけど、 その人が生きてきた成果と比較するための基準値といいましょうか。 ３５歳と聞くと、 ちゃんと向上心を持ち続けて生きてきたのか、適当に流されて生きてきたのかを どうしても見てしまいます。 ３０歳前後のエンジニアの皆さんに言います。 飛びぬけて技術に自信がある人以外は、 少しでも「リーダー経験」を積んでおきなさいよ。 本当にそこが一番重要だから。 一番汎用的なスキルだから。 人を動かせてなんぼですから。 人が作った土壌・枠組みの上で設計や実装をした経験の多さは、物の数ではないのです。 リーダ経験とい
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
