Technology Radar mentions Team Structure

ThoughtWorks が出している technology radar が今年もでています。これは、テクノロジーの中で現在イケているもの、今後イケそうなもの、をレーダーで（前方に何が見えているか）を表しているものです。 （ https://www.thoughtworks.com/radar より、綺麗なPDF資料もダウンロード可能のようです) ここのテクノロジーはここでは触れませんが、今回の大きなテーマは（超訳すると）、 Docker as process, PaaS as machine, microservices architecture as programming model Dockerを「プロセス」、PaaSを「マシン」、microservices architectureを「プログラミングモデル」とみようじゃないの。それに合わせて疎結合の小さなサービスの集合としてアプリケーションを作れるし、合わせて疎結合の小さなチーム構成が作れる。 Intelligent empowerment AIやDeep Learning使った差別化が可能になった。ずっと研究分野のものだった AI や Machine Learning が急激に実用になってきた！ The holistic effect of team structure チームにまかせる構造。スタートアップだけでなく企業の中でも、プロジェクト指向からプロダクト指向へと変わってきた。自分たちで作って自分たちで運用。 AR/VR （あまり知らないので訳はパス） 特に、前のブログでも書いたが、Docker/PaaS/Microservices のおかげで逆コーンウェイ戦略が取れるようになり、組織の構造とソフトウェアの構造を「戦略的に」合わせていく作戦が、1と3に出てくる。 企画・開発・運用、のようにサイロに別れた組織構造のなかでソフトウェアを考えるのではなく、顧客からみた「製品」、「サービス」という視点で、企画・開発・運用ふくめ必要な人材「全部入り」のチームを2つのピザを分け合えるくらいの人数のチームで構成する。これは、西海岸スタートアップのプロダクト開発の基本戦略だったのだが、それが、大企業の中の情報システム構築にももちこまれてきている。というようなメッセージングだ。 3のビデオを見てもらうとわかるが、そこには、Agile/DevOpsという「言葉」はでてきていない。それがあたりまえになったということよりも、そのような開発の言葉ではなく、よりデジタル革命による「ビジネス変化」と、そこでの人々の「働き方」の変化として、このムーブメントが表現されている。 そこが、新鮮というか、さすが、というか、そうだよなぁ〜という感触を強く受けました。3のビデオは特にオススメです。 （余談：英語のholisticという言葉使い（全部入り）は、最初のHBRのScrumの論文の中で竹内先生、野中先生が使った言葉でもあり、Ken Schwaber と Mike BeedleのScrum の最初の本の引用部分でもこの言葉が使われている）  

Read more "Technology Radar mentions Team Structure"

デジタルビジネスとアジャイル(Mary Poppendieck on Digitization)

10/18, エンタープライズ勉強会で行われた、Mary and Tom Poppendieckの講演資料を公開します。（その後、KDDIアジャイルカンファンレスでも話しました。）当日は私の拙い通訳で、うまく伝わらなかった部分を補強できたらと思います。 また、1ページごとにエピソードが盛り込まれていて、それが全体を形作っている講演でしたので、その部分についてもいずれ、解説したいと思います。 デジタル化(Digitization)は、DX(Digital Transformation)や、デジタルビジネス革命、という言い方でもよく現れますが、様々な産業で（銀行、製造業、小売、、）ソフトウェアがビジネスの「コア」になり、ITなしにビジネスができない時代の流れを指します。スライドの帯には、 “Software is eating the world” 2011のマーク・アンドリーセンのコラムからの言葉だと思う。「あらゆる産業がデジタル化し、すべての企業はソフトウェア企業になる」という強烈なデジタル革命宣言だった。 Maryの主張は、その中では、もっとも大事なのは有能な人を集めて、その人たちに権限をあたえ、自分で動けるようにするリーダーシップなんだ、というのがメッセージです。 GE のCEO、Jeff Immelt のページあたり、講演の途中でTom が立ち上がって、次のように一言放ったのが印象的でした。 “The most important resource for today’s companies is not capital, but talented and passionate people.” 「今日企業にもっとも重要な資源は、資本ではない。有能で情熱をもった人だ。」 — Tom Poppendieck Immelt の例以外にも、最もデジタル化が進んだエストニア、そこから学んだ英国政府、オバマケアのシステム失敗の話、などなど、面白いビジネスサイドからの話がたくさんあります。次の機会に詳しい解説を試みたいと思います。 Suncorp でアジャイルを成功せさ、IBMに移ったJeff Smithの話はここに詳しいです。 CIO.com.au: How Jeff Smith built an Agile culture at IBM さらに、この人の組織の仕方が変わってくる話は、「シリコンバレーから始まった小さいチームに権限を与える手法は、企業の情報システム開発にも影響を与え始めている」という言い方で、Technology […]

