本を出しました。「その仕事、全部やめてみよう」 このブログで書いてきたこと。 この20年間仕事で取り組んできたこと。 プログラマーとして、経営者として、感じたことや学んだこと。 誰かに伝えたら、その人や、あるいはその人のいる会社が、 もしかしたら何か変わっていくかもしれないこと。 「2020年版、書籍版・小野和俊のブログ」 のような形でまとめたらどんな風になるだろう。 そんな風に考えながらこの1年半ほど本を書いていました。 そしてようやく完成したのが今回の本です。 220ページの本になりました。 先日、とある日本の大企業の幹部の方からこんな相談を受けました。 「うちは事業会社ですが、手の内化・内製化が大事だということで、 今回初めて外部からベンチャー出身のエンジニアを採用してみたんです。 そしたらみんなが忙しい仕事中にも、業務時間外の夜中にも、 思いついたことを次々と好き勝手提案してくるん

トラックバック一覧 1. View point [〔N〕水泳・競泳情報のSWIMMING VIEW] 2007年06月19日 21:03 ・『コミかる！』届く！これで20世紀少年三昧だ！ ・「バランスボールで快適パソ... 2. 2007年6月19日　夏のボーナス [神戸の三代目] 2007年06月20日 00:30 車を購入して早1年が経とうとしています。もうすぐ、1年目の点検。ネタ夫の帰宅が早い！ : 家族・友人・人間関係 : 発言小町 : 大手小町 : YOMIURI ONLINE（読売新聞）　帰ってくるのが遅いと怒られ、帰ってくるのが早いと迷惑がられ・??y� 3. バランスボールでPCライフをハックする [My Digital Life Log] 2007年06月21日 15:00 バランスボールで快適パソコンライフのエントリに感化されて、ボクも投稿してみます。 バランスボールを

「HRTの原則」という言葉をご存知だろうか。 これは書籍 Team Geek ―Googleのギークたちはいかにしてチームを作るのか で紹介されている言葉であり、本書ではほぼ一冊すべてをかけてこのHRTの原則とその実践方法とを様々な角度から紹介している。 1. 謙虚(Humility) 2. 尊敬(Respect) 3. 信頼(Trust) の3つの価値が大切にされており、エンジニアとしてもチームや組織、顧客との対話においてこれらの価値を重んじていくことが成功につながる、というものである。 あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ Team Geek p.15 プログラマとして成功するには、最新の言語を覚えたり高速なコードを書いたりするだけではいけない。プログラマは常にチームで仕事をする。君が思っている以上に、チームは個人の生産性や幸福に直接影響するのである。 Team

伊藤直也さんが「些末なコードレビュー」というエントリを書いて話題になっている。このエントリで伊藤さんはコードレビューの話と、はてなのJavaScriptの話と2つの話題に触れている。前者のコードレビューについてはアプレッソでは8年ほど前から「コードレビューを通っていないコードはコミット不可」というルールですべてのソースコードに対してコードレビューを必須にしてきた関係で私も思うところがあるので、エントリを書いてみようと思う。 伊藤さんが例示しているように、インデントやreturnの省略などの話は好みの問題であり、議論してもソフトウェアの改善につながらない。なのでコードレビューでこうした宗教論争が起こるようなら、コーディング規約を見直すべきだ。「無駄に悩んだり議論したりすることを減らす」ことはコーディング規約の主たる効果のひとつだと言える。 コードレビューに慣れないチームが、何の考えもナシにコ

■ 半年後の君へ ドォォォン 兵士A 「第一バッファ、突破されました！！！」 兵士B 「そんな・・・この3年、バッファが食いつぶされたことなんてなかったのに・・・」 エレン 「こんな巨大なバグ、見たことがない・・・」 兵士A 「もし次のバッファが食いつぶされたら、このプロジェクトはもう終わりだ・・・」 ■ バグ調査兵団の帰還 母親 「私の息子は・・・？」 エルヴィン 「残念ながら・・・」 母親 「でも、息子は役に立ったんですよね？再現手順のひとつでも・・・見つけてきたんだろう？」 エルヴィン 「もちろん・・・いや・・・今回の調査で我々は、いや、今回も・・・くっ・・・何の成果も得られませんでしたぁぁ！！私が無能なばかりにただいたずらにスケジュールを食いつぶし、バグの原因を突き止めることが、できませんでしたぁぁ！！！」 ■ リヴァイ課長 「人類最強のトラブルシューター」と呼ばれ、1人で100人

