なるほど、最近感じるフラストレーションは、新しい仕事の考え方のフレームワークを欲している線から来てるのはあるかもしれないな。前回まとめた↓のが4.5年前で、当時と変わった視点もあるので考えてみよう。https://t.co/RPkqTwQtic

— Father as a Software hacker (@Kengo_TODA) September 14, 2019

ということで形にするために書き下しています。

背景にある考え方

• 高い利益を上げる製品、キャリアを高める成長機会、より良い待遇と給与、良い顧客。こうした良いモノすべての源泉が「良いチーム」である。
• しかし変化の激しい時代、ひとつの固定した「理想のチーム像」を作ることは不可能である。よって現代のチームは「時や状況に応じて学び変化できるチーム」を目指すべきである。
• この文書では「最高のチーム」「理想的なマネジメント」ではなく「より良いチーム」を作ることを目標とする。

良いチームの指標

• 頻繁に質の高い学習ができる。

  • 頻繁に：組織の目的によるが、少なくとも月イチ程度にretrospectiveを行う。開発組織の場合はweekly iterationやbiweekly iterationを目指す。突発性インシデントへの対応が規定され共有されているため、ダメージを抑えpostmortemを行い学習し製品にfeedbackできる。
  • 質の高い：すべての施策に共有された目標がある。このfactがほしいと思ったときに探し出せる、あるいは新規に測定できる。problem solvingについてチームが理解している。他社事例や公開された研究結果などを適宜参照する。自分たちの学習したことも可能な限り公開し、ひろくフィードバックを受け付ける。
  • 学習ができる：人のせいにしない、失敗を成長の糧として捉える、blameless postmortemの文化がある。個人の意識や努力でカバーするのではなく、組織や自動化でカバーする。目指す像が全員に共有されている。目標に対するオープンな議論とdisagree and commitのための責任の所在（後述）が明確である。

• 個人の個性と意思が尊重され、結果としてモチベーション高くモノづくりができる。

  • 多様性を重視する、オープンな議論を行う、役職を発言と紐付けない。認知的不協和を抑えるためにも、個人が謙遜さとオープンさを身につける必要が、組織が心理的安全性を満たす必要がある。
  • マネジメントが「上司」ではなく「支援者」であることを信じてもらう。servant leadershipを実行する。
  • 各個人が学びたいこと、挑戦したいことの把握に努める。得た情報を現状に照らし、勤務の一環として成長機会を作る努力をする。学びたくないこと、目を背けたいこととの折り合いを共に考える。
  • 健康状態や家庭の事情に気を配る。可能な限り勤務時間や貢献手法に制限を設けない。場所や時間を縛る働き方を排除する。

• 各自の役割が明確になっている、ボトムアップとトップダウンのバランスが良い。

  • ブレークスルーの源泉は常にチームにある。チームのリソースをどこに割くかを検討し優先度をつけるのがマネジメントの役割。
  • ボトムアップの力を信じてempowermentすることと、組織目標やスコープを明確にすることは両立する。
  • マネジメントはまずチームのMissionとVisionを明確にし、チームのベクトルを合わせる必要がある。
  • チームを信じられない、チームに任せられない理由があるならばまず第一に排除する。言語の壁、文化の壁、情報の不対称性、習慣の違いなどが該当する。

従来の「責任」と、これからの「責任」

我々は（失敗したときに）責任を取れという言い方をすることがあるが、それになんの意味があるのだろうか？

まさにそれですね。「責任」というものが出てくるのは仕事、職業が社会身分、ステータスの延長にあるようなメンタルモデルにとどまっているからだと考える次第。

— cobot_1 (@cobot_1) September 14, 2019

失敗によるダメージを抑えるためにマネジメントはリスク管理をするべきで、管理が足りていなかったなら反省し学ぶ必要がある。 また管理できなかったダメージは既に存在するので、再発防止だけでなくケアの方法も考える必要がある。

責任の本質は、情報と権限を明確にして状況に応じて速やかに学び行動できる組織づくりではないか。 責任を取らせることが必要なのではなく、責任を預けるに足る能力（組織づくりやリスク管理）を持つ人材を責任者に据えることと、能力が足りないと判断したときに上長の判断で外せることが必要なのではないか。

問題点を発見する運用手法

One on oneとOKR。MBO-Sでも良いけどOKRではダメな理由がないのと、OKRの方が明確に失敗を織り込んでいる（Key Resultsがすべて達成できてるのは逆に良くないという前提が共有されている）ので良いと思う。あとフォームを利用したマネジメントへの匿名FBも有用。あとで掘り下げる。

コーチングが問題発見の手法になるかもしれない。少なくとも聞き手と話し手の双方に問題発見を促す働きがある。

不確実性を早期に発見するために、目標は小さくし、Scrum手法を適用する。 ダメージを想定し備えるとともに、失敗したときのコンティンジェンシープランを持っておく。

良いチームを支える技術

手を動かすことと議論することにチームを集中させる必要がある。ここで言う議論はコンセンサスを作ることではなく知恵を出し合うことである。

手を動かす時間を作るために、作業は極力自動化する。バグの再現環境を作ったり、管理用の情報を揃えたり、やるべき作業をリマインドしたり、必要なライブラリやミドルウェアを揃えたり、コードレビューをしたり。 CIジョブでできるチェックは極力CIジョブで実施する。理想的には1日あたり4時間以上集中して作業できる状態にする。時間はまとまって確保できるようにし、フローに入れるようにする。

議論はあらかじめ目的を明確にして、結論の出し方を決めておく。ファシリテーターを置く。ここでは思考や知見を積み上げることを目的としているため、アウトプットは文書化し検索可能にする必要がある。

ほか

• TeachingとCoachingの使い分け
• 組織パターン
• 売上、利益、バジェット

参考書

• 失敗の科学 失敗から学習する組織、学習できない組織
• The DevOps ハンドブック 理論・原則・実践のすべて
• 失敗学のすすめ (講談社文庫)
• 組織パターン (Object Oriented SELECTION)
• ジョブ理論 イノベーションを予測可能にする消費のメカニズム (ビジネスリーダー1万人が選ぶベストビジネス書トップポイント大賞第2位! ハーパーコリンズ・ノンフィクション)
• 失敗の本質―日本軍の組織論的研究 (1984年)
• ワーク・ルールズ! ―君の生き方とリーダーシップを変える
• 個人、チーム、組織を伸ばす 目標管理の教科書
• リーン・スタートアップ
• エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング
• オープン・オーガニゼーション
• re:Work

考慮する点

成果物のデプロイ

ビルドの成果物（artifct）をアップロードすること。アップロードと公開は分けて考えることに注意。デプロイ先にはいくつか候補がある：

1. GitHub Packages (旧GitHub Package Registry)
2. Maven Central Repository
3. Docker HubなどのDocker Registry

GitHub Packagesはコンテナも.jarもまとめて置けるが、コミュニティ標準の場所ではないので利用する際にひと手間必要になる。プライベートプロジェクトの場合は積極利用することになりそう。FOSSなら基本的にMaven Centralに置くことになる*1。プロジェクトによっては.jarファイルとしてではなくコンテナとしてデプロイすることもあるだろう。

リリースノートの作成

CHANGELOG.mdやsrc/site以下のファイルを手動でメンテナンスする手法だけではなく、コミットコメントやPRからリリースノートを作成する手法もある。

1. 手動管理
2. CHANGELOG.mdなどファイルの自動生成
3. GitHub Releasesによるリリースノート自動生成

特に開発者向けであれば、CHANGELOG.mdではなくGitHub Releasesを使うことで、変更内容の伝達を自動化できる。例えばDependabotは依存先の更新を提案する際にリリースノートの内容をPRに含めてくれる。ファイルの頒布が必要な場合でも、GitHub Releasesも合わせて使ったほうが良い。

バージョンの管理

利用者の利便性のため、Semantic Versioning 2.0を使うことが前提になる。ただ混乱を避ける意味でもバージョン 0.x.x の利用は避けたほうが良いかもしれない。

1. 手動管理
2. 自動的に決定する

バージョンを決める作業自体は自動化が進んでいて、Conventional Commitsから生成するものがsemantic-releaseだけでなく様々あるので使ったほうが良い。私はプラグイン機構がしっかりしているのでsemantic-releaseを使っている。

プロジェクトのバージョンをpom.xmlやbuild.gradle, gradle.propertiesといったファイルで管理するのが普通だが、最近はGitのTagを見るものもある。Tagを見ることで「ファイルに書いてあるバージョンをインクリメントする」ためのコミットが不要になるのが利点。例えばDraft Releaseを本Releaseに昇格させる（ブランチの最新コミットにタグを打つ）ことで公開処理を回す（tagイベントに紐付いたワークフローを回す）処理がシンプルになる。のだが、SNAPSHOT運用と相性が悪いのと、ファイルに書かれたversionの信頼性がなくなるのとで、あまりJavaプロジェクト向きではないと考えている。

各手法について

Maven (maven-release-plugin)

mvn release:prepare && mvn release:performを実行するだけで必要な処理が完結する。Maven公式の機能で完結し、歴史も長いのでノウハウも蓄積されている。

シンプルだが、Tag作成をリリースの起点にできない（Tag打ちがプラグインによって行われる）ために自動化には向かない。多くの場合、リリース用の（Jenkins）Jobを作って手動で蹴るような運用になるのでは？pom.xmlの更新とGitへのpushがプラグインによって行われることもあり、自動化の際はプラグインによるコミットメッセージに[skip ci]を含めたり設定を変更したりといった工夫が必要になる。

Maven (maven-deploy-plugin)

Mavenでリリースを自動化する場合はmaven-deploy-pluginによるデプロイ手法を採ることになる。特にmaven-versions-pluginのsetゴールと組み合わせることが多いはず。

リリースに使用するバージョンをTag名などを経由してnewVersionプロパティに渡してversions:setを実行、deploy:deployでデプロイした後に再度versions:setでSNAPSHOTバージョンに変えてGitにpushする運用。release-drafterが使えるのでリリースノート管理もしやすい。

この場合でも、Tagが打たれたrevisionのpom.xmlには実際にリリースされたversionとは異なる値が書いてあるはず。versionの信頼性という点で問題が残る。

Maven (maven-semantic-release)

version mismatchが気になる場合は、semantic-releaseの利用を検討する。これはmasterブランチにpushされた変更をすべてリリースするという手法である。

バージョンの決定はsemantic-release本体が、リリースノートの作成は@semantic-release/githubや@semantic-release/release-notes-generatorや@semantic-release/changelogが、GitのcommitやTag打ちやpushは@semantic-release/gitが行うことになる。すべてのプロセスが自動化されるので、運用の負担は最も低くなる。またversionの信頼性も確保できる。

Conventional Commits（厳密にはAngularのルール）の利用を全開発者に強制しなければならないこと、Javaプロジェクトなのにpackage.jsonを使わなければならないこと、masterブランチを常にリリース可能にすることが許容できるならばこの手法が最善と思われる。

ライブラリはともかくアプリやサービスだとPR毎リリースが受け入れられないことはあると思うが、こちらのFAQに目を通した上でも必要と判断されるなら、リリースを意図的なタイミングでトリガする手法を取り入れることもできる。

Gradle (gradle-semantic-release-plugin)

semantic-releaseはGradleでも使える。詳細は以前の投稿を参照。

Jib

GitHub repoにBuild container images for your Java applicationsと書いてあるように、Javaアプリをコンテナ化するときに使えるツール。Maven/Gradle両対応。デフォルトでもコンテナのレイヤをうまく分けたり、warプロジェクトならJettyを同梱したりしてくれる。

依存を必要としないのはありがたいが、dockerひとつ追加するだけならあまり苦ではない（GitHub Actionsだとデフォルトで付いてくる）のでそこまでの利点という感じではない。ドキュメントにちょいちょいKubernetesとの組み合わせ方について言及されているので、Kubernetes使いにとってはやりやすいところがあるのかも。

Docker

MavenやGradleを使ってデプロイするのではなく、CIサービスでdockerコマンドを実行する。Maven/Gradleはpackage/assembleするまでが責務で、デプロイはdocker pushで行う運用になる。前述の通りdockerコマンドの導入は多くのCIサービスでfirst classのサポートを受けているので、セットアップは非常に楽。最近はmulti-stage buildもあるので最終成果物も充分に小さくしやすい。