Read more "デジタルビジネスとアジャイル(Mary Poppendieck on Digitization)"

SPI Japan 2016 で基調講演しました

富山で開催された SPI Japan 2016  にて、基調講演をさせていただきました。お声がけいただいたSRAの林好一さんはじめ、運営のみなさんに感謝です。林さんはAutomotive SPICEなどに造詣が深い、この界隈の有名人です。 SPIはSoftware Process Improvementの略で、ソフトウェアプロセス改善。林さんからいただいたお題は、現場ではエンジアリングに主眼が置かれるが、プロセス屋さん（という言い方されていた）は外側から見ていて、ともすると現場と衝突する。エンジニアリング側とプロセス側は衝突するものなのか、と。アジャイルはどちら？あるいは、そもそも両者は目的が同じですよね？という問いかけでした。 基調講演 それで、私なりに考えて、アジャイルと、特に「プロジェクトファシリテーション」の話をして、それらとエンジニアリングは「水」と「油」ではなくて「醤油」のように一体化されたものではないか、というストーリーを作って話をしました。先に結論を言うと、、、 アジャイルはプロセスではない。しかし、現場には必ず（今動いている）プロセスはある。 すべてうまくいくプロセスはなく、環境、働く人々、お客様、製品などの特性によってそれぞれである。 誰かが決めるプロセスではなく、現場改善こそが、具体プロセスを作っていく。（抽象プロセス、もしくは参照プロセスというものはあるかもしれないが） その仕組みをプロセス自身に入れるべき。 そして、その活動自体も、現場で行うべき。 この場のみなさんにとっては、、、、当たり前のことですよね！ それでね、懇親会で、「結局、水と油ではない醤油とはなんなんでしょう」という疑問に答えられていないことがわかりました。それで、このブログで付け足したいと思います。 アジャイルはなんといっても西海岸文化が強い。つまり青い空の下でスタートアップがたくさんうまれ、そこで育ち、イグジットした人たちが投資家に周り、スクラップ＆ビルドが急速に起こっている世界。イノベーションの真っ只中です。日本は、より長期的な視点や勝ち負けではない文化を持っています。例えば品質に対して強くこだわったり、人材教育を社内で手厚く行ったり、ある程度長い雇用の中で、エンジニアと技術を育てていこう、という文化です。ですから短期的でなく、人でつないでいく「持続的イノベーション」が日本には必要だし、それが日本にあった、イノベーションの形ではないでしょうか。 以下は、野中郁次郎先生がIPAのアジャイルの海外普及調査を行ったときに寄せてくれた、日本のアジャイルへの応援文です。野中郁次郎先生はもちろん、竹内弘高先生とともにScrumという名称を新製品開発の文脈ではじめて使った論文の共著者です。 “新製品開発としてのスクラムの源流は８０年代の日本の製造業にあり、それがソフトウェア開発の文脈で欧米から再発見されたものがアジャイルと理解しています。現在の欧米型企業経営が、必ずしも国民生活の質の向上に寄与していないことを鑑みると、私たち日本人が、過去の知恵と若者の活力の両方を活かす形で、新しい日本の持続的イノベーションのやり方をつむぎ出す必要があります。その力の源泉は、高い志を持った経営と、いきいきと働くことができる現場環境にあるのではないでしょうか。日本に適したアジャイル、スクラムの形を、描き出そうではありませんか。そのためにはまず、経営、ミドルマネジメント、現場が話す場を作り、お互いに共感することから始めなくてはなりません。” 平成24年4月16日 一橋大学名誉教授　野中郁次郎 これをもって「醤油」のぼくなりの結論にしたいと思います。 その他の発表 富士通の和田さんと永和の羽根田さんの企画による、アジャイル行動展示が行われています。永和から、岡島さんや村上さんが参加してGAS(GoogleApp Script)で簡単なシステムを、人通りの多いギャラリー内で開発します(旭川動物園の行動展示のように)。2時間イテレーションでかなり難しそうですが、昨日の講演終了後にはたくさんの人が訪れてくれました。 他にも永和から、天野さんの、ふりかえり、についてのセッションがあり、岡島さんが、パネルディスカッションで語りました。 他にも、アジャイル関係のセッション多数です。ISO26262機能安全やAutomotiveSPICE、CMMI言った重厚感あるプロセス信奉者が元々多い界隈ですが、着実にアジャイルが広まっているのを感じます。 個人的ベストプレゼン アジャイルの全体を導入するのではなく、技術的なプラクティスの肝である、ユニットテストをどう導入したか、という岡本さんのプレゼンが、個人的なベストプレゼンです。リーダーとしての役割のなかで、できることを、周りに説明しながら、やった、そしてその効果を語るというもの。大上段にふりかぶらず、できることから始める。これがぼくが思う改善の、あるいはアジャイルのはじまりだと思うからです。 最後に 懇親会では、富山の食事とカラオケまで行き、永田さんとアジャイルと品質の話をまた再燃させました。林さんはじめ、実行委員のみなさん、八木さん（お久しぶり）、小松澤さん（お久しぶりにお会いできて嬉しかったです）、武田さん、水田さん（懇親会での自己紹介は感動的でした）、河野さん、清水さん、中山さん（これまたお久しぶり）、実行委員長の千田さん、本当にありがとうございました。

