arclamp

ITアーキテクト 鈴木雄介のブログ

フェアユースは認められたが、Googleは対価を支払うべき - Java API訴訟に寄せて

ようやく裁判の結果が出ました。結果としてフェアユースが認められたのはよかったのですが、Googleが勝訴したということは素直に喜べないので、その理由を書いておきます。

関連ニュースは、こういったところから。
約1兆円の賠償金を巡るGoogleとOracleの10年にわたる訴訟が決着、「APIのコピー」は結局違法なのか? - GIGAZINE
Google、オラクルの著作権侵害せず 米最高裁判決: 日本経済新聞
グーグル、米最高裁でオラクルに勝訴--「Android」Javaコード訴訟で - CNET Japan

経緯

では、経緯について時系列に沿って整理していきます。推定可能な事実に基づきますが、一部、妄想も含まれています。

2005年
Google(広告収入増やすには無償で改変自由なスマホOSが重要になるはず。普及させるなら開発者の多いJavaベースだよな。でも、クラスライブラリ改変しないとダメだな...)

IBM「AL2なJDKとしてApache Harmonyをみんなで一緒に作ろう!大きくなりすぎたJDKをモジュール化するんだ」 ※AL2:改変部分の公開義務なし

Google(お、いいじゃん。採用したいな)

2007年
ASF「完成したから 標準互換認定してよ」
Sun「ダメ。使用分野にモバイルOSがあるけど、それは規定違反(ややこじつけ)」
ASF「なんやと、こら。公開質問状だ!SunはJavaのエコシステムを阻害している!」

Google(なんか揉めてる...。標準互換認定は取ったほうがいいけどな...)

ジョブス「iPhoneでるよー」

Sun「Sunが保有するJDKをGPLv2でOSSにしたよ。OpenJDK!」※改変部分の公開義務あり
ASF「ぐぬぬ

2008年
GoogleAndroid公開!好きに使ってね、Javaで書けるよ」
Sun「それJavaの亜種でしょ!そういうの良くないよ(あ、会社が潰れそう...)」

2010年
Oracle「Sun買った。でも、モバイルのライセンス収入、少なっ。AppleGoogleのせいだ...。なんとか訴えたいな...おや、Androidのコードが怪しいぞ!」 ※妄想