一見やりやすいが、開発作業中にdockerコマンドが実行されない可能性をはらんでいる。これは開発者が触るものがリリースされるものと異なるものになるということで、微妙なリスクになる。開発作業中もmvnw/gradlewではなくdockerコマンドを使うようにする（付随する課題も解決する）か、コンテナにデプロイされたアプリを使うE2Eテストを早期に統合すると良いかもしれない。

なおイメージを小さくするのに jlinkを試してみたいのだが、現状ではalpineで動くOpenJDK（Portolaプロジェクト）が公開されてない？ようで、2018年5月時点で有効だった手法が使えなくなっている。のでalpineイメージをベースにするためにはDockerfileがけっこう複雑かつ管理の難しい状態になってしまうのが難点。この辺の情報はおそらくこの2018年11月時点のブログ記事が最新。

docker-compose

コンテナの利用をもう一歩進めて、データストアやHTTPサーバもコンテナ化してアプリとの依存関係やそのバージョンをdocker-compose.ymlで管理する。 ここまで行くとより良いデプロイ手段というよりは、より良いプロビジョニングやポータブルな実行環境の方を実現したい段階だと思われる。

注意することはDockerを単体で利用する場合と同様だが、アプリのコンテナが依存するコンテナ（データストアなど）をアプリをビルドするたびにビルドするような運用にならないように注意する必要がある。具体的には、ADDするファイルを最小限にすることで、スキーマ定義やマイグレーションスクリプトが変更されたときなど、必要なときだけ依存するコンテナがビルドされるようにする。

以前のJavaウェブアプリ開発では、JavaScriptをはじめとした静的アセットはsrc/main/webappディレクトリに配置するのが普通だった。そこに置くことでmaven-war-pluginのようなビルドシステムが.warファイルの中に突っ込んでくれる。この挙動は今でも変わらないが、src/main/webappディレクトリに静的アセットを直接置くにはいくつかの問題がある：

1. TypeScriptコンパイラやBabelのような、静的アセットに事前処理を施す手法が普通になった。
   • src/main/webappに処理後のリソースを置くようにもできるが、mvn cleanなどで処理後のリソースが削除されるようにする手間を考えるとtargetディレクトリ直下にあるwebappDirectoryに置くのが無難と思われる。
   • よってsrc/main/webappには事前処理を必要としないアセットのみを置くことになるが、次に挙げる理由からそれも必要なくなってきている。
2. フロントエンド開発が複雑化し、サーバサイドと同一プロジェクト・モジュールで開発することが難しくなった。
   • ここで言うフロントエンドはサーバからのレスポンスを受け取ってユーザ向けにインタフェースを提供する部分。HTML5アプリだったりモバイルアプリだったりする。
   • フロントエンド開発で使うビルドツールやライブラリ、development workflowは必ずしもJavaのそれと一致しない。例えばブラウザやOSのプレビュー版が出たときにフロントエンドだけテストを回すといったことができればより高速に検証できる。またJavaScriptライブラリはJavaライブラリ以上にこまめなバージョンアップが必要となるケースが多い（脆弱性対応とか、OSアップデート追随とか）ため、フロントエンドを独立に更新していけるプロジェクト体制を整えることが必要になる。
   • frontend-maven-pluginを使ってJavaのビルドツールに統合することは可能だが、そもそも開発者が異なるケースではあまり意味がない。OpenAPIやgRPC、GraphQLなどのインタフェース定義をフロントエンドとサーバサイドの間に入れて独立に開発していく体制を組むほうが良い。
3. 静的アセットはTomcatのようなサーブレットコンテナではなく、Amazon S3のようなストレージサービスやCDNによって配信することが好ましい場合が多い。
   • 例えばGoogle Cloudのドキュメントでは、アプリによる静的アセットの配信をstraightforwardだが欠点のある手法として紹介している。

この問題を解決するために、大きく分けて3つの手法を紹介する。

1. 同一プロジェクト内で2つのビルドツールを併用する

サーバサイド開発にはMaven/Gradleを、フロントエンド開発にはnpm/Yarnを利用するが、プロジェクトは分割しない手法。

この手法1.を採る場合、アセットは .warや .jarに同梱する形が最もやりやすい。例えばSpringだと同梱されているリソースをStatic Resourcesとして配信可能。懸念されるサーブレットコンテナの負荷低減は、HTTPレスポンスのキャッシュやCDNによって実現することになる。

1.1. サーバサイドをMaven/Gradleで、フロントエンドをMaven/Gradleで包んだnpm/Yarnで開発するケース

サーバサイドとフロントエンドを同一のビルドライフサイクルに乗せるため、frontend-maven-plugin/frontend-gradle-pluginを使って、Maven/Gradleからnpm/Yarnを実行することになる。フロントエンド開発の複雑さがあまりない場合、Java開発者がフロントエンド開発も兼ねる場合に重宝する。例えばsrc/main/typescriptにTypeScriptを、src/main/sassにSassを置くような体制。

プロジェクトルートにpom.xmlやsettings.gradleを置いてフロントエンド用モジュールをMavenのサブモジュール/Gradleのサブプロジェクトとして扱うこともできるが、そこまでやるならば次に挙げる手法2で充分であろう。

なおフロントエンドの成果物をMaven Repositoryにzipしてデプロイし、他プロジェクトから利用するということを以前試したことがあったのだが、zip/unzipを多用し性能が出ないのでおすすめしない。普通にファイルコピーで済ませるために、利用者（サーバサイド）と同一プロジェクト（Gitリポジトリ）に置くようにしたほうが良い。

1.2. サーバサイドをYarnで包んだMaven/Gradleで、フロントエンドをYarnで開発するケース

逆にYarnを主、Maven/Gradleを従とする手法。サーバサイドが小さいときは使えるかもしれないが、そこまでするなら手法3が素直。

2. サーバサイドとフロントエンドでプロジェクトを分ける

各モジュールの開発技法において、自由度を確保することを意識した手法。それぞれ異なる開発者が請け負う場合にはこういった形を取ることが多いのでは。Gitリポジトリを分けるかmonorepoにするかという点も考慮が必要だが、自分の開発経験（小型中心）だと分割の必要性を感じたケースは無いので、ここではmonorepoという前提をおいて考える。またフロントエンド＝ウェブアプリとし、モバイルアプリ開発については触れない。

サーバサイドとフロントエンドのつなぎ目には、OpenAPIなどのAPI定義手法を利用する。サーバサイドとフロントエンドを突合する部分（CD、プロビジョニングなど）が複雑化する可能性はある（例えばspring-boot-vue-exampleではserverとclientのデプロイにスクリプトを使っている）が、多くの場合でさほど問題ないのでは。プロジェクト構成例は以下の通り：

interface/
  openapi.yml

server/
  src/
  pom.xml // 最終成果物は .war, executable .jar あるいはコンテナ

frontend/
  src/
  package.json // 最終成果物は .zip あるいはコンテナ

docker-compose.yml // あるいはTerraformとかCloudFormationとか？
README.md

この場合、フロントエンドの成果物はサーバサイドの成果物に含めない。またフロントエンド開発にサーバサイドの挙動をmockする必要があるが、Open APIならmock serverを利用できるし、その他のAPI定義手法でも似たものがあるはず。

3. サーバサイドをNode.js化するという選択肢

これはタイトルに全く沿わない手法であるが、真面目にありがちな話だと感じている。つまりJavaとJavaScriptという異なる言語を同一プロジェクトで使用することが複雑さを生むならば、その原因を取り除けないだろうか？ということである。

そもそもNode.jsが発展しTypeScriptのような型を使った開発も可能な現代において、サーバサイドとフロントエンドで異なる言語を使うモチベーションがどの程度あるだろうか？

サーバサイドをNode.jsにすれば、プロジェクトの複雑さを除くことができる。性能に直結する非同期処理もCompletableFutureやRxJava、spring-webfluxで使われるReactorに比べればJavaScriptのasync/awaitの方が簡潔になるし、何よりJavaScriptは言語自身が「メインスレッドをブロックしない」ことを前提に設計されているので、うっかりblocking処理をサーバ内に書くことを避けやすい。 もちろんJavaの方がやりやすいこともたくさんある。またJVMの進展は非常に目覚ましいものがある。運用の知見など積み直しになるものもあるため即置き換えとは行かないし、する必要もない。結局道具は適材適所なので、Javaエンジニアだと自分を狭く定義するのではなくて、JavaもNode.jsもTypeScriptも学んで使いこなせばいいし、KotlinやDartのような新しい言語とそのコミュニティにも目を向けていければ良いのだと思う。

まとめ

小型のプロジェクトでは手法1.1、専任のフロントエンド開発者がいる場合は手法2を使うことをまず検討すると良いだろう。

昨年のに引き続きFOSS活動状況をまとめます。2019年12月30日時点の情報です。

概要：昨年比22%増

GitHubのプロファイルページによると今年のpublic contributionsは1,166で、昨年が950だったので約22%増です。commit 61%のpull requests 21%なので、けっこう手を動かしてコードを書けたと思います。業務でのpublic contributionsはゼロなので、すべて趣味開発です。

今年新規に作成したのは主に gradle-semantic-release-plugin, open-the-sesameと spotbugs-gradle-plugin-v2です。gradle-semantic-release-pluginについては3月に紹介記事も書いています。

7〜9月の Contributions が減っているのは勤務先における異動による影響です。これがなかったら1,500くらい行けたかもしれません。

SpotBugs周りの開発

2019年もSpotBugsが一番活発な開発でした。コア開発58 commitsと昨年比で減っていますが、SonarQube pluginやGradle pluginは横ばいという感じです。

特に現Gradle PluginがGradle本体からのforkなため、internal APIに依存していたりAndroid開発へのケアが抜けていたりという課題が多かったので、半年ほどかけて準備をしスクラッチで書き直しています。Gradle Pluginポータルにはデプロイしたので、承認されしだい利用可能となるはずです。

今年の目玉はSpotBugsのダウンロード数がFindBugsのそれを上回ったことですね。あれから苦節3年弱、継続は力なりを体現した感じです。リリースもそうですがマニュアルサイトの作成と管理も結構関われているので、嬉しく思います。

Now SpotBugs (180k/mo) is downloaded more than FindBugs (140k/mo). Cool! Congrats, #SpotBugs community! 🎉https://t.co/oSi2HVM1LL

— not a robot but a cat (@Kengo_TODA) December 30, 2019

その他

ひとつプロジェクトに関わらせていただいているのですが、まだ公開できる状態ではなさそうです。あまり積極的に貢献できていないとはいえ意義のあるプロジェクトですので、機が熟したらいろいろと紹介していければと思います。

2020年やりたいこと100 - ややめもを見て良い取り組みだと思ったので書いてみたのですが、100も出てこないのでとりあえず半分でお茶を濁す作戦。

健康（1~10）

1. 週2回の筋トレを継続
2. 平日は10,000歩以上歩く
3. 体重を72kg±2程度に抑える
4. 24時までに寝る
5. 平日のコーヒーをやめる
6. 水やお茶を1日2リットル以上継続して採る
7. 朝ごはんの菓子パン依存率を減らす、食パン＋野菜や肉などで代替する
8. 皮膚のプロアクティブ治療を継続する
9. 暗いところでスマホで読書する習慣をなくす、視力低下を防ぐ
10. 平日の昼寝を継続する

育児（11~20）

1. 息子氏がひらがなを読めるようにする
2. 息子氏を新幹線に乗せる
3. 息子氏の小学校を決める
4. 息子氏の中学校以降を検討する
5. 絵本を継続して読みきかせる
6. 毎朝30秒のハグを息子氏が嫌がらない限り継続する
7. 幼稚園への登園中に日本語で息子氏にどんどん話しかける
8. 息子氏を動物園や水族館、スポーツの試合に連れて行く
9. 息子氏の友人一家と遊ぶ
10. 日本語を話す息子氏の友人を作る

家庭（21~30）