Read more "SPI Japan 2016 で基調講演しました"

Modern Agile JP

Modern Agileとは 初期のXP(Extreme Programming)賛同者、Joshua Kerievsky が世界最大のアジャイルカンファレンスである Agile2016 の基調講演において、モダンアジャイルというコンセプトを披露しました（→InfoQ記事）。 2001年に宣言されたアジャイルマニフェストが、15年を経ましたが、今の時点でアジャイルを再度考えてみよう、という命題です。http://modernagile.org より（超訳）… アジャイル宣言から10年、イノベーティブな企業、ソフトウェアの思想的リーダーたち、アジャイルとリーンの開拓者たちは、よりシンプルで、より強く、より合理化されたアジャイルを模索してきた。この「モダンアプローチ」は、「実験的な成果の創出」と、「優れたカルチャーの育成」に焦点をあてている。今日、伝統的なアジャイル定義をバイパスして、モダンアプローチを語ることには、十分意味があるだろう。 モダンアジャイルは、4つの原則で定義される。 Make people awesome Make safety a prerequisite Experiment and learn rapidly Deliver value continuously Google, Amazon, AirBnB, Etsy といった企業が、この4つの原理のよい見本だ。.. Modern Agileを日本語に訳そう 4つの原理を日本語にしました。ぼくはJoshから直接メールをもらい、日本語訳を頼まれて訳をしたのですが、これに興味を持って日本語に訳そうとしている人たちを、同時期にネットで3人発見しました。角征 典さん、今給黎 隆さん、伊藤宏幸さんです。短い4原則の訳ですが、せっかくなので4名で日本語訳を合意したいな、と考え、facebook groupで短いディスカッションの後、生まれたのがこの4つの日本語です。 人々を最高に輝かせる 安全を必須条件にする 高速に実験＆学習する 継続的に価値を届ける （角さんの提案で結果的にぴったり同じ長さの日本語になりました。） せっかくなので、このコンセプトについてのfacebook groupとして公開します。現代風のアジャイルの再定義に興味がある方、ぜひ参加してください。 モダンアジャイル日本語コミュニティ(facebook group) https://www.facebook.com/groups/modernagilejp/  これまでの記録 角征 典さんがGitHubで日本語版のpull requestを送る。 今給黎 隆さんのキースライドの訳資料（slideshare) 伊藤宏幸さんのAgile2016資料(slideshare p.41、これが今もっとも詳しい解説か?) 「安全」ということ […]

Read more "Modern Agile JP"

XP祭り 2016 私的まとめ

