生産性が高いエンジニアを評価するための２つの仕組み - レベルエンター山本大のブログ
仕事ができるプログラマって、できないプログラマに比べて「１０倍」も生産性が高い。とか言う話がありますよね。 僕も体感的に、本当にできるエンジニアは本当に生産性が５倍とか１０倍とか変わることを見てきました。 でも開発の現場では「残業しまくってる」ほうが、なんだか仕事してるように見えてしまう。 そんな中で久々にこの記事を目にしました（漫画なので1分ぐらいで読めます）。 ■「残業しないで帰るSEってやるきないんじゃない？」 http://next.rikunabi.com/tech/docs/ct_s03600.jsp?p=000800 2006年の記事ではありますが、こういう話って普遍的なので古くもありませんね・ 残業しないで定時に帰れるって評価するべきだし、残業をせず家庭を大事にする社風にしたい。 すごく生産性が高いっていうエンジニアを評価したい。 でも残業してるのって分かりやすいから評価さ
プログラマーの誇りを見せ付けろ - レベルエンター山本大のブログ
僕は今回の案件で、システムのレスポンスに徹底的にこだわってる。 それには理由がある。 それは、プログラマの誇りを見せたいからだ。 この案件は、既存機能をコピーして似た機能を作るというものだ。 既存機能は、Webシステムなのに1アクションで 1分や2分以上のレスポンスタイムはザラで、 悪いときには数分後にタイムアウトして、 さらに悪いときには、アプリケーション全体をロックしてしまっていた。 顧客はそれでも我慢して使っていてくれたそうだ。 今回の改修に際して、顧客がパフォーマンスを要求するのは当然だった。 それにしても酷いアリサマだとコードを見てみると 酷い。 確かにパフォーマンスは出ないのも無理はない。 いや、それどころか僕は、このSI業界の問題を感じざるを得なかった。 この機能はそこそこ難しく、業務的にも重要だ。 しかし、そのコードは、新人〜3年目ぐらいのプログラマが書いたとしか思えないコ
８つの質問で、Java SI業界の現状を知る - レベルエンター山本大のブログ
Webサービス系の会社の隆盛があって、人材流出が騒がれたのが１−３年ぐらい前だろうか。 SIの産業の人材動向が、今どうなってるかって？ 大方の予想より凄惨ですよ。 それが分かる方法がある。JavaWeb技術者に技術力を問う８つの質問によってだ。 SI業界のエンジニアの平均レベルを知りたくって、いろんな会社さんのJavaWeb開発者（経験者）向けに以下のような８つの質問を継続的にしている。 対象者としては、Java経験３から１０年ぐらいの現役バリバリのはずのJavaエンジニアだ。 その８つの質問というのはこんな問題だ。 JavaWeb技術者に技術力を問う８の質問 インターフェイスのメリットを一言で表して下さい。（筆記解答） HttpRequestオブジェクトからPostされたデータを取得するServletのメソッドは何ですか？（筆記解答） Sessionのスコープを端的に説明してください。（
大学の経営学部では教えてくれなかった「経営の必須事項」とお勧め本 - レベルエンター山本大のブログ
企業の経営を始めるにあたって、唯一必要なことを上げるとしたら？ それは簿記でも、税務でも、管理でもなく、「継続可能なビジネスモデルを持つ事」です。 私は経営学部を出ましたが、学校ではビジネスモデルの重要性やその組み立て方、注意点を教わった記憶がありません。 ですが、その代わりにたくさんの良い本を紹介してくれたので、今の自分があります。ですから本の選び方を教えてくれた大学の教授には大いに感謝してます。 これから起業しようという後輩たちに向けて、私もペイフォワードできたらと思いお勧め本をあげます。 ビジネスモデルとは「その事業がどんな価値を生み出しているか？どうやって継続・成長させていくか？誰が利益を得るのか（誰が顧客か）？その上でどれぐらいの対価を得るか？」ということです。 全然難しいことではありません。もしも難しいと感じているなら「新規で唯一のビジネスモデル」を考えようとしているからだと思
スマフォ受託の工数はストーリーポイントで見積もると良い - レベルエンター山本大のブログ
iPhoneやAndroidoといったスマートデバイス向けアプリの受託開発をやっています。 簡単に言うとオーダーメイドのスマフォアプリ開発です。 こういった案件の見積をいくつかやっていて気付いた点は、ストーリーポイント法を使って見積もると効果があるということです。 前提としてスマフォ開発は小規模だということ まずスマートデバイス向けアプリ開発は、 企業情報システム開発やECサイトなどの企業Webサイトに比べて開発規模が小さいことが多いです。 ふつうは数十万円程度、大きな案件でも200〜300万円を超えるような案件は希です。 （それに対して、企業情報システムなどは軽く数千万から数億円に達します。） 小規模の案件ですので、プロジェクトの全工程の見通しが効きます。そのため見積精度を上げやすいという特徴があります。 しかしながら、金額が小さいので細かい見積ミスの影響でも、開発会社にとっては赤字プロ
エンジニア人月０円セールと、ござ先輩に見た未来 - レベルエンター山本大のブログ
今日はid:gothedistanceと飲んだ。１年ぐらい前から飲もう飲もうといっていてようやく実現。 さすがはござ先輩。いろいろと教えてもらった。 その中で、SIおよびSEのこれからに暗い影を落とす話をした。 これはウチの関西側の営業担当が聞いてきた、あるSE派遣の企業の話。（とはいえ関西企業に限った話ではない） 何十人もの新人さんを集めて、無料でいろんなプロジェクトに派遣するビジネスモデルが台頭してきているらしい。 何十人の内、数名でも生き残って、その後定期的な売り上げになれば良いという、携帯の新規契約無料みたいなモデルだ。 経験者も言い値で出すという。 新人さんに経験を付けてもらうためにお試しで出向することは百歩譲って良いとしよう。 いくらなんでも新人ばかりで上手くいくと思っているような 受け入れ側もプロジェクトもさすがにないから、 こういう新人さんを受け入れるのも1つのプロジェクト
ソフト開発をステップ数で見積っていることに疑問を持たなくてはならない - レベルエンター山本大のブログ
ステップ数を見積もり根拠にする会社さんは、いまだに多い。嘘じゃない。 お世話になってる会社さんもそういう仕組みをとってるところがあって、いいにくい部分もなきにもあらずだが、お世話になってるからこそいいたい。 そんなことやってちゃだめだと。 １キロステップの生産性指数をだして、今回の開発は10キロだから１０００万円とか。 汎用機時代ならまだ百歩譲ってわからんでもないけど、オープン系という言葉すら死語になりつつあるこのご時世において、ステップ数が１キロ（１０００行）だったら１人月とかどうこうという話は、もはや見積もりでもなんでもなく、こじつけだ。 フレームワークのコアのコードも、 ビジネスロジックの肝のコードも、 ネットワークの通信コードも、 自動生成したコードも同じ１ステップとカウントする。 見積もり時の計画ステップ数と、実際に開発したときの実績ステップ数を比較して 次の開発の値決め（ダンピ
分散KVS設計の苦労ポイントTop 4 - レベルエンター山本大のブログ
さて信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計が、割とウケたので分散KVSの導入の話も書こう。 前エントリのブコメなどでもKVSでいいんじゃね？ってあった。 たしかに分散KVSは素晴らしい発明品だと思う。しかしながらRDBと同じように使ってはいけないしRDBの代替と考えてもいけない。 「KVSでいいんじゃね？」ってなノリで導入すると痛い目を見る。 RDBはよくできた製品である。RDBを正しく設計して使えば良いのだ。 RDBには人類がこの数十年で蓄積した沢山のノウハウがある。 KVSをやってみるとRDBの素晴らしさを改めて再認識することが多々あるだろう。 僕らは検討中、何度となく「RDBでいいんじゃね？」と口にした。 とは言えKVSも面白く、意義深い。要は使い分けである。 自分で言っていながらなんと多方面に気を使った回りくどいエントリだろう。
信じられないDB文化「固定長DB」でもあうんです。大規模コンシューマ向けサービスのRDB設計 - レベルエンター山本大のブログ
ずいぶん時間があいてしまったけど、大規模コンシューマ向けサービスRDB設計の続き。 僕はこのプロジェクトを自分のRDBの知識を使って革新してやろうと思って臨んだ。 しかし結果として逆に、コンシューマ向けサービスに最適化されたRDBの使い方について教わることになった。 ※ あと、KVSでいいじゃんって言ってる人もいるけど、それはKVS導入の苦労を知らない人だと思う。KVSの苦労は後で書く。 僕らが最近手がけているのは、とても大規模なコンシューマ向けサービスだ。 100万人の契約ユーザが使い、1テーブルに1億レコード以上のデータを貯め、24時間止めることが許されず、 要求から応答までのターンアラウンドタイムが1秒以内という厳しいSLAのサービスである。 中でも僕はDBやフレームワークの設計とアーキテクトっぽいことを担当している。 僕がこの現場に来て、驚愕した文化が2つある それは「Join禁止
エンジニアとして大成したいならやってはいけない48ヶ条 - レベルエンター山本大のブログ
いろんなエンジニアを見てきて、成功パターンはそれぞれだけれど 失敗パターンはだいたい決まっている。以下、アンチパターン。 成し遂げるのではなく、中途半端で満足する。 自分の責任と考えず、人のせいにする。 よりよくしようとせず、現状維持を良しとする。 仕事を中心においていない。 自分の特徴を構築していない。同世代と比べてさしたる特徴がない。 生活習慣を重視しない。日々の積み重ねに価値をおいていない。 与えられたチャンスに乗っからない。やる前から怖じ気づく。 アウトプットの質にこだわらない。 自分を分析していない。強み弱みを問われても答えられない。 刺激よりも、平穏を求める。変化に弱い。 行動よりも熟考を優先する。考えた末に行動しない。 現在の仕事の進め方に疑問を持たない。既存踏襲が正しいと思っている。 チームへの貢献よりも、自分の仕事の進捗を優先する。 焼き畑農業的な人間関係。信頼の構築では
ルーチンワークじゃあるまいし、効率や生産性を上げたからって残業はなくせんよ。 - レベルエンター山本大のブログ
今の勤務先では毎週水曜日、定時退社日となっていて ドアの前に張り紙が貼られる 「今日は定時退社日です。仕事の効率を上げて定時で退社しましょう」 と いやいや。効率上げても残業はなくせないよ。 ルーチンワークなら、効率を上げたから早く帰れるだろうけど、 エンジニアの仕事は、結局はモノづくり。 時間があれば、より時間をかけて良いものに仕上げるべきだ 時間があれば、より素早く先のリスクを摘んでおくべきだ という考え方になる。 定時退社したいなら、やるべきことは4つだけ 見切りを付ける やらないでいいことはやらない 時間泥棒にかかわらない 時計を中心に置く 見切りを付ける 約束や締切りが迫っている仕事以外は、見切りをつけてOKだ。 緊急だと思ってる仕事は、焦ってやっても上手くいかない。 長時間かかる仕事は、あと２時間や３時間やっても、大差ない。 やらないでいいことはやらない 効率を上げてゴミを掃除
簡単、OpenCV＋Javaで「顔認識プログラム」を作ってみよう！ - レベルエンター山本大のブログ
OpenCVで顔認識をするのが、いろんな言語で流行ってるけど、Javaでやってるのはあんまり見かけません。 と言うことで顔の部分を認識して四角で囲むってのをやってみます。 出来上がりはこんな感じ。 ハマったところはあったけど、出来上がってみると簡単。 OpenCVとは まずOpenCVをしらない人のために簡単に説明。 OpenCV（おーぷんしーぶい）とはインテルが開発・公開しているオープンソースのコンピュータビジョン向けライブラリ。 http://ja.wikipedia.org/wiki/OpenCV ただし、提供されているのはC++のライブラリなのでJavaなどから利用するのはちょっと手間です。 以下のサイトで、Javaから利用できるOpenCVのブリッジライブラリが提供されているのでここを参考にしてサンプルを作ってみます。 ただし、現時点ではまだOpenCVのすべての機能を、このライ
データベースパフォーマンスに関する、僕が知りうる限り最高の教科書 - レベルエンター山本大のブログ
データベースの醍醐味は、パフォーマンスチューニングにあります。 チューニングによっては、同じ処理でも1時間掛かる場合もあれば、 1秒で終わるということもあり得る世界です。 僕はDBの魅力に取り付かれた者の一人です。 DBという技術の奥深さが気に入っています。 DBを極めると、どこの現場に行っても絶対に必要とされます。 また、どこの現場に行っても正解を導く方程式は一緒なので応用が利くのです。 しかし、その基本原理を体系的に学べる手段はあまりありません。 OracleMasterやMCDBAといった資格試験でも学べることは限られていて あとはWebで調べるなりマニュアルを読むなりするしかありませんでした。 とくに肝であるパフォーマンスチューニングについては、 経験則でチューニングしている部分も多いです。 Oracle、SQLServer、MySQLと色々なDBのチューニングをしてきましたが、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
