SlackをSIerに導入した話。そしてSIerの未来 : 小野和俊のブログ
「Slackを入れるとSIerはどうなるのか？」 しばらくブログを休んでいたので少しだけ自己紹介をしよう。アプレッソというベンチャー企業を立ち上げて、セゾン情報システムズという会社にexitした。そしていまはアプレッソの社長として仕事をする傍ら、セゾン情報システムズのCTOの仕事もしている。どちらかというといまはセゾン情報の仕事の比重が高いから、リアルの世界では「セゾン情報の小野」と思っている人の方が増えてきていると思う。 「このままでは、SIに未来はない。だから変わらなければならない。」 「当社の社員は言われたことしかできない。」 SIerの経営者と会話していると、よくこんな言葉を耳にする。 自分たちの未来を悲観している人たちが、未来を明るくできるのだろうか？ だから私は、喜びと驚きのポジティブスパイラルで、SIerはどんな風に良くなるのか、壮大な実験をしてみようと思った。 その第一弾と
HRTの原則 〜ソフトウェア開発はバーでしっとり語り合うように 〜 : 小野和俊のブログ
「HRTの原則」という言葉をご存知だろうか。 これは書籍 Team Geek ―Googleのギークたちはいかにしてチームを作るのか で紹介されている言葉であり、本書ではほぼ一冊すべてをかけてこのHRTの原則とその実践方法とを様々な角度から紹介している。 1. 謙虚(Humility) 2. 尊敬(Respect) 3. 信頼(Trust) の3つの価値が大切にされており、エンジニアとしてもチームや組織、顧客との対話においてこれらの価値を重んじていくことが成功につながる、というものである。 あらゆる人間関係の衝突は、謙虚・尊敬・信頼の欠如によるものだ Team Geek p.15 プログラマとして成功するには、最新の言語を覚えたり高速なコードを書いたりするだけではいけない。プログラマは常にチームで仕事をする。君が思っている以上に、チームは個人の生産性や幸福に直接影響するのである。 Team
いまだに知らないなんてありえない病 : 小野和俊のブログ
いまだに知らないなんてありえない病とは、プログラマー同士の会話の場で、 「いまだに○○という本さえ読んでいないなんてありえない」 「いまだに○○というフレームワークさえ使っていないなんてありえない」 「いまだに○○という言語を触ったことさえないなんてありえない」 「いまだに○○というパターンさえ知らないなんてありえない」 というように、自分が知っていて相手が知らないものについて、 「いまだに知らないなんてありえない」 と発言してしまう病の総称である。 発症例として、例えば次のようなものがある。 「いまだにマシン語が書けないなんてありえない」 「いまだにRubyを1行も書いたことないなんてありえない」 「いまだにVisitorパターンさえ知らないなんてありえない」 「いまだに高校レベルの数学も押さえていないなんてありえない」 「いまだに個人で開発したアプリが1つもないなんてありえない」 「い
SIerでのキャリアパスを考える勉強会に参加してきた : 小野和俊のブログ
このところ「SIerの今後について」というテーマについて、意見を求められたりディスカッションしたりすることが多く、またエンタープライズ業界に身を置く立場として、売り上げ比・人口比とも業界の大半を占めるSIerが今何に取り組んでいて、今後どのようになっていくのか、というのは私自身関心のあるテーマなので、昨日は「SIerでのキャリアパスを考える」勉強会に参加してきた。 というわけで勉強会の中で印象的だったことや考えたことを書く。 勉強会の前半パートではゆもとさんによるSIerの現状分析、ひがさんによるSIerの中でのキャリア戦略が話題に上り、その中でも特に「上流と下流が工程分断されている」ことが現状のSIerを取り巻く諸問題の元凶、という指摘があった。 この「分断」については、中島聡さんの「ソフトウェアの仕様書は料理のレシピに似ている」というエントリが有名だが、今回の勉強会でのゆもとさんの資料
「努力なんて格好悪い」と斜に構えずに、集中して物事に取り組もう : 小野和俊のブログ
「起業してほぼ確実に成功する方法」 ホリエモンのこのエントリを、まあそうだよねーと思いながら読んでいたのだが、はてブのコメントを見たところ結構ネガティブな反応が多かったので驚いた。 どうも最近ネットでは、「長時間働くのは格好悪い」「海外ではそんな働き方誰もしていない。日本人格好悪すぎる」というようなエントリがよく話題になるようだが、私なんかはこうしたエントリを読む度に、 打ち込んでいることにできるだけたくさんの時間を使おうとするのってそんなに格好悪いことですか？？ shi3zさんとかはiPadが発売されるからということでサンフランシスコまで出向いてすぐにレビュー中継を配信したりしている。iPhoneの時もそうだったけど、自分が情熱を傾けている対象に対して、この上でどんなものを動かしたら面白いだろう、何が必要になってくるだろうと必死で考えて、徹夜で仕事して会社に泊まって、私はそんなshi3z
成長しないプログラマーの7つの悪習慣 : 小野和俊のブログ
はてブのホットエントリで「成功できない人たちが持つ7つの悪習慣」という記事を見かけたのだが、ライフハック系の本やエントリは胡散臭く感じるところがあってあまり好きではない私から見ても、これは確かに、と思える内容で、プログラマーについても同じことが言えると思ったので、エントリにまとめてみた。 ・自分の理解力不足を技術のせいにする。すぐ理解できない技術や、普段自分が使い慣れてない技術は「キモイ」、「自分には合わない」などといってすぐ学習を放棄する。 ・他人の非に非常に敏感。使っているライブラリや人が書いたコードに少しでもバグが見つかると、「使い物にならない」、「書き直した方が早い」などとすぐ口にする。 ・環境がよく壊れる。「このPC不安定」、「また開発環境がおかしくなった」、「OSから入れ直さないと」といったように、作業環境が頻繁におかしくなる。たいていは自分で必要なファイルを消してしまったり上
小野和俊のブログ:[お知らせ] ｢ソフトウェアアーキテクトが知るべき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さんにならって私の視点からもブログに書いてみよう
小野和俊のブログ:Thunderbird が遅くなってきたときの高速化の方法
Thunderbird はよくできたメーラーなのだけれど、使い続けていると起動後に受信トレイの内容が表示されるのが遅くなってきたり、メールの自動受信が動作しなくなったりすることがある。 この件について以前バグレポートしようかと思ったのだけれど再現方法がわからず、開発の仕事で使うわけでもない割にレポートに手間がかかりそうだったのでまだレポートしていない。知り合いで同じ問題で困っている人が結構いたので、とりあえず私が見つけた回避方法を書いておく。同じ問題で困っている人は試してみる価値があるかもしれない。 * 5/17 追記 hiragisan、vant さんからのコメントで、実は仕様だということが判明しました。hiragisan、vant さんありがとうございました。 ・使い続けていると、起動後に受信トレイの内容の表示が完了するまでに時間がかかるようになってくる。時間がかかる程度は状況によって
プログラマーの開発速度は「はまる」時間の長さで決まる : 小野和俊のブログ
プログラミングを始めてから今日に至るまで、 様々なタイプのプログラマーと開発を共にしてきたが、 驚くべき速度で高い品質のソフトウェアを作り上げるプログラマーには、 一つ共通の特徴があるように思える。 それは、「はまる」時間が極端に短い、ということである。 風のプログラマー」を指向しており、開発速度を重要視している。 例えば平成14年未踏ソフトウェア創造事業「PICSY」では、 発表直前に知人でプロジェクトリーダーの鈴木健にレスキュー隊として呼ばれて 2,3日でGUI全般と、クライアント/サーバー通信部分の設計と実装を終わらせたのだが、 このときなどは、大体の要件を口頭で聞いた後は、 ほぼまったく手が止まらずコードを書き続ける感じで開発をしていた。 「はまる」時間の長さは開発速度に直結するわけだが、 プログラマーが「はまる」場合にはある程度の傾向があると思うので、 今日は「はまる」プログラマ
プログラマー面接時の技術的な質問事項(アプレッソ版) : 小野和俊のブログ
技術者・SE・プログラマ面接時の技術的な質問事項というエントリをはてブで見かけたのだが、私もjavaプログラマーの面接を割とよくやっているので、よく質問する内容をまとめてみた。 (ちなみに、基本的にコーディング面接の形態を取っている) プロジェクトの性質にもよると思うが、私の場合には、情報処理技術者試験的に基礎が満遍なく抑えられているかどうかよりも、 すぐ答えが見つからないような課題に対して、きちんと自分でやり方を考え、対応することができるか 「変な」コードをコミットしたりしないか(見つけにくいバグを混入させるとか、汚いとか、遅いとか)といった点を重視している。 まず、何を知っているかよりも、どんなものを作れるか、どんなことができるか、という質問。 ここで強烈な回答が来る人は、たいていここより下の質問は「あー、はいはい」という感じでサラッと答えてくることが多い。 これまでに携わってきた開発
IT企業の経営者として、不景気だとしても守り続けたいこと : 小野和俊のブログ
「この不景気ですから」という言葉が 挨拶の常套句として定着しつつある今日この頃、 昨年末の時点では、今回の不景気はアプレッソにはあまり影響がなさそうに 見えていたものの、昨日、四半期に一度の全社でのキックオフミーティングで 営業の人たちの発表を聞いて、やはりある程度意識していかなければならないな、 と感じた次第である。 そんな中で、もしこれから不景気が自分の会社にも影響を及ぼした場合にも、 こういうことは守り続けたい、と思うことを、エントリにまとめようと考えた。 とりわけ不景気な情勢の中では、「企業は利潤追求団体である」という前提の元に、 取りかかろうとしていることが収益を生み出すものなのかどうか、 ということについて重点を置いて物事を考えがちになるのではないかと思う。 ちょうど昨日知った二宮尊徳の言葉で、 「道徳を忘れた経済は罪悪であり、経済を忘れた道徳は寝言である」 というものがあるそ
プログラマーにとっての読み書きそろばん : 小野和俊のブログ
基礎的な学力を表す言葉として読み書きそろばんという言葉があるが、 私はプログラミングについても読み書きそろばんに当たるものがあると思っている。 まず読みというのは、プログラムを読む能力である。 たまに、人の書いたソースを見て、すぐに 「全面的に書き直さないと使い物にならない」とか、 「グチャグチャですよ」とか、 「気持ち悪い」といったことを口にする人がいるのだが、 多くの場合、なぜそのように感じるのかを聞いてみると、 単に自分が今まで書いてきたコードと違ったスタイルで書かれている、 ということだったり、ごく一般的なデザインパターンが使われているのに、 そのデザインパターンを自分が知らないだけで 「わかりにくくて読めない」などと言っていたり、 人のコードを使い物にならないと簡単に口にする人であればあるほど、 その人自身が使い物にならない、という傾向がある。 もちろん、全体の整合性を取るために
ソフトウェア開発の「自由の悲劇」 : 小野和俊のブログ
クリエイティブな仕事というのはある意味で残酷だと思う。 なぜなら、 つくりあげたものが評価に値しないものだった場合に、 自由にできる環境があったのに、 この程度のものしかできなかったのかという批判が 本人に対して直接的に向けられやすいからだ。 というような話を耳にすることがあるのだが、 「誰でもいいからお金を出すので好きにつくってよい」 という状況はほとんど考えられないわけで、 もし本人の希望がかなった結果、 大したものを生み出すことができなければ、 自分には新しいものを生み出す才能がないのではないかという 悩みに直面することになる。 もちろん、中には自分自身でソフトウェアを次々と開発して、 ダウンロード数やアクセス数、メディアで取り上げられた記事などを印刷し、 この企画を会社の事業として採用しないか、 と持ちかけてくるような強者もいる。 だがそういう人でさえ、注目を浴びたソフトウェアの影
技術仕様国際標準化という修羅の道 : 小野和俊のブログ
先日某所で村田真さんとお話させていただく機会があった。 村田真さんと言えば、日本人として唯一XMLの仕様策定に携わった方、 ということがすぐに想起されるわけだが、 他にも各所で精力的に仕様の策定や標準化プロセスに 携わられている方である。 村田さんの話を聞いて驚いたのが、 技術仕様の国際標準化プロセスは、 技術者同士の穏やかな話し合いなどではなく、 まさしく"闘争"だということだ。*1 個人攻撃についてのSC34の公開書簡」に記されている例では、 村田さん自身も携わっているOOXML(Office Open XML)国際標準化に際して、 一部地域で標準化に理解を示した個人や小企業が様々な個人攻撃を受けたため、 それに対して標準化プロセスに携わるメンバーから 署名付きの公開書簡が出る、といった事態に進展したということである。 他にも、標準化プロセスの課程の中では、 誰が見ても明白な改善提案が
♪ バグは夜更け過ぎに仕様に変わるだろう : 小野和俊のブログ
トラックバック一覧 1. バグはいつか仕様に変わる？ [地方で活動するweb制作者の日々を綴るblog] 2007年07月18日 14:25 「バグは夜更け過ぎに仕様に変わるだろう」 というのは、IT屋さんの中では有名な格言らしいのですが（私は知りませんでしたが）、その全文版を公開したそうです。 業界の人なら受けること間違いなし。 そして、現実と照らし合わせてぞっとすることも間違いなし。 IT 業... 2. 2007年7月18日 1907年はこんな時代 [神戸の三代目] 2007年07月18日 20:04 またヤフー株が米国につられて下げてる・・。誰かアナリスト、ちゃんと指摘してよー。ネタ加藤一二三九段伝説 前も書いた気もするけど、加藤一二三が凄い（というか面白い）。 一芸に秀でている人はぶっ飛んでいる人が多 3. [研究室][雑記] [Gabari] 2007年07月18日 20:22
小野和俊のブログ:バランスボールで快適パソコンライフ
トラックバック一覧 1. View point [〔N〕水泳・競泳情報のSWIMMING VIEW] 2007年06月19日 21:03 ・『コミかる！』届く！これで20世紀少年三昧だ！ ・「バランスボールで快適パソ... 2. 2007年6月19日 夏のボーナス [神戸の三代目] 2007年06月20日 00:30 車を購入して早1年が経とうとしています。もうすぐ、1年目の点検。ネタ夫の帰宅が早い！ : 家族・友人・人間関係 : 発言小町 : 大手小町 : YOMIURI ONLINE（読売新聞） 帰ってくるのが遅いと怒られ、帰ってくるのが早いと迷惑がられ・??y� 3. バランスボールでPCライフをハックする [My Digital Life Log] 2007年06月21日 15:00 バランスボールで快適パソコンライフのエントリに感化されて、ボクも投稿してみます。 バランスボールを
小野和俊のブログ:IT業界の大企業での生々しい話を5つほど
先日某所で講演をする機会があったのだが、 そこでお会いした大企業に所属されている方からの発言でいくつか印象的なものが あったので、ブログに書くことにした。 中にはぐったりしてしまうような内容のものもあるのだが、 会社が大きくなるとこういうことが起こりえるのだという自分への戒めも込めて。 とある大手 SI の方の話。 会社で 2ch へのアクセスを禁止したところ、開発の速度が目に見えて低下したので、 何が起こったのかと現場にヒヤリングしたところ、今までは困ったときに 2ch で聞いて問題を解決していたが、2ch にアクセスできなくなって、 はまってしまったときにどうにもならなくなってしまったとのこと。 これは Messenger / Skype を禁止している会社にも同様のことが言えるだろう。 プロが 2ch で聞くというのはどうなのかという意見もあるとは思うが、 会社の枠を超えた横のつなが
デザインパターンの会議への応用 : 小野和俊のブログ
先日、名刺の肩書きがファシリテーターの ATL システムズ片山ちささんと話していたときのことである。 彼女は最近、会議の進め方にデザインパターンを当てはめてみる実験をしていて、第一弾として Iterator パターンを当てはめて会議を進めてみたところ、これまでの会議と違った感触を得られたのだと言う。 ソフトウェア開発のためにまとめられたデザインパターンを会議というまったく別のものに当てはめたところで成果が得られるのか、という指摘もあるとは思うが、このようなやや乱暴な方法で発見される会議の新しいスタイルというのは確かにあると思う。 そこで、片山さんの試みに着想を得て、GoF のパターンのそれぞれを会議に当てはめるとどのような会議のスタイルが生まれ得るのかを、次のように考えてみた。 1. Abstract Factory パターンの会議への応用 通常の会議では、参加者によって異なる特性があり、
小野和俊のブログ:金をつくるのか、富をつくるのか、それが問題だ
初対面の人との会話で最近印象的だったのは、「何階建てですか？」という質問だった。曰く、自社ビルとして何階建てのビルを持っているのかということで、彼の考え方としては、自社ビルを建てるくらいの収益がある事業をやっていない人間にはあまり興味がない、ということである。 【企業・個人の目的】 1. 金をつくろうとしている 2. 富をつくろうとしている 3. 金と富をつくろうとしている ここでいう富とは、ポール・グレアムが「ハッカーと画家」で言っているような、人に何らかの幸福感を与えるものすべてである。例えばそこには祖母の肩叩きをすることも含まれるし、大切な人のために料理に腕を振るうことも含まれるし、困っている顧客にアドバイスをすることも含まれる。学術的な発明や発見も含まれるし、道に困っている人に行き方を教えてあげることも含まれるだろう。 企業で活動していると陥ってしまいやすいのが、ボランティアではな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