1. 家族と中国国内旅行に行く
2. 家族と日本国内旅行に行く
3. 音声認識コントローラを導入する
4. 無駄を省き効率化を進めることで、平日夜の時間を創出する
5. 平日朝の忙しさを緩和する（≒息子氏をきちんと起こす、息子氏の朝食や着替えをきちんと済ませさせる）
6. 投資や副業などで収入を増やす
7. 映画や美術館、新しいショッピングモールなどに行く習慣を作る
8. そのための日常的な情報収集を行う（WeChatなど）
9. 実家との継続的な連絡を取る
10. スケジュールや心持ちに余裕を持つ、息子氏の突発的な風邪などを常に想定に入れる

趣味（31~40）

1. Skebでらきすけさんにライチュウを描いてもらう
2. SpotBugs Gradle plugin v2をSpotBugs Organization下でリリース
3. SpotBugs 4.0.0安定版をリリース
4. Sphinxに3つ貢献する（docker imageとか）
5. n月刊ラムダノートに寄稿する
6. JavaプロジェクトをひとつKotlinで書き直す
7. VRゴーグルを導入する
8. 週1冊の本を読む
9. GitHub sponsorsに登録する
10. ブログ記事を6つ書く

業務（41〜50）

1. 部署の売上目標をつくり達成する
2. 部署の利益目標をつくり達成する
3. 部署の技術目標をつくり達成する
4. 個人の技術目標を策定・達成する
5. 職場のモニタを新調する
6. 職場のポインティングデバイスを新調する
7. 日本の技術イベント登壇
8. 上海の技術イベント登壇
9. 3回ほど社内技術勉強会で公開セッションをする
10. M5StickCで職場用ガジェットを作る

.classファイル向け静的解析ツールであるSpotBugsのバージョン4.0.0がリリースされました。 FindBugsとの互換性を極力保っていた3.1系と異なり、いくつかのAPIが変わったり機能が削られていたりします。 特にプラグイン開発者は、SpotBugs 3.1 から 4.0 への移行ガイドを確認するようお願いします。 一応ユーザに使われていない機能を調べて削ったので、一般ユーザに対する影響は限定的なはずです。

なおJava 9以降にはまだ対応していません。コミュニティで議論された4.0でやりたいことには含まれていたのですが、貢献がありませんでした。 ObjectWeb ASMやApacheBCELの更新に追随しているのでコア機能は動作しますが、標準DetectorのうちNullness周りをはじめとしたいくつかのDetectorが動作しないことが知られています。のでJava9移行のプロジェクトでもSpotBugsの利用が必要な場合は、オプションで利用するDetectorを絞ってください。詳細は以下のissueを確認すると良いでしょう：

• Java 9
• Java 10
• Java 11

なお最近はIDEAプラグインの実装に動きがあるので、SpotBugsを使いたいIDEAユーザはwatchすると良いかもしれません。 Gradleプラグインもフルスクラッチで書き直し中で、正式リリースも近いのでGradleユーザは是非試してみてほしいです。

SpotBugsは貢献者を求めています

さて本日、サイボウズさんのブログでOSSに貢献する利点や手法が紹介されています：

そしてSpotBugsは知名度もあり、本家のFindBugsよりも使われているプロダクトとなりましたが、まだ貢献者が少ない状態です。コードが複雑なのは難点ですが、貢献を始めるには良いプロジェクトかもしれません！ぜひ覗いてみてください！！！

チームには私の他に、issueでの返信やコードレビューを担う人、Eclipse PluginやMaven Pluginに特化した人がいますが、間に落ちている問題もJava9対応に限らず多くあります。また直接コードに貢献しなくても、使い方や利用状況をブログやSNSで発信するだけでも他のユーザの参考になります。どういう形でも構わないので、ぜひ検討してみてください。コミュニティの言語は英語ですが、日本語のわかる私を貢献の取っ掛かりに利用していただいても構わないです。Twitterやメールで連絡ください。

なお継続的に貢献いただいた方には、Organization参加要請を出していきます。実績としても、2019年には2名をOrganizationに招待しています。お邪魔でなければ受けていただければ幸いです。一見リリースが少ない不活発なプロダクトではありますが、チーム自体はissueだけでなくGitHub Teamを通じてコミュニケーションを取っていますので、招待や議論は問題なく行えます。よろしくお願いします。

あわせて読みたい

• 本ブログのSpotBugsタグのついている記事一覧
• SpotBugs3.1.xの現状と
内部実装が抱える問題

人に説明するのがスムーズにできなさそうなので、理論武装というか順序立てて話すためにこの記事をまとめる。

対象

• ブラウザから利用するマルチプラットフォーム向けウェブアプリケーションの開発
  • モバイルのネイティブアプリ開発は含まない（知らないので）
  • 利用言語はJava, JavaScript/TypeScriptを想定するが、特に言語に依存しない認識
• 開発経験はあるが、情報や経験が少なくて「よりよいプロダクト開発」の理想が描けない方への一助として作成

TL;DR

1. 状況やベストプラクティスが目まぐるしく変わる現代において、すぐに変化できるソフトウェアを保つこと・ヒトの手をできるだけ空けることが重要。
2. かつてIaaSがAPIを提供し環境管理の多くを自動化したように、各種サービスがAPIやWebhookを通じてDevelopment Workflowの多くを自動化してきている。
3. 多くの視点や知見を活かすcross functionalチームによる共同開発を支えるために、コラボレーションを助ける仕組みも必要。

前置き：課題解決手法としての生産性向上

我々はなぜ生産性向上を目指すのか？　それは生産性が十分ではないという課題意識や危機感を持っているからだろう。では、なぜ課題意識を持ったのか？　機能の実装が進まないとか、バグが多いとか、手戻りが多いとか、本質的でない業務が多いとか、現場によって多くの理由があると思われる。そしてそれを深堀りする前に他者とざっくり課題意識を共有するための言葉として「生産性を向上しないとね」といった表現が用いられる。 言い換えれば、生産性向上というのは現場の抱える課題に対する抽象的な解決策である。ので「生産性を向上するには」などと議論しても、地に足をつけた議論にはならない。「なぜ生産性が低いのか」を掘り下げて、その解決策を見出す必要がある。

ここで重要なのは「なぜ低いのか」は比較対象を知らなければ説明できないことだ。それが他のチームが実際に回している開発なのか、スケジュールから逆算した「理想生産性」なのかは課題ではない。そうした「あるべき姿」が共有されてはじめて比較ができ、KPI（モノサシ）が生まれ、議論できるようになる。これは開発手法や組織、プロセスなど、どこに課題がある場合でも同じだ。

これはこのブログで繰り返し出てきているproblem solvingの考え方であり、真新しいものではない。単に課題の設定と共有をきちんとしようという話である。課題が設定されてはじめて、課題解決の進捗や施策の妥当性を評価できる。Development Workflowに手を入れる前に、本当に必要なものがそれで手に入るのか確認する必要がある。

Development Workflow

私はDevelopment Workflowは自分の専門というわけではなく、またウォッチャーを自任できるほど時間をかけてトレンドを追ってもない。いちエンジニアの理解であり何かを代表するものではないことを、はじめに改めて強調しておく。

またここでDevelopment WorkflowというのはCI, CD, DevOpsといった文脈で出てくるパイプライン処理、特に確認や承認や手動テストという非自動化処理をも含めた一連の流れを指している。ワークフローの「終点」は成果物のデプロイだけでなく、チームへのフィードバック＝学習機会の提供であることも多い。

かつてDevelopment Workflowはどのようなものだったか

自分が10年前にどういうDevelopment Workflowを組んでいたかというと、概ね以下の通りだったように記憶している（便宜上HudsonをJenkins*1と表記）：

• trunk, branches, tagsを備えたSubversionによるコードのバージョン管理（ブランチ切り替えコストが高い）
• 設定画面を利用したJenkinsジョブの作成・設定
• ブランチを指定して実行するJenkinsジョブを開発者に対する公開
• プラグインによるJenkinsの機能拡張
• Mavenの親pomファイルを利用したプロジェクト管理
• LANに閉じた開発環境
  • Jenkins EC2 pluginはあった
• 環境構築や開発作業の手順書をWiki等でメンテ（.jarファイルの手動配置、テスト手順、IDE設定方法など）

自動化されているのはジョブと呼ばれる単発作業のみで、いつどのように実行するかは主にヒトに委ねられていた。出荷作業をするにはこのジョブをこういったパラメータで実行すること、という手順書が必要だったのである。VCS上での変更を知るにはpollingを必要としていたし、結果をヒトに通知する手法はメールが主体だったので、何かを強制することは難しかった。

当時はまだビルド職人という言葉があったが、それは成果物の作成を特定の環境や個人でしか行えなかったり、ジョブ実行時間が非常に長かったりしたことを反映している。実際ビルド環境を可搬にすることはまだ難しく、また手順書が必要な現場も多かったのではと推測される。

近年Development Workflow周りで見られる変化

逆に、当時に無くここ10年で開発され普及したものを思いつく限り列記する：

• ブランチを利用しやすいVCS（Git）
• 画面による設定ではなく、VCSによって管理されたファイルよる設定
  • Maven Wrapper
  • .mvnディレクトリによる設定
  • Jenkins PipelineをはじめとしたCI設定ファイル
  • .ideaディレクトリによるIDE設定のバージョン管理、共有
  • pom.xmlやbuild.gradleからIDEプロジェクトを作成（mvn eclipse:eclipseのことではなく、IDE自体がビルド設定を読むようになった）
• CIパイプライン
  • Jenkins v2の改良点としてパイプラインを第一級エンティティとしたことが挙げられている
  • ワークフローの分岐やマージ、複数ノードでの実行が直感的にできるようになった
• インクリメンタルビルド
  • The Takari Lifecycle, Gradle Incremental Build, Gradle Build Cache, Bazel Remote Cachingなど
  • 手法によっては同一ノードだけではなく、他ノードでのビルド結果を踏まえてビルドすることもできるようになった
• 複数ノードにおけるテストのparallel実行
  • Circle CI, Jenkinsなど
• プロジェクトごとに利用するJDKを切り替える仕組み
  • rvmはあったようなので、他言語には実行環境をプロジェクトローカルのファイルで指定する仕組みはあった？
  • 開発環境にはあらかじめ複数のJDKを入れておくことで、Toolchainを使って使うものを指定する仕組みはあった（どの程度普及していたのかは不明）
• DisposableでReproducibleな、頻繁に壊して作りなおせる環境
  • Vagrant Sahara pluginが出たのが2011年
  • Boxenが出たのが2012年
  • Dockerが出たのが2013年
  • ChefとPuppet, EC2にAMIはあったので、自前でコード書いて実現する手はあったと思う（自分はやった記憶がない）
• CLIから実行できる、設定がVCSで共有可能で環境非依存なコードフォーマッター
  • gofmt, rustfmt, Prettier, Spotlessなど
  • コードフォーマットが個人の環境・設定に依存する必要性をなくし、差分レビューを容易にした
• チケット中心主義の緩和
  • PRで変更を提案し、その中で議論・修正できる
  • 不具合も再現するテストをPRで送り、同一PR内で修正しマージできる（チケットによる報告も残ってはいる）
  • GitHub Releasesなどでタグに対して情報を残せるのでリリース作業もチケット不要
  • チケットを作って議論を尽くしてからコードを書くケースはもちろん残っているが、関連作業の記録・集約のためにまずチケットを作るというフローはほぼ不要になった
  • チケット管理システムの責務から変更の記録が外れ、要件の記録に注力できるようになった
• 他システムとの連携を前提としたAPIやWebHook、アクセストークン
• 運用を肩代わりし本質に注力させてくれるSaaS群
• ベンダ間で統一されたインタフェース（WebDriver, JS, CSSなど）

多様にわたるが、その多くがビルド時間の短縮や環境管理を楽にすること、システムを”繋ぐ”ことに貢献するものである。

10年前と比較して、どのようなニーズの変化があったのか

技術の進展というのはあとから振り返ると「なんで今までなかったんだっけ？」と感じるものが多いが、Development Workflowを構成するサービスの成長にも同じことを感じる。 例えば10年前はヒトに使われることを前提にGUIを通じて提供していた機能の多くが、サービスから使われることを前提にWebAPIやVCSで管理されたファイルによって使えるようになった。しかしGUIとCUIどちらが技術的難易度が高いかと言うと、一般的にGUIだろう。GUIを提供できるがCUIはできない、というケースはあまりないはずだ。

