「ソフトウェア・ファースト」を読むべし : 小野和俊のブログ
10月初めに著者の及川さんより「ソフトウェア・ファースト」を送っていただいていたのだが、つい先日まで仕事が立て込んでおりずいぶんと読み終わるのが遅くなってしまった。極めて良著だった。 とりわけ私にとっては、問題意識や取り組みの方向性があまりにも自分と一致しすぎていて、「いや、本当にそう。それでいまこういうことをやってるのよね。」と一致の程度が高すぎて読んでいてところどころで共感の気持ちが声として漏れ出てしまう内容であった。むしろ違和感があまりにもなさすぎて、危険だとさえ感じた。共感の程度が高すぎると、自らが肯定されたような気分になり、このままで良いのだろうかという迷いから生まれる自省的考察から自らを遠ざけることがあるからだ。 私がクレディセゾンに来たのはまさにこれが理由だ。 自分でアプレッソといベンチャーを立ち上げてきたし、DataSpiderというプロダクトも生み出した。だが、あるときか
曲面ディスプレイの導入 : 小野和俊のブログ
「曲がったディスプレイを使ってみたい」 もう随分と前からディスプレイはデュアルディスプレイにしているが、二枚のディスプレイの前でふとそう思ったのだった。そこで曲面ディスプレイを購入し、まずは試験的に私の仕事環境に適用してみた。 まずはこの写真を見てほしい。 そう、曲面ディスプレイはまるで「一枚に連結されたデュアルディスプレイ」なのだ。 しかしデュアルディスプレイで以前からひとつだけ気になっていたことがある。 それは、「いちばん大切な真ん中のエリアに集中できない」ということだ。 デュアルディスプレイだとどうしても左か右か、どちらかに集中することになる。これはこれで左右それぞれでウィンドウを最大化できて便利だったりもするのだが、本来一番集中したい真ん中のエリアが2枚のディスプレイの物理的境界線になってしまい、そこにコンテンツが映せないのだ。 例えば集中して作成したプレゼン資料や文章があったとす
SlackをSIerに導入した話。そしてSIerの未来 : 小野和俊のブログ
「Slackを入れるとSIerはどうなるのか？」 しばらくブログを休んでいたので少しだけ自己紹介をしよう。アプレッソというベンチャー企業を立ち上げて、セゾン情報システムズという会社にexitした。そしていまはアプレッソの社長として仕事をする傍ら、セゾン情報システムズのCTOの仕事もしている。どちらかというといまはセゾン情報の仕事の比重が高いから、リアルの世界では「セゾン情報の小野」と思っている人の方が増えてきていると思う。 「このままでは、SIに未来はない。だから変わらなければならない。」 「当社の社員は言われたことしかできない。」 SIerの経営者と会話していると、よくこんな言葉を耳にする。 自分たちの未来を悲観している人たちが、未来を明るくできるのだろうか？ だから私は、喜びと驚きのポジティブスパイラルで、SIerはどんな風に良くなるのか、壮大な実験をしてみようと思った。 その第一弾と
わたしのバイモーダル戦略 : 小野和俊のブログ
このところ知人からよく、「小野さんはプログラマーから経営者になった」と言われる。これはまさにその通りで、かつてソースコードを美しくリファクタリングすることに情熱を燃やした私は、いまは組織をより良いものにしていくことに情熱を燃やしている。つまりリファクタリング対象がソースコードから会社に変わったのだ。 そんな私が今やや苦戦しつつもやりがいを感じて取り組んでいるのが、「2つの異なる文化の共存協調」だ。具体的には、大企業的な文化とベンチャー的な文化を共存させ、かつ協調させようにしようとしている。ウォーターフォール的な文化とアジャイル的な文化の共存協調、と言い換えることもできるだろう。 アプレッソでかなり自由にやってきた私にとって、当初、セゾン情報の動き方は不慣れであり、また動きが遅く感じることもあった。だが少しすると、こうした動き方や文化にも相応の合理性があり、アプレッソで取り入れることが望まし
コードレビューについて : 小野和俊のブログ
伊藤直也さんが「些末なコードレビュー」というエントリを書いて話題になっている。このエントリで伊藤さんはコードレビューの話と、はてなのJavaScriptの話と2つの話題に触れている。前者のコードレビューについてはアプレッソでは8年ほど前から「コードレビューを通っていないコードはコミット不可」というルールですべてのソースコードに対してコードレビューを必須にしてきた関係で私も思うところがあるので、エントリを書いてみようと思う。 伊藤さんが例示しているように、インデントやreturnの省略などの話は好みの問題であり、議論してもソフトウェアの改善につながらない。なのでコードレビューでこうした宗教論争が起こるようなら、コーディング規約を見直すべきだ。「無駄に悩んだり議論したりすることを減らす」ことはコーディング規約の主たる効果のひとつだと言える。 コードレビューに慣れないチームが、何の考えもナシにコ
「『ガンダム』を創った男たち。」 : 小野和俊のブログ
機動戦士ガンダムといえばロボットアニメの金字塔であり、日本国内に「ガンダム」という言葉を聞いたことがない、という人はほとんどいないのではないかと思える程の知名度を誇る作品だ。 こうした印象から、ガンダムと言えば「大成功したアニメ」という印象を持つ人が大半だろう。しかし「『ガンダム』を創った男たち。」を読むとその印象は一変する。 こうした紆余曲折を経て遂にTV上映が始まるが、その結果は大惨敗だった。15%〜20%が期待された第一回の視聴率はたった3%。そして第七回では遂に実質0%の「誰も見ていない番組」にまで落ち込んでしまう。この状況を打開すべく、次々と新モビルスーツを登場させ、さらに「オモチャが売れれば数字には目をつぶる」というスポンサーの声に応えるべく、ガンダムというドラマを完成させるための苦肉の策として、兵器としてはリアリティがまったくなく、しかし「オモチャとしては最高」の妥協の産物で
新生ミクシィへの期待と要望 : 小野和俊のブログ
「ここに書いても・・・誰からも反応なしか」、「○○月☓☓日でmixi退会します」などとマイミクがmixiから次々と去って行ってはや数年、mixiはもう再び話題になることはないかのように思える時期が長く続いていましたが、昨日の新経営陣発表を受け、「mixiアカウント復活！」、「懐かしい！」といった要領で、知人の間でmixiが盛り上がりを見せております。 マイミクの多くがmixiを離れてFacebook/Twitterに移行したりログインしなくなったりしていく中、私は1年前までブラウザ三国志 for mixiをかなり激しくプレイしていたこともあり、また、その結果mixiでしか繋がっていない知人もそれなりにおり、なんだかんだで今日に至るまで毎日5〜10回くらいはmixiにアクセスしていたので、ここはどうにかならないかなぁ、この部分はやっぱりmixiが良いんだよなぁ、などとmixiに対して感じるこ
ベンチャー企業の事業推進と資本政策: 私の場合 : 小野和俊のブログ
2ヶ月前にポストした前回のエントリに関して、「おめでとうございます」的なコメントを多数いただいた一方、「小野さんって8%しか株持ってなかったの？ギリギリまでむしり取られてたのね・・・」的な感想をTweetしている人もいたようで、いや、違うんだけどなぁと思いつつも別にエントリを書くほどのことでもないか、と思っていたのですが、アプレッソの資本政策周りの経緯を書いておくことは今後ベンチャーを始める人の参考になる部分もあるかもしれないのでエントリを書くことにしました。 会社を始める目的は人それぞれかと思います。こんなものがあったら素晴らしいだろう、というアイデアを世に問うてみたい、という人もいるでしょうし、一攫千金を夢見る人もいるでしょう。自分の中にくすぶる若さのエネルギーをぶつける先がなく、ほぼ勢いだけで始める人もいるでしょうし、身近な誰かが切実に求めているものがあり、それを実現するために起業す
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は良いと思うけれど、次のプロジェクトから」という結論に落ち着いた事例を目にしたことがある人は少なくないだろう。そして
いまだに知らないなんてありえない病 : 小野和俊のブログ
いまだに知らないなんてありえない病とは、プログラマー同士の会話の場で、 「いまだに○○という本さえ読んでいないなんてありえない」 「いまだに○○というフレームワークさえ使っていないなんてありえない」 「いまだに○○という言語を触ったことさえないなんてありえない」 「いまだに○○というパターンさえ知らないなんてありえない」 というように、自分が知っていて相手が知らないものについて、 「いまだに知らないなんてありえない」 と発言してしまう病の総称である。 発症例として、例えば次のようなものがある。 「いまだにマシン語が書けないなんてありえない」 「いまだにRubyを1行も書いたことないなんてありえない」 「いまだにVisitorパターンさえ知らないなんてありえない」 「いまだに高校レベルの数学も押さえていないなんてありえない」 「いまだに個人で開発したアプリが1つもないなんてありえない」 「い
ペアプログラミングについて : 小野和俊のブログ
5年ほど前に「1日中ペアプロしかしないガチペアプロ」のエントリを書き、 その後も社内でも社外の開発合宿等でも 数えきれないほどのペアプロを行ったり見たりしてきたが その中で新たに気づくこともあったので、 エントリを書こうと思う。 ペアプロは、ドライバーとナビゲーターとが 二人三脚で一つのソフトウェアを作り上げたり、 磨き上げたりしていく行為だ。 二人で作業するので、ペアプロとは会話する行為でもある。 そして忘れてはならないのは、 ペアプロでの会話は聞こえている ということだ。 バグ修正やリファクタリングの際、 既存のコードを洗練させる前向きな目的で 「この箇所、ちょっとわかりにくいね。これだとバグが出やすいよね」 「ここは本当はこういう風に書いた方がきれいだね」 「この命名は誤解を招く可能性があるから、名前を変更しよう」 というような会話をすることがある。 さらに、名前から想像しにくい動き
Metro UIは「UXアプリ養成ギプス」 : 小野和俊のブログ
昨日、今日とWindows Developer Days(WDD)に参加してきた。二日間セッションに参加して感じたのは、「Metro UIは『UXアプリ養成ギプス』だ」ということである。 デザインの原則がある。 例えば原則のひとつに、”Content before Chrome”というものがある。これは、「コンテンツを主役にし、ツールバーやメニュー等のコンテンツへの没入を妨げるものは最小限にする」というものだ。 こうしたデザインの原則やガイドラインがきちんと決められている、ということは重要なことではあるが、それ自体はさほど驚くべきことでもない。先日ブログに書いたように、最近の主要なプラットフォームには、大抵UX/UIのデザインガイドラインが定められているからだ。 では私が何に驚いたかというと、Metro UIではこのデザインガイドラインが「半強制」されていることだ。 UX/UIに意識の高い
ソーシャルメディアで破局するカップル : 小野和俊のブログ
「Twitterで結婚しました！」 「ネットで知り合って付き合い始めました！」 ソーシャルメディアで知り合ったり結婚したり人のことは以前からよく耳にしますが、最近、逆にソーシャルメディアで別れたカップルの話を耳にすることが何度かありました。 半年ほど前に、カップルの女性が別の男性と浮気してししまったことがありました。 が、男性側にも過去に浮気の経験があり、女性もそれを知っていたので、浮気自体はまあお互い様、ということでそこまで問題にならなかったそうです。 男性は女性に「彼と寝ちゃったことは仕方ないけど、もうやり取りしたりしないでね」と話し、女性も「うん、わかった」と答え、二人には平穏な日々が戻って来ました。 しかしある日、浮気相手の男性のFacebookタイムラインを見ると、和解した後もほとんどすべてのポストに女性が「いいね」をつけていることが発覚。 男性は「いいね」を見るたびに「ふざけん
マイクロソフト西脇資哲氏に学ぶプレゼンとデモの秘訣 : 小野和俊のブログ
昨日はマイクロソフトの西脇さんのMIJS会員向けエヴァンジェリスト養成講座に参加してきた。 前職のオラクル時代に一度、現職のマイクロソフトで一度、計二回西脇さんのプレゼンとデモを見てすっかりファンになった私は、その彼がプレゼンとデモの秘訣を披露してくれるということで、これは参加しない手はないだろうと思い、イベントの開催告知が届くや否や、すぐに参加申し込みをしたのだった。 とても勉強になる内容だったのでブログで書いても問題ないかと確認したところ、OKとの回答をいただいたので、以下に私が講義を聴きながらメモした内容を書く。 -------- ■ はじめに 今日の講座はプレゼンテーションとデモンストレーションに関する講座。 オラクルに13年いて、今はマイクロソフトにいる。 エヴァンジェリストという仕事は、会社の製品や取り組みを、自社の製品を好きでない人に対しても、魅力的に伝える仕事。 マイクロソ
SIerでのキャリアパスを考える勉強会に参加してきた : 小野和俊のブログ
このところ「SIerの今後について」というテーマについて、意見を求められたりディスカッションしたりすることが多く、またエンタープライズ業界に身を置く立場として、売り上げ比・人口比とも業界の大半を占めるSIerが今何に取り組んでいて、今後どのようになっていくのか、というのは私自身関心のあるテーマなので、昨日は「SIerでのキャリアパスを考える」勉強会に参加してきた。 というわけで勉強会の中で印象的だったことや考えたことを書く。 勉強会の前半パートではゆもとさんによるSIerの現状分析、ひがさんによるSIerの中でのキャリア戦略が話題に上り、その中でも特に「上流と下流が工程分断されている」ことが現状のSIerを取り巻く諸問題の元凶、という指摘があった。 この「分断」については、中島聡さんの「ソフトウェアの仕様書は料理のレシピに似ている」というエントリが有名だが、今回の勉強会でのゆもとさんの資料
DataSpiderにおけるコンポーネント間のインタラクションの設計と実装 : 小野和俊のブログ
先日、ソースコードのメンテナビリティについてのエントリを書きましたが、dankogaiさんから「で、具体的にどんなコード書いてるの？」という指摘がありました。 返信エントリでは、「DataSpiderはオープンソースではないのでソースコードをそのまま出すことはできない」と書いたのですが、よく考えたら、一部エッセンスを抜き出してサンプルコードとして紹介することはできるので、最近私が書いたコードの中で、メンテナビリティに関係するコードを紹介したいと思います。 ※ ソースコードの行数が正しく表示されない場合にはブラウザの幅を広げると正しく表示されます。なお、ソースコードの構成をシンプルにするため今回のサンプルではViewModelは使用していません。 目次 ・コンポーネント間のインタラクションの管理 ・最も原始的な実装方法: コンポーネントの相互参照 ・Mediatorパターン ・Role Ob
dankogaiさんへの返信 : 小野和俊のブログ
昨日、「メンテナビリティの高いソースコードを目指して」というエントリを書いたところ、dankogaiさんから、「コードも見せていないお前にコードを語る資格はない」と怒られてしまったので返信エントリ。 実はブログを初めて1,2年くらいの頃はコードを含むエントリをそこそこ書いてたのですが、プログラマーでない知人から「何の話か全然わからなかった」と言われ、またdankogaiさんも指摘している通り、「コードについて書く方がコードを書くより読まれる現実」があり、コードを含むエントリはJava Programming Tipsという別のブログに移した経緯があります。 ではどこに力を入れているかというと、私が一番力を入れいてるのはDataSpiderという商用ソフトウェアの設計と実装ですが、これはアプレッソの50人の社員を10年間支えてきてくれているソフトウェアなので「はい、どうぞ」とソースコードをお
小野和俊のブログ:メンテナビリティの高いソースコードを目指して
ソフトウェアを中長期にわたってメンテナンスしていく場合、メンテナンスしやすいコードと、メンテナンスしにくいコードとの間には、同じ機能を実現していたとしても、その価値には雲泥の差があります。 メンテナンスの容易さを示す言葉として、メンテナビリティ(Maintainability)という言葉がありますが、私自身、アプレッソでDataSpiderを11年間開発・メンテナンスしていく中で、「この人の書いたコードは本当にわかりやすいし無駄がない」とメンテナビリティの高いソースコードに感心させられることもあれば、「急いでいたとはいえ、このソースコードはリファクタリングしないと・・・」と、メンテナビリティの低いコードがソフトウェアに混入してしまったことを嘆くこともありました。 このエントリでは、一本のソフトウェアを11年間開発・メンテナンスしてきた経験から、ソフトウェアのメンテナビリティについて考察して
人を萎縮させるやり方はその人の価値を下げる : 小野和俊のブログ
はてなの近藤さんのブログの「怒る必要などない」というエントリーで、京都ではてなと同じビルに入っていた歯医者さんの引退飲み会に参加して、引退する彼の「怒る必要などない」という話を聞いたことが紹介されている。 先生が30代の頃は毎日スタッフのミスをメモし、診察時間が終わるとそのスタッフを怒っていたそうです。ところがある時、「怒る必要などない」ということを悟り、対等な人間として接するように変わったそうです。それから入ったスタッフの方の多くは、10年以上も勤務され続けたそうです。怒るのは自分の自信のなさの現れである、と仰っていました。 私個人としては、社内で人のことを「○○君」と呼ぶことにも抵抗があるタイプの人間で、「上司が部下を○○君と呼んだりしてるけど、もし立場が逆転したらどうするつもりなの？」と素朴に思ったりしてしまうわけだが、取引先や社内の関係者に対して、冷静な言葉を保てず、怒ったり威圧す
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
