HRTの原則 〜ソフトウェア開発はバーでしっとり語り合うように 〜 : 小野和俊のブログ
「HRTの原則」という言葉をご存知だろうか。 これは書籍 Team Geek ―Googleのギークたちはいかにしてチームを作るのか で紹介されている言葉であり、本書ではほぼ一冊すべてをかけてこのHRTの原則とその実践方法とを様々な角度から紹介している。 1. 謙虚(Humility) 2. 尊敬(Respect) 3. 信頼(Trust) の3つの価値が大切にされており、エンジニアとしてもチームや組織、顧客との対話においてこれらの価値を重んじていくことが成功につながる、というものである。 あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ Team Geek p.15 プログラマとして成功するには、最新の言語を覚えたり高速なコードを書いたりするだけではいけない。プログラマは常にチームで仕事をする。君が思っている以上に、チームは個人の生産性や幸福に直接影響するのである。 Team
コードレビューについて : 小野和俊のブログ
伊藤直也さんが「些末なコードレビュー」というエントリを書いて話題になっている。このエントリで伊藤さんはコードレビューの話と、はてなのJavaScriptの話と2つの話題に触れている。前者のコードレビューについてはアプレッソでは8年ほど前から「コードレビューを通っていないコードはコミット不可」というルールですべてのソースコードに対してコードレビューを必須にしてきた関係で私も思うところがあるので、エントリを書いてみようと思う。 伊藤さんが例示しているように、インデントやreturnの省略などの話は好みの問題であり、議論してもソフトウェアの改善につながらない。なのでコードレビューでこうした宗教論争が起こるようなら、コーディング規約を見直すべきだ。「無駄に悩んだり議論したりすることを減らす」ことはコーディング規約の主たる効果のひとつだと言える。 コードレビューに慣れないチームが、何の考えもナシにコ
「『ガンダム』を創った男たち。」 : 小野和俊のブログ
機動戦士ガンダムといえばロボットアニメの金字塔であり、日本国内に「ガンダム」という言葉を聞いたことがない、という人はほとんどいないのではないかと思える程の知名度を誇る作品だ。 こうした印象から、ガンダムと言えば「大成功したアニメ」という印象を持つ人が大半だろう。しかし「『ガンダム』を創った男たち。」を読むとその印象は一変する。 こうした紆余曲折を経て遂にTV上映が始まるが、その結果は大惨敗だった。15%〜20%が期待された第一回の視聴率はたった3%。そして第七回では遂に実質0%の「誰も見ていない番組」にまで落ち込んでしまう。この状況を打開すべく、次々と新モビルスーツを登場させ、さらに「オモチャが売れれば数字には目をつぶる」というスポンサーの声に応えるべく、ガンダムというドラマを完成させるための苦肉の策として、兵器としてはリアリティがまったくなく、しかし「オモチャとしては最高」の妥協の産物で
"connecting the dots"な生き方 : 小野和俊のブログ
スマートフォン向けのニュースアプリSmartNewsが、先日第三者割当増資によって4億2千万円の資金調達を行い、話題になっています。 SmartNewsを開発している株式会社ゴクロの取締役の鈴木健さん(以下健さん)は大学時代の弁論部の先輩で、卒業後も仕事や各種プロジェクト、ネットゲーム、飲み会などで時折接点があるのですが、この記事などを見ていると、SmartNewsの長所と、健さんのこれまで取り組んできたこととのつながりが改めて感じられ、スティーブ・ジョブスの"connecting the dots"という言葉を思い出します。 また、「タコツボ化しない情報収集」は彼が関わっていた一連の未踏ソフト関連のプロジェクトのテーマのひとつで、情報が氾濫する時代に、いかに各個人にパーソナライズした情報を適切に届けるか、ということは、健さんが長年追い求めてきたテーマのひとつでした。SmartNewsを支
小野和俊のブログ:ネット大企業病
■ 症状と名前の由来 ネット大企業病とは、ブログ等で何かしら情報発信をしようとした際、 「当たり前のことかもしれないしなぁ」 「ネガティブな反応があると嫌だしなぁ」 「感じ悪いと受け止められるかもしれないしなぁ」 「あまり面白くないかなぁ」 「自分ごときがこんなこと書いちゃいけないかな・・・」 「こんなこと言うと老害って言われるかな・・・」 「もしかすると誰も反応してくれないんじゃないかな・・・」 「こんなポエム書くとキモいだろうな・・・」 などという考えが頭をよぎり、 情報発信を躊躇するようになる病のことを指す。 失敗を恐れて行動そのものを起こさなくなったり、 慎重になってアウトプットが出るまでの速度や頻度が著しく低下する点において 大企業病と類似していることが命名の起源とされている。 ■ 発症の傾向と診断 特に一時期活発に情報発信を行なっており 一定の
小野和俊のブログ:7月からのポジションについて＆アプレッソ開発エンジニアウォンテッド！
7月から肩書きが変わりまして、これまでアプレッソ代表取締役副社長CTOだったのですが、代表取締役社長になりました。また、兼任で、セゾン情報システムズHULFT事業部CTOにも就任いたしました。 アプレッソについては、前期は売上・利益ともに過去最高となりまして、おかげさまで好調に業績が推移してきていますが、より価値ある製品をつくりあげ、ご提供していくことができるよう心がけながら、社業に取り組んでいきたいと思います。タイトルからはCTOが外れましたが、引き続き現役プログラマーとしても腕に磨きをかけていきたいと思います。 HULFTは、エンタープライズ業界でもっとも成功しているプロダクトのひとつと言えるかと思います。エンタープライズのど真ん中に広く深く浸透している大先輩の製品に学び、確かさ、堅牢さ、変わらず使い続けることができる安心感などのHULFTの良さに最大限の敬意を払い、これらの要素を
私がshi3zさんを愛さずにいられない理由、そしてノブレス・オブリージュ : 小野和俊のブログ
清水亮という男がいる。ネットのidはshi3z。 本当に嫌な奴で、だいたい飲み会の席で同席すると喧嘩になる。 4年ほど前にもこんなことがあった。九州大学工学部大学院の『高度ITCリーダーシップ特論』という授業の講師として招かれた我々は講師陣の飲み会で口喧嘩を始め、shi3zさんは私に捨て台詞を吐いてその場を退席したのだった。リーダーの見本たるべき私達が飲み会の席で喧嘩別れし、しかもその直後からTwitterなどの公の場で互いに罵り合う姿を見て、「自分はこんなリーダーにだけはなりたくない」と思った学生も少なからずいただろう。この授業の本質が、ダメなリーダーを反面教師的に間近に見ることで受講生の意識改革を促すことにあったのだとしたら、そこまで見越してコーディネートした楠さんの深謀遠慮には敬服の意を表さざるを得ない。 shi3zさんの昨日のエントリによれば、小野和俊、すなわち私という人間は、慶応
エンジニアの成長と「快適な職場」について : 小野和俊のブログ
「時間あれば軽く飲んでいきます？」 一年前のちょうど今くらいの季節に、Diablo3のオフ会の後に伊藤直也さんと2人で新宿三丁目のバーに向かった。 伊藤さん曰く、 「グリーにいたとき、すごく優秀な人がいて。お願いしたいことを短い言葉で伝えるだけで、行間を読んでこちらがやりたいことを全部理解して、必要な指示を出して自分も動いてあっという間に成果を出しちゃう。」 一般に、エンジニアの楽園のような職場 - 快適で自由闊達に意見が言えて、技術力があり、それぞれが自主性を持ってのびのびと仕事をしている職場の方が、エンジニアは良いアウトプットを出せるし、類は友を呼んで優秀なエンジニアが集まってきやすい。これは確かなことだろう。ただ、エンジニアの成長を考える時、そういう職場は本当に理想的なのか、という点については、少し立ち止まって考える必要がある。 人の成長には、明るく楽しく周囲も優秀でコミュニケーショ
進撃のプログラマー : 小野和俊のブログ
■ 半年後の君へ ドォォォン 兵士A 「第一バッファ、突破されました！！！」 兵士B 「そんな・・・この3年、バッファが食いつぶされたことなんてなかったのに・・・」 エレン 「こんな巨大なバグ、見たことがない・・・」 兵士A 「もし次のバッファが食いつぶされたら、このプロジェクトはもう終わりだ・・・」 ■ バグ調査兵団の帰還 母親 「私の息子は・・・？」 エルヴィン 「残念ながら・・・」 母親 「でも、息子は役に立ったんですよね？再現手順のひとつでも・・・見つけてきたんだろう？」 エルヴィン 「もちろん・・・いや・・・今回の調査で我々は、いや、今回も・・・くっ・・・何の成果も得られませんでしたぁぁ！！私が無能なばかりにただいたずらにスケジュールを食いつぶし、バグの原因を突き止めることが、できませんでしたぁぁ！！！」 ■ リヴァイ課長 「人類最強のトラブルシューター」と呼ばれ、1人で100人
ベンチャー企業の事業推進と資本政策: 私の場合 : 小野和俊のブログ
2ヶ月前にポストした前回のエントリに関して、「おめでとうございます」的なコメントを多数いただいた一方、「小野さんって8%しか株持ってなかったの？ギリギリまでむしり取られてたのね・・・」的な感想をTweetしている人もいたようで、いや、違うんだけどなぁと思いつつも別にエントリを書くほどのことでもないか、と思っていたのですが、アプレッソの資本政策周りの経緯を書いておくことは今後ベンチャーを始める人の参考になる部分もあるかもしれないのでエントリを書くことにしました。 会社を始める目的は人それぞれかと思います。こんなものがあったら素晴らしいだろう、というアイデアを世に問うてみたい、という人もいるでしょうし、一攫千金を夢見る人もいるでしょう。自分の中にくすぶる若さのエネルギーをぶつける先がなく、ほぼ勢いだけで始める人もいるでしょうし、身近な誰かが切実に求めているものがあり、それを実現するために起業す
硬直化を避けるために希望を語る : 小野和俊のブログ
昨夜は某SIerの方々と飲んだ。 企業の大小に関わらず、大企業病的なものがあるけど、 どんな感じですかねぇ、と、そんな話になった。 問題が起きた時、これは誰のせいなんだという話になってしまうと、 萎縮して自分で手を上げることができなくなってしまう。 それで動きが鈍くなってしまうことが多々ある。 ひとつ希望が持てるのは、自社では、取締役がやるんだ、と 言ったことについては、未知の領域やリスクのある領域についても 突き進んでいくことができる企業体質があること。 しかしこれはこれで別の問題が浮上してきている。 それは、「取締役が言ったんだから」という言葉を盾に、 踏み込んで考えたり、創意工夫したりすることをせず、 思考停止してしまう人がいること。 それでね、私はこうするようにしてるんです、とO氏は続ける。 何かやりたいという夢や情熱や興味を持っている人がいれば、 とにかくまずやってみればいい。
小野和俊のブログ:プログラマー風林火山
アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニアと仕事をしてきた。 あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。 そういう経験を重ねていくにつれ、私の中では、スターエンジニアと呼べる人たちの持っているものについての、いくつかの類型ができてきている。今まで一緒に仕事をしていく中で本当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるような財務のわかるエンジニアとか営業もできるエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもなかった。ではどういうエンジニアが、というこ
ガード節を用いた if-then-else 文の置き換え : 小野和俊のブログ
昨日 if-then-else 文の順序に関するエントリを書いたところ、いくつか「レアケースは先に切って return する」というブクマコメントがあり、確かにこの点も考慮すべき重要な点なので前のエントリの補完的な意味も含めてエントリを書く。 if (よくあるケース/正常なケース) { // 処理 } else if (比較的特殊なケース) { // 処理 } else if (さらに特殊なケース) { // 処理 } else { // 処理 } しかしもしこれがメソッド/関数で、次のように後続の処理がないものだった場合を考えてみる(後続の処理がある場合には先のエントリに書いた検討を行う)。 public void method() { if (よくあるケース/正常なケース) { // 通常の処理 } else if (特殊なケース1) { // 特殊な処理1 } else if (特殊
if-then-else文の順番 : 小野和俊のブログ
ペアプロで if-then-else 文が出てきた際、「これ、else if の順序、こっちの方が良くない？」というような会話をすることが時折ある。 どれも当たり前のものかもしれないが、「ああ、確かに」という反応があることもあるので、今日はそんな会話の際に出てくる視点についてまとめてみた。 if (よくあるケース/正常なケース) { // 処理 } else if (比較的特殊なケース) { // 処理 } else if (さらに特殊なケース) { // 処理 } else { // 処理 } 条件式の結果がtrueになる確率が高く、「ノーマル」に近いものを上に書く。可読性が上がる他、特に2.で触れる条件式の判定に時間のかかる場合や、ループの最奥にある処理などのif-then-else文の実行される回数が極めて多い場合には体感レベルで実行速度にも大きな差が出ることもある。 Code Co
レガシーコード改善ガイド : 小野和俊のブログ
以前からパラパラと部分的には目を通していたレガシーコード改善ガイドを、週末に最初から最後まで通して読んだ。 テスト駆動開発入門(以下TDD本)がゼロからテスト駆動でソフトウェアを開発するための方法を示した書籍であるのに対し、本書はテスト駆動で開発されなかったソフトウェアを、後からテスト駆動に変えていく方法を示した書籍である。本書の定義によれば、最近開発されたソフトウェアでも、テストコードのないコードはレガシーコードであり、そのレガシーコードを改善し、レガシーコードでなくしていくための道筋を提示するのが本書の目的だ。 TDDに興味は持ったものの、自分たちのソフトウェアはすでに完成してユーザーに使われており、今からTDD化のためだけに大きな予算や工数を取るわけにもいかず、「TDDは良いと思うけれど、次のプロジェクトから」という結論に落ち着いた事例を目にしたことがある人は少なくないだろう。そして
ペアプログラミングについて : 小野和俊のブログ
5年ほど前に「1日中ペアプロしかしないガチペアプロ」のエントリを書き、 その後も社内でも社外の開発合宿等でも 数えきれないほどのペアプロを行ったり見たりしてきたが その中で新たに気づくこともあったので、 エントリを書こうと思う。 ペアプロは、ドライバーとナビゲーターとが 二人三脚で一つのソフトウェアを作り上げたり、 磨き上げたりしていく行為だ。 二人で作業するので、ペアプロとは会話する行為でもある。 そして忘れてはならないのは、 ペアプロでの会話は聞こえている ということだ。 バグ修正やリファクタリングの際、 既存のコードを洗練させる前向きな目的で 「この箇所、ちょっとわかりにくいね。これだとバグが出やすいよね」 「ここは本当はこういう風に書いた方がきれいだね」 「この命名は誤解を招く可能性があるから、名前を変更しよう」 というような会話をすることがある。 さらに、名前から想像しにくい動き
小野和俊のブログ:[お知らせ] Software Design記事、AWS Summitセッション
■ Software Design 8月号に記事を2本寄稿 2012年7月18日(水)に発売されたSoftware Design 8月号「エンジニアのパワーアップ読書」に「あなたの開発チームをより良くするための5冊」、「頭で考えたことを実現するためのパワーの根源」を寄稿しました。書店で特集連動フェアも開催されるそうです。 ■ AWS Summit Tokyo 2012 2012年9月14日(金)に台場のホテル日航東京で開催されるAWS Summit Tokyo 2012にて、「クラウド時代のISV」をテーマとした18:30からのセッションに登壇します。 18:30-20:30 丸山先生 クラウド研究会 in AWS Summit モデレーター： 丸山 不二夫先生 パネラー： 平野 洋一郎 （株式会社インフォテリア 代表取締役）、 小野 和俊 （株式会社アプレッソ CTO）
解決困難な課題に対し、どのように向き合っていくか : 小野和俊のブログ
・最善を尽くしてもどうにもならないなら、自分のこれまでのやり方に固執せずに、課題を解決している先人達がどのように対処してきたのかを謙虚に学び、自らも実践を試みる。 ・先人達の方法を模倣しても課題が解決しないなら、自分の強みと弱みとを振り返り、自分の強みが活きるよう、先人から学んだ方法を微調整して再度課題解決に臨む。 ・失敗が続き、もう自分は降りよう、という気持ちになってしまったら、課題を乗り越えた先にある成功をイメージし、「あの坂を登れば、海が見える」のだ、と、自らを勇気づけるようにする。 ・身も心も疲れ果て、自分を奮起させる気力さえも無くなってしまったら、再起のためにあえて一時的に課題から離れ、安楽の中で自らを癒す期間を設けることも検討する。 解決が困難な課題に直面した時、ただ立ち尽くすだけでなく、解決に向けたステップをひとつひとつ踏んでいくことが大切なのだと、ここ半月ほどDiablo3
UX/UIデザインガイドライン : 小野和俊のブログ
このところ、アプレッソの中でも、MIJS製品技術委員会でも、自分たちのソフトウェアのUX/UIをブラッシュアップしていくためにどんなことができるのかをディスカッションしている。 UX/UIデザインガイドラインとして各社の推奨する指針をまとめたものがWebで公開されているので、プログラマーであれデザイナーであれ、ソフトウェアの画面設計に何らかの形で携わるのであれば、基礎知識として主要なものには目を通し、プログラマーがデザインパターンの用語で手短にコミュニケーションが取れるのと同じように、「ここは○○ガイドラインの△△パターンを使うのはどうかな？」というような会話ができるようにしていきたいと思っている。 ■ Apple ・アップル ヒューマンインターフェースガイドライン ・iOSヒューマンインターフェースガイドライン(PDF) ・iPadヒューマンインターフェースガイドライン(PDF) ■ M
ブラウザ三国志の課金システムを振り返る : 小野和俊のブログ
1年前に一度引退宣言をしながらも、諸事情により完全には引退せず、先日まで隠居の身で細々と活動していたブラウザ三国志を、4/4の17鯖6期終了のタイミングで完全引退しました。 よく、「ソーシャルゲームはゲームとしてクソ。金ばかり取ろうとして面白くも何ともない。」というような意見を耳にすることがありますが、この指摘については私は2つ意見があります。 確かに現在のソーシャルゲームはコンシュマー機向けの一般のゲームやPC向けのゲームと比べるとゲームとしての完成度は高くないが、現状はまだ黎明期であり、これだけお金も人も動いている世界なので、これから進歩しないと考える方が不自然。現時点でもブラウザ三国志のようなゲーム性だけ見ても従来のコンシュマー機に劣らないものもある。 「もし自分が運営する側だったら」と想定してみると、今でも運営する側はどんなアクションに対してユーザーはどのように反応するか、という人
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