ではなぜ10年前はGUIを中心としていたのか？それは（特にJenkinsについては）利用者に対するハードルを下げた面もあると思うが、手実行することがあまり問題にならなかった、設定や運用をオープンにし誰でも触れるようにするモチベーションが高くなかったことが要因として挙げられる。もっと言えば、当時は1日に数回のビルドで十分にビジネスを回せたのだ。DevOpsの草分けとなったFlickrの発表がちょうど10年ちょっと前*2だし、おそらく当時はまだ多くの組織で「開発と運用の対立」「出荷前検証の重視」が残っていたはずだ。Flickrを始めとした多くの組織で、インフラのコード化や共有されたVCSリポジトリがいかに生産性へ貢献するか、注目された頃とも考えられる。

つまり10年前と今の大きな違いは、開発における試行錯誤の速度だ。自動テスト、継続的デプロイ、カオスエンジニアリング、コンテナなどの様々な技術が生まれたことで、ソフトウェアがより素早く変化するものになっている。またソフトウェア開発の現場に経験主義の考えが強く根付いていることや、スタートアップとソフトウェアの相互の結びつきから、ソフトウェアが素早く変化できることがビジネスで有利に働くと強く信じられるようにもなっている。DevOpsやSREが生まれた背景もそれを裏付けているように思う。

速度が違うとは、どういうことか。例えば10年前の私に「Gradle Pluginの開発でテストに使うGradleのバージョンを増やしたい、なぜこんなことをJenkins管理者にお願いしなければならないのか」と言ったところで、「え、メール一本だし別にいいじゃん、何気にしてるの？」と不思議がられるに違いない。今はこれもPRひとつで実現可能だが、当時はそうではなかった。
他の例では、Mavenのバグを回避するためにバージョンを上げるとして、Jenkins管理者にお願いしてCI環境のバージョンを上げるだけでなく、各開発者の使っているMavenのバージョンまで上げるにはメールでバージョンを上げるよう依頼しつつmaven-enforcer-pluginで意図しないバージョンでビルドした場合に落ちるようにする必要があるだろう。さらに複数プロジェクトで実施するにはすべてのプロジェクトのpom.xmlを書き換えるか、あらかじめ親pomを作成して各プロジェクトに依存させ、maven-enforcer-pluginの設定を親pomに加えてprivate maven repositoryにdeployしてから各プロジェクトのpom.xmlを書き換える必要がある。文が長くてわかりにくいが、とりあえず面倒なプロセスが必要ということが伝われば良い。これもMaven Wrapperを使うようにすればPRひとつで済む。ミドルウェアについても同様で、Dockerfileなりdocker-compose.ymlなりAnsibleなり、何らかのファイルを少し変えるだけで意図したバージョンが確実に使われるようにできる。

こうして製品ないし開発環境を変えることがPRひとつでできるようになっただけでなく、マージ前のプロセスの簡素化・短縮化も図られるようになった。Tracでチケットを作って手元で対応するパッチを作ってReview Boardでレビューして問題なければパッチを適用するという複数のシステムを行き来する方法から、検証済みマージやPull Requestといったひとつのシステムで完結する方法へと変化した。またPre-merge build自体の実行時間も各種技術によって短縮されたし、ミドルウェアを使った統合テストも使い捨て環境を作りやすくなったので実行したいときに他のテストとの衝突を気にせず実行できるようになった。気にすることが減るというのは、Pre-merge buildでいろんなことを自動的に確認・検証したいというニーズを満たす上で必要だ。統合テストを回して互換性が壊れていないことを確認したいのに、DBが他のテストで使われているので待つ必要がある、なんて事態は避けたいのだ。

10年前と今の「生産性」を比べたときに、この開発プロセスの違いは大きな差を生むに違いない。

自動化、有機的連携、そしてリアクティブワークフロー

別の表現をすると、10年前は省力化のために作業の自動化が推奨され、それで十分競争力を生んでいた。その後、自動化された作業を有機的に繋ぎ合わせるようになり、CIパイプラインが登場した*3。その後でWebAPIやWebHook等の整備により、PRやcron以外でもパイプラインを自動発火することが増え、リリース作業やデプロイ、ドキュメント整備など多様な使い方をされるようになったと言えるだろう。 近年は脆弱性対応の観点から、ライブラリのリリースや脆弱性の公開をイベントとして使えるようになってきている*4が、これも従来なら開発者が各ベンダからの情報をRSSやSNS等を使ってウォッチする必要があった。

さてジョブの並列実行・並行実行ならびに有機的連帯についてはPipelineやWorkflowという用語が存在するが、このヒトの指示による実行ではなくイベントに応じた実行を意識した組み方については特に固有名詞がないように思う。イベントを受け取りステートレスな要素をつなぎ合わせて実行する様がリアクティブシステムの考え方に近いことから、ここではリアクティブワークフロー（Reactive Workflow）と呼ぶ。

なぜリアクティブワークフローが好ましいのか、その説明はReactive Manifestoが流用可能だ。使いたいときにすぐ使え（Responsible）、ジョブがステートレスなため壊れても再実行でほぼ対処でき（Resilient）、ビジネス上の要請あるいは技術的な必要性から生まれる突発的な負荷に対応する（Elastic）。また各ジョブの入出力がコミットハッシュやパラメータなど不変なものがほとんどであることと、ワークフロー基盤がサーバーレスアーキテクチャで構成されることが多いことから、メッセージ駆動のメリットも享受できると思われる。

おそらくユーザ（開発者）としてはResponsibleであることが最も重要だ。JenkinsのマスターやエージェントをLAN内に構築していた（サーバーレスでなかった）ころは、資源をうまく使うように夜間に定例処理を回したり週末にテストを回したりといった工夫が必要だった。これはリアクティブワークフローを組み、資源の管理をSaaSあるいはIaaSに押し付けることで、必要なときに必要なだけ実行し即結果を受け取れるようになった。Elasticであることも合わさって、開発者が本質的でない気遣いを排し（ビルド並列化などによって）開発速度を上げることに貢献できるわけだ。

こうしてみると、コンテナ（ジョブはコンテナ内で走ることがある）やサーバーレスといった新技術によって最近のDevlopment Workflowも支えられているのだなと感じる。

コラボレーションの重要性

近年の開発手法、例えばSREやDevOps, Lean, cross-functional teamについて紐解くと、個人の役割を明確化・細分化すると同時に組織のサイロ化を防ぐことに多大な関心を持っていることが伺える。著名なのがError Budgetで、Reliabilityの実現を目的としたSREと多様なデプロイを多数行う（ことによるプロダクトの改善）を目的とした開発という一見相反する行動原理を持つ役割をうまく「同じ課題を解決するチーム」へと仕立て上げ、サイロ化を防いでいる。詳しい話は書籍に譲り割愛する：

The DevOps ハンドブック 理論・原則・実践のすべて

• 作者:ジーン・キム,ジェズ・ハンブル,パトリック・ボア,ジョン・ウィリス
• 発売日: 2017/06/22
• メディア:単行本（ソフトカバー）

他にもプロダクトマネジメントトライアングルでも、立場が異なるヒトをいかに連帯させ機能させるかという関心ごとについて説いているが、その議論の中心はProductという誰もが共有しているモノにある（と私は解釈した）。デザイナーは開発者の生み出す価値をユーザーに届けるためにどうデザインすべきか、経営は開発資源を効率的に使うためにどうマネジメントすべきか、開発者はユーザに製品の魅力を伝えるためにどうコミュニティを築くべきなのか。そのすべてのコラボレーションが製品というOutputを通じてOutcomeを生み出す。開発、ビジネス、ユーザのどれを取っても独立しておらず、すべてがProductや他のロールと繋がっている。プロダクトマネジメントはヒトのコラボレーションを認めてはじめてできるものだ。

もうひとつ、面白い観点にロックスターエンジニアというやつがある。有能なエンジニアはそうでないエンジニアの10倍、あるいは27倍の生産性を持っているというold termだ。これもたぶん昔は説得力のある概念だったのだろうが、近年では全く使われなくなっている。代わりにtechnology raderでは10x teamという表現を紹介していて、素晴らしいoutputが素晴らしいチームによって生まれるとしている。これはGoogleが研究で明らかにしたチームやマネジメントの重要性によっても肯定されていると言えよう。

つまり近年のソフトウェア開発の現場では、個人を育てること以上にチームを育てることに関心を持っている。個人を育て組織を開発することで、ビジネス上の競争力を効率的に高めていけると信じているわけだ。 チームを育てるには様々な手法があるだろうが、成長が内省によって生まれることを考えればBlameless Postmortemのような事実と向き合い理性的な議論を通じてより良い姿を模索する活動には一定の価値があると思われる。失敗時に限らず日頃から反省の機会を持つこと、Scrumで言うSprint Retrospectiveのような定例イベントも助けになるだろう。

さてこの手のイベントをやってみるとわかるのが、準備のコストが高いことだ。Postmortemのためには事実をリアルタイムに記録しなければならないし、ベロシティを測るには日々チケット消化の状況を記録する必要がある。自分とは違う専門性を持つチームメイトに向けて資料を整理することもあるし、わかりやすくするためにグラフを整理することもあるだろう。定期的なイベントの準備をすべて人力でやっていては、継続的にコストを払うことになる。

Development Workflowはこのコストを下げることができる。人手を使って証跡を残していた運用を、自動的にログを残す運用に変えられる。ChatOpsやGitOpsが最もイメージしやすいだろう。 また自動化やSaaSなどによって、相手の専門性に合わせたビューやファイル形式で情報を提供するコストも下げられる。例えばデザイナの要請を受けてCSSを変更したときに、それが既存ページにどういった影響を及ぼすか、percyのようなGUI regression testingが整っていればスクリーンショットを取ること無くPR一本で説明できる。

まとめ

とりとめのないままに書き下した結果、ひどいことになってしまったが。

結局は「cross-functional teamとして高速度で成果を出す」という時代の要請に自動化やコンテナ、サーバーレスといった技術が応えた形がいまのリアクティブワークフローなのだと思う。機械学習や業務改革の文脈で「機械ができることは機械にやらせて、ヒトはヒトにしかできないことをやろう」と言われるが、開発プロセスにそれを適用したものがこれだ。 事実と向き合い考えることこそが、ヒトにしかできないことだ。事実（ログ）の集約や解析、テストやビルドといった開発作業、ライブラリの更新や脆弱性報告の精査といった定例作業はすべてリアクティブワークフローにやらせる。私達は上がってきたデータをもとに考え、議論し、内省し、立てた仮説をもとに次のPRを作る。Gitにpushすれば機会が変更の妥当性をまず検証してくれるので、ヒトは既知の問題が無いことを前提に議論を尽くすことができる。タブ文字かスペースか、括弧の位置はどこにするかなんて議論をPRでする時代ではもう無いのだ。

もちろんここで議論したのはある種の理想形で、すべてのプロジェクトがこれを満たせるとは限らない。私が見ているFOSSプロジェクトにも、まだ手動で色々とやらなければリリースすらできないものもある。また10年前でも既にリアクティブワークフローを回していたところもあるかもしれない。

いろいろ手を出しすぎてごちゃごちゃしてきているので、頭の中を整理する目的でここに書き出す。

reproducible build

Mavenのメーリスで話題に出ることがあり知った。特別新しい概念ではないけどある種のunlearningであり、ビルド職人は見といて損ないやつ。

reproducible-builds.org

端的に言うと、誰がどこでビルドしても同じアーティファクトができるようにしようという話。実はJavaのビルドツールでアーティファクト（主に.jarファイル）を作ると、そのビルド結果は常にバイナリ等価とは限らない。ビルドした日付がMETA-INFに入ったり、同梱されたファイルはすべて同じなのにZIPに突っ込む順番が違ったりと、ビルドした時刻や環境によって異なる結果が生まれることがある。詳細はDZoneの記事を参照。

