今回は、マイクロソフトにいて自分が感じているIT業界の大きなスタイルの変化の兆候とその対策について書いてみた。今回もいつも通り、単に自分の意見をシェアしているだけであって、他の人にどうこうしろと言いたいわけではない。ただ、日本のIT業界が米国に追いつき、追い越すための議論のきっかけになるといいなと思っている。自分も楽しみながらも、もがいていることと、そこで見えた光について書いてみたい。 世界は「技術力」の重視に向かっている 私のキャリアは、某大手SIerを12年勤めた後、ITコンサルティング企業に３年在籍して、主に超上流を実践した。その後独立し、ビジネスモデリングから、アジャイルや、DevOpsの導入支援、マネジメント、開発などを実施していた。 私がマイクロソフトを受けてみようと思ったのは、友人からの推薦の要素が大きかったのだが、その背景では、海外で勤務したいという希望があったのと、「技術

エンジニアに英語が必要と言われて久しい。技術情報を早く入手するためには、英語を使えないといけないからとあるがこれは本当なのだろうか？自分的な気づきがあったので、その考察をシェアしたい。 エンジニアに英語が必要と言われている。いろんなことが言われているが、情報の入手のスピードが遅くなるという意見がある。個人的にはこの意見はある意味微妙な意見だと思う。 最近だと例えば最新技術に関する海外イベントがあったとしても、翌日、早ければ当日の間に誰かがまとめブログをアップしてくれたりする。もっと時間がかかったとして、２カ月程度後に誰かが書いた日本語の情報でそのことを学んだ ところで、大勢に影響はない。 また、日本語で出ている書籍は確かに翻訳のタイムラグがあるが、海外の人も主だったすべての本を読んでいるわけではないし、日本語になったものを着実に勉強しても、勉強の知識としては、相当なエンジニアになれるはずだ

以前から不思議に思っていたことがある。それは、少なくとも米英の人は、ソフトウェア技術やプロセスに対して誤解が圧倒的に少ないということである。 別の回でも書いたが、イギリスの会社とお話しした時も、「アジャイル」に対するとらえ方、考え方は、100%といっていいほど正確だった。 バリューストリームマッピングで困っている人の話 今回の出張で、Sam Guckenheimerに依頼されたことがある。ある人が「バリューストリームマッピングをやっているのだが効果が出なくて困っている」だから原因を一緒に探ってほしいとのことだった。 Samと一緒に彼の話を聞いていると、バリューストリームマッピング、DevOps に関する考え方とらえ方は極めて正確だった。彼の問題は、「コンセプトの理解」は何の問題も無く、その先の「実際にやってみて工夫してみないと到達できない部分」の問題だった。 なぜか米英では、ソフトウェアの

先日ブログを書いたら大いに炎上した。いろんな方がいろんなブログを書かれていたようだ。しかし、私は一切読んでいない。なぜならそこに関心がないからだ。ウォータフォール vs アジャイルの比較は私の関心ではなく、私の関心は「どうやったらソフトウェアに関する新しい考えや技術が、日本でも早く導入されるようになるか」だからだ。人生は短い。自分の時間配分は自分で決めているので 申し訳ないが、今後も読まないだろう。自分の人生は自分で決めるのだから。 simplearchitect.hatenablog.com 実は、この炎上の過程でいろんな仮説を考えることができた。なぜ、日本のソフトウェア産業は、海外に大きく後れを取ってしまっているのか？どうすれば、進化する手助けができるのだろうか？ 自分の現在の仮説はマインドセット、つまり「考え方」が根本的な原因ではないか？という気がしてきた。 私が最近研究しているのは

私はソフトウェアの専門家としてお答えすると、ウォータフォールは何のメリットも無いというのが私の意見であることを共有しておきたい。そういう意見に至った経緯をこのブログで書き留めて置きたい。 尚、これは所属会社の見解ではないことは明確にしておきます。 サム・グッケンハイマーの一言 私は DevOpsのエバンジェリストで、それ以前からアジャイル開発をかれこれ１５年ぐらい実施し、導入の支援をしている。私はかつては、日本の環境の制約の中で如何にアジャイル開発のメリットを最大に引き出すか？ということを考えていた。 ウォーターフォールに対する立場も、真っ向から否定するものでもなく、現状もあるし、それに慣れている人もいるし、実際ウォーターフォールでも失敗しない人も居る。だから、人にウォータフォールのメリット・デメリットを聞かれた時も「変化しないものに関してはウォータフォールはいいのかもしれない」と回答して