清水亮という男がいる。ネットのidはshi3z。 本当に嫌な奴で、だいたい飲み会の席で同席すると喧嘩になる。 4年ほど前にもこんなことがあった。九州大学工学部大学院の『高度ITCリーダーシップ特論』という授業の講師として招かれた我々は講師陣の飲み会で口喧嘩を始め、shi3zさんは私に捨て台詞を吐いてその場を退席したのだった。リーダーの見本たるべき私達が飲み会の席で喧嘩別れし、しかもその直後からTwitterなどの公の場で互いに罵り合う姿を見て、「自分はこんなリーダーにだけはなりたくない」と思った学生も少なからずいただろう。この授業の本質が、ダメなリーダーを反面教師的に間近に見ることで受講生の意識改革を促すことにあったのだとしたら、そこまで見越してコーディネートした楠さんの深謀遠慮には敬服の意を表さざるを得ない。 shi3zさんの昨日のエントリによれば、小野和俊、すなわち私という人間は、慶応

「時間あれば軽く飲んでいきます？」 一年前のちょうど今くらいの季節に、Diablo3のオフ会の後に伊藤直也さんと2人で新宿三丁目のバーに向かった。 伊藤さん曰く、 「グリーにいたとき、すごく優秀な人がいて。お願いしたいことを短い言葉で伝えるだけで、行間を読んでこちらがやりたいことを全部理解して、必要な指示を出して自分も動いてあっという間に成果を出しちゃう。」 一般に、エンジニアの楽園のような職場 - 快適で自由闊達に意見が言えて、技術力があり、それぞれが自主性を持ってのびのびと仕事をしている職場の方が、エンジニアは良いアウトプットを出せるし、類は友を呼んで優秀なエンジニアが集まってきやすい。これは確かなことだろう。ただ、エンジニアの成長を考える時、そういう職場は本当に理想的なのか、という点については、少し立ち止まって考える必要がある。 人の成長には、明るく楽しく周囲も優秀でコミュニケーショ