なぜこれが着目されているかは公式サイトに書かれているが、つまるところ「アーティファクトとソースコードの対応」を検証する術として期待されている。
従来は「本当にこれが公式に配布されているファイルかどうか」はchecksumや署名で確認できていたが、それ以前にバージョン v1.0.0がVCSの v1.0.0タグから本当にビルドされたのかを検証することができなかった。ので例えばビルドとリリースのプロセスを攻撃することで、悪意あるコードが含まれた v1.0.0がリリースされる可能性を検証するコストが高かった（CHANGELOGやRelease Notesではなくバイトコードを読む必要がある）。これがreproducible-buildにより、手元で v1.0.0をチェックアウトしてビルドした結果と配布物を突き合わせることで攻撃の可能性をまず検証できるようになる。

これがunlearningだと考える理由は、ビルドツールのデフォルト設定だと達成されないから。つまりコミュニティで可搬性のあるプラクティスと考えられてきた常識を疑い変えていくフェーズに今はある。まぁ落ち着いて考えればビルドした日付をアーティファクトに埋める必要性など皆無なわけだが、昔は「このJenkinsジョブが作った.jarだ」ということを明確化するためにファイル指紋に加えてユーザ名やらホスト名やらいろいろMETA-INFに組み込んでいたような気がする。

なおMavenだとプラグインが提供されているので、これをプロジェクトに適用すればよい。Gradleのもあるけど活発ではないので、カバーされていない問題もあるかもしれない。Gradle公式には特にまとまった情報はなく、依存先のバージョン固定に関するドキュメントにさらっと書いてあるくらい。

visual testing (GUI regression testing)

Seleniumを使ったGUIテストについては従来からやってきたが、主なテスト対象はアプリの挙動だった。これに加えてUIの崩れについてもテスト対象とする動きがある。JS界隈・CSS界隈は動きが速く、それでいて多様な環境で動作しなければならないということで、互換性維持の難度がもともと高い。これがUIとなると解像度についても考える必要性があり、余計に複雑化する。例えば最新のブラウザでベンダプレフィックスがサポートされなくなったり、flexboxの挙動が変わったりしたときに、レガシーブラウザでの挙動を変えること無く新しいコードに実装を置き換えていく必要があるが、これを手動でやっていると大変。

visual testing自体は7年前に試行錯誤しているブログがあるくらい仕組みは簡単で、スクリーンショットを撮っておいて保存、次回実行時に比較するというもの。なおまだ名前が定着していないらしく、visual testingとかGUI regression testingとか、みんな好きに呼んでいる。SaaSベンダーやFOSSプロジェクトの比較をするならawesome-regression-testingが役に立つ。

Seleniumを使ったGUIテストが安定かつ高速に回せる環境がすでにあれば、導入自体は難しくない。ブラウザやOSのベータ版でテストを回す仕組みとか、失敗したテストだけを再実行する仕組みとか、テストを複数ノードに分散して実行する仕組みとかがあれば強みを活かしやすい。percyのペーパーによるとUIの変化が確認されたケースの96%はapproveされたようなので、visual testingが失敗したら無条件にマージさせない的なPR運用ではなく、開発者に判断材料を提供する仕組みとして運用する必要性がありそう。

ここまで書いてみて、なぜここ最近でSaaS/PaaS界隈が盛り上がってきたのかがよくわかっていないことに気づいた。BrowserStackのリリースノートによると実デバイスによる機能を提供したのが2019年2月、AWS Device Farmに至ってはSeleniumテストの実行をサポートしたのが2020年1月ということで、最近の動きであることは間違いなさそう。自分の直面している課題に最適なのは疑い無いので構わないが。

cross-functional team

従来の「組織の役割を単純化して相互連携によって業務を進める組織設計」の課題を解決する手法としての「単一チームに複数の役割をつめこむ組織設計」と認識している。チームができる意思決定を増やし、組織の壁を超える頻度を減らし、ビジネスのagilityを上げることを目的とする。縦割り（silos）の弊害を解消するために全員をひとまとめにしようというアイデアと考えるとわかりやすいが、チームリーダーの責務が大きく変わるので導入は慎重にしたほうがいい。

cross-functional teamの背景にはcontinuous deployment, DevOps, servant management, capability modelといったトレンドがあると理解している。「マネジメントが理想を描いてメンバーを従える」独裁型と違い、「ミッションを明確化し、専門家がミッション達成のために必要なもの全てを提供するために腐心する」調整型のマネジメントになる。従来型の組織ではチームの長はメンバーと専門性を共有していることが多かったが、cross-functionalチームではそうではないので、独裁のしようがない。これがcross-functional teamとservant managementそしてcapability modelが切り離せないと自分が感じる理由。ただ今まさにaccelerateを読んでいるので、この辺の意見は今後変わるかもしれない。

まだよくわかってないのがチームの小ささ（two-pizzas team）とバス係数の両立。cross-functionalとは言えどもチームは充分小さく活発に議論ができなければならないはずで、例えばDX Criteriaでは5-12名の規模を目安としている。バス係数を考慮し各roleを2名以上とすると、どんなに頑張っても入れられるrole数は2−4個に制限されるはずで、専門性の細分化が進むシステム開発において企画から運用まですべてのプロセスで必要になるすべての専門性をチームに入れることは不可能だとわかる。のでcross-functional teamを採用する組織においても、ある程度の縦割りは残るだろう。その「残し方」として著名なのはSREだが、他にもセキュリティやUXなど組織横断的に統制をかけてやるべき活動については専門のチームが残ると予想する。その際はcross-functional teamとは異なる解決策が必要で、それがSREではerror budgetになる。silosの壁を壊すには「同じ問題を解決する1つのチームなんだ！」的精神論ではなくて、仕組みまで落とし込むことが肝要。

ではどういったroleをcross-functional teamに入れられるかというと、すぐに思いつくのがテスト周りの責務。テストの知見を持ったエンジニアを企画段階から参画させやすくなり、手戻りを減らし保守性を向上すると期待できる。testabilityに配慮したコードかどうかをPRレビューで見てもらえるし、組織としてPOVがひとつ増えることのメリットが大きいはず。Opsも同様。

ちょっと脱線するけどテストはビルドエンジニアのキャリアパスとしてもわりとアリだと思っていて、自動テストの重要性がどんどん上がっている昨今、テストをどうCD pipelineに組み込むか・高速に終えるか・安く実行するかというビルドエンジニアならではの貢献ポイントが多々あるように見受けられる。もちろん別々のroleとしてチームに配置してもいいんだけど、GoogleのTEの例にあるように、1人が知識を持ち合わせてその掛け算で問題解決を図るのは十分可能なレベルだと思う。

Product Management

Strategic Management, Visionary Leadership, Project Management (PjM)とやってきて、いざProduct Management (PdM)に首を突っ込んでいるのだが。今のところは「プロダクトを形作る組織の全体像を把握して、課題に優先度を付けて解決する」という解釈しか持てていない。

Product Managementわからん超人してるんだけど、これ俯瞰してバランスしろっつー、ビジネスとエンジニアリングわかるフルスタックジェネラリストじゃないと回らんのではないの？ある程度は理解浅くて良いとは思うが

— ゲーマーじゃないってば (@Kengo_TODA) May 27, 2020

すえなみさんのツイートに共感した。

最近、プロダクトマネジメントとプロジェクトマネジメントを区別しないことを心がけています。

— 焼肉 (@a_suenami) May 19, 2020

PjMとPdMに限らず、最近はアジャイルとウォーターフォールにも差が対して無いんじゃないかみたいな気持ちになってきていて、学習の振り子が振り切った感じがする。そのうち逆側に振れると思うけど（比較対象表とか書き出すやつ）。

ウォーターフォールだからinspectionがいらない訳では無いし、アジャイルだから計画や見積がいらない訳では無いんだよなぁ。最近はもう「どっちも本質的に同じものでは？」って思ってしまってる自分がいるよ……

— ゲーマーじゃないってば (@Kengo_TODA) May 13, 2020

FOSS開発で細かいやらかしを積み上げてきたのでまとめる。

テストの失敗原因レポートをartifactとしてアップロードしそこねる

actions/upload-artifactを使ってテストレポートをartifactとしてアップロードする際、以下の書き方だと失敗する。

# bad
    - run: |
      ./gradlew test --no-daemon --stacktrace
    - uses: actions/upload-artifact@v2
      with:
        name: reports
        path: build/reports

これはテストが失敗した時点で後続のstepsが実行されなくなるため。明示的に失敗時でもアップロードされるように指示する必要がある。

# bad
    - run: |
      ./gradlew test --no-daemon --stacktrace
    - uses: actions/upload-artifact@v2
      if: always() # this config is necessary to upload reports in case of build failure
      with:
        name: reports
        path: build/reports

forkからのPRではGITHUB_TOKENを除くsecretsを参照できない

secretsの存在を前提にしているコードがあると、forkからPRをもらったときにビルドが通らなくなる。

# bad- name: Decrypt file
    env:GPG_SECRET_PASSPHRASE: ${{ secrets.GPG_SECRET_PASSPHRASE }}
    run: |
      gpg --quiet --batch --yes --decrypt --passphrase="$GPG_SECRET_PASSPHRASE" --output decrypted encrypted
      # -> gpg: missing argument for option "--passphrase="

後述する方法でsecretsが空かどうか確認する必要がある。

if では $VAR で環境変数を参照できない

ifで書くのはbashじゃくてexpressionなので、runに書くのと同じノリでやると失敗する。

# bad- name: Run SonarQube Scanner
      env:GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        SONAR_LOGIN: ${{ secrets.SONAR_LOGIN }}
      if: ${{ $SONAR_LOGIN !="" }}
      run: |
        ./gradlew sonarqube -Dsonar.login=$SONAR_LOGIN --no-daemon

正しくはenvコンテキストを参照する（なお${{ .. }}で囲むのは必須ではない）か、

# good- name: Run SonarQube Scanner
      env:GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        SONAR_LOGIN: ${{ secrets.SONAR_LOGIN }}
      if: env.SONAR_LOGIN !=""run: |
        ./gradlew sonarqube -Dsonar.login=$SONAR_LOGIN --no-daemon

bashで統一して読みやすくしたいなら runの中で判定する。

# good- name: Run SonarQube Scanner
      run: |
        if ["$SONAR_LOGIN" != ""]; then
          ./gradlew sonarqube -Dsonar.login=$SONAR_LOGIN --no-daemon
        fi
      env:GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        SONAR_LOGIN: ${{ secrets.SONAR_LOGIN }}

たまに研究への協力依頼などをいただくのですが、それに対するポリシーをこちらにまとめます。説明用です。

連絡先

Twitterかメールを推奨しています。メールアドレスは私のウェブサイトで紹介しています。

サーベイに対する協力

常識的なボリュームのサーベイであれば協力させていただきます。URLと回答所要時間を共有いただければそれで充分です。

その他の協力

SpotBugsの使い方やbytecode manipulationなどについて、突っ込んだ質問をいただくことがあります。こうしたクローズドな質問はStackoverflowやGitHubで行っているFOSS活動とは一線を画するものですし、対応コストも高いので、基本的にはお受けしません。まずは対応するFOSSコミュニティ、あるいは周囲の指導担当者からの協力を得るようにしてください。ウェブサイトやメーリングリスト、GitHubプロジェクトなどで質問を行えることが多いはずです。

どうしても必要と思われる場合は、所属機関のメールアドレス（.ac.jpドメインなど）から所属と研究目的、得たい協力について説明するメールを送ってください。この際、指導担当者もCCに入れてください。指導担当者はあなたの指導に何らかのポリシーを持っているはずで、それを逸脱する助力をすることを避けるためです。

この記事は、2013年に書いた記事を現状に合わせてアップデートするものです。結論から言うと、当時から id:miyakawa_takuさんがおっしゃっていた「APIは依存に含めて良い」を支持するものです。あるいは無難にバージョン 1.7.30を使っておきましょう。

blog.kengo-toda.jp

slf4j-apiに1.7, 1.8, 2.0の3バージョンが生まれた

現在slf4j-apiには3つのバージョンが存在します。現在のSLF4Jエコシステムを考える上では、これらの違いを抑える必要があります：

1.7.x

Java 1.5から利用できるバージョンです。安定版にこだわるなら未だこのバージョンを使う必要があります。

1.8.x

