私は昔から ADHD で昔から発想力や問題解決力はあるのだが、自分自身が何かのスキルを上達することが非常に苦手だ。コンサルとか、エバンジェリストみたいな「人にやってもらう仕事」は得意だが、プログラマとか、ヴォーカリストとか、自分が本当になりたかった職業には何回もチャレンジして何回も失敗してきた。 遠くから見ていると私は何かが出来てるように見えるかもしれないが、冗談抜きで人の３倍ぐらい時間をかけないと成果が出ない。しかも、中途半端にしか完成しない。だから、土日も常に何か努力していないと不安になる。 多分私と同じようなADHDの人は、自分的に努力しても何も達成出来ない辛さを感じているかもしれない。過去にも色々試してみたのだが、４７年生きてやっと自分でも実施できる対策が見つかったので、同じ様なことで苦しんでいる人のヒントになればと思い久々にこのブログを書いてみた。 「自分で何かを作れる人」が長年

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

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

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

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

仕事の習慣・考え方を変え生産性や新しい技術の導入を米国並みに加速する「８つの習慣」のうち「リスクや間違いを快く受け入れる」に関して考察した。具体的な実践プラクティスに関して言及してみたい。 最初の習慣は次のブログで紹介してみた。 simplearchitect.hatenablog.com リスクや間違いを快く受け入れる リスクを背負うことは推奨されている 間違いを厳しく批判したり懲罰したりしない 失敗から学ぶ態度 Fail Fast(早く失敗する） 実験が推奨されている 全員に「現状維持」や「標準」を要求せず、臨機応変が推奨される 非難や恐怖感の無い環境 この習慣は、日本人の我々にとってかなり難易度の高いものである。なんとなく言葉では分かっているつもりでも、海外で働いていると、自分の想像の範囲を超えていた。ということは、この習慣が身につけば相当かっこいいかもしれない！ 間違いや失敗に対す

クロスカルチャーの専門家Rochelle Koppさんと一緒に考案した 新技術の導入を加速させるための「８つの習慣」をまとめ上げた。この習慣を習得することで、米国と同じようなスピードで新しいことに対応したり、生産的になることができる。今回はその一つ目の習慣について解説してみた。 今回、日本最大級のアジャイル開発のイベントの一つである Scrum Gathering Tokyo で先のRochelle さんと一緒に「８つの習慣」を初めて発表させていただいた。 2017.scrumgatheringtokyo.org 「８つの習慣」は日本での Agile / DevOps をはじめとする最新技術やプロセスの導入を米国並みのスピードにすることを目指している。Agile や DevOps を開発した人は西洋の人なので、西洋文化の上に成り立っている。だから、日本の文化の上でそれらを使うと、どうもうま

先日、米マイクロソフトの Redmond キャンパスで行われたマイクロサービスのハックフェストに２週間ほどサポーターとして参加してきた。 そこで気づいた日本との技術導入の差の秘密について気づきをブログに書き留めておこうと思う。 ハックフェストというのは、お客様のガチの環境もしくはそれに近い環境/テーマで行うハッカソンだ。 例えば DevOps の文脈であれば、自動化したら効率化されそうな部分に関して、マイクロソフトの製品チーム、エバンジェリストがサポートしながら、お客様自身が我々と一緒にハックをして、実際にお客様の環境を自動化してしまうようなイベントだ。 Hello Worldやチュートリアルレベルではないので、お客様の環境が本当に自動化されてリードタイムが短縮されたり、我々にとっても、現場の難しい問題を知り、それに対してソリューションを作ることができるので、スキルアップまでできるので私は

10/1に、ServerlessConf 出店ブース始め、会場におられる方も、AWSを利用されている方がほとんどだった様子だったので、講演では、AWSを普段使っておられる方を想定して、お話しをしました。ただ、盛り上がった一方、詳細なアーキテクチャが知りたかったとか、AWSのλとの違いがわからなかったというご意見をいただきましたので、そういうフォローアップ記事を書いてみようと思いました。 個人的には、Serverless は、Microservicesの次のパラダイムぐらいの勢いがありますが、どのような利用がされているかのアイデアとその未来を知りたくて参加しました。ちなみに、スポンサーセッションと思われていますが、一応、スポンサーセッションではなく、サブミッションを出しています。本イベントは、非常に熱気があり、学びも多く、素晴らしいイベントでした。こんなにも素晴らしいイベントをこんなにも早く

Fig1. アリスターとXPJUGの仲間 2002年 How I saved Agile and the rest of the world 「アジャイル開発」そして「オブジェクト指向」などに多大な貢献をしたアリスターコバーンさんが、最近こんな記事を公開した。 Alistair.Cockburn.us | How I saved Agile and the Rest of the World 「アジャイル」が広まりだした2000年当初、アリスターは、Kent Beckと共に日本に来てくれた。本でしか見たことがない、想像上の偉人のように感じていたアジャイル界の大物の来日は衝撃的だった。当時は外タレの来日は非常にまれだった。これはテクノロジックアートの長瀬さんそして、XP JUGのコミュニティの貢献が大きかったと思う。しかも、東京だけではなく、関西に来てくれたのだ。 当時、アジャイルの世界は今

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

今回マイクロソフトの社内カンファレンスに参加するために、シアトルに滞在したが、以前からどうしてもやりたかった、マイクロソフト最高の DevOps チームを直接観察してみたいという夢をかなえてみた。 私はマイクロソフトの DevOps エバンジェリストだが、Sam Guckenheimerのチームの話は、本人の口と、プレゼンテーションと、アーティクル経由で理解したものに過ぎない。現場に行って本物を見てみたかったのだ。 だから、今回Ｓａｍにお願いして、VSTS/TFSを開発しているMatthewのチームを観察させてもらった。そこで得たことを皆さんと共有しておきたい。 気になっていたSamの一言 VSTS / TFSの開発チームがいるビルにやってきた。ここにあのチームがいるのかと思うとすごくワクワクしてきた。一体どんなことを彼らはやっているのだろう。それと同時に、私が顧客訪問をSamと日本で行っ

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

おかげさまでたくさん読んでいただいたブログですが、この内容について聞いてみたいということで先日アジャイルラジオという番組の収録を行いました。 simplearchitect.hatenablog.com 前半、後半になっています。私の意図していることなどについて、自分の声でお話しさせていただきました。 よかったらお楽しみください。 agileradio.github.io agileradio.github.io

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

最近は、ソフトウェアの新しい技術や、考え方の日本に対する導入の遅れをどうやったら無くすことができるか？ということを考えている。今回はインターナショナルチームに参加して感じたマネジメントスタイルの違いについて書いてみたい。 海外企業のリーダーシップスタイルの変化 ソフトウェアの世界では、2001年にアジャイル開発が登場以来、それ以降のパラダイムでは、「サーバントリーダーシップ」と呼ばれるタイプのマネジメントスタイルが主流になっている。 従来型のスタイルは「コマンドアンドコントロール」というスタイルで、リーダーが部下に指示をし、リーダーは部下の状況を把握、確認し、管理していく。一方、サーバントリーダーシップの場合、リーダーは、ビジョンとKPIを示すが、実際にどのようにするかは、チームが自ら考えて意思決定していく。 この考え方は、既に1969年に発表されているらしいというのを下記の本で知った。

今回は、前回のブログの内容をより考えてみたいと思う。 「自分で人生を決める」人は、他人に対して「すべき」がない 前回のブログの主張は、「自分で人生を決めない」マインドセットが、新しい考えや技術導入を遅らせるというアイデアだった。今回はさらに、「自分で人生を決める」マインドセットをもっていると、どういう効果があるのかを考えてみたい。 simplearchitect.hatenablog.com 「自分で人生を決める」というマインドセットを持っていると、「自分のことは自分で決める」という考えになる。心理学で鏡の法則というのがある。自分に適用している考えを他人にも適用するという法則だ。「自分のことは自分で決める」人は、「他人のことは他人が決める」という考え方になる。新しいアイデアや技術の導入スピードにはこれがとても効いている気がする。 逆に自分の人生が自分でコントロールできないと思っている人は、

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

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

今まで、幾つかのポストで書いてきたのですが、私は今のインターナショナルチームのポジションをとても気に入っています。楽しく、気に入ってるだけではなく、実際の生産性やワークライフバランスも過去最高です。 私は、「Be lazy」の回で書いた通り、「Be Lazy」を極めるために、「エッセンシャル思考」を実践しています。日本Microsoftは相当素晴らしい会社ですが、それでも、正直いうと、日本で「エッセンシャル思考」を実践すると、若干肩身が狭い思いをします。かといってこの人体実験をやめるつもりはありません。私の職業上の次のゴールは、「世界のどこでもご飯を食べられる様になること」だからです。 simplearchitect.hatenablog.com 一方、「Be Lazy」の考えを、チーム丸ごと受け入れてくれて実践しているお客様がいます。そうか、チーム丸ごとその考えを受け入れるならば、問題な