2011年
IBM「みんなでOpenJDKにしよ。Harmony中止(しれっ」

2012年
一審「API著作権はない(≒Google勝訴)」

2014年
二審「API著作権はある(≒Google敗訴)」

2016年
GoogleAndroidもOpenJDKに対応したよ」

2018年
控訴審フェアユースではない(≒Google敗訴)」

2021年
最高裁フェアユースです(≒Google勝訴)」

解説

訴えた内容は言いがかりに近い

裁判でOracleGoogleが訴えたのは「AndroidOracle(当時Sun)が保有するJava(クラスライブラリ)のコードが流用されている」というものです。
AndroidJavaを利用していますが、そもそも、Sunが保有していたコードを流用したのではなく、Apache Harmonyという別のコードを利用しています。なので、流用したとされる量も微々たるものです。

  • APIの中の本体コードが9行(メソッドはrangeCheck)
  • APIが37個(APIのメソッド名やパラメタであり、中身ではない)

本体コードはわずか9行で「rangeCheckじゃ、そう書くわな」というもので、裁判でもあまりに対象が小さいため棄却されています。残ったのがAPIの37個。ただ、Android全体のコード量からして37個がなんなの、というのが正直な感想です。なので、ほぼ言いがかりです。

APIフェアユースが認められたのはよかった

とはいえ、Googleが敗訴する可能性もありました。米国の裁判では巨大企業が懲罰的に賠償金を支払うことがあるためです。ただ、裁判の結果としてはフェアユースが認められました。

APIというのは、あえて真似して互換性があるコードを作ることがあります。裁判中も「Oracleだって、Amazon S3API互換な製品を販売している」といわれていました。ユーザーからするとAPIが同じであればコードの書き換えコストなく製品を乗り換えできます。APIにおいてフェアユースが認められないとなると、結果的にプラットフォーマーの独占を強化し、ユーザーに負担を強いることになります。

そもそも、当時のJavaが「標準APIをみんなでオープンに決めて、各社がクローズに実装する」という考え方です。これによってJavaは多くのユーザーを獲得しました。この際「標準への互換性を維持する」のが、Javaの非常に重要なポリシーとなります。

こうして考えるとフェアユースが認められたのはソフトウェア業界全体にとってよかったのです。ただ、その付随としてGoogleが勝訴したことについては想うところがあります。

オープンソースライセンスとJava

まず、AndroidのベースとなったApache HarmonyとOpenJDKの違いを整理します。

前述通り、Javaは「標準仕様をみんなでオープンに決めて、各社がクローズに実装する」という考え方ですが、バージョンを重ねるごとにコードが肥大化しており、各社にとって負担になっていました。そこでApache Harmony

  • 実装もオープンソース化して共有資産にする
  • モジュール化を可能にし、必要な部分だけで構成できるようにする

というコンセプトでスタートしました。これはオープンソースベースの商用製品では重要な考え方で、現在のOpenJDKも同じです。ただし、ソフトウェアライセンスが違います。

Apache HarmonyはAL2(Apache License 2.0)で「改変部分の公開義務がない」、OpenJDKはGPLv2で「改変部分に公開義務がある」というライセンスです。

Java自身がサーバサイドで大きく発展したのはTomcatStrutsといったAL2で開発されたOSSの存在を抜きにしては語れません。無償利用できたことも重要ですが、それらが改変や流用され商用製品の一部となっていたのです。

ただしAL2には「OSS本体にコードが還元されない」という問題があります。近年でもAWSOSSをカスタマイズして儲けていることに対してOSSコミュニティが反発し、ライセンス規定を変える動きがありました。このようにOSSを土台にして金儲けをしたらOSSに還元する、というのは大企業のたしなみとして重要です。
Redis、MongoDB、Kafkaらが相次いで商用サービスを制限するライセンス変更。AWSなどクラウドベンダによる「オープンソースのいいとこ取り」に反発 - Publickey

Sunは、JDKオープンソース化にあたりGPLv2を選択しました。GPLv2では改変したコードをOSS本体にコントリビュートすることになります。こうすることで本当に1つのコードが共有されるのです。LinuxもGPLv2ですね。

現状のOpenJDKは、GPLv2になったことで開発リソースが集約され、機能開発が半年サイクルで行われています。そこにはOracleだけではなく、RedhatIBMMicrosoftAWSGoogleなどの多くの企業が参加しています。こんな言語は他にありません。結論から見れば、Javaのような基盤製品にはGPLv2が望ましいのでしょう。

ちなみにAndroidはAL2です。Android初期に「メーカーによる改変が大きすぎて本体のアップデートについていけない」とか「メーカーごとの非互換が強すぎてアプリが動かない」と言った混乱がありました。現在はGoogleの努力もあって、少しはマシになっていますが、それを見ているとAL2が必ずしも正しい選択ではないことがわかります。ま、当時の携帯メーカーの文化や力関係を考えるとGPLv2では受け入れられなかったとは思いますが...。

時代の流れで生まれたAndroidの幸運と問題

というわけで、AL2かGPLv2か、というのは非常に重要な議論です。この大激論が闘わされている最中に、GoogleApache HarmonyをベースにAndroidを作ってしまいました。Apache HarmonyはAL2として公開されていたわけで、それを流用してAndroidを作ってもライセンス的には問題ありません。

しかし、Javaというのは「標準への互換性を維持する」ということについて各社が非常に大きな努力を払ってきました。IBMなど各社がAL2でオープンソース化しようとしたのは「標準の範囲内で自由度を増す」ための取り組みであって、標準を無視して亜種を作ることを目指したわけではありません。

それなのにGoogleは、Javaの「標準への互換性を維持する」という取り組みを無視し、勝手に亜種を作ってしまったのです(経緯もある通り、2016年にはAndroidもOpenJDKベースになっています)。

とはいえ、Googleも無視したくて無視したわけではないと思います。裁判資料の中でもAndroidの父、Andy Rubin氏が「標準互換認定を得るべきだ」というメモを書いていたことがわかっています。タイミングの問題は大きいと思います。AppleiPhoneを発表しており、急いでAndroidを作り上げる必要があった中で、AL2かGPLv2かという議論に付き合っている暇はありません。

結果論としては、この判断はJavaにとっても、スマホユーザーにとっても良かったのでしょう。Javaは開発者を増やし、iOSよりも安いスマホが作られました。

時代の流れの中で、Googleは幸運にもタイミングよくタダで自由に改変できるJavaのコードを入手しました。しかし、その時代の流れはJavaのエコシステムをよくしようとした企業やコミュニティの努力の成果によって生まれたものです。その成果を使い、しかも標準への互換性を無視し、利益を得たGoogleは批判されるべきです。

フェアユースは認められたが、Googleは対価を支払うべき

2016年にOracleが提出した裁判資料によれば、GoogleAndroidによって420億ドルもの広告収入を得たと試算されています。ここにはJavaが必要だったのでしょうし、Javaオープンソース化について貢献した企業やコミュニティの努力が含まれています。それを無視してGoogleの勝訴を喜ぶ気にはなれません。

というわけで、僕としては「APIの流用についてフェアユースは認められてよかったがGoogleは相応の対価を支払うべきだ」という感情になります。ただ、その対価はOracleに払うというよりは、なんらかの形でOSSコミュニティに貢献をするのが望ましいでしょう。支払わなくて済んだお金を、なにか良い形で使ってもらいたいですね。Googleは、それができる企業だと信じています。

ここまでOracleの話をしていませんでした。10年前に訴えたこと自体はどうかと思いますが、OpenJDKの現状を見るに、OracleJavaというOSSOSSコミュニティにきちんと貢献をしています。その点は、ちゃんと評価したいと思います。

JJUG CCC Fall 2020をオンラインで開催しました

ちょっと時間が経ってしまいましたが、2020/11/7にJJUG CCC 2020 Fallをオンラインで開催しました。オンラインでのイベント開催は、まだ世の中にもノウハウがないと思うので公開報告です。

JJUG CCC 2020 Fall 会場タイムラプス

概要

セッションスケジュールはこちら。3トラック26セッション(10:00 - 18:50)と、事務局が配信するアンカンファレンスが1トラックで、計4トラックです。通算の参加者は600名程度で、通じての参加は300名程度でした。

f:id:arclamp:20201201104210p:plain
セッションスケジュール

セッションは事前録画の動画(40分)とし、ライブ感を出すために動画配信後はZoom経由で講演者がQA(10分)に答えるようしました。また、講演者は配信中に録画をみながらチャットに参加したり、Twitterで返信したり、わりと自由に過ごしてもらいました。事前録画の負荷はありますが、当日は気楽に参加してもらえますし、その点はよいのかなと思います。また、配信事故があった場合にも10分遅延で配信するといった対応がコントロールできるので、その点もよかったです(事故がないのが一番ですが)。

f:id:arclamp:20201201172221p:plain
セッションの配信画面

アンカンファレンスは1枠しか埋まらなかったため、それ以外の時間は「どこかのセッションをみながら副音声で説明や雑談をする」というゆるい企画になりました。これは意図していたというよりも、枠を管理していたリーダー @cero_t のキャラもあったのかなと思います。途中でコンビニ買い出しに行ったり、こちらも自由に過ごしています。ただ、この枠が「コミュニティ感がある」と評価をいただいたように思います。

システム

オンライン配信にはテイラーワークスを採用しました。オンラインセミナーのシステムはたくさんありますが、コミュニティ向けに成長させていきたいというコンセプトにも共感したことと、JJUG用にカスタマイズをしてくれるということで採用しました。ただ、朝イチのピークで障害が発生するなど、参加者の皆様にはご迷惑おかけしました。開発元とは原因と今後の対策を確認していますので、次回は大丈夫だと思います。

セッション管理にはConfengineを使いました。CfPの募集、選考、結果公開、スケジュール作成まで対応してくれます。JJUG CCCは公募で成り立っているため、公募と、その選定というのが一番手間がかかります。これはオンライン開催とは関係なく試してみたいツールだったのて、利用しています。決してUIが良いとは言えないのですが、手間は軽減できました。次回も使うかは悩みますが、実際、ある程度の規模だと、こういうものに頼るしかないと思います。

当日の体制

配信会場としてグロースエクスパートナーズ株式会社のG's LounGeを無償で借りました(ステマ)。まず、セッショントラックについては3つのブースに配信機材とオペレーター、司会を配置しています。機材はレンタルしており、オペレーターとディレクターは専門業者の方です。講演者は全員自宅からZoomに参加してもらっています。トラック別にZoomアカウントがあり、配信中は動画を流しますが、司会進行やQAになったらZoomからの配信にスイッチする形になります。

f:id:arclamp:20201201141033p:plain
セッショントラックの配信ブース

アンカファレンスは配信会場内にブースを設置し、そこからZoomで配信を行っています。このZoomには自由に参加することができ、直接、コミュニケーションをします。最大100人の制約はありますが、実際には20-40人の方が参加されていました。このZoomへの参加リンクをSNSで共有したため、Zoom-Bombingが発生してしまいました。この点は深く反省しております。
配信機材はG's LounGeの据え置きのものを借りています。スピーカーの手元のPC画面のスクリーン映像と、配信カメラで撮影している複数名のスピーカーの映像をPinPで合成し、音声はマイクから拾ったもの使って配信用PCからZoomに流しています。スピーカーは、配信用PCの映像をモニターでみています。

f:id:arclamp:20201201181707p:plain
アンカファレンスの配信ブース

費用

みなさんが気になる費用です。事務局依頼費ですが、JJUG CCCではスポンサーとのやりとりや事前準備をアウトソースしており、幹事はコンテンツの選定に集中するようにしています。ちなみにスポンサー収入は350万円なので、その他の雑費を含めるとトントンということになりました。

項目 費用 備考
各システム利用料 50万円 テイラーワークス/Confengine/Zoom等
配信機材 170万円 セッションの配信機材&スタッフ&設置等
事務局依頼費 100万円 スポンサー対応、準備等

合計:330万円

物理開催の場合、50セッション程度、1000人参加で実施していますが、会場のレンタル費用が300万円、それに懇親会、無線LAN、Tシャツ、託児、事務局費などをいれると、650万円ぐらいになります。また、ボランティアスタッフを30名程度お願いしていましたが、オンライン開催では0名にしています。


さいごに

まず、初のオンライン開催に参加いただいたみなさま、事前録画していただいた講演者のみなさま、支援いただいたスポンサー各社さまには心から感謝です。まずは「オンライン開催して、すべてのセッションが実施できた」ということは成果としつつ、やはり、もっとセッションを盛り上げるため仕掛け、スポンサーにメリットがある取り組みをしないといけません。また、幹事会側としても、もっと効率化したいとか、情報共有の方法を変えないといけないとか、色々と反省がありました。いずれも次回の開催で対応していきたいと思います。

次回は2021年の5月あたりを予定しています。また、参加いただけたら、とても嬉しいです。

やるべきことをやる、壁を越える #devsumi 2020

久しぶりのデブサミで、世界最高の靴売場をシューカウンセラーとともにデジタル変革してみた という講演をしました。

ともにつくる

2019/10から三越伊勢丹グループの(株)アイムデジタルラボで取締役(Graatとは兼務)として仕事をしています。会社設立&取締役就任のきっかけであったプロダクト(YourFIT 365)が落ち着いてきたので、その成果の発表場所を探していました。

そんなとき、デブサミ2020のテーマが「ともにつくる」であることを知り、これはぴったりと応募したところ選出いただきました。講演の機会を与えてもらってありがたかったです。しかも、A会場って。

f:id:arclamp:20200219174219j:plain
会場の様子

資料を作る過程では「ともにつくる」というキーワードを伝えながら関係者にヒヤリングをしました。その話を整理して4つの「ともにつくる」を紹介できました。

  • 当事者と、ともにつくる
  • お客様と、ともにつくる
  • アナログと、ともにつくる
  • 既存組織と、ともにつくる

どれも大事なのですが、後半の2つはエンタープライズ領域のDX案件ならでは、かと思います。講演では話しきれなかったところを補足させてください。

アナログと、ともにつくる

三越伊勢丹というか百貨店そのものが斜陽産業であり、生産性の低いアナログの塊のように見られていると思います。たしかに、そういう側面もありますが、良い商品を良い形で買っていただく、ということには深い想いがあり、ECで得難いものもあります。
その代表が伊勢丹新宿本店の靴売場です。昔からフィッティングサービスに取り組んでいただけではなく、浅草の靴職人さん達とも深い関係にあり、プライベートブランドの靴を作ってたりします。Perfume ダンスヒールとかが有名ですかね。

だからこそ、「アナログがあるからデジタルが活きるし、デジタルがあるからアナログが伸びる」ということが実現できたのだと思います。ビジネス現場とエンジニアが一緒にプロダクトを育てる、という感覚が得られたのは良い経験となりました。

既存組織と、ともにつくる

システム開発をする上では、既存の基幹システムとの連携は必須でした。これが実現できたのは基幹システムとのブリッジをするAPIゲートウェイのチームのおかげです。彼らは数年前からフロントシステム向けのAPI基盤整備に取り組んでおり、いろいろな苦労をしながら仕組みを作り上げてきていました。
今回の案件では、既存のAPIの活用だけではなく、新たにデータを引っ張ってきてAPIを作るなど、幅広く対応してくれました。
また、初物のクラウドサービスを使う点も、セキュリティやガバナンスのチェックなど、様々な面で相談にのってくれ、結局「〇〇委員会の申請書」みたいなものはほとんど彼らが通してくれました。

もちろん、既存組織のしがらみというものは厳然とあるものの、それをどうやって変えていくのか、超えていくのか、ということを一緒に真剣に取り組んでくれたことは感謝しかありません。彼らも立派な当事者です。

やるべきことをやる

このプロダクトの成功は経営層、マネージャー、現場、開発チーム、その他多くの関係者一同が、それぞれにコミットしてくれた結果です。ただ、そのコミットは最初からあったわけではありません。

「なぜ、この案件が成功したのか?」と聞かれれば、「地力があった」のは前提ではありますが、その地力を引き出して成功するように、やるべきことをやったからなのです。
この裏には、山のように「失敗プロジェクトあるある」な要素があり、それが見つかるたびに各所の掛け合い、(裏技も含め)様々な手段を使って対応してきました。その度に奔走いただいた方々に大変感謝しています。

壁を超える

エンタープライズ案件の素晴らしいところは地力があるところです。大量の既存資産、優秀な人材、大きな市場。それを利用すればレバレッジが効きます。

エンタープライズ案件で壁になるのは変化を嫌うところです。非効率な意思決定ルート、無意味な規則、組織間の不整合、よくわからない忖度。それらに絡めとられると生産性が激減します。

だから、壁に当たりそうなときは「プロダクトにとって良いことはなにか?」ということに素直に向き合い、あるべき姿を実現すべく壁を超えるように働きかけるのです。

「それが日本企業のダメなところだ」という意見があることもわかります。でも、僕は、壁を越える方が、より大きく世の中を変えられると考えています。小さなプロダクトあったとしても、多くの人に届く可能性が高いからです。

YourFIT 365は靴のフィッティングサービスです。たかが靴、されど靴。お孫さんの結婚式に久しぶりに履くパンプスを見つけてくれた。わざわざ地方から合う靴がなくて悩んでいた方が来てくれた。クリスマスに奥様にプレゼンとしてくれた。パンプスが嫌いだった就活生が素敵な靴を見つけれた。そんなサービスです。

なにをしていくのか

さて、手元には数千件(年内には1万超)の足形データがあります。医療やスポーツ目的以外ということであれば日本最大規模でしょう。これが何に使えるのか、実は僕たちにもわかっていません。いろいろな試行錯誤をしながらプロダクトを成長させます。

そして、この取り組みを他の売場にも広めるべく、活動を開始しています。現場と一緒に顧客特性や商品特性と向きあい、新しいプロダクトを生み出していきます。

さらに、「ともにつくる」DXを積み重ねることが、日本全体でDXが越えるべき壁を低くしていくと信じています。そのために事例はどんどんオープンにしていきます。なにかあればtwitterなどで連絡をください。


最後になりますが、こういうのに興味がある!という人は、アイムデジタルラボに参加しませんか?エンジニアだけではなく、プロダクトオーナー支援やデザイナーなど幅広いキャリアの方を歓迎します(いまはエンジニア枠しかないですが、近々に増えます。それまで待てない方はエンジニア枠を利用して応募ください)。
www.wantedly.com

2040年問題とITエンジニア - DevLOVE Xに寄せて

エモいことで有名なDevLOVEの10周年記念イベントDevLOVE X 〜 それぞれの10年、これからの10年 〜で「エンタープライズアーキテクチャアジャイルのこれから」という講演をしてきました。資料は以下。

Togetter - #DevLOVEX 鈴木 雄介「エンタープライズ、アーキテクチャ、アジャイルのこれから」 #DevLOVEXC Day2-7C

10年間の振り返り

10年間の振り返りとして10年前に書いた記事や講演資料をみたのですが、わりと一貫していて安心しました。たとえばクラウドを超えた先の企業システム像 20091008 JJUG CCC では、

・インターフェースによる分業
  ーマルチパラダイム
   ・個々のシチュエーションでは1つの最適な道具(パラダイム

って、まさにマイクロサービスのことだし。日経SYSTEMS 2009年2月号の特集1「10年後も通用するスキル」では、(都合良く考えると)DevOps、アジャイル開発、マルチクラウドのようなことを示唆しています(手元の最終提出原稿なので、掲載原稿ではありません)。

クラウド・プラットフォームは,サーバーリソース,サービス管理機能,それらのスケーラビリティや安定性など,サービス提供に必要な機能や機構を提供するものだ。ITエンジニアはクラウド・プラットフォーム上で開発を行うことで、簡単にサービスを提供できるようになる。
<中略>
 10年後のITエンジニアは,このクラウド・プラットフォームを利用したり,他人が開発したサービスを組み合わたりして,ユーザーの求めるサービスを作っていくようになると筆者は考える。
 ではそのとき,ITエンジニアに必要なスキルはどう変わるのか。筆者は,ITエンジニアにとって重要な「問題発見」「課題解決」の二つのスキルが大きく変わってくると予測する(図2)。
 例えば問題発見スキル。現在のシステム開発では,高品質・高性能を追求するのが一般的だ。しかし,インターネット上の複数のモジュールを組み合わせるサービス開発では,そもそも品質や性能を一定に保つことが難しい。ユーザーの抱える問題を的確に発見し,ユーザーの求める品質や性能のレベルがどのあたりにあるのか,確かめることが重要になる。
 作るべきものを決めて手順通りに作業を進めるという課題解決スキルも変わってくる。短いサイクルでサービスを提供しているとユーザーから頻繁にフィードバックがある。よいサービスを提供するためには、常に改善をしていかなくてはいけない。こういった場合に発生する多数の課題について優先度を付けながら解決をしていかなくてはいけない。

2040年問題

さて、未来のことを考えるのに、わりと確定した未来として2040年問題を取り上げました。2040年は団塊ジュニア世代が高齢者(65歳)になる年で、高齢者数が最も多くなると予測されています。総人口は減少傾向なので、社会保障の維持、労働力の減少、地方の低密度化など、様々な社会問題が指摘されています。僕は1975年生まれなので、まさに2040年には65歳になるという世代です(参考:pdf 今後の社会保障改革についてー2040年を見据えてー)。

この解決にむけた提言に多く含まれるのがIT活用です。社会保障は原資が生産年齢人口で確定されるため、配分の最適化がポイントです。このためには正確なデータ収集が重要です。たとえばオンライン資格確認という取組みはマイナンバーカードを健康保険証代わり(2021年度5月開始予定)にするものですが、これによって薬剤情報、医療費情報、特定健診データを正確に収集できるようになります(参考:PDF オンライン資格確認等システムの検討状況)。

また、そもそも健康維持が一番よいわけで、病気の兆候を早期発見するためにAI導入やセンサー導入といったことも必要です。さらに介護業務や保育業務の効率化といったことも含まれます(参考:PDF 社会保障ワーキング・グループの会議資料 参考 医療・福祉サービス改革

ITエンジニアのすべきこと

こうした取組みの阻害になると思うのは、いま社会を支えている企業におけるIT活用センスのなさです。残念ながらITを個別の道具としてしかとらえておらず、社会全体の良い方向にむけるITサービスを実現する、といった視点に欠けます。

2040年というと20年後です。20年後に問題が解決されているには、どう遅くても10年ぐらいで、この視点を持ってもらわないといけない。われわれITエンジニアこそ、こうしたセンスを磨き、古臭い企業の論理に屈することなく、現場でより良いサービスの実現に寄与すべきです。

幸い、多くの企業では問題に気づきつつありますし、現場にいる非IT人材も優秀です。デジタルトランスフォーメション(DX)というのが、それを象徴する言葉です。これをバズワードにしないようにしないといけません。

最近、僕が提言しているようなのは以下のようなことです。

小さいことを積み重ねる

エモい名言で有名なイチローが2004年にNBA年間最多安打を更新した時の言葉です。

いま、小さなことを多く積み重ねることが、とんでもないところへ行くただひとつの道なんだなというふうに感じています

2040年問題が解決した未来は「とんでないないところ」でしょう。そこに至るのは簡単ではありません。では、何をすべきかといえば「いま、小さなことを多く積み重ねる」しないのです。個別の現場で、より良いと思えることを1つでも積み重ねる。そういう積み重ねでしか世の中は変わらないと思います。

さあ、個別の現場で頑張りましょう!そして、色々な形で交流していきましょう。ぜひ、気軽に声をかけてください。

Graat始めました。

本日2018年11月1日、Graatグラーツ)を設立し、代表取締役社長に就任しました。社名はグロース・アーキテクチャ&チームス株式会社です。

f:id:arclamp:20181101121825p:plain

これまでの活動とは特に変わらず、アーキテクチャ設計やエンタープライズアジャイル開発周りの仕事をしていきます。設立1日目の想いを記事にしてありますので、ご興味のある方はどうぞ。

www.graat.co.jp

このブログも個人のエントリとしては書いていきますが、会社のブログのほうがまめに書くようになるはずです...。引き続き、よろしくお願いいたします。

エンタープライズアジャイルとNoOpsとマイクロサービス

最近、以下の2つの講演をしました(資料は記事末に貼っておきます)。

エンタープライズアジャイルでチームが超えるべきこと」(2018/10/17) エンタープライズアジャイル勉強会 2018年10月セミナー
「MicroserviceでのNoOps戦略」(2018/10/26)NoOps Japan Community NoOps Meetup Tokyo #2

アジャイルとNoOps(DevOps)というのは実装を挟む両輪なので、話は違えど、目的は同じです。
f:id:arclamp:20181027081911p:plain

現在のITサービス(特にSoE/mode2)において大事なことは「素早く届け、素早くフィードバックを反映し、また届ける」というサイクルです。これを高速にしていくためには

  • アジャイルのような短期タイムボックス型でのタスク管理
  • NoOps/DevOpsのような運用作業の事業化

という両輪がなくてはならないものでしょう。

そして、これらの概念を統合するのは「マイクロサービス」という言葉です。言葉が拡がるきっかけとなった記事「Microservices」ではマイクロサービスを示す9個の特徴が挙げられていますが、いかの3つの観点が含まれていることが分かります。

  • サービス分割、API連携、分散データ管理、進化的設計など実装面
  • チーム構成、プロダクト思考、脱中央集権などの組織面
  • インフラ自動化、対障害設計などの運用自動化面

f:id:arclamp:20181027083526p:plain

マイクロサービスについては、来週11/2はAWS Dev Day Tokyo 2018でマイクロサービス化デザインパターンという話をさせていただきます。マイクロサービスはいきなり完成形でシステムができあがるものではなく段階的に「マイクロサービスになっていく」ものです。なので「マイクロサービス"化"」という言葉を使っています。

もちろん、全体の土台となるのはアーキテクチャ設計です(僕の中心はここ)。今月10/12には翔泳社アーキテクチャ設計実践講座(10/12)というワークショップ型のセミナーを開催しました。これは、また来年早々に開催する予定なので日程が決まればお伝えします。

相変わらず、色々、散らかっているようで繋がった話をしているつもりなのでお付き合い&フィードバックいただけるとうれしいです。
あ、僕が会長を務めさせていただいている日本Javaユーザーグループの1000人規模イベントJJUG CCC 2018 Fallは12/15(土)です!そろそろ、募集が始まるはず。


エンタープライズアジャイルの成長過程について

2018年7月23日におこなわれた要求開発アライアンス2018年7月定例会で「エンタープライズアジャイルにおける要求探索の勘所」という話をさせていただきました。資料は以下。

僕にとってのエンタープライズアジャイルの定義は

ウォーターフォール開発の環境が整備されている中で取組むアジャイル

のことです。で、こういう現場の支援、あるいは自社で開発していると以下のような段階で成長していっているなぁと感じています。
1.PO本人がスコープ管理をちゃんとできるようになる
2.企画組織内でPOがリードタイムの管理をちゃんとできるようになる
3.他部署ともルールをきめてプロセスの共有をちゃんとできるようになる
というわけで、そういったところを資料にしてあります。

まだまだ、エンタープライズアジャイルには辛いところも多いですし、進化の過程だなと思うところもたくさんあります。しかし、こういった取組みを深めていってこそ、日本のシステム開発の現場がまともになっていくものだと信じています。ぜh、フィードバックなどくださいませ。