JPMS（a.k.a. jigsaw）を採用しServiceLoaderを使ってBindingを呼び出すようになったバージョンです。Java 1.6が必要です。alpha0が出てから3年以上経ちますが、未だbeta4です*1。作業用ブランチも残っていないので、1.8は安定しないまま2.0開発に移ったものと思われます。

2.0.x

このバージョンからはJava 8が必要です。Fluent Logging APIが実装され、ログの書き方の選択肢が増えました。新しい実装はinterfaceのdefault methodを使って実装されているため、slf4j-api単体で変更が完結しており、binding側は変更なく利用できます。

複数バージョンの存在を踏まえ、ライブラリ配布者は何を気にするべきか

前出の情報を紐解くと、3バージョン間に眠る2つの差が見えてきます：

1. APIの差。slf4j-api 2.0.x には従来存在しなかったメソッドが増えている。これに依存したライブラリのユーザは、slf4j-api 2.0.xを利用しなければ実行時に NoSuchMethodErrorが出るかもしれない。
2. binding選択手法の差。slf4j-api 1.7.x と1.8.x以降では実装を決定するための手法が異なるため、apiとbindingのバージョンは揃える必要がある。

このうち2については、アプリケーションをビルドする開発者に責任があります。実行時にCLASSPATHにどのバージョンのAPIとbindingを含めるか、彼らに決定権があるからです。のでライブラリ提供者としては、彼らに選択肢と必要な情報を提供しつつ、1に取り組む必要があります。

考慮すべきはライブラリでFluent Logging APIを使っているかどうか、です。このAPIに依存していないなら、実行時にslf4j-apiのどのバージョンを利用しても問題ありません。

もし使っているなら、その旨をユーザに伝えて実行時にもslf4j-api 2.0.xを使ってもらう必要があります。そしてそのための最もsemanticな方法が、compileスコープで依存することです。ライブラリが2.0.xに依存しているにも関わらずに古いバージョンで依存が上書きされてしまった場合、ビルドツールによっては警告を発してくれます。Gradleの場合はもっと細かな依存指定も可能です。

よって、現時点では slf4j-apiには compile スコープで依存することが望ましいと思います。bindingは引き続きprovidedあるいはtestスコープが望ましいでしょう。

どのバージョンを使うべきか

安定版にこだわるなら1.7.xを、JPMSを使いたいなら1.8.xか2.0.xを、Fluent Logging APIを使いたいなら2.0.xを選ぶことになるでしょう。

1.8.xと2.0.xはJPMSに準拠しており、モジュールを利用したビルドを行っているプロジェクトでも安心して使うことができます。ただどちらも安定版が出ていない点には注意が必要です。

マイナーケース：ライブラリとしても実行可能ファイルとしても配布する場合

私がメンテに参加しているSpotBugsは、spotbugs-gradle-pluginやspotbugs-maven-pluginなどから利用されるライブラリとしての性質と、CUIやGUIで実行される実行ファイルとしての性質とを持ち合わせています。内部的にはDistribution Pluginで配布用パッケージを作成しています。

この場合、Maven Centralにアップロードする pom.xmlにはSLF4J bindingを依存として追加しない一方で、distribution pluginの対象にはSLF4J bindingを追加する必要があります。

runtimeOnly依存を使うことが素直な解決になるでしょう。configurations.runtimeClasspathを配布用ファイルに入れる形になります。

ただSpotBugsの場合はEclipse用依存を別に管理している（Eclipse用のruntimeClasspathにはSLF4J bindingを入れたくない）ので、以下のようにconfigurationを自前で定義しています。

plugins {
    id 'distribution'
}
configurations {
  slf4jBinding
}
dependencies {
  implementation 'org.slf4j:slf4j-api:1.8.0-beta4'
  logBinding ('org.apache.logging.log4j:log4j-slf4j18-impl:2.13.3') {
    exclude group: 'org.slf4j'
  }
}
distributions {
  main {
    contents {
      from ([configurations.compileClasspath, configurations.slf4jBinding]) {
        into 'lib'
        include '**/*.jar'
      }
    }
  }
}

前回の投稿で、SLF4Jには現在1.7、1.8、2.0の3バージョンがあるという話をしました。

これについてSLF4Jのuser向けメーリングリストで質問をしたところ、1.8の開発中にFluent Logging APIを追加するために2.0へとメジャーバージョンを上げたという旨の回答を得られました。つまり1.8は今後開発されず、安定版も出ないことになります。

[slf4j-user] Will version 1.8 be released in future?

よって現時点では1.8を利用する積極的な理由はあまりないと思われます。ライブラリ開発者としては、JPMS（Jigsaw）あるいはFluent Logging APIが必要なら2.0、そうでないなら1.7を選択することが良いのではないでしょうか。

Bing検索で見つけるのが難しかったのでメモ。Project Reactorでページング処理を書く方法について。

例えばこういうAPIがあったときに、どう実装するか？

class Foo { ... }

class FooPage {
  @NonNull
  Foo[] getEntities();
  Optional<Integer> getNextPageNumber();
}

interface FooRepository {
  /** @param page 0-indexed page number */@NonNull
  Mono<FooPage> loadPage(int page);
}

class FooService {
  @Inject// use constructor injection instead in prod.
  FooRepository repository;

  @NonNull
  Flux<Foo> loadAll() {
   // TODO
  }
}

以下のようにFlux#expand()を利用する必要があります。引数には前回ロード時の値が入っているので、そこから次回のリクエストに使用するパラメータを算出します。大抵はサーバのレスポンスに次のページ番号が入っていたり、検索パラメータとして使用すべきトークンやIDが入っているはずなので、それを引き回す形になるでしょう。

  Flux<Foo> loadAll() {
    Flux<FooPage> fluxForPage = repository.loadPage(0).expand(prevPage -> {
      return prevPage.getNextPage().map(repository::loadPage).orElse(Mono.empty());
    });
    Flux<Foo> fluxForEntity = fluxForPage.flatMap(page -> Flux.fromArray(page.getEntities()));
    return fluxForEnttiy;
  }

Reactorはリソースの開放に using()を使うのもわかりにくかったですが、ページング処理もJavadocやGitHubを検索しても出てこないのでちょっと苦労しました。

そうですね。例えば2つのクエリをDBに投げて結果を合成する、みたいなことを書いてみると実感しやすいです。Statementをcloseする処理ももちろん書くのです。

— 達者でな (@Kengo_TODA) March 14, 2020

DBにクエリを2つ投げて合成する処理

例えばユーザーIDから所有するリソースを検索してその情報を返すAPIStream<Resource> find(long userId)を実装するとします。Resourceは大量に帰ってくる可能性があるので、List<Resource>ではなくStream<Resource>として扱います。実装はどうなるでしょうか：

// blocking API (wrong)try (UserDao userDao = daoFactory.createUserDao();
    ResourceDao resourceDao = daoFactory.createResourceDao();) {
  Stream<Long> resourceIds = userDao.search(userId); // ページング処理を隠蔽return resourceIds.map(resourceId -> {
    Resource resource = resourceDao.find(resourceId);
    return resource;
  }); // Stream<Result>
}

これは正常に動作しません。メソッドを抜ける前にtry-with-finallyブロックがDAOを閉じてしまうからです。 呼び出し元がStream<Resource>を閉じてくれることを期待して、以下のようなコードになるでしょう：

// blocking API
UserDao userDao = daoFactory.createUserDao();
ResourceDao resourceDao = daoFactory.createResourceDao();
Stream<Long> resourceIds = userDao.search(userId); // ページング処理を隠蔽// Streamが閉じられたらDAOも閉じる
resourceIds.onClose(userDao::close);
resourceIds.onClose(resourceDao::close);

return resourceIds.map(resourceId -> {
  Resource resource = resourceDao.find(resourceId);
  return resource;
}); // Stream<Result>

このように処理を遅延するコードはFutureでは書けません。Java8で登場したCompletableFutureを使うことになります。例えばUserにResourceがひとつだけ結びつく状態なら以下のように書けます：

// CompletableFuture
UserDao userDao = daoFactory.createUserDao();
ResourceDao resourceDao = daoFactory.createResourceDao();
CompletableFuture<Long> future = userDao.search(userId).whenComplete( ... );

return future.thenApply(resourceId -> {
  Resource resource = resourceDao.find(resourceId);
  return resource;
}).whenComplete( ... ); // CompletableFuture<Result>

が、Streamのように複数の値を返すモノに使うのは複雑な工夫が必要ですし、やりようによってはすべての値を一度にオンメモリに乗せてしまいます。 私の知る限りではReactorフレームワークやRxJavaの採用がこの問題へのスマートな解になります。例えばFlux#using()を使うと以下のように書けます：

// Reactor
Flux<Long> resourceIds = Flux.using(daoFactory::createUserDao, userDao -> {
  return userDao.search(userId);
}, UserDao::close);

return resourceIds.flatMap(resourceId -> {
  Mono<Resource> resource = Mono.using(daoFactory::createResourceDao, resourceDao -> {
    resourceDao.find(resourceId);
  }, ResourceDao::close);
  return resource; // Flux<Resource>
});

関連記事

blog.kengo-toda.jp

4年前の下書きが出てきたので、供養のために置いておきます。

SpringOne Platform 2016のKeynoteとSessionを、特にProject Reactor周りについて確認した。

• https://www.youtube.com/watch?v=Xm-KjMY_Z_w
• http://www.slideshare.net/SpringCentral/going-reactive-building-better-microservices-rob-harrop
• http://www.slideshare.net/SpringCentral/data-microservices-in-the-cloud
• http://www.slideshare.net/SpringCentral/designing-implementing-and-using-reactive-apis
• http://www.slideshare.net/SpringCentral/imperative-to-reactive-web-applications
• http://www.slideshare.net/SpringCentral/reactive-kafka
• http://www.slideshare.net/SpringCentral/reactor-30-a-jvm-foundation-for-java-8-and-reactive-streams

これらに最近考えていたことを加えて、マイクロサービスやサーバサイドリアクティブについて（利点や必要性は一旦論点から外したうえで）実現するためのあるべき論をざっくり整理したい。プライベートプロジェクトで検証済みではあるがチーム開発でも通用するかは不明である。

なお簡単のためRxJava用語のみ記述するが、Project Reactor等の用語で置き換えても良い（Single→ Mono, Observable→ Flux）。

あるべき論

APIサーバ＆BFF共通

• Repository（DAO）
  • 境界を超えないデータストアに対するアクセスを担うレイヤのこと。
  • Repositoryのメソッドは非同期I/Oを呼び出すことが期待される。よってSingleあるいはObservableを返すべき。
  • 戻り値がない場合（例えば更新処理）でも、内部の処理が正常に終了したかどうかを表現するために Single<Void>を返すべき。
  • 非同期I/Oを呼び出さないことが明らかな場合のみ、同期的にインスタンスを返しても良い。
• Service（ビジネスロジック）
  • ServiceのメソッドはDAOを通じて、あるいは境界外へアクセスするクライアントを通じて非同期I/Oを呼び出すことが期待される。よってSingleあるいはObservableを返すべき。
  • 戻り値がない場合（例えばジョブキューにジョブを登録する場合）でも、内部の処理が正常に終了したかどうかを表現するために Single<Void>を返すべき。
  • Repositoryから渡されたSingle/Observableのエラー処理（ログ出力等）は、
    • その Single/ObservableがControllerから利用されるのであれば、Service内で行っても行わなくても良い。
    • その Single/ObservableがControllerから利用されないのであれば、Service内で行う。
  • Serviceは冪等性を保つ必要がある。UUID version 1でID採番する場合などは、処理結果にランダム失敗した性が含まれるので扱いに注意する（Eventual Consistencyを意識する）。
• Client（境界外アクセス）
  • RestTemplate等を直接呼び出す実装が多く見受けられるが、サーキットブレーカーや監視や自動テスト容易性を考えると一枚抽象化を入れた方が良いと思われる。
  • 各マイクロサービス提供者がEntityと共にユーザに提供する。Serviceから呼び出され、HTTP等によるRPCを行う。よってSingleあるいはObservableを返すべき。
  • コレオグラフィ優先採用するならば、基本的には使用しない方が良い。
• EventBus
  • Serviceによって購読ないしpublishされる。