いつも通り、生産性に関するブログを書こうと思ったのですが、その過程で、ダイバーシティについて少し調査しようと ブログや本をチェックして、とても違和感を感じました。そこで自分の意見を整理するために、ブログを書いてみました。 私は単にインターナショナルチームのメンバーであるだけで、専門家でもなんでもないので、稚拙で誤った意見かもしれませんが、それでも何か書いておくと自分の整理と学び（プロセスの改善のプロフェッショナルとして）になるかと思い筆をとってみました。 自分の感じるダイバーシティの違和感 私はインターナショナルチームで働いています。そして実際にその環境で働いていると、本当に楽しく快適に働けています。だから、その環境の素晴らしさと、その環境を日本でも実現する方法を考察するために、インターネットを調査してみました。 Microsoftはダイバーシティに非常に力をいれているので、必須教育でもダ

私はマイクロソフトのインターナショナルチームで働いています。特に私は以前からUSのエンジニアの生産性の高さの秘密を学びたいと思っています。今回は日本でプロジェクトの改善活動を実施している時に気づいたことをシェアしたいと思います。 先日、ハックフェストというイベントを実施していました。現在実施している開発チームの作業工程を見える化して、無駄を発見し、マイクロソフトのメンバーが支援して、自動化のハックをして、実際に改善しちゃおう！というイベントです。このようなステップを踏むと、実際に自動化する前に、現在のソフトウェアリリースのリードタイムが８ヶ月だったものが、１週間ぐらいになることがわかったります。 それを実際にハックして実現しちゃおう！というものがハックフェストなのでなんともエキサイティングな仕事です！ ところが、先日ハックフェストを実施したときに、メンバーの人と一緒にペアプログラミングをし

DevOps という言葉は2009年のVelocity conference でFlickerが発表した 10 deploys per day という発表が起源になっています。 10+ Deploys Per Day: Dev and Ops Cooperation at Flickr from John Allspaw www.slideshare.net 残念ながらアジャイル開発宣言のような公式の定義がないため、多くの人がその定義をしようと頑張っています。私はその起源や、インターネットでいろんな人が定義している内容を総括して次のように「DevOps のエレベータピッチとは」という問いに答えてきました。 ビジネス・Dev・Ops が協力し、ソフトウェアのライフサイクルと価値の創出を改善する活動 これはこれで特に悪くないとは思うのですが、正直若干「ふわっ」としているのは否めません、また、私

私はマイクロソフトのインターナショナルチームで働いています。特に私は以前からUSのエンジニアの生産性の高さの秘密を学びたいと思っています。今回は同僚からの何気ない一言からの気づきをシェアしたいと思います。 David からの何気ない一言 私は無宗教で葬式の時は曹洞宗なのですが、以前から聖書には興味がありました。私の叔父はドイツ、アメリカに長年住んで仕事 をしていました。そんなガチに海外で生活していた彼が言っていました。 彼らの文化を理解したかったら聖書を読むのがいいよ 確かにイギリスにいた時もあらゆる場面で、日本に帰っても海外の映画を見ても様々な場面で、聖書の影響を感じます。 私は自分の仲間をより理解したいし、明るさ、生産性の高さ、芸術性などを本当に尊敬しているので、是非ともその考えを学んでみたいと思っていました。 私の尊敬する同僚の David もクリスチャンなので、彼にどの聖書を読んだ

私は米マイクロソフトの DevOps のインターナショナルチームに所属しています。ただ、住んでいるところは日本なので日本側のオペレーションも実施しています。 前回のブログでも書いた通り、私はどうして米国のエンジニアが生産性が良いのかをずっと知りたいと思っていたし、今も研究中です。この２つのチームに同時に見えてきたことがあり、彼らの生産性の良さの一端に気付いたのでブログにして残しておきたいと思いました。 見えてきた「物量」の違い 私がインターナショナルチームと一緒に向こうでしているときに、仕事でアップアップになったことはありませんが、日本だとしょっちゅうです。日本のMSもはっきり言って過去に私が所属したどの会社より相当効率的で無理がないのですが、それでも存在するこの差はいったい何でしょうか？いくつかの事例を通じてだんだん見えてきたことは１つのことをこなすための「物量」が違うということです。