８つの質問で、Java SI業界の現状を知る - レベルエンター山本大のブログ
Webサービス系の会社の隆盛があって、人材流出が騒がれたのが１−３年ぐらい前だろうか。 SIの産業の人材動向が、今どうなってるかって？ 大方の予想より凄惨ですよ。 それが分かる方法がある。JavaWeb技術者に技術力を問う８つの質問によってだ。 SI業界のエンジニアの平均レベルを知りたくって、いろんな会社さんのJavaWeb開発者（経験者）向けに以下のような８つの質問を継続的にしている。 対象者としては、Java経験３から１０年ぐらいの現役バリバリのはずのJavaエンジニアだ。 その８つの質問というのはこんな問題だ。 JavaWeb技術者に技術力を問う８の質問 インターフェイスのメリットを一言で表して下さい。（筆記解答） HttpRequestオブジェクトからPostされたデータを取得するServletのメソッドは何ですか？（筆記解答） Sessionのスコープを端的に説明してください。（
エンジニア人月０円セールと、ござ先輩に見た未来 - レベルエンター山本大のブログ
今日はid:gothedistanceと飲んだ。１年ぐらい前から飲もう飲もうといっていてようやく実現。 さすがはござ先輩。いろいろと教えてもらった。 その中で、SIおよびSEのこれからに暗い影を落とす話をした。 これはウチの関西側の営業担当が聞いてきた、あるSE派遣の企業の話。（とはいえ関西企業に限った話ではない） 何十人もの新人さんを集めて、無料でいろんなプロジェクトに派遣するビジネスモデルが台頭してきているらしい。 何十人の内、数名でも生き残って、その後定期的な売り上げになれば良いという、携帯の新規契約無料みたいなモデルだ。 経験者も言い値で出すという。 新人さんに経験を付けてもらうためにお試しで出向することは百歩譲って良いとしよう。 いくらなんでも新人ばかりで上手くいくと思っているような 受け入れ側もプロジェクトもさすがにないから、 こういう新人さんを受け入れるのも1つのプロジェクト
ソフト開発をステップ数で見積っていることに疑問を持たなくてはならない - レベルエンター山本大のブログ
ステップ数を見積もり根拠にする会社さんは、いまだに多い。嘘じゃない。 お世話になってる会社さんもそういう仕組みをとってるところがあって、いいにくい部分もなきにもあらずだが、お世話になってるからこそいいたい。 そんなことやってちゃだめだと。 １キロステップの生産性指数をだして、今回の開発は10キロだから１０００万円とか。 汎用機時代ならまだ百歩譲ってわからんでもないけど、オープン系という言葉すら死語になりつつあるこのご時世において、ステップ数が１キロ（１０００行）だったら１人月とかどうこうという話は、もはや見積もりでもなんでもなく、こじつけだ。 フレームワークのコアのコードも、 ビジネスロジックの肝のコードも、 ネットワークの通信コードも、 自動生成したコードも同じ１ステップとカウントする。 見積もり時の計画ステップ数と、実際に開発したときの実績ステップ数を比較して 次の開発の値決め（ダンピ
人月は悪どころか、ものすごい善かもしれない - レベルエンター山本大のブログ
人月計算は、悪だ。 という話はソフトウェア産業にいるエンジニアだったら、誰でも聞いたことがあるだろう。 よく言われる人月計算の悪とは、管理者の意識から個人個人の能力差などの情報が失われることが根本だと僕は考える。 悪影響の一例としてエンジニア単価に能力差が反映されないという点がある。 また別の例として「10人月の工数の作業も20人でやったら0.5ヶ月で終わるんじゃね？」 という単純計算による安易な管理が横行しデスマを生む原因となる。 「人月」の捉え方はともかくとして、すくなくとも良い評判を聞いたことがない。 しかし、僕は最近、人月計算とはとてつもない善ではないかという考え方になっている。 とくにエンジニアに対して「善」、というよりもエンジニアに対して優しさをもって考えられた仕組みだと感じて仕方ない。 人月の神話 作者: フレデリック・P・ブルックス Jr.,滝沢徹,牧野祐子,富澤昇出版社/
SI開発におけるヒトとカネの話 - レベルエンター山本大のブログ
エンジニアやりつつ、経営や営業をやっている。 このところずっと思っていることがある。 ソフトウェア開発という仕事の成否について、 失敗するのは金の使い方によってであり 成功するのは人の集め方によってである。 プロジェクトは、開発プロセスや、フレームワークやツールやサーバや言語で成否が決まるんじゃない。 開発プロセスがどーのこーのとか、僕もよく言ってたけどね。 極論だけれどもアジャイルでもウォーターフォールでも、なんでもいいって。 プロジェクトは、それを動かす人が良ければ成功する。 言い換えれば技術や方法論は、どうあがこうが組織に溜まるのではなく人に溜まるんだ。 だから良い人に任せたい。 現場マネージャーの立場で考えると、プロジェクトを回すとき 自社の優秀なメンバーばかりで固められたらいいのだが、 優秀な人こそ案件を抱えてるのでうまくアサインできるとは限らない。 自社社員だけで足りない部分を
エンジニアとして大成したいならやってはいけない48ヶ条 - レベルエンター山本大のブログ
いろんなエンジニアを見てきて、成功パターンはそれぞれだけれど 失敗パターンはだいたい決まっている。以下、アンチパターン。 成し遂げるのではなく、中途半端で満足する。 自分の責任と考えず、人のせいにする。 よりよくしようとせず、現状維持を良しとする。 仕事を中心においていない。 自分の特徴を構築していない。同世代と比べてさしたる特徴がない。 生活習慣を重視しない。日々の積み重ねに価値をおいていない。 与えられたチャンスに乗っからない。やる前から怖じ気づく。 アウトプットの質にこだわらない。 自分を分析していない。強み弱みを問われても答えられない。 刺激よりも、平穏を求める。変化に弱い。 行動よりも熟考を優先する。考えた末に行動しない。 現在の仕事の進め方に疑問を持たない。既存踏襲が正しいと思っている。 チームへの貢献よりも、自分の仕事の進捗を優先する。 焼き畑農業的な人間関係。信頼の構築では
【有能リーダの鉄則】同コンテキストでの有能リーダ vs 無能リーダ - レベルエンター山本大のブログ
今僕らのプロジェクトは大きな危機に直面していると言える。 なぜなら、商流の変化からワケの分からない人が大量に流入してきているからだ。 それも、プロジェクトマネージメントメンバーとしてだ。 今、僕らが参画しているプロジェクトは、 某大手メーカーさんの優秀なエンジニアをかき集めた一大プロジェクトだ。 しかし、どれだけ優秀なメンバーを集めても、リーダシップをとるべき人たちがダメだと プロジェクトは烏合の衆にならざるを得ない。 羊がライオンを率いる状況のまずさを実感する。 しかし、このプロジェクトの面白いところは、 過去の巨大なプロジェクトで功績のあった優秀なリーダ（AさんとYさんとYさんの3人）が サブリーダ的なポジションにいて、リーダーの 無能 vs 有能 の比較が同一コンテキストで測れることだ。 プロジェクトは上流工程段階ですでに壊滅的だが リーダーの資質についてエッジの効いたエピソードを集
ルーチンワークじゃあるまいし、効率や生産性を上げたからって残業はなくせんよ。 - レベルエンター山本大のブログ
今の勤務先では毎週水曜日、定時退社日となっていて ドアの前に張り紙が貼られる 「今日は定時退社日です。仕事の効率を上げて定時で退社しましょう」 と いやいや。効率上げても残業はなくせないよ。 ルーチンワークなら、効率を上げたから早く帰れるだろうけど、 エンジニアの仕事は、結局はモノづくり。 時間があれば、より時間をかけて良いものに仕上げるべきだ 時間があれば、より素早く先のリスクを摘んでおくべきだ という考え方になる。 定時退社したいなら、やるべきことは4つだけ 見切りを付ける やらないでいいことはやらない 時間泥棒にかかわらない 時計を中心に置く 見切りを付ける 約束や締切りが迫っている仕事以外は、見切りをつけてOKだ。 緊急だと思ってる仕事は、焦ってやっても上手くいかない。 長時間かかる仕事は、あと２時間や３時間やっても、大差ない。 やらないでいいことはやらない 効率を上げてゴミを掃除
机に向かって取れる解決法だけを並べて「限界だ」なんてあきらめてないか？ - レベルエンター山本大のブログ
プロジェクトで発生する様々な問題の答えは、IT技術や開発の方法論だけではありません。 問題解決のためには、あらゆる手段を視野に入れてのぞむ必要がありますが、 僕らエンジニアは「あらゆる手段」を狭く取りすぎていることがあります。 「あらゆる」と言いながら、机の前、パソコンの前に座って取れる方法だけにとらわれていたことが 僕自身にもありました。 そのプロジェクトのエンドユーザーさんはとても田舎の工場で、 僕が勤務してた大阪の市内からは、車で行って2時間（高速代などで10000円）、 電車で行くと2時間40分（片道3000円）かかるところにある、 なかなか厳しい立地条件のお客さんでした。 僕はこの案件で、要件定義から参画しましたが、 ミーティングをするために、客先に出向いても往復に4時間以上かかるので せいぜい3時間しかミーティングの時間が取れません。 このため時間的にもお金的にも、ミーティング
誇りを貫くプログラマのキャリアパス - レベルエンター山本大のブログ
エンジニアの誇りを減退させずキャリアを積むためには、とっとと管理を極めて*1管理の仕事を他の人に振れるようにすることだと思っている。*2 あなたが管理を嫌ってもキャリアアップするにあたって管理という仕事は回ってくる。 管理という仕事に目を背け続けることは出来ない。 僕は、管理という仕事をエンジニアの終着点だと考える必要はないと思っている。 乗り越えるべき通過点なのだと思う。 エンジニアのキャリアアップの中でも管理職の乗り越え方を考える。 原則：エンジニアよ、管理職を超えろ。 会社側の論理で言えば、キャリアの長い人に高い給料を支払うためには、 その人が複数のメンバーの仕事を上手く回してくれなくてはならない。 会社がベテランに求めるのは、チームを引っ張っていってくれることだ。 当然、あなたが管理向きならば問題にはならない。 管理とリーダーシップは両立しやすい。しかし、管理系リーダーが全てではな
はよプログラマとかエンジニアとかから脱却せんかい。 - レベルエンター山本大のブログ
プログラマの誇りがどうこうと書いていていうのもなんだけど、 プログラマが下手に誇りを持ちはじめた昨今。 いい加減、うんざりしてきた。職業ぷろぐらまな面々に。 作る技術がスキルのすべてだと勘違いしてるぷろぐらまに。 誰をターゲットに吠えるわけではないけれど、 我慢してることを言います。 仕事＝きれいなコーディング 仕事＝疎な設計 仕事＝きれいなドキュメント とか、そんなことで満足してんなって。 作る技術をバックボーンにして、 話をまとめる力をつけて、 要件をまとめる力をつけて、 交渉をまとめる力をつけて、 費用抑える力つけて、 お客さんの要件を引き出して、実現して、貢献して、 初めて仕事が成り立ってるんだろうが、 ビジネスが成り立つんだろうが。 目指さんかい、営業からテストまで1人で全部実現できるぐらいの境地を。 一周して来いって。 それができるまではずっとワーカー。 #追記 ワーカーは煽り
データベースパフォーマンスに関する、僕が知りうる限り最高の教科書 - レベルエンター山本大のブログ
データベースの醍醐味は、パフォーマンスチューニングにあります。 チューニングによっては、同じ処理でも1時間掛かる場合もあれば、 1秒で終わるということもあり得る世界です。 僕はDBの魅力に取り付かれた者の一人です。 DBという技術の奥深さが気に入っています。 DBを極めると、どこの現場に行っても絶対に必要とされます。 また、どこの現場に行っても正解を導く方程式は一緒なので応用が利くのです。 しかし、その基本原理を体系的に学べる手段はあまりありません。 OracleMasterやMCDBAといった資格試験でも学べることは限られていて あとはWebで調べるなりマニュアルを読むなりするしかありませんでした。 とくに肝であるパフォーマンスチューニングについては、 経験則でチューニングしている部分も多いです。 Oracle、SQLServer、MySQLと色々なDBのチューニングをしてきましたが、
プログラマーの誇りを見せ付けろ - レベルエンター山本大のブログ
僕は今回の案件で、システムのレスポンスに徹底的にこだわってる。 それには理由がある。 それは、プログラマの誇りを見せたいからだ。 この案件は、既存機能をコピーして似た機能を作るというものだ。 既存機能は、Webシステムなのに1アクションで 1分や2分以上のレスポンスタイムはザラで、 悪いときには数分後にタイムアウトして、 さらに悪いときには、アプリケーション全体をロックしてしまっていた。 顧客はそれでも我慢して使っていてくれたそうだ。 今回の改修に際して、顧客がパフォーマンスを要求するのは当然だった。 それにしても酷いアリサマだとコードを見てみると 酷い。 確かにパフォーマンスは出ないのも無理はない。 いや、それどころか僕は、このSI業界の問題を感じざるを得なかった。 この機能はそこそこ難しく、業務的にも重要だ。 しかし、そのコードは、新人〜3年目ぐらいのプログラマが書いたとしか思えないコ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