• Controller
  • モデルとしてSingleやObservableをテンプレートエンジンに渡す。テンプレートエンジンの機能に応じて、SingleやObservableを変換するかもしれない。CompletableFutureあたりが有望か。
  • 通信先サービスが正常動作しなかった場合、CircuitBreakerが落ちている場合のUIも考えておく。

BFFサーバ の実装

WebAPIを多数コールして1つのレスポンスにまとめるには、大きく分けて2つ実装パターンが考えられる。

1. サーバ内ですべてのサービスからのレスポンスを束ね、1枚のHTMLページやJSONデータをつくり上げる
2. サービスから逐次受け取ったデータをクライアントに横流しして、クライアント側で組み立てる（Server-sent Event, WebSocket, Big pipe etc.）
   • 2020年夏時点ではJSON listをうまく扱うJS手法はまだなさそう？Streams APIの安定化を待つ必要があるのでは。

完全な2だとBFFを作る意味が無いので、1を主体として見た目に影響の薄い部分で2のような遅延処理をを採用することが多いはず。しかし1のレスポンスを束ねる部分で各サービスに線形的に問い合わせてはレイテンシ低下が容易に発生するため、非同期I/Oを使った並行問い合わせが必要になる。

サーバ間連携

• メッセージキューには永続性が必要
  • コレオグラフィを志向してサービスを実装するためには「イベントを永続化してサブスクライバが何度も読みに行く」か「サービスを冪等にしてパブリッシャが何度もリトライする」かのどちらかになる。後者はパブリッシャがイベント発火によって行われる処理を知っている必要があるので、基本的には前者が好ましいと思われる（Webアプリだとパブリッシャが何度もリトライするような書き方だとユーザへのレスポンスが遅れるのも痛い）。
    • 2020年追記：一見意味不明だが、ここで言うサブスクライバとパブリッシャはサービス単位を指している（同一JVM内にあるインスタンスを比較しているわけではない）と思われる。前者はイベントが永続化することで、同じイベントを何度も聞きに行くケースのこと。複数種類のサブスクライバがいたり、サブスクライバが常時起動でなかったりするとこの必要性が生じるはず。後者は非同期処理を依頼する、例えば送信処理や投機的実行のケースで事実上リアルタイム性を求めているケースのこと。当時使ってたVertxがデフォルト設定で利用するhazelcastのイメージに引っ張られてそう。
  • このため、キューに記録されたメッセージは1回以上必ず読まれること、つまりロストがないことを保証したい。そのためにはキューに永続性が必要。
• サブスクライバごとにイベントの既読管理を行う
  • コレオグラフィを採用するならば、1イベントにサブスクライバが多数いることも予想されるため、メッセージ（イベント）がConsumeされたかどうかはサブスクライバごとに管理する必要がある。
  • 例えばKafkaなら、イベント種別＝Topic、サブスクライバ＝Consumer Groupとすることでサブスクライバごとの管理が可能。

備考

RxJava v2, reactive-streams そして Java9 Flow APIについて

現状では気にしないので良さそうな印象。

operatorすら用意されていないシンプルなreactive-streamsが、それだけ見ていれば詳細実装を気にしないで良いレベルのインタフェースになることは当面ないだろうし、そもそもそこを目指していないように見受けられる。ライブラリ提供者にとっては各プラットフォームを公平にサポートするための良いインタフェースになるだろうが、サービス開発者にとってはRxJavaやProject Reactorに直接依存・利用したほうがコードもシンプルになるし利用できる機能も多く便利なはず。

参考：

• reactive-streams.org
• Reactive Streams · ReactiveX/RxJava Wiki · GitHub
• RxJava 2.xについて - Qiita

zenn.dev がホットなのでフォロワーの皆様にアンケートを取った結果、「JavaのビルドとCIのキホン」が5票を獲得したので書きました。

私が書くなら何を読んでみたいですか

— 達者でな (@Kengo_TODA) September 20, 2020

書籍はこちらです。

zenn.dev

zenn.dev上では約26266文字と言われてるんですが、いや流石にそんなに書いてないはず。まえがきと付録を除いて6章構成です。 初心者向けを意図していますが、経験者でないとわからない論理的飛躍というか、結果ありきの書き方になっているところが残っているかもしれません。しばらくは継続的に更新します。

actions-setup-docker-compose, sonar-update-center-actionやsauce-connect-actionなど5つくらいActionを実装したので、Tipsをここにまとめます。

公式テンプレートを使う

TypeScriptでGitHub Actionを書くためのテンプレートが公開されています。とりあえずこのテンプレートを使うのがおすすめです。

github.com

使っているのはnpm, jest, @vercel/ncc, eslint, prettierとオーソドックスなもの。jestが気に入らなければ置き換えても構わないでしょう。

公式ドキュメントとライブラリに目を通す

さらっとで良いので以下のページは読んでおくといいです。どういった情報がどこにあるのか、これをするために何を使えばいいのか、情報の場所を掴んでおきます。

• 公式ドキュメント
• @actions/toolkit

特に以下は必要になる知識だと思われます：

• コマンドの実行はexecaのようなライブラリではなく@actions/execを使う
• GitHubAPIの利用はoctokit直呼び出しではなく@actions/githubにある getOctokit() を使う
• ファイル操作は fsモジュール直呼び出しではなく@actions/ioを使う

Fixtureの作成と読込

単体テストでは api.github.comとの通信を再現してコードの挙動を見ていくことになります。一応 docs.github.com に期待されるステータスコードやそのペイロードが書かれていますが、まだ内容が間違っていることがあったので実際にコードを回して確認することを薦めます。ドキュメントよりは @octokit/restの型情報のほうが信用できます。

レスポンスを再現するためのFixtureは、JSON.stringify(response.data)をJSONファイルに保存して作成します。tsconfig.jsonに"resolveJsonModule": trueを設定すればJSONファイルをそのままオブジェクトとしてimportできるので便利です。

// quoted from https://git.io/JIchkimport releases from'./fixtures/sonarqube-releases.json'const token = process.env.GITHUB_TOKEN
if(!token){thrownewError('No GITHUB_TOKEN env var found')}

test('searchLatestMinorVersion()',async()=>{const scope = nock('https://api.github.com')
    .get('/repos/SonarSource/sonarqube/releases')
    .reply(200, releases)
  expect(await searchLatestMinorVersion(token)).toBe('8.5.*')})

こうしたテストの面倒を見てくれる@octokit/fixturesもあるようですが、私はまだnockしか使っていないので詳しいことは不明です。

Changelog Blogを購読する

Actions周りはまだ動きが活発で、最近も add-pathコマンドなどが削除されたばかりです。 変更に追従するためにもChangelog Blogは購読をすると良いでしょう。

TBU: まだ自動化できていないこと

• dependabot が依存を更新したら distディレクトリ以下のファイルも更新する
  • pull_requestイベントでActionを発火させて、 npm run allした結果をcommit & pushするようにすればできるはず

昨年のに引き続きFOSS活動状況をまとめます。2020年12月21日時点の情報です。

概要：昨年比23%増

GitHubのプロファイルページによると今年のpublic contributionsは1,440で、昨年が1,166だったので約23%増です。commit 69%のpull requests 16%なので、引き続き手を動かしてコードを書けたと思います。

また今年からGitHub Enterprise Cloud（GHEC）の業務利用を始めたのですが、publicとprivatecontributions比はだいたい趣味:業務が7:3でした。業務の方に手を動かす余地があると考えるべきか、マネジメントなのにこんなに手を動かしてることを反省点として受け止めるか……。

今年の主なリリースはspotbugs-gradle-plugin 4.0.0~4.6.0、SpotBugsの4.0.0 beta5～4.2.0、あといくつかGitHub ActionをTypeScriptで実装しました。

SpotBugs周りの開発

今年はSpotBugs v4の安定版を出したことが1番大きいリリースでした。加えてGradleの非公開APIに依存してしまってメンテナンス性と性能の双方に問題が出ていたGradleプラグインをスクラッチで書き直したのも大きなプロジェクトだったと言えます。

SpotBugs v4がFindBugsよりも性能上で改善されていることはマイクロベンチで確認しましたし、MavenプラグインやGradleプラグインに加えてGitHub Actionもあるらしいので、特にFindBugsで困ってないという方も一度アップグレードを検討してみると良いと思います。

その他

この夏ごろにSLF4Jがメンテナンスされるのか知る目的で、チケットやPRの整理をしたりMLにメールを送ったりという活動をしばらく続けていました。私個人の結論としては1.8は使うべきではないし2.0も先行き不透明なので、今後は極力Log4j 2をLogging Facadeとして使うべきだろうと考えています。

• SLF4Jの1.8は安定版が出ないので2.0を使おうという話 - Kengo's blog
• Javaライブラリを配布する際のログ周りにおける配慮と実践 2020 - Kengo's blog

OASISの定めるSARIFに興味を持ってSpotBugsレポートとしての実装を進めています。JSONスキーマの制約から望ましい実装ができていない状態が続いているので、いずれテコ入れしたいところです。

Elastic社のブログをきっかけに、最近見かける新しいライセンスについて個人的に調べてみた。私は専門家ではないので要注意。公開情報も隅々まで追えているわけではないし。

なお一部ライセンスはOpen Source Initiative (OSI)による承認を受けていないので、ここではオープンソースライセンスではなく単に「ライセンス」と書くことにする。

新しいライセンスが誕生している背景

• 従来のオープンソースライセンスが再頒布以外の利用をあまり想定していなかった。
• Open-core modelないし完全オープンソース戦略を採る企業が自衛策を必要とした。
• 既存のライセンスが難解なため、理解しやすいライセンスが求められた。
• OSS活動を収入に繋げるためのモデルが試行錯誤されている。

新しいライセンスを導入しているプロジェクト（一例）

各種ライセンス

GNU Affero General Public License (AGPL3)

言うほど新しくない。2010年に公開されたnippondanji氏のスライドを参照。

Business Source License (BSL)

MariaDBが作成、v1.1が最新。以下説明文をサイトから引用：

BSL is a new alternative to Closed Source or Open Core licensing models. Under BSL, the source code is freely available from the start and it is guaranteed to become Open Source at a certain point in time (i.e., the Change Date). Usage below a specific level in the BSL is always completely free. Usage above the specified level requires a license from the vendor until the Change Date, at which point all usage becomes free.

一定期間後にオープンソースになる（MaxScaleならGPLのv2以降になる）ということは、旧バージョンのサポートをユーザ自身が行うことも他の企業が請け負うことも可能ということ。最新バージョンの開発に注力したいLicensorと、サポートが切れたときの対応を懸念するユーザとの双方に利がありそう。以下のQ＆Aはこれを意図しての記載と思われる。

Q: What are the main benefits for a company using BSL for their product?

A: BSL allows anyone to work on the code, both for their own benefit and that of others. It also generates trust in the BSL product, as there is no lock-in to a single software vendor.

このときusage limitsの定義はLicensorに委ねられている。例えばMaxScaleだとサーバ台数で絞っていて、2台までならどのような用途でも制限なく利用可能。このため”自衛策”になると期待される。

ちょっと気になるのはChange Dateの変更タイミングで、FAQには以下のようにメジャーバージョンごとに設定するものとある。マイナーバージョンごとにEOLを設定したいケースもあると思うのだけど。

Q: Will the Change Date remain constant?

A: No. Each new major version of the software will have its own Change Date.

Server Side Public License (SSPL)

今回Elasticが採用したライセンスで、MongoDBも利用している。GPLv3をベースにしているらしい。

AGPLv3をベースにしなかった理由として、AGPLv3のRemote Network Interactionの定義が曖昧で市場に混乱を生んでいたと書いてある。AGPLv3との違いが公式サイトで配布されているので具体的な違いを容易に確認できる。

このライセンスはAGPLv3同様、改変したソースコードの公開を求めるだけ。ソースコードを変更することなくサービスとして提供する場合は、特に制約はない。 このため完全オープンソースなプロジェクトよりは、基本機能のみオープンソースにする（サービス化のキー機能をクローズドに開発している）Open-core戦略向きと言える。

言い換えると、SSPLを適用するだけでは他の企業に "as a Service"を展開される可能性は残ってしまう。事実Elasticは追加機能（Gold+）のソースコードは商用ライセンスのみでの提供としている。Elastic Licenseの方もBSLの精神を引き継ぐシンプルなものにしたいと考えているようだ。