9/24土に早稲田大学で行われた「XP祭り」の私的まとめです。XP祭りは完全に有志駆動で、好きな人が、好きな風にあつまって、好きに発表する、年に一度のお祭りです。今年はぼくは発表しませんが、牛尾さんの基調講演と、永和システムマネジメントの新人教育のセッションを中心に感想とともにお伝えします。 仙人たちの漫才 恒例の小井土さんと福井さんによるアジャイル漫才です。XPの概要といいながら、動くコードを書くことの大切さやフロー（流れ化）について語っていました。 牛尾さんの「XPが日本のソフトウェア開発」 MSのVSTSの開発チームを見に行った話から。DevOps の形として L-team(Live=ライブサイトのメンテ) と F-team(Feature=新機能開発)の2チームに分けて、それぞれ長く滞在している人を交換している。というのが新しかったけれど、ほとんど他のプラクティスは「知っているもの」であり、ペアプロも含めて愚直にやっている。 「ウォーターフォール対アジャイル、そんな話は10年前。」 牛尾さんは日本の現状をほんとうに心配しているのだなぁ。海外を見に行ってDevOpsの高速デプロイ(10 deploys per day)を見たりして、「竹槍」と「戦闘機」くらいの違いだと。 また、Hofstede の文化ディメンションの話で、なぜAgileが日本に導入がむずかしいか、それは文化の違いだと。 （牛尾さんブログより：http://simplearchitect.hatenablog.com/entry/2016/05/30/080421） なので「文化をインストール」する、というのが日本で必要なんだということです。 さてさて、ぼくはこの点に関しては違う意見を持っていて、「文化」はインストールできないものだと思っています（「技術」やさらに「ビジネス」に比べても慣性モーメントが大きい）。だから、やり方は二つで、 逆に、日本人が海外へ飛び出してやる。 もしくは、日本の文化にあうやり方でアジャイルを使う だと思う。この話は、「リーン開発の本質」のMary Poppendieckにも登場しています。平鍋訳による解説のスライドを紹介します(24 page目くらいから)。以下、この中の数ページだけハイライトです。日本文化がいかに特殊かが分かる資料になっています。アジャイル宣言の「変化に対応」と「不確実性回避と長期指向」、「個人と対話」と「個人主義」を対応づけています。     ぼくは、日本の良さを生かした、アジャイルが作りたい、と思っています。（あるいは、もう少し若かったら海外に行ってしまうのもありだなぁ。） 牛尾さんは、他にも、社員の扱い方、雇用の流動性、などなど、海外と日本の違いをたくさん語ってくれました。最後に、日本のよさとして、物事のすすめかた、人との接し方、美的感覚などを挙げていたのもよかったです。 ※追記：牛尾さんの資料が公開されました。 XPが日本のソフトウェア開発の未来を実現する—Tsuyoshi Ushio https://docs.com/d/embed/D25192761-1370-1913-3430-000745383429%7eM30d2b3b9-dd1e-22b9-abac-56fd14e17722 お昼の野良LT 侍れっどが、どんどん進化するふりかえり（KPTATAH)について、てらひでさんが、ToCとふりかえりについて。とてもXP祭りらしい、自分の経験を語るLTでした。 俺たちの新人教育（永和システムマネジメント） 永和のアジャイル事業部からの発表です。伊藤（@koic）さんと 小林（@junk0612 ）さん。小林さんは新入社員で、鷲崎研究室出身なのです！（なんてXP祭り的な。。。）伊藤さんが先生として、小林さんが新入社員としてかかわった永和のアジャイル事業部的な教育の実話です。 支給する書籍、着席準備 新入社員の入社前の準備。。。書籍を渡します。 達人プログラマー エクストリームプログラミング リーダブルコード（持っていた！意識高い！） Webを支える技術 SQLドリル 必須図書です。着席準備（永和では「着席」という期間がある）として、Railsチュートリアルをやる。Javaをやっていたけど「Rubyって楽だなぁ。。public static void main(String[] args) … って書かなくていい。public/private 全部全部書かなくていいい。」と思ったそうです。dotfiles(.emacs .profile などの個人の設定ファイル)をGitHub管理することで学習状況を共有する、というのは知らなかったなぁ。 […]

Read more "XP祭り 2016 私的まとめ"

Enterprise Offshore Development Conference in KDDI

