小野和俊のブログ:ネット大企業病
■ 症状と名前の由来 ネット大企業病とは、ブログ等で何かしら情報発信をしようとした際、 「当たり前のことかもしれないしなぁ」 「ネガティブな反応があると嫌だしなぁ」 「感じ悪いと受け止められるかもしれないしなぁ」 「あまり面白くないかなぁ」 「自分ごときがこんなこと書いちゃいけないかな・・・」 「こんなこと言うと老害って言われるかな・・・」 「もしかすると誰も反応してくれないんじゃないかな・・・」 「こんなポエム書くとキモいだろうな・・・」 などという考えが頭をよぎり、 情報発信を躊躇するようになる病のことを指す。 失敗を恐れて行動そのものを起こさなくなったり、 慎重になってアウトプットが出るまでの速度や頻度が著しく低下する点において 大企業病と類似していることが命名の起源とされている。 ■ 発症の傾向と診断 特に一時期活発に情報発信を行なっており 一定の
進撃のプログラマー : 小野和俊のブログ
■ 半年後の君へ ドォォォン 兵士A 「第一バッファ、突破されました！！！」 兵士B 「そんな・・・この3年、バッファが食いつぶされたことなんてなかったのに・・・」 エレン 「こんな巨大なバグ、見たことがない・・・」 兵士A 「もし次のバッファが食いつぶされたら、このプロジェクトはもう終わりだ・・・」 ■ バグ調査兵団の帰還 母親 「私の息子は・・・？」 エルヴィン 「残念ながら・・・」 母親 「でも、息子は役に立ったんですよね？再現手順のひとつでも・・・見つけてきたんだろう？」 エルヴィン 「もちろん・・・いや・・・今回の調査で我々は、いや、今回も・・・くっ・・・何の成果も得られませんでしたぁぁ！！私が無能なばかりにただいたずらにスケジュールを食いつぶし、バグの原因を突き止めることが、できませんでしたぁぁ！！！」 ■ リヴァイ課長 「人類最強のトラブルシューター」と呼ばれ、1人で100人
エンジニアの成長と「快適な職場」について : 小野和俊のブログ
「時間あれば軽く飲んでいきます？」 一年前のちょうど今くらいの季節に、Diablo3のオフ会の後に伊藤直也さんと2人で新宿三丁目のバーに向かった。 伊藤さん曰く、 「グリーにいたとき、すごく優秀な人がいて。お願いしたいことを短い言葉で伝えるだけで、行間を読んでこちらがやりたいことを全部理解して、必要な指示を出して自分も動いてあっという間に成果を出しちゃう。」 一般に、エンジニアの楽園のような職場 - 快適で自由闊達に意見が言えて、技術力があり、それぞれが自主性を持ってのびのびと仕事をしている職場の方が、エンジニアは良いアウトプットを出せるし、類は友を呼んで優秀なエンジニアが集まってきやすい。これは確かなことだろう。ただ、エンジニアの成長を考える時、そういう職場は本当に理想的なのか、という点については、少し立ち止まって考える必要がある。 人の成長には、明るく楽しく周囲も優秀でコミュニケーショ
硬直化を避けるために希望を語る : 小野和俊のブログ
昨夜は某SIerの方々と飲んだ。 企業の大小に関わらず、大企業病的なものがあるけど、 どんな感じですかねぇ、と、そんな話になった。 問題が起きた時、これは誰のせいなんだという話になってしまうと、 萎縮して自分で手を上げることができなくなってしまう。 それで動きが鈍くなってしまうことが多々ある。 ひとつ希望が持てるのは、自社では、取締役がやるんだ、と 言ったことについては、未知の領域やリスクのある領域についても 突き進んでいくことができる企業体質があること。 しかしこれはこれで別の問題が浮上してきている。 それは、「取締役が言ったんだから」という言葉を盾に、 踏み込んで考えたり、創意工夫したりすることをせず、 思考停止してしまう人がいること。 それでね、私はこうするようにしてるんです、とO氏は続ける。 何かやりたいという夢や情熱や興味を持っている人がいれば、 とにかくまずやってみればいい。
レガシーコード改善ガイド : 小野和俊のブログ
以前からパラパラと部分的には目を通していたレガシーコード改善ガイドを、週末に最初から最後まで通して読んだ。 テスト駆動開発入門(以下TDD本)がゼロからテスト駆動でソフトウェアを開発するための方法を示した書籍であるのに対し、本書はテスト駆動で開発されなかったソフトウェアを、後からテスト駆動に変えていく方法を示した書籍である。本書の定義によれば、最近開発されたソフトウェアでも、テストコードのないコードはレガシーコードであり、そのレガシーコードを改善し、レガシーコードでなくしていくための道筋を提示するのが本書の目的だ。 TDDに興味は持ったものの、自分たちのソフトウェアはすでに完成してユーザーに使われており、今からTDD化のためだけに大きな予算や工数を取るわけにもいかず、「TDDは良いと思うけれど、次のプロジェクトから」という結論に落ち着いた事例を目にしたことがある人は少なくないだろう。そして
ペアプログラミングについて : 小野和俊のブログ
5年ほど前に「1日中ペアプロしかしないガチペアプロ」のエントリを書き、 その後も社内でも社外の開発合宿等でも 数えきれないほどのペアプロを行ったり見たりしてきたが その中で新たに気づくこともあったので、 エントリを書こうと思う。 ペアプロは、ドライバーとナビゲーターとが 二人三脚で一つのソフトウェアを作り上げたり、 磨き上げたりしていく行為だ。 二人で作業するので、ペアプロとは会話する行為でもある。 そして忘れてはならないのは、 ペアプロでの会話は聞こえている ということだ。 バグ修正やリファクタリングの際、 既存のコードを洗練させる前向きな目的で 「この箇所、ちょっとわかりにくいね。これだとバグが出やすいよね」 「ここは本当はこういう風に書いた方がきれいだね」 「この命名は誤解を招く可能性があるから、名前を変更しよう」 というような会話をすることがある。 さらに、名前から想像しにくい動き
UX/UIデザインガイドライン : 小野和俊のブログ
このところ、アプレッソの中でも、MIJS製品技術委員会でも、自分たちのソフトウェアのUX/UIをブラッシュアップしていくためにどんなことができるのかをディスカッションしている。 UX/UIデザインガイドラインとして各社の推奨する指針をまとめたものがWebで公開されているので、プログラマーであれデザイナーであれ、ソフトウェアの画面設計に何らかの形で携わるのであれば、基礎知識として主要なものには目を通し、プログラマーがデザインパターンの用語で手短にコミュニケーションが取れるのと同じように、「ここは○○ガイドラインの△△パターンを使うのはどうかな？」というような会話ができるようにしていきたいと思っている。 ■ Apple ・アップル ヒューマンインターフェースガイドライン ・iOSヒューマンインターフェースガイドライン(PDF) ・iPadヒューマンインターフェースガイドライン(PDF) ■ M
DataSpiderにおけるコンポーネント間のインタラクションの設計と実装 : 小野和俊のブログ
先日、ソースコードのメンテナビリティについてのエントリを書きましたが、dankogaiさんから「で、具体的にどんなコード書いてるの？」という指摘がありました。 返信エントリでは、「DataSpiderはオープンソースではないのでソースコードをそのまま出すことはできない」と書いたのですが、よく考えたら、一部エッセンスを抜き出してサンプルコードとして紹介することはできるので、最近私が書いたコードの中で、メンテナビリティに関係するコードを紹介したいと思います。 ※ ソースコードの行数が正しく表示されない場合にはブラウザの幅を広げると正しく表示されます。なお、ソースコードの構成をシンプルにするため今回のサンプルではViewModelは使用していません。 目次 ・コンポーネント間のインタラクションの管理 ・最も原始的な実装方法: コンポーネントの相互参照 ・Mediatorパターン ・Role Ob
小野和俊のブログ:メンテナビリティの高いソースコードを目指して
ソフトウェアを中長期にわたってメンテナンスしていく場合、メンテナンスしやすいコードと、メンテナンスしにくいコードとの間には、同じ機能を実現していたとしても、その価値には雲泥の差があります。 メンテナンスの容易さを示す言葉として、メンテナビリティ(Maintainability)という言葉がありますが、私自身、アプレッソでDataSpiderを11年間開発・メンテナンスしていく中で、「この人の書いたコードは本当にわかりやすいし無駄がない」とメンテナビリティの高いソースコードに感心させられることもあれば、「急いでいたとはいえ、このソースコードはリファクタリングしないと・・・」と、メンテナビリティの低いコードがソフトウェアに混入してしまったことを嘆くこともありました。 このエントリでは、一本のソフトウェアを11年間開発・メンテナンスしてきた経験から、ソフトウェアのメンテナビリティについて考察して
小野和俊のブログ:罪悪感駆動開発(zaiakukan-driven development; ZDD)
みなさんは罪悪感駆動開発(zaiakukan-driven development; ZDD)という言葉をご存知だろうか。私はつい先ほどまでこの概念を知らなかった。なぜなら先ほど自分で思いついたばかりだからだ。 仕事をしていく中で、やるべきことが山積みなのについネットサーフィンをしてしまい、「うわ、今日仕事全然進んでない、やばい」という罪悪感から、その後の仕事が妙に捗る、という経験をしたことがある人は少なくないだろう。 罪悪感駆動開発は、こうした危機感や罪悪感といった人間が本来持っている感情を引き出すことで、より高い仕事の成果を上げていくことを志向する。 罪悪感を感じるポイントは人によって個人差があるが、一般に仕事中に罪悪感が高まりやすい充填行為として、次のようなプラクティスが広く認知されている。 (a) 昼寝 (b) ネットサーフィン (c) ゲーム (d) タイピングソフトでランキング
成長のためのリセットボタン : 小野和俊のブログ
東急ハンズの長谷川さんがブログで印象深いエントリを書いていた。 東京渋谷: 成長のためには、リセットが必要だ。幼稚園、小学校、中学、高校、大学と「新米」と「最年長」を５回くりかえす。問題は、社会人になって、このサイクルが、１回しかないことだ。 大学４年生は、大学１年生をつかまえて、「子供だな〜」なんて、いうけど、社会人になったら、ペコペコだ。 社会になっても、このシステムがあれば、もっと、よい組織であり、会社になると思う。 私は、何歳であろうとも、役職がなんであろうとも、自分がなんていう会社に勤めていようとも 「フラットでいること」 が大切なんだなと思っている。 東京渋谷: 成長のためには、リセットが必要だ。幼稚園、小学校、中学、高校、大学と「新米」と「最年長」を５回くりかえす。問題は、社会人になって、このサイクルが、１回しかないことだ。 以前、「初心者であり続けること」というエントリを書
あえてNoSQLでクラウド上にエンタープライズアプリを作ってみる : 小野和俊のブログ
RDBMSとNoSQLを巡る議論でいつも私が違和感を感じるのは、RDBMSに固執しようとする人と、NoSQLに固執しようとする人と、それぞれが極端にどちらかを擁護し、極端にどちらかの長所や可能性に対して目を瞑ろうとしているように見受けられることである。 これまでRDBMSを業務で使ってきた人にNoSQLの制約の話をすると、大抵の場合、「そんなのじゃ業務には使えない」という反応が返ってくる。特に即時一貫性が保てないという話をすると「まったく使い物にならない」と脊髄反射的に拒否反応を示されることが多い。 私が思うに、クラウドがシステム構築で活用されていくのに比例して、これからは「RDBMSとNoSQLを適材適所で使い分ける」ことがこれからのアーキテクトに求められるのではないか。 これまではRDBMSがあったから何もかも一貫性が保障されていた。だが、本当にそこまですべてのデータに即時一貫性が必要
「努力なんて格好悪い」と斜に構えずに、集中して物事に取り組もう : 小野和俊のブログ
「起業してほぼ確実に成功する方法」 ホリエモンのこのエントリを、まあそうだよねーと思いながら読んでいたのだが、はてブのコメントを見たところ結構ネガティブな反応が多かったので驚いた。 どうも最近ネットでは、「長時間働くのは格好悪い」「海外ではそんな働き方誰もしていない。日本人格好悪すぎる」というようなエントリがよく話題になるようだが、私なんかはこうしたエントリを読む度に、 打ち込んでいることにできるだけたくさんの時間を使おうとするのってそんなに格好悪いことですか？？ shi3zさんとかはiPadが発売されるからということでサンフランシスコまで出向いてすぐにレビュー中継を配信したりしている。iPhoneの時もそうだったけど、自分が情熱を傾けている対象に対して、この上でどんなものを動かしたら面白いだろう、何が必要になってくるだろうと必死で考えて、徹夜で仕事して会社に泊まって、私はそんなshi3z
成長しないプログラマーの7つの悪習慣 : 小野和俊のブログ
はてブのホットエントリで「成功できない人たちが持つ7つの悪習慣」という記事を見かけたのだが、ライフハック系の本やエントリは胡散臭く感じるところがあってあまり好きではない私から見ても、これは確かに、と思える内容で、プログラマーについても同じことが言えると思ったので、エントリにまとめてみた。 ・自分の理解力不足を技術のせいにする。すぐ理解できない技術や、普段自分が使い慣れてない技術は「キモイ」、「自分には合わない」などといってすぐ学習を放棄する。 ・他人の非に非常に敏感。使っているライブラリや人が書いたコードに少しでもバグが見つかると、「使い物にならない」、「書き直した方が早い」などとすぐ口にする。 ・環境がよく壊れる。「このPC不安定」、「また開発環境がおかしくなった」、「OSから入れ直さないと」といったように、作業環境が頻繁におかしくなる。たいていは自分で必要なファイルを消してしまったり上
Twitterの危険性 : 小野和俊のブログ
コメント一覧 (11) 1. ありがとうございます 2009年11月16日 05:55 最初の意気込みだけででエネルギーを使い果たしてしまった・・・ そうならないように気をつけます。 2. nic 2009年11月16日 17:50 たしかに、よく言われてますね。なにかで発散されてしまうと満足してしまって、創作意欲がなくなると。 私はTwitterで反応してくれるお友達がいないので、呟いても全然大丈夫です 3. min 2009年11月16日 19:05 でも、それってTwitterに限ったことじゃないし、ブログも同じだし、インターネット自体がそうだし？？？ 4. fo 2009年11月16日 21:20 >>3 読解力が無いって言われない？ 5. ベータブロガー 2009年11月16日 22:35 blogとtwitterを同列に並べるのがそも間違い それぞれの特徴をとらえて合ったものを
プログラマーの開発速度は「はまる」時間の長さで決まる : 小野和俊のブログ
プログラミングを始めてから今日に至るまで、 様々なタイプのプログラマーと開発を共にしてきたが、 驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、 一つ共通の特徴があるように思える。 それは、「はまる」時間が極端に短い、ということである。 風のプログラマー」を指向しており、開発速度を重要視している。 例えば平成14年未踏ソフトウェア創造事業「PICSY」では、 発表直前に知人でプロジェクトリーダーの鈴木健にレスキュー隊として呼ばれて 2,3日でGUI全般と、クライアント/サーバー通信部分の設計と実装を終わらせたのだが、 このときなどは、大体の要件を口頭で聞いた後は、 ほぼまったく手が止まらずコードを書き続ける感じで開発をしていた。 「はまる」時間の長さは開発速度に直結するわけだが、 プログラマーが「はまる」場合にはある程度の傾向があると思うので、 今日は「はまる」プログラマ
はてなおやさんからの手紙、そしてはてブFirefox拡張 : 小野和俊のブログ
本日午後三時半頃、はてな伊藤さんからのmixi新着メッセージを知らせるメールが私のThunderbirdに届いた。何だろうと思ってメールを見た途端、私はうれしさで飛び上がりそうになったのだった。 それもそのはず、個人的に以前から熱望していたはてなブックマークFirefox拡張が、βリリースされたというのだ。メールは、次のような内容だった(引用許可をもらっています)。 1年以上前に飲み会で del.icio.us の Firefox 拡張の話にはじまって はてなブックマークに Firefox 拡張作らないの? というようなことを 話したのを覚えていますでしょうか。 あの話を聞いて以来 Firefox 拡張を作るぞと固く決心したのですが ようやく今日ベータ版をリリースできました。 http://hatena.g.hatena.ne.jp/hatenabookmark/20090402/fire
プログラマー面接時の技術的な質問事項(アプレッソ版) - 解答編 : 小野和俊のブログ
昨日、プログラマー面接時の技術的な質問事項(アプレッソ版)を書いたところ、「自分ならこう答える」というエントリを書いてくれた人が何人かいて、個別にコメントしようかとも思ったのだが、昨日のエントリだけだと質問の投げっぱなしになってしまうところもあるので、解答編を書くことにした。 なお、「面接の質問項目を公表しちゃっていいの？」という指摘もあったが、ブログに書いたのはあくまでも質問項目の一例だし、解法を検討する過程を見れば普段どんな風に開発しているのかはだいたいわかるので、特に問題ない。 for (int i = 0; i < list.getLength(); i++) {}の潜在的パフォーマンスボトルネック list.getLength()がlist.getLength()回評価されてしまう。具体例としては、JREに標準で付属するDOMのライブラリのNodeListの実装はlist.get
プログラマー面接時の技術的な質問事項(アプレッソ版) : 小野和俊のブログ
技術者・SE・プログラマ面接時の技術的な質問事項というエントリをはてブで見かけたのだが、私もjavaプログラマーの面接を割とよくやっているので、よく質問する内容をまとめてみた。 (ちなみに、基本的にコーディング面接の形態を取っている) プロジェクトの性質にもよると思うが、私の場合には、情報処理技術者試験的に基礎が満遍なく抑えられているかどうかよりも、 すぐ答えが見つからないような課題に対して、きちんと自分でやり方を考え、対応することができるか 「変な」コードをコミットしたりしないか(見つけにくいバグを混入させるとか、汚いとか、遅いとか)といった点を重視している。 まず、何を知っているかよりも、どんなものを作れるか、どんなことができるか、という質問。 ここで強烈な回答が来る人は、たいていここより下の質問は「あー、はいはい」という感じでサラッと答えてくることが多い。 これまでに携わってきた開発
小野和俊のブログ:[お知らせ] ソフト開発未来会議「どうなる!?日本のソフト開発」
2009年2月18日(水) 19:00〜21:00、マイクロソフト新宿セミナールームで開催される ソフト開発未来会議のパネルディスカッションににパネラーとして参加します。 今回はクラウド関係や今後のソフト開発、という割と広めなテーマ設定になっていて、 合間に軽食を兼ねたフリーディスカッションみたいなものもあるようなので、 時間のある方はぜひ :) イベントの詳細・参加申し込みはこちらから: ソフト開発未来会議[オフライン] 第一回 どうなる!?日本のソフト開発 トラックバックURL (スパム対策のため、この記事へのリンクが含まれないエントリからのトラックバックは自動的に拒否されてしまうのでご注意ください。また、トラックバックを送っていただいても何故か届かないことがありますが、当ブログではスパムや一切関係のないトラックバック以外のトラックバックを拒否することは原則ありませんの
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