Parity Public License

Husky v5が採用しているライセンス。7.0.0が最新。GitHubで各種ドキュメントが公開されている。あまりアクティブじゃなさそうというか、さほど導入実績がなさそうというか、Huskyもよく使う気になったなぁという感じ。READMEにはアーリーアクセスが完了したらMITに戻すとも書いてあるので、試用という立ち位置なのだろうか。

無償で自由に使えるし共有も可能だが、ライセンスされたソフトウェアを使ってビルドされたソフトウェア（software that builds on it）もまた同様に公開されなければならない。このbuilds on itという表現が珍しい。Huskyで使われているということは、ライブラリとしてリンクしたソフトウェアだけではなく、このソフトウェアをdevDependenciesに入れて利用したすべてのソフトウェアに対して効力があるものと推測される。ホントか？

またライセンスにDon’t make any legal claimという文が入っているのも気になる。Facebookが”BSD + Patents”でやらかしたのと何が違うんだろう。ここまでくるとIANALなのでさっぱりわからない。

Patron License

Husky v5が採用しているライセンス。1.0.0が最新。他のライセンスと組み合わせて使う。 支払いを行うことで他のライセンスが持つnoncommercial or copyleftの制約を外すことができる。つまり商用利用やソースコード改変がしたかったら支払いをするように、ということ。

Husky v5は自身のライセンスを「License Zero Parity 7.0.0 and MIT (contributions) with exception License Zero Patron 1.0.0」としているが、整理すると：

• OSSプロジェクトではv4同様に無制限で利用可能
• 貢献はMITライセンスに準拠可能である必要がある
• 例外的に、GitHub SponsorsかOpen Collectiveでプロジェクトを支援すれば商用利用・ソースコード改変も可能

ということらしい。Huskyは2年前からnpm install時に寄付を呼びかけていたので、金銭的支援を得ることがライセンス導入の主目的と思われる。サービスではないOSSが選択可能な収益につながるライセンスは現状他になさそうなので、Huskyが先鞭をつけてくれるといいなぁ。

結局こうしたライセンスは勝手に "as a Service"されることへの自衛策になるのか

• BSLを適用することで、サーバ台数などに制限をかけることができそう。Elasticの語る将来の計画を見る限りでは、有償モジュールの代替機能開発・利用を禁止する拘束力を持たせることも可能と見ているのかも。
• 完全にソースコードを公開しているプロジェクトの場合、AGPLやSSPLを適用しても"as a Service"への抑止力は得られないが、サービス提供側に改変内容を公開する必要性が生じる。それでも大規模なインフラを持っているクラウドベンダーに目をつけられると競争力を発揮できなさそう。このあたりはReadTheDocsのような会社が今後どう動くか、vercelのようなOSSそのものはサービス化しない会社がどうなっていくかを注視したい。
• Open-core戦略を採るプロジェクトの場合、AGPLやSSPLを適用しても"as a Service"への抑止力は得られないが、サービス提供側に改変内容を公開する必要性が生じる。非公開モジュールと同じ機能を持つモジュールをクラウドベンダーが実装し"as a Service"を実現することに対する抑止力をどう持たせるかが課題か？
• Patron Licenseは商用利用自体を制限するライセンスと組み合わせなければならず、"as a Service"だけを制限したい場合には使いにくそう。

揺らぐオープンソースの定義

これらのライセンスを適用すると厳密な意味でのオープンソースではなくなるわけだが、より強力かつ実情に沿ったコピーレフトを実現するという意味でも、オープンソースの定義自体が更新を必要としていると見ることもできそう。"as a Service"を自由に提供できるのも、ひとつのopennessではあるわけで。

どんどん「オープン」の定義がすれ違っている。

私から見ればカネが落ちなければベンダもコミュニティも立ち行かなくなるのは明白で、AWS主張の方が顧客中心でないというかサステナブルでないと映る。 https://t.co/NY1YYgmT7U

— 名前がコロコロ変わる (@Kengo_TODA) December 23, 2019

ライセンスが乱立しても良いことはないので、OSIなどの団体がいずれBSLなどを追認するような流れになると良いなぁと思う。

以上。間違っている箇所があれば、はてなブックマークかTwitterでご指摘いただけるとありがたい。

ITエンジニア本大賞2021で紹介されていた「ドメイン駆動設計入門」（以下、本書と呼ぶ）が、DDDを学ぶ上でわかりやすかったです。一応他のDDD本も数冊読んではいたのですが、どうしてもユビキタス言語や境界づけられたコンテキストなど”場合による”ものが頻出してしまい、結局どうすればいいんだ……となって手が動きにくかったのです。よくわからない概念の上にさらにわからない概念を積み重ねるので、どんどん混乱する感覚がありました。

定期的にDDD勉強しなきゃ……ってなるんだけどやらない（やれ）

— 正月と正月のあいだ (@Kengo_TODA) September 5, 2019

反面、本書では副題の通りボトムアップ形式を採っているため、実際にどう手を動かせば良いのか細かく確認できました。また不明点を最小化しながら進むだけでなく、その概念を導入することでどんな問題が解決されるのかが実例をもって明示されており、私のような独学派にはとてもありがたかったです。

さて本書ではC#を使っています。Javaとたいして変わらないとはいえ細かいところは違ってきますので、ここでは付録で紹介されたソリューション（プロジェクト）構築方法をGradleユーザ向けに解釈したものを紹介します。なおウェブアプリケーションフレームワークとしてspring-bootを利用するものとしますが、他のフレームワークでも大差ないはずです。

サブプロジェクトによる分割

Mavenではサブモジュール、Gradleではサブプロジェクトを使ってプロジェクトを分割します。本書ではプロジェクト分割の方針を2つ紹介していますが、ここでは簡単のためすべてのレイヤが固有サブプロジェクトを持つ構成を説明します。

domainサブプロジェクトには値オブジェクトやエンティティ、ドメインサービス、仕様やリポジトリインタフェースを配置します。ほぼPOJOで済むため、依存はspring-contextのようなアノテーションのみとなるでしょう。

ドメインオブジェクトの振る舞いの多くがここに配置されるため、Javadocやunit testを優先的に充実させる必要があるでしょう。また equals()や hashCode()を手書きするとコードやテストカバレッジの見通しが悪くなることから、Immutablesのようなコードジェネレータによって対策することも考えられます。

infrastrutureサブプロジェクトはdomainサブプロジェクトに含まれるリポジトリインタフェースの実装を配置します。このサブプロジェクトはJDBCドライバのような依存先ミドルウェア固有の依存を持ちます。productionで利用する実装に加え、オンメモリで動作する実装も別途用意することで、unit testを書きやすくできます。

このサブプロジェクトではクラスをpublicにする必要はありません。Springが自動的に＠Repositoryで修飾されたクラスを見つけてインスタンスを作るためです。他サブプロジェクトのunit testから呼び出す必要がある場合のみ、publicにすると良いでしょう。

applicationサブプロジェクトはdomainサブプロジェクトとinfrastructureサブプロジェクトの双方に依存します。アプリケーションサービスによるユースケースの記述をメインとするサブプロジェクトです。

本書の方針に従うならば、このサブプロジェクトに含まれるクラスやメソッドのAPIにはドメインオブジェクトを露出させないことが望ましいと言えます。このため他サブプロジェクトには api configuration ではなく implementation configuration を使って依存します。これによりドメインオブジェクトの露出をコンパイルエラーとして発見できる可能性が上がります。詳細は後述します。

presentationサブプロジェクトはapplicationサブプロジェクトにのみ依存します。後述するGradleの機能により、presentationサブプロジェクト内ではドメインオブジェクトやRepositoryの実装に触れない状態を担保できます。MockMvcなどを使うことでunit testが重くなり、またこのサブプロジェクトをビルドしている際はGradleのworkerが空きがちなので、maxParallelForksオプションでテストを並列実行することの恩恵が大きいでしょう。

apiとimplementationの使い分け

ここまでで2つ、詳細を後述すると述べたことがあります：

1. presentationサブプロジェクトに対するドメインオブジェクトの露出をコンパイルエラーとして発見する方法
2. presentationサブプロジェクト内ではドメインオブジェクトやRepositoryの実装に触れない状態を担保する方法

これらは表現こそ異なりますがひとつの課題を示しています。すなわち「ドメインオブジェクトをpresentationサブプロジェクトに露出させたくない」です。 もちろん依存先のpublicフィールドや戻り値がドメインオブジェクトでないことをArchUnitなどで確認しても良いですが、Gradleならこれらをコンパイルエラーとして発見する方法があります。

API and implementation separationがこの課題に対する解決になります。これはAPIとして外部に露出している依存と、そうではない内部利用している依存とを明確に分けて定義するものです。つまりサブプロジェクトが内部利用している依存は、そのサブプロジェクトの利用者に対して開示する必要はないという考えです。

これにより、applicationサブプロジェクトが依存しているdomainサブプロジェクトやinfrastructureサブプロジェクトを、presentationサブプロジェクトのコンパイル時クラスパスに含めずプロジェクトをビルドすることができます。 依存に色を付ける必要があるという意味で手間は増えますが、そもそもAPIとして露出している依存は減らすべき（JLBP-2）という話もありますので”依存がAPIとして露出しているのか？”を意識することは有用です。Gradle公式ドキュメントによるとコンパイルのパフォーマンス改善も期待できるケースがあるそうです。

例えば以上のサブプロジェクトの依存関係を図示すると、以下のようになります。

api configurationを使うのは1箇所だけです。infrastructureサブプロジェクトに含まれるクラスはdomainサブプロジェクトに含まれるリポジトリインタフェースを実装しており、またドメインオブジェクトをその引数や戻り値に使っているため、api configurationを使って依存します。その他はすべて implementation configurationが使えます。

補足: アセット生成を独立したサブプロジェクトの責務とする理由

前出の図に含まれているfrontendサブプロジェクトは、HTMLやJSなどのアセットを生成するためのものです。ドメイン駆動からは外れますが解説します。

このサブプロジェクトだけ若干特殊で、npmやyarnのプロジェクトをfrontend-gradle-pluginを通じてビルドする作りになります。ReactやVueの開発をGradleで無理やり実現するのではなくnpmあるいはyarnを呼び出す形を取ることで、JavaScript開発の知見を無理なく導入するとともにフロントエンド開発者にGradleやJavaの学習を強要する必要性を減らせます。

ちなみにビルド性能の向上も期待できます。これはfrontend-gradle-pluginのタスク、特にinstallFrontendタスクが重いことと、Gradleは異なるプロジェクトに属するタスクだけparallel buildできることから、説明できます。なおプロジェクトと同数以上のworkerがいないと性能が出ないので、--max-workersオプションを使うかorg.gradle.workers.maxプロパティを使って明示的にワーカー数を引き上げておくことが望ましいです。以下に手元の環境でhyperfineした結果を貼っておきます：

Benchmark #分割前: ./gradlew clean build
  Time (mean ± σ):     28.356 s ±  2.624 s    [User: 1.419 s, System: 0.145 s]
  Range (min … max):   25.914 s … 33.624 s    10 runs

Benchmark #分割後 (4 workers): ./gradlew clean build
  Time (mean ± σ):     27.161 s ±  3.987 s    [User: 1.388 s, System: 0.137 s]
  Range (min … max):   23.202 s … 33.721 s    10 runs

Benchmark #分割後 (5 workers): ./gradlew clean build --max-workers=5
  Time (mean ± σ):     24.442 s ±  2.916 s    [User: 1.321 s, System: 0.135 s]
  Range (min … max):   21.799 s … 31.388 s    10 runs

まとめ

「ドメイン駆動設計入門」付録のGradle向け解釈を述べました。本書は私のような、ドメイン駆動を手を動かしつつ独学したい方におすすめします。

ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本

• 作者:成瀬 允宣
• 発売日: 2020/02/13
• メディア:Kindle版

本投稿が本書の内容を実践する上でGradleユーザの参考になれば幸いです。またGitHubに私の書いたプロジェクトを置いてありますので、具体的にプロジェクト設定を見てみたい方は参照ください。