9/2 に飯田橋のKDDIさんで行われた、Enterprise Offshore Development Conference に参加しました。これは、ベトナムで出会った、日本からのオフショア開発をやっている佐々木さんと加藤さんと、「日本に帰ったら一度、ノウハウを共有する会をやろうね」という約束を交わしたのがきっかです（FPTさんでのカンファレンス）。 今回、佐々木さんが音頭を取って会の開催にこぎつけました。 「はじめてのオフショア、アジャイル開発」 平鍋の資料です。これは、実は2002年くらいに astah の開発を始めて2年くらいたったときの、オフショアでアジャイル開発をするお話です。 以下、当日資料に少しコメントを入れて読みやすくしています。 まとめると、 10年以上続いている、アジャイルオフショア事例です。 ツールは進歩しても、大事な変わらないもの（ソーシャルプラクティス）が多い。これらを中心にお話しました。 特に立ち上げ時はコミュニケーション（人を知る）が大事。部屋を一緒にする、ペアプロ、など期間を。知らない人とメールでコミュニケーションしない。 「ふりかえり」が超重要。分かれていても、KPTシートを交換するなど、本音の会話を。 開発方針や、全体絵、会社としての思い、などを最初に語ろう。 絵、UML、による仕様の「理解共有」(Shared Understanding)が大事。特にこの開発はUMLエディタなので、UMLメタモデルを議論しながら理解することが必須になりました。 技術的には、 各イテレーションについても、アプリケーションの性質上、モデル層は各リリース毎の先頭イテレーションにストーリーとしていています（スクラム的にはバックログの先頭の意味）。 UIのなめらかさや思考を止めないことを重視しているため、最後のイテレーションをすべて手動のストーリーテストにあてています。 テストを3層にわけて作っています。モデルテスト、コマンドテスト、ストーリーテスト。 当日は時間が混んでいて、私はすぐに会場を出てしまいましたが、佐々木さんと加藤さんのお話きけずにごめんなさい。 「爆速　オフショアに挑む」 IDOM（旧：ガリバーインターナショナル）加藤さんのプレゼン。200人月を3.5ヶ月でリリースしたというクルマコネクトの爆速開発事例です。 この発表では、FPTさんの部隊とともに開発しながら、ハノイからダナンへと拠点を移した話、コアとなるデータベース設計やAPI設計は日本で（加藤さんが）やった話、要件定義をキーメンバーを日本にやって固めた話、などが中心でした。  

Read more "Enterprise Offshore Development Conference in KDDI"

Visiting Ikujiro Nonaka, Grandfather of Scrum

I visited Prof. Ikujiro Nonaka, the grandfather of Scrum yesterday.  Since I co-authored with him “Agile and Scrum” two years ago, we have been enjoying opportunities of discussion occasionally. 野中先生を一橋に訪ねました。先生との共著（左）「アジャイル開発とスクラム」を書いてから２年経ちましたが、81歳とは思えないエネルギーと思考力です。今回は、今先生が書いている、ソーシャルイノベーションの書籍のアイディアを交換するものです。継続的イノベーションを起こす組織とSECI モデル、スクラムの関係を解く内容になるということです。 He was very energetic at his age of eighty one(!), and invited me to his office at Hitotsubashi University to discuss the idea of […]

Read more "Visiting Ikujiro Nonaka, Grandfather of Scrum"

「ソフトウェア技術者サミット in 福井 2016」に参加してきた

