CIOとしての挑戦：事業会社のITの理不尽さを最小化する試み＆社員募集 : 小野和俊のブログ
2019年にクレディセゾンに入社して、3年の月日が経った。 これまで基本的にシステムに関するすべてを外部に委託してきたこの事業会社で、ゼロから内製チームを組成し、70名規模に拡大し（※1）、データ駆動経営の推進チームも組成した。また、日本の大手金融会社として初めてSlackを全社導入するなどデジタル人材の採用・育成による内製開発を武器に、デジタルの力を事業会社のど真ん中にインストールしていくことはそれなりにできてきたかな、と感じている。 そして1年前に大きな転機があり、CTOに加えてCIOの仕事もすることになった。長きに亘りプログラミングを自分の仕事の核としてやってきた私にとって、当初はCIOの仕事は違和感もあり慣れないことばかりだったが、1年間を経て課題がクリアに見えてきて、今後何をすれば良いかが分かってきた。（※2） だから2022年は、CIOとして一気に会社を良くしていきたい。 「こ
塾に行かずに中学受験 : 小野和俊のブログ
我が家は小学生の子供が3人おり、みな近所の公立の小学校に通っている。 一番上の長男が生まれたばかりの頃はうちの子供はみんな中学校までは公立がいいんだろうなぁ、と思っていたのだが、長男については友人の親からも「私立の方が向いているのかも」と言われることがあり、親としても何となくそうかもねぇ、などと話し始めたのが小学６年になった昨年の春。そして直後に友人もたくさん受けていた無料学力テストの結果を受け取りに近くの学習塾に行った際、そこで言われた言葉が「あのね。今からは無理ですよ。お子さんはずっと塾や家庭教師なしで学校の授業だけ受けてきたようですけれど、もう小６に入ってしまっていますから。塾では５年生までに６年生までの勉強を全部終わらせて、６年生はひたすら応用問題を解くんです。それに今回のテストは受験しない生徒も多数受けるごく一般の学力テストで、そこで現在偏差値40台ですし・・・。ですから、私たち
珠玉のエンジニアリング冒険譚 〜 書評「Engineers in VOYAGE 事業をエンジニアリングする技術者たち」 : 小野和俊のブログ
VOYAGE GROUP CTOの小賀さんから本書を送っていただき、読了。 ひとことで言うなら、本書は「俺たちはこんなに綺麗にうまくやっている」というベストプラクティスと自慢の本とは対極にある、「こんな課題がありました。それに対して俺たちはこうやって向き合ってきました」という、エンジニアたちの生々しい戦いの実録だ。 そんな本書にはところどころに、言葉を見ただけで身体の内側から胃をグッと握られたような、少し内臓が重たく感じられるような表現が出てくる。 「とりあえず使ってみる文化」(p.11)、「ついカッとなってパッチを投げまくっていた」(p.25)、「短期間にブルドーザーのようにコードの削減と整理をする腕力」(p.26)、「オブザーバビリティを高めることに注力」(p.35)、「全員がフルサイクル開発者」(p.60)、「重要なのは切り戻しできるかどうか」(p.70)、「レガシーシステムと戦う決
本を出しました。「その仕事、全部やめてみよう」 : 小野和俊のブログ
本を出しました。「その仕事、全部やめてみよう」 このブログで書いてきたこと。 この20年間仕事で取り組んできたこと。 プログラマーとして、経営者として、感じたことや学んだこと。 誰かに伝えたら、その人や、あるいはその人のいる会社が、 もしかしたら何か変わっていくかもしれないこと。 「2020年版、書籍版・小野和俊のブログ」 のような形でまとめたらどんな風になるだろう。 そんな風に考えながらこの1年半ほど本を書いていました。 そしてようやく完成したのが今回の本です。 220ページの本になりました。 先日、とある日本の大企業の幹部の方からこんな相談を受けました。 「うちは事業会社ですが、手の内化・内製化が大事だということで、 今回初めて外部からベンチャー出身のエンジニアを採用してみたんです。 そしたらみんなが忙しい仕事中にも、業務時間外の夜中にも、 思いついたことを次々と好き勝手提案してくるん
「ソフトウェア・ファースト」を読むべし : 小野和俊のブログ
10月初めに著者の及川さんより「ソフトウェア・ファースト」を送っていただいていたのだが、つい先日まで仕事が立て込んでおりずいぶんと読み終わるのが遅くなってしまった。極めて良著だった。 とりわけ私にとっては、問題意識や取り組みの方向性があまりにも自分と一致しすぎていて、「いや、本当にそう。それでいまこういうことをやってるのよね。」と一致の程度が高すぎて読んでいてところどころで共感の気持ちが声として漏れ出てしまう内容であった。むしろ違和感があまりにもなさすぎて、危険だとさえ感じた。共感の程度が高すぎると、自らが肯定されたような気分になり、このままで良いのだろうかという迷いから生まれる自省的考察から自らを遠ざけることがあるからだ。 私がクレディセゾンに来たのはまさにこれが理由だ。 自分でアプレッソといベンチャーを立ち上げてきたし、DataSpiderというプロダクトも生み出した。だが、あるときか
クレディセゾンでエンジニアリングチームを立ち上げます : 小野和俊のブログ
先程、クレディセゾンの来期組織のプレスリリースが出ましたが、3/1からクレディセゾン CTOの仕事をメインの仕事にしていくことになりました。 （立場は変わりますが技術顧問という形でセゾン情報システムズ/アプレッソの仕事も継続しますので、引き続きぜひ何かありましたらお声がけください。昨年秋にはAmazon Alexaスキルアワードで法人部門優勝＆特別賞のダブル受賞もしたりしてだいぶ面白くなってきています！）。 で、クレディセゾンで何をやっていくか？ エンジニアリングチームの立ち上げをします。 具体的には2つのことをしようとしています。 クレディセゾンは金融の会社です。ITの世界の枠組みで言うと、いわゆるユーザー企業です。 少し前までは、多くのユーザー企業にとって、ITは「社内業務の効率化」のためのものであり、重要ではない、とまでは言わないまでも、今日のような重要性を持つものではなかった。 そ
新オフィスへの移転: 社内コミュニケーションの再デザイン : 小野和俊のブログ
昨年の11月にセゾン情報システムズとアプレッソは、9月に竣工されたばかりの赤坂インターシティAirに引っ越した。移転後すぐにブログの記事に書こうかと思っていたのだが引越し後どんな風に仕事の仕方が変わったかの様子を見てから書こうなどと思っているうちに9ヶ月近くが経ち、これまでのオフィスと比べた時の違いもかなりはっきりと見えてきた。様々な点で変化があったのだが、一番大きかったのは、社員同士のコミュニケーション機会が増えたことだ。 1. バリスタ2名常駐の社内カフェ 新オフィスで一番人気のエリアがこの社内カフェのエリア。バリスタが一杯一杯ハンドドリップで淹れてくれるコーヒーはとても人気で、一日に二杯も三杯もコーヒーを飲みに来る人もいる。カフェの前に広がるオープンスペースでは大体いつもどこかしらの事業部が何かの発表をしていて、コーヒーの待ち時間に他事業部の話を聞くことで、「へー、そんなことやってる
SIについて私が思ったこと。そしてSIerにおけるモダン開発について : 小野和俊のブログ
ひとことで言えば、「レビュー文化は良くない」ということになるだろうか。 Slack導入、そして同時期に開始した服装の自由化、バイモーダルという考え方の浸透、AIやブロックチェーンを活用したPOC等の取り組みによって、SIerとしてのセゾン情報システムズは、社内の雰囲気もずいぶんと変わってきた。 しかし、こうした取り組みだけではどうにもならないものも少なからずあった。 そのひとつは、「悪い報告がしづらい」ことだった。 これは他のSIerでも同様のことが多いのではないかと思うが、問題プロジェクトに認定されると、品質管理部のモニタリングが強化されたり、第三者によるプロジェクト監査が始まったり、経営会議での定期的な報告が求められたり、何をやっているのかとレビューでこっぴどく叩かれたり、、、。 そうした責任感から、遅れをキャッチアップできるよう少しでもがんばろう、と励まし合う中で、それなのに四方から
SlackをSIerに導入した話。そしてSIerの未来 : 小野和俊のブログ
「Slackを入れるとSIerはどうなるのか？」 しばらくブログを休んでいたので少しだけ自己紹介をしよう。アプレッソというベンチャー企業を立ち上げて、セゾン情報システムズという会社にexitした。そしていまはアプレッソの社長として仕事をする傍ら、セゾン情報システムズのCTOの仕事もしている。どちらかというといまはセゾン情報の仕事の比重が高いから、リアルの世界では「セゾン情報の小野」と思っている人の方が増えてきていると思う。 「このままでは、SIに未来はない。だから変わらなければならない。」 「当社の社員は言われたことしかできない。」 SIerの経営者と会話していると、よくこんな言葉を耳にする。 自分たちの未来を悲観している人たちが、未来を明るくできるのだろうか？ だから私は、喜びと驚きのポジティブスパイラルで、SIerはどんな風に良くなるのか、壮大な実験をしてみようと思った。 その第一弾と
小野和俊のブログ:プログラマー風林火山
アプレッソというベンチャー企業の CTO を務めて6年と2ヶ月になる。変化の激しいベンチャーに比較的長い期間身をおいていたので、社内外のいろいろなタイプのエンジニアと仕事をしてきた。 あるエンジニアが参加することで開発チームが短い期間で大きく変わったこともあったし、開発チームのメンバーが15人いた頃よりも、お互い補い合えるエンジニアが5人くらいの頃の方が成果が出たりすることもあった。 そういう経験を重ねていくにつれ、私の中では、スターエンジニアと呼べる人たちの持っているものについての、いくつかの類型ができてきている。今まで一緒に仕事をしていく中で本当に心強かったのは、最近エンジニアのキャリアパスの議論でよく言われるような財務のわかるエンジニアとか営業もできるエンジニアではなく、あるいは人と異なるユニークな能力を身に付けようとしているエンジニアでもなかった。ではどういうエンジニアが、というこ
HRTの原則 〜ソフトウェア開発はバーでしっとり語り合うように 〜 : 小野和俊のブログ
「HRTの原則」という言葉をご存知だろうか。 これは書籍 Team Geek ―Googleのギークたちはいかにしてチームを作るのか で紹介されている言葉であり、本書ではほぼ一冊すべてをかけてこのHRTの原則とその実践方法とを様々な角度から紹介している。 1. 謙虚(Humility) 2. 尊敬(Respect) 3. 信頼(Trust) の3つの価値が大切にされており、エンジニアとしてもチームや組織、顧客との対話においてこれらの価値を重んじていくことが成功につながる、というものである。 あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ Team Geek p.15 プログラマとして成功するには、最新の言語を覚えたり高速なコードを書いたりするだけではいけない。プログラマは常にチームで仕事をする。君が思っている以上に、チームは個人の生産性や幸福に直接影響するのである。 Team
コードレビューについて : 小野和俊のブログ
伊藤直也さんが「些末なコードレビュー」というエントリを書いて話題になっている。このエントリで伊藤さんはコードレビューの話と、はてなのJavaScriptの話と2つの話題に触れている。前者のコードレビューについてはアプレッソでは8年ほど前から「コードレビューを通っていないコードはコミット不可」というルールですべてのソースコードに対してコードレビューを必須にしてきた関係で私も思うところがあるので、エントリを書いてみようと思う。 伊藤さんが例示しているように、インデントやreturnの省略などの話は好みの問題であり、議論してもソフトウェアの改善につながらない。なのでコードレビューでこうした宗教論争が起こるようなら、コーディング規約を見直すべきだ。「無駄に悩んだり議論したりすることを減らす」ことはコーディング規約の主たる効果のひとつだと言える。 コードレビューに慣れないチームが、何の考えもナシにコ
想像力の届く範囲 : 小野和俊のブログ
ランチで隣の席についた客は、食事中絶えず何かの文句を言っていた。 先日紹介を受けた保険には騙された、 近くにあるあの店は高い、あそこは良くない食材を使っている、 上司は使えない、同僚の誰それは直さなくてはならない欠点がある。 50歳近くと思われる彼は、奥さんと思しき正面に座った女性に対して 「もう本当に色々とダメなんだよ」、と、終始愚痴をこぼしていた。 何かをつくる立場を一度経験すると、 それについて軽率に悪く言う事はできなくなる。 自ら本格的に製造してみようとすることについて、 「自分にはこれは無理なんだ」 ということを思い知りたくてそのようにしているのだ、 と話していたことがあった。 野菜でも一年も作り続けていると 細やかな土の味の違いがわかるようになり、 ビールやワインも自らゼロからつくってみると、 お店で出るたった一杯の生ビールがいかに 感動的な作品なのかを思い知ることができるとい
人生のパフォーマンスチューニング : 小野和俊のブログ
プログラマーはソフトウェアを開発する際、無駄な処理や非効率的な処理を極力排除しようとする。この意味においてプログラマーは処理の効率化の専門家であると言える。ならば私たちプログラマーはソフトウェアだけでなく、自分自身の人生についてもパフォーマンスチューニングできるはずだ。 プログラムでしばしばパフォーマンスのボトルネックになるのは、「ループの中の処理」だ。例えば10万行10列のデータを1列ずつ処理していくようなループ処理の中身を1ミリ秒速くすれば、全体で約16分の速度向上が見込める。 人生においても、実行頻度の高い処理はパフォーマンスチューニングの効果を得やすい。 例えば職種を問わず毎日2回ずつ実行される処理として、通勤がある。通勤のチューニングにより、営業日が月に20日だとして、もし通勤を片道30分短縮できれば、月20時間の時間を得ることができる。具体例として私の場合、「通勤を徒歩10分以
私がshi3zさんを愛さずにいられない理由、そしてノブレス・オブリージュ : 小野和俊のブログ
清水亮という男がいる。ネットのidはshi3z。 本当に嫌な奴で、だいたい飲み会の席で同席すると喧嘩になる。 4年ほど前にもこんなことがあった。九州大学工学部大学院の『高度ITCリーダーシップ特論』という授業の講師として招かれた我々は講師陣の飲み会で口喧嘩を始め、shi3zさんは私に捨て台詞を吐いてその場を退席したのだった。リーダーの見本たるべき私達が飲み会の席で喧嘩別れし、しかもその直後からTwitterなどの公の場で互いに罵り合う姿を見て、「自分はこんなリーダーにだけはなりたくない」と思った学生も少なからずいただろう。この授業の本質が、ダメなリーダーを反面教師的に間近に見ることで受講生の意識改革を促すことにあったのだとしたら、そこまで見越してコーディネートした楠さんの深謀遠慮には敬服の意を表さざるを得ない。 shi3zさんの昨日のエントリによれば、小野和俊、すなわち私という人間は、慶応
エンジニアの成長と「快適な職場」について : 小野和俊のブログ
「時間あれば軽く飲んでいきます？」 一年前のちょうど今くらいの季節に、Diablo3のオフ会の後に伊藤直也さんと2人で新宿三丁目のバーに向かった。 伊藤さん曰く、 「グリーにいたとき、すごく優秀な人がいて。お願いしたいことを短い言葉で伝えるだけで、行間を読んでこちらがやりたいことを全部理解して、必要な指示を出して自分も動いてあっという間に成果を出しちゃう。」 一般に、エンジニアの楽園のような職場 - 快適で自由闊達に意見が言えて、技術力があり、それぞれが自主性を持ってのびのびと仕事をしている職場の方が、エンジニアは良いアウトプットを出せるし、類は友を呼んで優秀なエンジニアが集まってきやすい。これは確かなことだろう。ただ、エンジニアの成長を考える時、そういう職場は本当に理想的なのか、という点については、少し立ち止まって考える必要がある。 人の成長には、明るく楽しく周囲も優秀でコミュニケーショ
新生ミクシィへの期待と要望 : 小野和俊のブログ
「ここに書いても・・・誰からも反応なしか」、「○○月☓☓日でmixi退会します」などとマイミクがmixiから次々と去って行ってはや数年、mixiはもう再び話題になることはないかのように思える時期が長く続いていましたが、昨日の新経営陣発表を受け、「mixiアカウント復活！」、「懐かしい！」といった要領で、知人の間でmixiが盛り上がりを見せております。 マイミクの多くがmixiを離れてFacebook/Twitterに移行したりログインしなくなったりしていく中、私は1年前までブラウザ三国志 for mixiをかなり激しくプレイしていたこともあり、また、その結果mixiでしか繋がっていない知人もそれなりにおり、なんだかんだで今日に至るまで毎日5〜10回くらいはmixiにアクセスしていたので、ここはどうにかならないかなぁ、この部分はやっぱりmixiが良いんだよなぁ、などとmixiに対して感じるこ
Clash of Clansがかなり面白い件 : 小野和俊のブログ
このところ知人から紹介を受けて新しくゲームを始めてはすぐ飽きて止め、というのを繰り返していて、これまで私が人生の1ページとして記憶に残るレベルでプレイしてきた Ultima Online、Quake2、Diablo1/2/3、World of Warcraft、ブラウザ三国志などのクラスのゲームにはなかなか出会えないものだなぁ、などと思っていたのだが、年明けに Aiming 小林さんから紹介された iOS 向けの Clash of Clans というゲームがかなり面白いのでブログで紹介しようと思う。どこかで iOS 向けのゲームでアメリカで9週連続1位、というデータを見たような記憶があるが、これは確かに面白い。 最初は箱庭ゲームとして自分の村を自分の好みでレイアウトしながら育てていくのだが、途中、かなり初期の段階から、プレイヤー同士が互いに他のプレイヤーの村を攻撃して資源を奪うことができる
if-then-else文の順番 : 小野和俊のブログ
ペアプロで if-then-else 文が出てきた際、「これ、else if の順序、こっちの方が良くない？」というような会話をすることが時折ある。 どれも当たり前のものかもしれないが、「ああ、確かに」という反応があることもあるので、今日はそんな会話の際に出てくる視点についてまとめてみた。 if (よくあるケース/正常なケース) { // 処理 } else if (比較的特殊なケース) { // 処理 } else if (さらに特殊なケース) { // 処理 } else { // 処理 } 条件式の結果がtrueになる確率が高く、「ノーマル」に近いものを上に書く。可読性が上がる他、特に2.で触れる条件式の判定に時間のかかる場合や、ループの最奥にある処理などのif-then-else文の実行される回数が極めて多い場合には体感レベルで実行速度にも大きな差が出ることもある。 Code Co
いまだに知らないなんてありえない病 : 小野和俊のブログ
いまだに知らないなんてありえない病とは、プログラマー同士の会話の場で、 「いまだに○○という本さえ読んでいないなんてありえない」 「いまだに○○というフレームワークさえ使っていないなんてありえない」 「いまだに○○という言語を触ったことさえないなんてありえない」 「いまだに○○というパターンさえ知らないなんてありえない」 というように、自分が知っていて相手が知らないものについて、 「いまだに知らないなんてありえない」 と発言してしまう病の総称である。 発症例として、例えば次のようなものがある。 「いまだにマシン語が書けないなんてありえない」 「いまだにRubyを1行も書いたことないなんてありえない」 「いまだにVisitorパターンさえ知らないなんてありえない」 「いまだに高校レベルの数学も押さえていないなんてありえない」 「いまだに個人で開発したアプリが1つもないなんてありえない」 「い
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
