塾に行かずに中学受験 : 小野和俊のブログ
我が家は小学生の子供が3人おり、みな近所の公立の小学校に通っている。 一番上の長男が生まれたばかりの頃はうちの子供はみんな中学校までは公立がいいんだろうなぁ、と思っていたのだが、長男については友人の親からも「私立の方が向いているのかも」と言われることがあり、親としても何となくそうかもねぇ、などと話し始めたのが小学６年になった昨年の春。そして直後に友人もたくさん受けていた無料学力テストの結果を受け取りに近くの学習塾に行った際、そこで言われた言葉が「あのね。今からは無理ですよ。お子さんはずっと塾や家庭教師なしで学校の授業だけ受けてきたようですけれど、もう小６に入ってしまっていますから。塾では５年生までに６年生までの勉強を全部終わらせて、６年生はひたすら応用問題を解くんです。それに今回のテストは受験しない生徒も多数受けるごく一般の学力テストで、そこで現在偏差値40台ですし・・・。ですから、私たち
進撃のプログラマー : 小野和俊のブログ
■ 半年後の君へ ドォォォン 兵士A 「第一バッファ、突破されました！！！」 兵士B 「そんな・・・この3年、バッファが食いつぶされたことなんてなかったのに・・・」 エレン 「こんな巨大なバグ、見たことがない・・・」 兵士A 「もし次のバッファが食いつぶされたら、このプロジェクトはもう終わりだ・・・」 ■ バグ調査兵団の帰還 母親 「私の息子は・・・？」 エルヴィン 「残念ながら・・・」 母親 「でも、息子は役に立ったんですよね？再現手順のひとつでも・・・見つけてきたんだろう？」 エルヴィン 「もちろん・・・いや・・・今回の調査で我々は、いや、今回も・・・くっ・・・何の成果も得られませんでしたぁぁ！！私が無能なばかりにただいたずらにスケジュールを食いつぶし、バグの原因を突き止めることが、できませんでしたぁぁ！！！」 ■ リヴァイ課長 「人類最強のトラブルシューター」と呼ばれ、1人で100人
マイクロソフト萩原正義氏MIJS講演「スケールアウト設計における問題点の考察と分析手法の提案」 : 小野和俊のブログ
昨年末にMIJSのコンソーシアム内での交流会があり、前回のはてな伊藤さん講演に続き、理事会の方から講演者の選定とコンタクトを依頼されたので、マイクロソフトの萩原さんに「クラウドの時代のデータモデリング」の講演をお願いした。 今回萩原さんに講演をお願いしたのは、以前参加させていただいたマイクロソフト系のイベントでの萩原さんの講演が大変興味深い内容だったからだ。 以下、今回の講演を聞きながら私がメモした内容である。 「スケールアウト設計における問題点の考察と分析手法の提案」 現在マイクロソフトでクラウドの技術のうち、開発の現場に対して、どういうやり方をしなければいけないかを提案する仕事をしている。 今日お話しする内容は、インターネットや書籍で紹介されているものよりも、深いところを話していきたい。とはいえ1時間という短い時間なので、ポイントを絞って話をしていきたい。マイクロソフトはWindows
小野和俊のブログ:人月ビジネス、プロダクト、ウェブのサービス
IT 系の会社の経営者の方と話をしていると、 人月ビジネスをやめて、パッケージやサービスに移行したいという話をよく耳にします。 しかし、半年か一年経ってその後どのようになったのかを聞いてみると、 パッケージやサービスの開発プロジェクトが立ち上がるところまでは行ったものの、 結局は中途半端なものにしかならず断念したという話が多く、 事業内容をスムーズに移行することができたという話はあまり聞きません。 このようなビジネスの転換がうまく行かないケースには、 いくつかの共通点があるように思えます。 第一の関門は、経営陣が、まったく異なるビジネスに対して、 考え方を切り替えられるかどうかという点にあります。 パッケージやサービスのビジネスというのは、基本的に先行投資のビジネスです。 まずソフトウェアを完成させるまでに時間がかかり、 次にソフトウェアが世の中で認知されるまでに時間がかかり、 認知されて
小野和俊のブログ:バランス感覚を身に付けると、コミュニケーションの角と同時に能力の角も取れることがある
分裂勘違い君劇場 - 優秀な人材に変身するキッカケに出会うか、未熟なまま老いていくかで述べられている内容について。 intelligent ではあるが wise ではないために今一アテにできない、という人にはいくつもの心当たりがあって、そういう人とうまく仕事をしていくことができなかった頃のもどかしさが蘇って来るようで、古傷に指を入れてこじ開けられるようで読み進めるのが辛かった。 一方で考えなければならないのは、物事を大きく変えるような提案というのは、実は往々にして、intelligent だけれども wise ではない人たちから出て来ている、ということである。 wise ではない人の意見は、第一印象として、マネージャや周囲の人たちから見てムッとする意見であることが多い。そのネガティブな反応の内訳は、ただでさえやることが山積みなのに新しい方法の導入を提案することに対する反発であったり、誰も問
ホットな組織とクールな組織 : 小野和俊のブログ
数年前に某大手戦略コンサルに入った知人がしきりに驚いていたのは、 どのプロジェクトリーダーの下につくかで、 同じ会社の中でもあまりにも仕事のスタイルが違うということだった。 具体的には、彼が最初に配属されたプロジェクトのリーダーは熱血な人であり、 顧客との打ち合わせや提案資料の作成で平日休日問わずいつも24時を回ってしまう。 だから社内での打ち合わせは25時か26時くらいから始まることがほとんどだった。 私はそんな彼の手伝いを何度かしたことがあったのだけれど、 彼が仕事の打ち合わせの途中で抜けてきてオフィスの入り口付近で話すことが多くて、 待ち合わせの時間はいつも26時前後だった。 そのプロジェクトの組織は、ホットな組織だったと思う。 プロジェクトリーダーも、今、自分たちがどのような状況にあり、 何のためにこれだけの時間をかけているかということをきちんと説明できていた。 情熱 少しでも良い
全共闘世代30人と Web 2.0 を語り合う : 小野和俊のブログ
「Google には決めさせない。俺が決める。」 参加者の一人がこう言った瞬間、拍手喝采が沸き起こり、会場がワーッと盛り上がった。 弊社営業からのリクエストで参加してきた「Web 2.0」をテーマに冠した、参加者のほとんどが60前後のIT系の会社の経営者で20代は私一人というシニアな勉強会での1シーンである。ディスカッションの後の飲み会では、あいつは東大で旗を振ってたとか、俺は京大で旗を振ってたとか、学生運動の昔話に花が咲く。学生運動 → 音楽活動でプロを目指す → 挫折してソフトウェア会社または学習塾を創業 というのがこの世代の人々の職業選択の典型的なパターンの一つであるらしい。 今回のディスカッションでは、Web 2.0 を構成する概念のうち、受け入れられたものとそうでないものとがはっきりと分かれた。 → Web でここまでできるのはすごい。ビジネスの幅や発想が大きく広がる。 ・Saa
小野和俊のブログ:諸君 私はプログラミングが好きだ
諸君 私はプログラミングが好きだ 諸君 私はプログラミングが好きだ 諸君 私はプログラミングが大好きだ 設計が好きだ 実装が好きだ デバッグが好きだ コンパイルが好きだ リファクタリングが好きだ パフォーマンスチューニングが好きだ ペアプログラミングが好きだ クラスの名前を考えるのが好きだ 自分が書いたソースを眺めるのが好きだ Java で C で C++ で C# で Perl で Ruby で PHP で Python で Lisp で VB で この地上で行われる ありとあらゆるプログラミング行為が大好きだ 轟音と共にバグを吹き飛ばしていくのが好きだ 空中高く放り上げられたバグが 効力射でばらばらになった時など心がおどる プログラマーの操る キーボードが コンパイルエラーを撃破するのが好きだ 悲鳴を上げて 燃えさかるソースコードから飛び出してきたエラーを テキストエディタで薙ぎ倒した
一番近くと一番遠くだけを見る : 小野和俊のブログ
「一番近くと一番遠くだけを見る」 これは以前に CE の中嶋さんと話していたときに彼が言っていた言葉で、 印象的だったので、散歩したり、座って考え事をしているときに時々思い出すことがある。 別のどこかで 「夢は大きく、目標は小さく」 という言葉を聞いたことがあるが、これも意味するところは近いと思う。 直近でやるべきことを機械的にこなしていくだけになってしまいがちだ。 ひどいときには、脱線して、目指していたことの実現にまったくつながらないことに 忙しい忙しいといいながら皆で取り組んでしまう。 一番遠くだけを見ていると、 夢やアイデアは語りつくされるものの、 そのときの熱気と情熱だけが残って、アウトプットが何も残らずに終わってしまうことが多い。 そして同じアイデアとそれに伴う実践力を持った人たちに、次第に追い抜かれていってしまう。 間をとった一番近くと一番遠くの中間のところはどうかと言うと、
小野和俊のブログ:Web 2.0 時代の企業情報システムの姿 - (1)
基本的に個人向けのものだから、 企業や組織のためのシステムのことをいつも考えている私にとっては、 仕事の面では直接関係ないものだと思っていたのだ。1ヶ月前には。 この数週間で、私は考えが変わってきている。 企業で働く人たちもやはり一人の個人、ということを言おうとしているのではない。 Web 2.0 の持つ要素のいくつかは、 企業や組織のために作られていくシステムのあり方を変革していく可能性を秘めている。 はてなブックマークや del.icio.us などのソーシャルブックマークを通じて、 私は今まで知ることのなかったたくさんの Web サイトと出会うことができた。 しかし、求めている情報の種類によっては、もっと範囲の狭いものを使いたいときもある。 「The Wisdom of Crowds」が成立するための条件の一つには多様性が挙げられているが、 自分と近しい人たちや特定のコミュニティの中
没入感の中断 : 小野和俊のブログ
1976年生まれ。1999年慶應義塾大学環境情報学部卒業後、同年サン・マイクロシステムズ株式会社に入社。入社後まもなく米国 Sun Microsystems, Inc での開発を経験し、2000年より株式会社アプレッソ代表取締役に就任、データ連携ミドルウェア DataSpider を開発する。2002年には DataSpider が SOFTIC ソフトウェア・プロダクト・オブ・ザ・イヤーを受賞。2004年度未踏ソフトウェア創造事業 Galapagos プロジェクト共同開発者。2007年〜2010年日経ソフトウェア巻頭連載「小野和俊のプログラマ独立独歩」執筆。2008年〜2011年九州大学大学院「高度ICTリーダーシップ特論」非常勤講師。2013年よりセゾン情報システムズ HULFT事業CTO、2014年 CTO、2015年 取締役 CTO、2016年 常務取締役 CTOを務め、2019年
カジュアル・プログラミング : 小野和俊のブログ
ちょっと前のエントリになるけれど、新しくソフトウェアを作っていくときのスタイルとして、 伊藤さんのこのエントリにはとても共感できる。共感度120%。 DataSpider を最初に開発したときにも、 1年半くらい前に Galapagos 開発チームでミーティングツールを開発したときにも、 同じような感じだった。 スタイルは言語を越えて共通なんじゃないかな。 完成した時に提供できるであろうサプライズにワクワクしながら、 作って、使ってみて、少し考えて変えてみてまた使ってみて、という風に、 手触りを確認しながらソフトウェアを開発していくのは本当に楽しい。 議事録を書く代わりにプログラムを書く。 こんな感じかな？と話しながらお互いにその場で作って見せ合いながら議論を進める。 ブログに書いているだけで、そういう風に開発している時のことを考えて胸が高鳴る。 カジュアル・プログラミング。 発散か収束か
小野和俊のブログ:アンチ・プログラマー35歳定年説
プログラマー35歳定年説の論拠は一般的に次の2点だと思う。 1. 若いプログラマーでないと徹夜で仕事することができない 言語道断。徹夜が当たり前になっている業界の体質自体がそもそもおかしい。 スケジュールを守らなければいけないという真面目さは良い。 予測できない突発的な問題が発生する。 バッファを取っていても解決の目処が立たない問題が発生したらどうにもならない。 人員補充をしようとしても良い人が見つからなければ少人数で取り組んだ方が解決が早い。 良い人を探そうとしても見つからない。または他のプロジェクトで手一杯になっている。 そういう難しさは、刃物で身が切られるように、痛いほどわかる。 しかし、 そうならないようにするのがマネージャの仕事であり、 問題が起こってしまった時にスケジュールを調整したり機能が削れないか交渉したり、 何とか良い人を探してきたりするのもマネージャの仕事である。 それ
小野和俊のブログ:プログラマー風林火山
アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニアと仕事をしてきた。 あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。 そういう経験を重ねていくにつれ、私の中では、スターエンジニアと呼べる人たちの持っているものについての、いくつかの類型ができてきている。今まで一緒に仕事をしていく中で本当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるような財務のわかるエンジニアとか営業もできるエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもなかった。ではどういうエンジニアが、というこ
小野和俊のブログ:徹夜をしてはいけない理由
どうしても昨日までに仕上げなければならない仕事があったので、一昨日は徹夜で開発をした。一人で飲んだり、人と飲んだり、布団の中で考え事をしたり、徹夜をすること自体は悪いことではない。しかし、徹夜で仕事をするのは可能な限り避けた方が良い。 ベンチャーを始めてからの最初の2年は、年末年始を含めて365日1日も休まず仕事をした。徹夜なんて当たり前である。そんな私だったが、会社が3年目に入る頃に休息の重要性を痛感し、以来、できるだけ徹夜はしないようにしている。それは、徹夜がもたらす作業時間よりも、悪影響の方がずっと大きいということに気づいたからだ。 私の経験では、徹夜が常習化するにつれ、個人/組織には次のような症状が出てくることがある。特に、影響力のある人がこのような状態になると、組織全体が影響されて深刻な症状にかかりやすい。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