福井に集うアーキテクト/プログラマーたち 「ソフトウェア技術者サミット in 福井 2016」に参加してきました。今回は、福井コンピュータの小島さん(@fujiwo)の呼びかけで、鈴木雄介(@yusuke_arclamp)さん、福井さん(@afukui)、小井土さん(@koido1961)、という現在の名だたるソフトウェアアーキテクト、プログラマーの方々が福井大学に集まりました。加えて、中西さん(ぼくも活用している音楽共有創作アプリのmelocyを創っている)と鈴木孝明さん（Microsoft MVP）。いや〜、これは小島さんのお手柄ですね、こんな会が福井で開催できるとは！（以下の写真は小島さんによる） 鈴木さんのAgile/Cloud/DevOps/MSA 鈴木雄介さんの話は、アジャイルを起点に、現在起きているクラウド、DevOps、Microservices Architecture の話を俯瞰したもので、とても分かりやすいものでした。 ぼくも以前、「逆コーンウェイ戦略とDevOps, Microservices, Agile」というエントリを書いていて、まさに、アジャイルが持っている「チーム構成戦略」がマイクロサービスアーキテクチャに出会って、組織実装されるものが、DevOps という話を、楽天の川口さんの受け売りでやっています。つまり、ビジネス要請が強ければ、フィーチャーチーム（機能チーム）を作った方がコンポーネントチームを作るよりうまくいく（組織戦略）。それを実装するするのがMicroservices Architecture（アーキテクチャ戦略）。という話です（→こちら）。 TDDデモ（平鍋+小島） 学生さんも多いということで、ぼくはあまりコンセプト的な話はせずに、小島さんとペアプロライブをやりました。TDD （テスト駆動開発）は、実際にやってみる（のを見る）のが一番です。 とてもいい写真 (@jun1sさん、小島さんありがとう！)。この写真でわかるように、やること（テストExample）をリストにして、コーディングしながらできたら１つずつ、クロスアウトしていきます。 教室でやる、と聞いていたので、小島さんとは、 「黒板にやることリストを書いて、それを消して行くので、ハイタッチしましょう」 という打ち合わせをしておきました。 スタックを作る. 作ったらisEmpty push(1)したら、isEmptyでない push(2)したら top が 2 実は、ここまでなら、内部に配列のような実装を持たずに(値1つで)実装できます。そして、ここまでそのように実装するのです! そして5番目に push(3),  push(4), pop したら top が3 というテスト（仕様Example）を書いてはじめて、Stack らしい実装が現れます。 IDE(VS)の電球マークをうまく使って示唆を得ています。テストを先に書くので、コンパイルが通らず、今ないクラスは作る？ときいてくれます。また、会場にも電球（福井さんと小井土さん）がいたので、その都度ツッコミを入れてくれて助かりました。 あと、変数名やコードのダブリなど、気持ち悪いことがあったらその都度リファクタリングをしますが、結構小島さんのこだわりが分かって楽しかった。小さいことですが、private メンバ変数の size を index と名前変更したときに、「一つずれます」と言いましたが、後で考えると僕が間違っていて同じになりますね。(array<T>[n] が次にpushする位置の要素の時、現在のsize も n) 当日の資料はこちらです。 まとめ 平鍋なりにまとめたマインドマップ(astah)です。 一番よかったのは、福井さんのプログラミングへの愛が聞けたこと！年齢よりなにより、エンジニアとしてのAPIに対するLoveを感じて、とっても勇気をもらいました。これは、melocy を創っている中西さんのプレゼンにも、そして、C#のライブコーディングをしくれた鈴木さんにも感じたことですが、パッションで人はつながっている、ということを信じられた一日でした。 […]

Read more "「ソフトウェア技術者サミット in 福井 2016」に参加してきた"

Thank you Agile Japan 2016

