ここ１ヶ月ぐらいは、海外のメンバーと仕事をしているが、Serverless Hackfest というイベントと、Serverless Conf やワークショップに関わっているので仕事量が増えていった。日本にいることだし、久々に「日本流」のハードワークをしてしまったのだが、一つ気づいたことがあった。それは、ここしばらくの謎だった、日本人のIT エンジニアはなぜイノベーティブな感じがしないのか？ということに対する問いだった。 Microsoft Hack week 日本人はイノベーティブ Rochelle Kopp さんとの仕事で知ったことで、一つとても意外だったことは、アメリカ人から見ると日本人は相当にイノベーティブに感じるらしい。 自分的には、少なくともIT 分野に関しては、向こうの真似ばかりしていて、後追いのイメージがある。私たちも向こうで生まれたツールやサービスばかり使っていて、全然日

今年から会社の方針も変わり、エバンジェリストからSoftware Development Engineer という職種に変わった。プレゼンとデモの世界から、お客様と一緒にハックしたりコードで世の中にインパクトを出す仕事に変わったので、楽しくも四苦八苦しながら頑張っている。 先日友人の Rochelle Kopp さんから Agile のビデオを作ってくれないか？という依頼があった。今から Agile を始めたいと思っている企業さんが増えてきたのだが、残念ながら私はコードを書くのが`今の仕事なので、エバンジェリストやコンサルをやっているときのように対応できない。出来るとしたら、自分が新技術導入 (Serverless, Microservices等)をご支援しているプロジェクトに限られる。 だから、彼女がビデオを作ってくれたらうれしいといったので、既存の資料を少しカスタマイズして、ビデオをい

クロスカルチャーの専門家のロッシェル・カップさんと共同でマイクロソフトの投資の元作成した「働き方を変えて生産性を高める８つの習慣」だが、動画シリーズが完成したので、各習慣の動画をここで整理しておきたい。楽しんでもらえる内容になっているので、是非楽しんでご覧ください！また、すべての項目について、私が過去にこのブログで書いた、各習慣に関するポストへのリンクを整理しておいたので本ブログの集大成になっている。 元々本シリーズは、日本でも、DevOps や Agile を米国並みに実践したいという考えから考察されたものですが、働き方を変えて変化対応性と、生産性を向上させるためのもので、どなたにも楽しんでもらえる内容になっております。早速各習慣のビデオをご紹介させてください。それぞれ１０数分以下のサイズになっています。 序章：イントロダクション ８つの習慣をなぜ作成したのか？どういう効果があるのか？と

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

私は入社以来、月1回以上のペースで、DevOps ハッカソンという無料イベントを実施しています。 DevOps が学べて、関連技術を自由にハックして楽しめるイベントです。マイクロソフトが、DevOps を広く普及させて将来DevOps の良い事例になってくれるお客様を探すことを目的としています。マイクロソフトというとWindowsみたいなイメージがありますが、このハッカソンはそういった縛りはありません。Azureを使っていただくことと、 Visual Studio Team Services という Git / Kanban / Build(CI) / Release Management / Testingみたいなのが便利にできる SaaSサービスをちょっとだけでいいので使っていただくこと、DevOpsプラクティス (例えばInfrastructure as Code)をどんな技術を使っ

私が初めてeXtreme Programming に出会ったのは確か2000年だと思う。実際に初めてのプロジェクトを実施したのが2001年。それからすでに15年が経過していることになる。そんな長い間アジャイル、そして DevOps の日本での導入に関わってきた。日本のアジャイル導入に関しては全て成功とは言わないが、かなり成果は上げてきたとは思う。だけと、今日は自分の導入ポリシーの誤りに気付いて、新たなステージにいける気がしたので、そのことを共有してみたい。 2002年 尊敬するアリスターコバーンと、XP JUG関西のメンバーと清水寺で。私が写真撮ってたのかなw Alistair.Cockburn.us | Alistair's first trip to Japan sept 2002 日本はアジャイルの導入がこれからという噂を聞いたけど本当？ これは、私がマイクロソフトの面接の時に、当時

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

DevOps を導入して、リードタイムの短縮などの効果を出したい時に、前提条件となっている「アジャイル」がまだ導入できていないケースが多い。そういったケースでは、まずアジャイル導入のご支援をすることもよくある。 そういった支援に入ると、「アジャイル導入前提」で構成されたはずのプロジェクトであっても、全然「アジャイル」のポイントを外しているというケースは珍しくない。更に問題なことに、「アジャイルをできます！」と言っているベンダーさんを連れてきても、全然ポイントを外しているというケースすら珍しくない。今回のブログではそういったケースでも、簡単に確認できる、「アジャイルになっていないかもしれない簡単なチェックポイント」を対策付きでいくつかご紹介しよう。 スプリントの中で、ウォータフォールを実施するのではない。それはミニウォータフォールというバッドプラクティスだ。 1. 進化型設計ができていない

仕事の習慣・考え方を変え生産性や新しい技術の導入を米国並みに加速する「８つの習慣」のうち「不確実性を受入れる」に関して考察した。具体的な実践プラクティスを踏まえ言及してみたい。 ご興味があれば、是非以前にご紹介した第一、第二の習慣に関してもご一読されるとよいかもしれない。 不確実性を受入れる マネージメントは詳細まで細かく練られた計画を期待しない。 予算と報告のプロセスは精密な結果の予測を要求しない。 内部プロセスは計画や優先順位の変更に柔軟である 事前に全ての問題分析が完了せずとも新しい事に挑戦する姿勢を持つ システムとプロセスは柔軟で、複数の頻繁な変更を受入れられる 学びに基づいて、変化を精力的に行う。 この習慣は日本人の最も苦手とするところのうちの一つかもしれない。しかし、変化に柔軟に対応する必要のある分野特にソフトウェア開発の分野では最も理解し、実戦して練習しておいたほうがよいと思

このエントリでは、ソフトウェアの見積もりがどういうものであるかをシェアした上で、今後日本はどのような方向に向かえばよいのでは？という私のアイデアをシェアしたいと思う。 注：このエントリは、某銀行の件とは全く関係ありません。考えるきっかけになっていますが、中の人がどんな状況だったかもわからないのに、勝手なことを想像して、人や企業を叩くのは私の趣味ではないからです。 ソフトウェアの見積もりの正確さ ソフトウェア見積もりのことを知りたければ、下記の本がお勧めだ。 books.rakuten.co.jp この本に「不確実性のコーン」という開発フェーズごとの見積もりの正確性に関する図がある。これを見ると、最初の企画の段階で実施した見積もりは、誤差が何と16倍もあり、概算見積もりのレベルでも4倍の開きがある。画面帳票仕様を「確定」したレベルでやっと1.6倍程度の開きになる。 請負開発を実施するときに、

「Be Lazy」というのは、日本側の上司にあたる Drew がいつも口にしている言葉だ。その意味合いは、「最小の工数で、最大のインパクトを出す」 という考え方だ。私もアジャイルやリーンを学んできたので、「大量のものを高速に作れること」はむしろ悪であり、いかに「作らなくていいか」を考えてインパクトの出るものにエネルギーをフォーカスするのが重要と思っている。 しかし、正直に言うと、それは、日本人の感覚からいうと最も縁遠い感覚だ。私がなぜ「Be Lazy」を極めたいと思っているか？というと、インターナショナル チームの同僚は仕事で成果をガッツリ出すのも尊敬に値するが、仕事をしている様子も実に楽しそうだ。誰も苦しそうだったり、我慢したりしていない。 仕事は楽しむものと言っていて、「我慢するべきもの」という日本側の空気とは相当違う。私は自分も人生や仕事を楽しみたいし、多くの人がそうなったらいいのに

世の中には、使う側、使われる側がある。一部の優秀な人が多くの平均的な人を使うのがどの業界でもあること。確かに現状はそうだと思う。しかし、私はそういう世界からは脱退して、自分が使いも、使われもしないゾーンに居続ける事を目指している。 ピンハネの定義 私は大手SIer出身で、技術系のコンサルティングファームを経て独立した。会社にいるときはピンハネについて考えた事も無かった。ここで、ピンハネについて定義しておくと、「自分は稼働せずに、他の人に働いてもらってその上前をはねる事」と定義しよう。 ピンハネはびこる世の中 私は独立した後、このピンハネの辛さについて思い知らされた。正直言って自分もそう思った事があるのだが、「自分は稼働せずにお金を稼ぎたい」いわゆる不労収入の世界はみんなの憧れだ。 これを実現するために、素晴らしいビジネスの仕組みを考えるとか、素晴らしいソフトウェアシステムを作るということだ