ペアプロで if-then-else 文が出てきた際、「これ、else if の順序、こっちの方が良くない？」というような会話をすることが時折ある。 どれも当たり前のものかもしれないが、「ああ、確かに」という反応があることもあるので、今日はそんな会話の際に出てくる視点についてまとめてみた。 if (よくあるケース/正常なケース) { // 処理 } else if (比較的特殊なケース) { // 処理 } else if (さらに特殊なケース) { // 処理 } else { // 処理 } 条件式の結果がtrueになる確率が高く、「ノーマル」に近いものを上に書く。可読性が上がる他、特に2.で触れる条件式の判定に時間のかかる場合や、ループの最奥にある処理などのif-then-else文の実行される回数が極めて多い場合には体感レベルで実行速度にも大きな差が出ることもある。 Code Co

5年ほど前に「1日中ペアプロしかしないガチペアプロ」のエントリを書き、 その後も社内でも社外の開発合宿等でも 数えきれないほどのペアプロを行ったり見たりしてきたが その中で新たに気づくこともあったので、 エントリを書こうと思う。 ペアプロは、ドライバーとナビゲーターとが 二人三脚で一つのソフトウェアを作り上げたり、 磨き上げたりしていく行為だ。 二人で作業するので、ペアプロとは会話する行為でもある。 そして忘れてはならないのは、 ペアプロでの会話は聞こえている ということだ。 バグ修正やリファクタリングの際、 既存のコードを洗練させる前向きな目的で 「この箇所、ちょっとわかりにくいね。これだとバグが出やすいよね」 「ここは本当はこういう風に書いた方がきれいだね」 「この命名は誤解を招く可能性があるから、名前を変更しよう」 というような会話をすることがある。 さらに、名前から想像しにくい動き

いまだに知らないなんてありえない病とは、プログラマー同士の会話の場で、 「いまだに○○という本さえ読んでいないなんてありえない」 「いまだに○○というフレームワークさえ使っていないなんてありえない」 「いまだに○○という言語を触ったことさえないなんてありえない」 「いまだに○○というパターンさえ知らないなんてありえない」 というように、自分が知っていて相手が知らないものについて、 「いまだに知らないなんてありえない」 と発言してしまう病の総称である。 発症例として、例えば次のようなものがある。 「いまだにマシン語が書けないなんてありえない」 「いまだにRubyを1行も書いたことないなんてありえない」 「いまだにVisitorパターンさえ知らないなんてありえない」 「いまだに高校レベルの数学も押さえていないなんてありえない」 「いまだに個人で開発したアプリが1つもないなんてありえない」 「い

このところ、アプレッソの中でも、MIJS製品技術委員会でも、自分たちのソフトウェアのUX/UIをブラッシュアップしていくためにどんなことができるのかをディスカッションしている。 UX/UIデザインガイドラインとして各社の推奨する指針をまとめたものがWebで公開されているので、プログラマーであれデザイナーであれ、ソフトウェアの画面設計に何らかの形で携わるのであれば、基礎知識として主要なものには目を通し、プログラマーがデザインパターンの用語で手短にコミュニケーションが取れるのと同じように、「ここは○○ガイドラインの△△パターンを使うのはどうかな？」というような会話ができるようにしていきたいと思っている。 ■ Apple ・アップル ヒューマンインターフェースガイドライン ・iOSヒューマンインターフェースガイドライン(PDF) ・iPadヒューマンインターフェースガイドライン(PDF) ■ M

みなさんは罪悪感駆動開発(zaiakukan-driven development; ZDD)という言葉をご存知だろうか。私はつい先ほどまでこの概念を知らなかった。なぜなら先ほど自分で思いついたばかりだからだ。 仕事をしていく中で、やるべきことが山積みなのについネットサーフィンをしてしまい、「うわ、今日仕事全然進んでない、やばい」という罪悪感から、その後の仕事が妙に捗る、という経験をしたことがある人は少なくないだろう。 罪悪感駆動開発は、こうした危機感や罪悪感といった人間が本来持っている感情を引き出すことで、より高い仕事の成果を上げていくことを志向する。 罪悪感を感じるポイントは人によって個人差があるが、一般に仕事中に罪悪感が高まりやすい充填行為として、次のようなプラクティスが広く認知されている。 (a) 昼寝 (b) ネットサーフィン (c) ゲーム (d) タイピングソフトでランキング

先日、ソースコードのメンテナビリティについてのエントリを書きましたが、dankogaiさんから「で、具体的にどんなコード書いてるの？」という指摘がありました。 返信エントリでは、「DataSpiderはオープンソースではないのでソースコードをそのまま出すことはできない」と書いたのですが、よく考えたら、一部エッセンスを抜き出してサンプルコードとして紹介することはできるので、最近私が書いたコードの中で、メンテナビリティに関係するコードを紹介したいと思います。 ※ ソースコードの行数が正しく表示されない場合にはブラウザの幅を広げると正しく表示されます。なお、ソースコードの構成をシンプルにするため今回のサンプルではViewModelは使用していません。 目次 ・コンポーネント間のインタラクションの管理 ・最も原始的な実装方法: コンポーネントの相互参照 ・Mediatorパターン ・Role Ob

昨日、「メンテナビリティの高いソースコードを目指して」というエントリを書いたところ、dankogaiさんから、「コードも見せていないお前にコードを語る資格はない」と怒られてしまったので返信エントリ。 実はブログを初めて1,2年くらいの頃はコードを含むエントリをそこそこ書いてたのですが、プログラマーでない知人から「何の話か全然わからなかった」と言われ、またdankogaiさんも指摘している通り、「コードについて書く方がコードを書くより読まれる現実」があり、コードを含むエントリはJava Programming Tipsという別のブログに移した経緯があります。 ではどこに力を入れているかというと、私が一番力を入れいてるのはDataSpiderという商用ソフトウェアの設計と実装ですが、これはアプレッソの50人の社員を10年間支えてきてくれているソフトウェアなので「はい、どうぞ」とソースコードをお

ソフトウェアを中長期にわたってメンテナンスしていく場合、メンテナンスしやすいコードと、メンテナンスしにくいコードとの間には、同じ機能を実現していたとしても、その価値には雲泥の差があります。 メンテナンスの容易さを示す言葉として、メンテナビリティ(Maintainability)という言葉がありますが、私自身、アプレッソでDataSpiderを11年間開発・メンテナンスしていく中で、「この人の書いたコードは本当にわかりやすいし無駄がない」とメンテナビリティの高いソースコードに感心させられることもあれば、「急いでいたとはいえ、このソースコードはリファクタリングしないと・・・」と、メンテナビリティの低いコードがソフトウェアに混入してしまったことを嘆くこともありました。 このエントリでは、一本のソフトウェアを11年間開発・メンテナンスしてきた経験から、ソフトウェアのメンテナビリティについて考察して

RDBMSとNoSQLを巡る議論でいつも私が違和感を感じるのは、RDBMSに固執しようとする人と、NoSQLに固執しようとする人と、それぞれが極端にどちらかを擁護し、極端にどちらかの長所や可能性に対して目を瞑ろうとしているように見受けられることである。 これまでRDBMSを業務で使ってきた人にNoSQLの制約の話をすると、大抵の場合、「そんなのじゃ業務には使えない」という反応が返ってくる。特に即時一貫性が保てないという話をすると「まったく使い物にならない」と脊髄反射的に拒否反応を示されることが多い。 私が思うに、クラウドがシステム構築で活用されていくのに比例して、これからは「RDBMSとNoSQLを適材適所で使い分ける」ことがこれからのアーキテクトに求められるのではないか。 これまではRDBMSがあったから何もかも一貫性が保障されていた。だが、本当にそこまですべてのデータに即時一貫性が必要

昨日、プログラマー面接時の技術的な質問事項(アプレッソ版)を書いたところ、「自分ならこう答える」というエントリを書いてくれた人が何人かいて、個別にコメントしようかとも思ったのだが、昨日のエントリだけだと質問の投げっぱなしになってしまうところもあるので、解答編を書くことにした。 なお、「面接の質問項目を公表しちゃっていいの？」という指摘もあったが、ブログに書いたのはあくまでも質問項目の一例だし、解法を検討する過程を見れば普段どんな風に開発しているのかはだいたいわかるので、特に問題ない。 for (int i = 0; i < list.getLength(); i++) {}の潜在的パフォーマンスボトルネック list.getLength()がlist.getLength()回評価されてしまう。具体例としては、JREに標準で付属するDOMのライブラリのNodeListの実装はlist.get

技術者・SE・プログラマ面接時の技術的な質問事項というエントリをはてブで見かけたのだが、私もjavaプログラマーの面接を割とよくやっているので、よく質問する内容をまとめてみた。 (ちなみに、基本的にコーディング面接の形態を取っている) プロジェクトの性質にもよると思うが、私の場合には、情報処理技術者試験的に基礎が満遍なく抑えられているかどうかよりも、 すぐ答えが見つからないような課題に対して、きちんと自分でやり方を考え、対応することができるか 「変な」コードをコミットしたりしないか(見つけにくいバグを混入させるとか、汚いとか、遅いとか)といった点を重視している。 まず、何を知っているかよりも、どんなものを作れるか、どんなことができるか、という質問。 ここで強烈な回答が来る人は、たいていここより下の質問は「あー、はいはい」という感じでサラッと答えてくることが多い。 これまでに携わってきた開発

「起業してほぼ確実に成功する方法」 ホリエモンのこのエントリを、まあそうだよねーと思いながら読んでいたのだが、はてブのコメントを見たところ結構ネガティブな反応が多かったので驚いた。 どうも最近ネットでは、「長時間働くのは格好悪い」「海外ではそんな働き方誰もしていない。日本人格好悪すぎる」というようなエントリがよく話題になるようだが、私なんかはこうしたエントリを読む度に、 打ち込んでいることにできるだけたくさんの時間を使おうとするのってそんなに格好悪いことですか？？ shi3zさんとかはiPadが発売されるからということでサンフランシスコまで出向いてすぐにレビュー中継を配信したりしている。iPhoneの時もそうだったけど、自分が情熱を傾けている対象に対して、この上でどんなものを動かしたら面白いだろう、何が必要になってくるだろうと必死で考えて、徹夜で仕事して会社に泊まって、私はそんなshi3z

はてブのホットエントリで「成功できない人たちが持つ7つの悪習慣」という記事を見かけたのだが、ライフハック系の本やエントリは胡散臭く感じるところがあってあまり好きではない私から見ても、これは確かに、と思える内容で、プログラマーについても同じことが言えると思ったので、エントリにまとめてみた。 ・自分の理解力不足を技術のせいにする。すぐ理解できない技術や、普段自分が使い慣れてない技術は「キモイ」、「自分には合わない」などといってすぐ学習を放棄する。 ・他人の非に非常に敏感。使っているライブラリや人が書いたコードに少しでもバグが見つかると、「使い物にならない」、「書き直した方が早い」などとすぐ口にする。 ・環境がよく壊れる。「このPC不安定」、「また開発環境がおかしくなった」、「OSから入れ直さないと」といったように、作業環境が頻繁におかしくなる。たいていは自分で必要なファイルを消してしまったり上