アジャイルジャパン 2016 今年のテーマは、「あなたとつくるアジャイル」。私は今回は運営にはほとんどタッチせず（実行委員、運営、ボランティアのみなさんありがとう）、基調講演の Joe Justice さんの翻訳と、自分の１つのセッションに専念しました。 初参加の方も結構いらっしゃたようです。初参加とリピーターが50/50になると、いい循環の会になると思っています（アジャイルジャパンの歴史を知りたい方は、これまでアジャイルジャパンの活動、とくに海外スピーカーとの交流について、InfoQの記事です。） 「日本のアジャイルに、何が起きていたのか、何が起きているのか」 Linda Rising visited Japan and talked about “Fearless Change” – a report from Agile Japan 2011 基調講演 スクラムがイノベーションを加速する 〜ソフトウェア以外にも適用されはじめたアジャイル〜 ソフト以外へ、ということで、ワイナリーでスパークリングワインを作るスクラムチーム、農業用の重機の開発でスクラムを取り入れるチーム、車体を分割してスクラムチームで開発する話、戦闘機を作るチーム、教育をスクラムで変える話、、、本当にたくさんの「ソフト」でもなく「ハード」でもなく、人間の関る活動をスクラムで変える話でした。冒頭に、 火星に人間が住めるようにする、というプロジェクトをやっているチームがある。これは、ハードウェアかい？ソフトウェアかい？ という質問があって、考えさせられた。何かの目標があり、それを達成する手段がハードやソフトなわけで、チームで何かを達成したい、という活動そのものに、スクラムを使って行こうという活動なのだ。 講演は、ほんと、Joeが関ったすごい例ばかりで、圧倒されてしまいました。昨年の基調講演の横塚さんも、「これはいろんなところで話してもらったら、日本が変わるきっかけになる」とコメントもらいました。 Joe の TEDx での講演ビデオはここから見れます。(Awesome Joe) ぼくはいつもの逐次通訳で、なんとかJoeの速度を落とさせないようにしながら、意図を伝えるよう、（二日酔いの中で…^^）がんばりました。実は去年あたりから、通訳がないくてよい（ない方がたくさん内容が聞けて良い）という意見をもらっていて、どうしようか迷ったのですが、サテライトの人も見やすいようにお願いします、ということになって今回は逐次訳を入れました。直後にアンケートをとってみましたが、「あってよかった」という方が7割で、やってよかったです。 「アジャイルは本当に日本のソフトウェア開発を変えることができるか」 さて、いつもは話をしないのですが、今回ははじめて、自分のトークをやってみました。 今まで、「アジャイル」という言葉を出さずにアジャイルの「魂」の部分を表現してきたのが、いま、とてもふつうにアジャイルの話を聞いてもらえてうれしい、ということ。また、ぼくが新しく永和の社長になったことで、全社員にアジャイルの話をした、という話と、永和の社是がすごく、アジャイル宣言に近いという話もしました。そして、ブラジルの CI&Tの話は、日本が忘れた何か、を思い出させてくれる、という意味で、Kent Beckのシャンペンボトルのコルクは、ここにあったという話。(上記スライド、一部日本語が欠けていますが、原因が分からないので、細部に興味があれば、こちらと合わせてみてもらえればと思います。) 「アジャイルの魂〜チームでお客様に価値を届けよう（永和、4/1 入社式での話）」 ちょっと懐かしく感じる話です。咳さんからも、PFの話が懐かしくて、自分の昔の活動のスライドを見てみたら、10年くらい時間が止まっていた、というコメントをもらいましたし、参加者の方から、こんなレポートをもらって、嬉しかったです。「AgileJapan に参加してきた」 （ありがとー！） また、講演の前に、昔集めた認定スクラムマスターの世界各国の人数を、ScrumAllianceに再度調査依頼しました。返答があったが前日だったのでなんとか間に合いました！（まだまだ、日本は少ないようです。）下のグラフは、上記のスライドp60を実際に畳み込まずに表示下グラフで、左が2013, 右が2016です。赤い部分（PO）の伸び、また、アメリカとインドの伸びがはっきり分かりますね。 他の講演 ほとんど聞けなかったのですが、、時間をみつけて、いくつか、ここに書いていきます。（TODO) 最後に 参加者のみなさん、スポンサーのみなさん、ボランティアのみなさん、そして、実行委員と運営のみなさん、本当にありがとうございました！！来年またお会いしましょう。ぜひ、みなさんの実践の気づきを持って来てください。共有したいです。 今年は、大企業の、中間管理職層の方もかなり出て来て頂いたり、エンタープライズアジャイル、という言葉も出て来て、いよいよ、アジャイルが「普通の開発」になった感じが強くしました。 でも、やっぱりソフトウェア開発は簡単なものではなくてですね、方法論とか問わず、もともと昔から簡単なものなどなくて、ですね、日々、工夫な訳です。当たり前なんです。そこを「よりよく」しようという活動がアジャイル、と私は捉えています。Do Agileでなく、Be […]

Read more "Thank you Agile Japan 2016"

逆コーンウェイ戦略とDevOps, Microservices, Agile

コーンウェイの法則 「コーンウェイの法則」というのを知ってますか？Jim Conplien の組織プロセスパターンにも登場しますが、”組織の構造がソフトウェアの構造に反映する“あるいはその逆、“ソフトウェアの構造が組織の構造に反映する”というものです。Wikipedia によると、 Conway’s law is an adage named after computer programmer Melvin Conway, … “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations” — M. Conway 分かりやすくたとえが、「４つのチームでコンパイラを作成すると、4 pass コンパイラになる」 という言い方で知られています。（どちらかというと、ソフトウェアの構造が組織の壁によって悪いアーキテクチャを生み出す、というような意味合いが多い） 逆コーンウェイ戦略 少し前の ThoughtWorks のテクノロジーレーダーに、逆コーンウェイ（“Inverse Conway Maneuver” ）というのがあり、気になっていましたのでちょっと調べてみました。 コーンウェイの法則が、「観察結果」に対しての「こうなっちゃいます」というパターンとして言語化されているのに対して、逆コーンウェイは、「積極的に組織とコミュニケーションを設計しよう」というのです。観察でなく、積極的に。Maneuver、すなわち設計戦略なのだと。Maneuver は軍事用語で「作戦行動」なので、戦略的に組織を変えて transformation して行く、という意味合いがあります。 “The ‘Inverse Conway […]

Read more "逆コーンウェイ戦略とDevOps, Microservices, Agile"