クレディセゾンでエンジニアリングチームを立ち上げます : 小野和俊のブログ
先程、クレディセゾンの来期組織のプレスリリースが出ましたが、3/1からクレディセゾン CTOの仕事をメインの仕事にしていくことになりました。 （立場は変わりますが技術顧問という形でセゾン情報システムズ/アプレッソの仕事も継続しますので、引き続きぜひ何かありましたらお声がけください。昨年秋にはAmazon Alexaスキルアワードで法人部門優勝＆特別賞のダブル受賞もしたりしてだいぶ面白くなってきています！）。 で、クレディセゾンで何をやっていくか？ エンジニアリングチームの立ち上げをします。 具体的には2つのことをしようとしています。 クレディセゾンは金融の会社です。ITの世界の枠組みで言うと、いわゆるユーザー企業です。 少し前までは、多くのユーザー企業にとって、ITは「社内業務の効率化」のためのものであり、重要ではない、とまでは言わないまでも、今日のような重要性を持つものではなかった。 そ
"connecting the dots"な生き方 : 小野和俊のブログ
スマートフォン向けのニュースアプリSmartNewsが、先日第三者割当増資によって4億2千万円の資金調達を行い、話題になっています。 SmartNewsを開発している株式会社ゴクロの取締役の鈴木健さん(以下健さん)は大学時代の弁論部の先輩で、卒業後も仕事や各種プロジェクト、ネットゲーム、飲み会などで時折接点があるのですが、この記事などを見ていると、SmartNewsの長所と、健さんのこれまで取り組んできたこととのつながりが改めて感じられ、スティーブ・ジョブスの"connecting the dots"という言葉を思い出します。 また、「タコツボ化しない情報収集」は彼が関わっていた一連の未踏ソフト関連のプロジェクトのテーマのひとつで、情報が氾濫する時代に、いかに各個人にパーソナライズした情報を適切に届けるか、ということは、健さんが長年追い求めてきたテーマのひとつでした。SmartNewsを支
進撃のプログラマー : 小野和俊のブログ
■ 半年後の君へ ドォォォン 兵士A 「第一バッファ、突破されました！！！」 兵士B 「そんな・・・この3年、バッファが食いつぶされたことなんてなかったのに・・・」 エレン 「こんな巨大なバグ、見たことがない・・・」 兵士A 「もし次のバッファが食いつぶされたら、このプロジェクトはもう終わりだ・・・」 ■ バグ調査兵団の帰還 母親 「私の息子は・・・？」 エルヴィン 「残念ながら・・・」 母親 「でも、息子は役に立ったんですよね？再現手順のひとつでも・・・見つけてきたんだろう？」 エルヴィン 「もちろん・・・いや・・・今回の調査で我々は、いや、今回も・・・くっ・・・何の成果も得られませんでしたぁぁ！！私が無能なばかりにただいたずらにスケジュールを食いつぶし、バグの原因を突き止めることが、できませんでしたぁぁ！！！」 ■ リヴァイ課長 「人類最強のトラブルシューター」と呼ばれ、1人で100人
セゾン情報さんとの資本業務提携について : 小野和俊のブログ
昨日発表のあった件で個別に多数問い合わせいただいていまして、個人的には、株主の変更はあるものの体制・事業等これまで通りなので特に何も書かなくて良いかな？と思っていたのですが、「小野さんもしかして辞めるの！？」等のご心配もいただいていますのでここでも少し触れておきます。 まず、私は辞めません(笑) 株主の移動はありますが、基本的に組織・事業ともアプレッソは今までどおりに事業を進めていきます。もともとアプレッソの事業は順調に推移していて、今期は過去最高益を更新できそうな見込みなのですが、今回の資本業務提携でほぼ確実に事業が加速すると思います :) 24歳になったばかりで世の中の右も左もわからない中で立ち上げたアプレッソの事業が、社内外のみなさんに支えられながら12年間でここまで成長してきて、時価総額15億円ということでこの分野では非常に高い評価を得ることができたのはとても嬉しく、また誇らしく思
if-then-else文の順番 : 小野和俊のブログ
ペアプロで if-then-else 文が出てきた際、「これ、else if の順序、こっちの方が良くない？」というような会話をすることが時折ある。 どれも当たり前のものかもしれないが、「ああ、確かに」という反応があることもあるので、今日はそんな会話の際に出てくる視点についてまとめてみた。 if (よくあるケース/正常なケース) { // 処理 } else if (比較的特殊なケース) { // 処理 } else if (さらに特殊なケース) { // 処理 } else { // 処理 } 条件式の結果がtrueになる確率が高く、「ノーマル」に近いものを上に書く。可読性が上がる他、特に2.で触れる条件式の判定に時間のかかる場合や、ループの最奥にある処理などのif-then-else文の実行される回数が極めて多い場合には体感レベルで実行速度にも大きな差が出ることもある。 Code Co
解決困難な課題に対し、どのように向き合っていくか : 小野和俊のブログ
・最善を尽くしてもどうにもならないなら、自分のこれまでのやり方に固執せずに、課題を解決している先人達がどのように対処してきたのかを謙虚に学び、自らも実践を試みる。 ・先人達の方法を模倣しても課題が解決しないなら、自分の強みと弱みとを振り返り、自分の強みが活きるよう、先人から学んだ方法を微調整して再度課題解決に臨む。 ・失敗が続き、もう自分は降りよう、という気持ちになってしまったら、課題を乗り越えた先にある成功をイメージし、「あの坂を登れば、海が見える」のだ、と、自らを勇気づけるようにする。 ・身も心も疲れ果て、自分を奮起させる気力さえも無くなってしまったら、再起のためにあえて一時的に課題から離れ、安楽の中で自らを癒す期間を設けることも検討する。 解決が困難な課題に直面した時、ただ立ち尽くすだけでなく、解決に向けたステップをひとつひとつ踏んでいくことが大切なのだと、ここ半月ほどDiablo3
Metro UIは「UXアプリ養成ギプス」 : 小野和俊のブログ
昨日、今日とWindows Developer Days(WDD)に参加してきた。二日間セッションに参加して感じたのは、「Metro UIは『UXアプリ養成ギプス』だ」ということである。 デザインの原則がある。 例えば原則のひとつに、”Content before Chrome”というものがある。これは、「コンテンツを主役にし、ツールバーやメニュー等のコンテンツへの没入を妨げるものは最小限にする」というものだ。 こうしたデザインの原則やガイドラインがきちんと決められている、ということは重要なことではあるが、それ自体はさほど驚くべきことでもない。先日ブログに書いたように、最近の主要なプラットフォームには、大抵UX/UIのデザインガイドラインが定められているからだ。 では私が何に驚いたかというと、Metro UIではこのデザインガイドラインが「半強制」されていることだ。 UX/UIに意識の高い
UX/UIデザインガイドライン : 小野和俊のブログ
このところ、アプレッソの中でも、MIJS製品技術委員会でも、自分たちのソフトウェアのUX/UIをブラッシュアップしていくためにどんなことができるのかをディスカッションしている。 UX/UIデザインガイドラインとして各社の推奨する指針をまとめたものがWebで公開されているので、プログラマーであれデザイナーであれ、ソフトウェアの画面設計に何らかの形で携わるのであれば、基礎知識として主要なものには目を通し、プログラマーがデザインパターンの用語で手短にコミュニケーションが取れるのと同じように、「ここは○○ガイドラインの△△パターンを使うのはどうかな？」というような会話ができるようにしていきたいと思っている。 ■ Apple ・アップル ヒューマンインターフェースガイドライン ・iOSヒューマンインターフェースガイドライン(PDF) ・iPadヒューマンインターフェースガイドライン(PDF) ■ M
「最悪の事故」から学ぶ教訓 : 小野和俊のブログ
「最悪の事故が起こるまで人は何をしていたのか」では、チェルノブイリ原発事故、スペースシャトル・チャレンジャー爆発墜落事故をはじめ、潜水艦の沈没や航空機墜落事故、石油プラットフォームの爆発や橋の崩落といった巨大事故が実際に起こってしまった事例と、事故が起こる直前に食い止めることができた事例を通じて、事故を生み出してしまったシステムや体制、組織の規律やそこで働く人のメンタルな状態など、さまざまな切り口から事故の原因が考察されていく。 普段の生活において、自分のちょっとしたミスがこのような大事故につながるような場所に身を置いている人はそれほど多くないかもしれない。しかし、本書で述べられている内容のうち、事故の原因とそこから学ぶ教訓の部分について目を向けてみると、私たちが日常的に接しているような場面においても同じように当てはまる内容があまりにも多いことに驚く。 本書には実に数多くの教訓が含まれてい
DataSpiderにおけるコンポーネント間のインタラクションの設計と実装 : 小野和俊のブログ
先日、ソースコードのメンテナビリティについてのエントリを書きましたが、dankogaiさんから「で、具体的にどんなコード書いてるの？」という指摘がありました。 返信エントリでは、「DataSpiderはオープンソースではないのでソースコードをそのまま出すことはできない」と書いたのですが、よく考えたら、一部エッセンスを抜き出してサンプルコードとして紹介することはできるので、最近私が書いたコードの中で、メンテナビリティに関係するコードを紹介したいと思います。 ※ ソースコードの行数が正しく表示されない場合にはブラウザの幅を広げると正しく表示されます。なお、ソースコードの構成をシンプルにするため今回のサンプルではViewModelは使用していません。 目次 ・コンポーネント間のインタラクションの管理 ・最も原始的な実装方法: コンポーネントの相互参照 ・Mediatorパターン ・Role Ob
小野和俊のブログ:罪悪感駆動開発(zaiakukan-driven development; ZDD)
みなさんは罪悪感駆動開発(zaiakukan-driven development; ZDD)という言葉をご存知だろうか。私はつい先ほどまでこの概念を知らなかった。なぜなら先ほど自分で思いついたばかりだからだ。 仕事をしていく中で、やるべきことが山積みなのについネットサーフィンをしてしまい、「うわ、今日仕事全然進んでない、やばい」という罪悪感から、その後の仕事が妙に捗る、という経験をしたことがある人は少なくないだろう。 罪悪感駆動開発は、こうした危機感や罪悪感といった人間が本来持っている感情を引き出すことで、より高い仕事の成果を上げていくことを志向する。 罪悪感を感じるポイントは人によって個人差があるが、一般に仕事中に罪悪感が高まりやすい充填行為として、次のようなプラクティスが広く認知されている。 (a) 昼寝 (b) ネットサーフィン (c) ゲーム (d) タイピングソフトでランキング
企業や組織のおける新規メンバーの受容について : 小野和俊のブログ
企業や組織が成熟し、安定してくると、メンバーの中に「今うまく行っているのだから、明日も同じようにうまく行くはずで、できるだけ現状を維持したい」という考えが芽生えてくることがある。 その結果、組織に新規のメンバーが加わった時、特に新規メンバーがその組織に取って何らかの形で刺激的だった場合、次のような事象が起こることがある。 組織が安定した状態が長く続くと、半年前には誰もが「改善が必要」と合意していたような不便さや非効率さも、「まあそんなものか」と日常に溶け込んで当たり前のことになってしまうことがあるが、これまで外部の世界を見てきた新規メンバーは「常態化した理不尽さ」に敏感なので、現状に問題がある、と指摘することがある。こうした指摘は、「自分たちのやり方を批判している」と受け止めることもあるが、慣れで麻痺した感覚を揉みほぐしてくれるマッサージのようなものとして機能することがある。 能力のある人
あえてNoSQLでクラウド上にエンタープライズアプリを作ってみる : 小野和俊のブログ
RDBMSとNoSQLを巡る議論でいつも私が違和感を感じるのは、RDBMSに固執しようとする人と、NoSQLに固執しようとする人と、それぞれが極端にどちらかを擁護し、極端にどちらかの長所や可能性に対して目を瞑ろうとしているように見受けられることである。 これまでRDBMSを業務で使ってきた人にNoSQLの制約の話をすると、大抵の場合、「そんなのじゃ業務には使えない」という反応が返ってくる。特に即時一貫性が保てないという話をすると「まったく使い物にならない」と脊髄反射的に拒否反応を示されることが多い。 私が思うに、クラウドがシステム構築で活用されていくのに比例して、これからは「RDBMSとNoSQLを適材適所で使い分ける」ことがこれからのアーキテクトに求められるのではないか。 これまではRDBMSがあったから何もかも一貫性が保障されていた。だが、本当にそこまですべてのデータに即時一貫性が必要
ブラウザ三国志17鯖 - プログラマー同盟の軌跡その2 (皇位継承編) : 小野和俊のブログ
金獅子との外交問題も解決に向かっていたある日、私のもとに一通の書簡が届いた。 「アンチ武帝連合で動かれていると聞きました。協力します。」 武帝連合は、規模、同盟ポイント、領地取得状況など、どの点を取っても17鯖最強の同盟だった。ゲーム開始後ごく初期の段階で全NPC城への隣接を実現し、いくつもの支部を従えたその本部の盟主は７鯖で天下統一を実現した「皇帝」その人である。 プログラマー同盟は、武帝連合に対して「一緒に倒したい」、「継いで欲しい」という相反する2通の書簡をほぼ同時に受け取ったわけである。 この二通の書簡を見て、幹部達は口々にこう言った。 幹部: 「プログラマー同盟は強烈なアンチ武帝だったんですね。知りませんでした。」 lalha: 「そのようですね。私も知りませんでした。」 この二通の不可思議な書簡について、プログラマー同盟幹部はいくつかの仮説を立てた。 (1) 一通目を送ってきた
マイクロソフト萩原正義氏MIJS講演「スケールアウト設計における問題点の考察と分析手法の提案」 : 小野和俊のブログ
昨年末にMIJSのコンソーシアム内での交流会があり、前回のはてな伊藤さん講演に続き、理事会の方から講演者の選定とコンタクトを依頼されたので、マイクロソフトの萩原さんに「クラウドの時代のデータモデリング」の講演をお願いした。 今回萩原さんに講演をお願いしたのは、以前参加させていただいたマイクロソフト系のイベントでの萩原さんの講演が大変興味深い内容だったからだ。 以下、今回の講演を聞きながら私がメモした内容である。 「スケールアウト設計における問題点の考察と分析手法の提案」 現在マイクロソフトでクラウドの技術のうち、開発の現場に対して、どういうやり方をしなければいけないかを提案する仕事をしている。 今日お話しする内容は、インターネットや書籍で紹介されているものよりも、深いところを話していきたい。とはいえ1時間という短い時間なので、ポイントを絞って話をしていきたい。マイクロソフトはWindows
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を同列に並べるのがそも間違い それぞれの特徴をとらえて合ったものを
小野和俊のブログ:[お知らせ] ｢ソフトウェアアーキテクトが知るべき97のこと｣発売、10/17 池袋ジュンク堂でトークイベント
[お知らせ] ｢ソフトウェアアーキテクトが知るべき97のこと｣発売、10/17 池袋ジュンク堂でトークイベント "97 Things Every Software Architect Should Know"の邦訳版、「ソフトウェアアーキテクトが知るべき97のこと」が10月5日に発売されます。 監修のゆうすけさんからお声がけいただいて、私も日本人アーキテクトの書き下ろし枠で「開発スタイルをデザインする」というコラムを書きました。10月17日(土) 19時から池袋ジュンク堂で、ゆうすけさん、はてな伊藤さんと私の3人で、出版記念トークイベントもありますので、よろしければお立ち寄りください(予約が必要とのことなので、リンク先を参照ください)。 以下、少し書籍の内容についての紹介を。 本書は、一言で言うと、「ソフトウェア開発に携わる人のためのバランス感覚調整ヒント集」とでも言うべき内容とな
福岡の夜 (shi3zさんとの喧嘩) : 小野和俊のブログ
8/5から三日間、昨年に引き続き、九州大学非常勤講師として高度ICTリーダー特論という大学院の授業で福岡に来ている。この授業では、日本の大企業からはNECのシステム開発本部長の池上さん、国際的なリーダーシップということで東京海上で世界中を飛び回っている牧野さん、外資系企業のマイクロソフト楠さん、ベンチャー企業のUEI shi3zさんと私、経産省の境さんと、様々な立場の講師がプレゼン、パネルディスカッション、グループワークなどに参加しながら授業を進めるというなかなか面白いタイプの授業である。 こうした諍いのことをネットに書くのもどうかとも思ったのだが、リーダーシップを論じるために呼ばれた講師同士が飲み会で喧嘩、ということになると、授業そのものが駄目なリーダーの見本市のような様相を呈してしまうため、私たちが何を議論していたのかについて、shi3zさんにならって私の視点からもブログに書いてみよう
小野和俊のブログ:アプレッソのジョエルテスト判定結果
今週末は熱海の温泉に行ってきた。 行き帰りの新幹線で読んだJoel on Softwareは衝撃的に良かった。 この本はソフトウェア開発に携わるすべての人が読むべき本だと真剣に思う。 中でも第三章に書かれているジョエルテストが面白かったので、 これをアプレッソに当てはめて判定してみることにした。 現在のアプレッソでは、12のテストのうち、10項目が当てはまっている。 該当する項目が2から3の会社が圧倒的に多いということなので、 判定結果としてはかなり良い方だと思う。 しかし、今は導入した後でその効果を知っているから全面的に賛成できるのだが、導入する前は、 「今のままで特に大きな問題があるわけでもないし、 新しい方法を導入することにはリスクも伴う。 このままでも良いのではないか。」 という理由で導入を躊躇したものも多かった。 これらはどの項目についても、マネージャーがどんなに反対したとしても
プログラマーの開発速度は「はまる」時間の長さで決まる : 小野和俊のブログ
プログラミングを始めてから今日に至るまで、 様々なタイプのプログラマーと開発を共にしてきたが、 驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、 一つ共通の特徴があるように思える。 それは、「はまる」時間が極端に短い、ということである。 風のプログラマー」を指向しており、開発速度を重要視している。 例えば平成14年未踏ソフトウェア創造事業「PICSY」では、 発表直前に知人でプロジェクトリーダーの鈴木健にレスキュー隊として呼ばれて 2,3日でGUI全般と、クライアント/サーバー通信部分の設計と実装を終わらせたのだが、 このときなどは、大体の要件を口頭で聞いた後は、 ほぼまったく手が止まらずコードを書き続ける感じで開発をしていた。 「はまる」時間の長さは開発速度に直結するわけだが、 プログラマーが「はまる」場合にはある程度の傾向があると思うので、 今日は「はまる」プログラマ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
