Kengo's blog

Technical articles about original projects, JVM, Static Analysis and TypeScript.

spotbugs-gradle-plugin v6の安定版をリリースしました

spotbugs-gradle-plugin v6のリリース候補版(RC版)をお試しください で紹介したバージョン6の安定版が出ました。

今回の大きな目的はGroovyとJavaの混成で書かれていたプロジェクトをKotlinで書き直すこと、最新のAndroid開発環境でのテストに対応することにありました。ユーザから見た違いとしてはJava 8が使えなくなったことと、effortreportLevel 周りで書き直しが必要になったことが特筆すべき点で、その他は大きな変更はありません。詳しくはリリースノートをご覧ください。

github.com

今回のリリースは特にコミュニティで求められたものではなく、GradleがKotlinを推していく姿勢が明確になったことと私がGroovyでの開発に限界を感じたことを原動力として、ほぼ私個人で行いました。このつらみについては以前集まれKotlin好き!Kotlin愛好会 vol.47で話した資料にまとめています:

speakerdeck.com

それでもレビューをしてくれたチームと、メジャーリリース向けの変更をIssueの山から拾ってくれた・適したIssueを切ってくれたユーザには、大変ありがたいと思っています。ありがとうございました。

AccelerateとState of DevOpsをもとにした、DevOps問題意識の移り変わり

Accelerate 第1版(以下単にAccelerateと呼ぶ)はDevOpsに関するトレンドを抑えるうえで基本となる本なのですが、もはや古く最新の知見が書いてあるとは言えません。State of DevOpsは毎年アップデートされているのですがコンテキストを丁寧には抑えてくれず、背景を含めて読み解くのが難しいという印象があります。どうもAccelerate 第2版がそろそろ出るらしいんですが、とりあえず現時点での自分の理解をまとめておきます。

端的に言うと、これらは安定したソフトウェアを高速に顧客に提供できる良い開発チームの特徴を踏まえ、皆さんの組織で再現可能にするための研究であり指針です。当然「良い開発チームがあれば常に良い問題解決ができる」というわけでも「ここで定義された良さが組織問わず普遍的である」というわけでもありませんが、顧客の課題に立ち向かうための組織設計において良い仮説を提供してくれるはずです。

「こんにちのソフトウェア開発組織はどうあるべきか」を示す研究

Accelerateでは24個のケイパビリティ(組織全体やグループとして保持する機能や能力)を提唱しており、それらの実践を推奨しています。これらのケイパビリティは以下のカテゴリに分類されます:

  1. 継続的デリバリ
  2. アーキテクチャ
  3. 製品とプロセス
  4. リーン思考に基づく管理と監視
  5. 組織文化

State of DevOps Reportはこの流れを汲み、ハイパフォーマーは何をして、結果として何を得ているのか?ハイパフォーマーに近づくために何をすべきなのか?を明確にしています。Exective Summaryをざっとまとめると以下のような要素を深堀りしています:

  • 2018: クラウド、OSS、組織文化、アウトソーシングなどの組織戦略など
  • 2019: 人材育成によるハイパフォーマーの増大が可能であること、デリバリ速度や安定性が組織目標達成率に影響すること、レガシーな変更承認プロセスの問題など
  • 2020: 組織内プラットフォームの重要性、変更管理プロセスのあり方など
  • 2021: SREの重要性、中間層からの脱出、ドキュメントのDevOpsケイパビリティへの貢献
  • 2022: ソフトウェアサプライチェーン、組織パフォーマンスの要因

こうした深堀りにより、目指すべき理想のソフトウェア開発組織が高い解像度で抽象化されます。各組織が自己を見つめ直し変更点を見出すための道標として活用できる、鏡のような研究になっていると言えるでしょう。キモはこの研究が実際の数万もの組織を調査した結果を踏まえており、「ぼくのかんがえたさいきょうのそしき」でも「専門家が提唱する10年後の働き方」でもない「既に実現されている未来」が書かれている点です。書かれている内容には一定の信頼性と普遍性を期待できます。

またSoftware Delivery Performanceを示す指標であるFour Keys Metricsに、Operational Performanceを示すFifth MetricsであるReliabilityを加えて、Software Delivery and Operational (SDO) Performanceを継続的に評価し改善することが重要であると述べています。これもまた自組織をどう変えていくかを議論するための良い道標となるでしょう。

図1 2019年レポートより。第5のメトリックはAvailabilityと書かれているが、2021年レポートではReliabilityに変わっている

アウトソーシングや組織パフォーマンスなど、経営や組織設計に向けた研究内容も多いので、DevOps=デプロイ自動化と思っていると少し面食らう内容かもしれません。この研究は「組織としてパフォーマンスを高めたければ組織設計に向き合うことが必要で、そのためには古い慣習を疑い継続的デリバリやアーキテクチャなどの技術を理解することが必要」だということを繰り返しデータを用いて述べるものです。もちろんDevOpsに関心のあるエンジニアにも役に立つのですが、どちらかといえば「なぜ組織のパフォーマンスが上がらないのか」に悩む経営にこそ役に立つ内容となっています。

DevOps現場における問題意識の移り変わり

継続的デリバリは本当に必要なのか

研究はまず「ソフトウェアのデリバリは組織のパフォーマンスを左右するのか」を疑うところから始まっています。結果的にこの仮説は証明され、例えば2016年のレポートには「ハイパフォーマーがソフトウェアのデリバリを高頻度に行っていて、結果として低い障害発生率と安い障害対応コストを実現している」という例が示されています。ここに相関関係が認められるのだから、高頻度デリバリが行えていない理由を見つけて潰していきましょうという話になります。

図2 2016年レポートより。組織によるデプロイあたりダウンタイムコスト試算

ここで面白いのが、Total cost of downtime per yearはローパフォーマーが最も安いという点です。ということは障害由来の損失を減らしたいなら、デリバリ回数を減らして慎重に評価するべきということでしょうか?もちろんそうではなくて、2021年のPuppetのState of DevOps Reportでは以下のように強調されています:

The result of all this is that those organizations that claim to be discouraging risk are actually following practices that increase risk, and many of their existing practices around risk management of infrequent deployments are simply risk management theater, when repeatedly, the data has shown that the use of continuous delivery practices predicts higher IT performance, and highly evolved respondents have higher levels of throughput and stability. In 2021, there’s virtually no rational argument for not adopting continuous delivery practices.

リスクを回避するためにデプロイを減らすアプローチは、むしろリスクを増やす結果に終わっている。今日において継続的デリバリをしない理由はない……という主張です。こうした傾向を数値で説明できるようになったのは、開発チームがあるべき姿を模索する人にとってとても重要な変化だと思います。

古典的な組織管理にテクノロジーで立ち向かう

リスクを減らすための工夫がむしろリスクを増やしている、というのはこのState of DevOps Reportで繰り返し指摘されています。のでマネジメントを長くやってきた人もけっこう興味深く読めるレポートになっていると思います。

例えば2019年にはフォーマルな変更管理システムについて掘り下げています。heavyweight change approval process(重量変更承認プロセス)とも呼ばれているこれは、承認委員会とかそんな感じの存在にお伺いを立ててソフトウェアに変更を加えていくというアプローチです。segregation of duties(職務分掌)を普通に実装しようとすると、実装する人と適用・運用する人との間でソフトウェアを受け渡す際に承認プロセスが入るのは自然なことだと思われます。

対してClear change process(軽量変更承認プロセス)というのはPull Requestのことです。変更内容に対してレビューをして承認しマージ(適用)するのですから、これもれっきとした変更管理だということですね。PRをマージした結果がいつどのように本番環境に適用されるのかを明確にする、すなわちデプロイパイプラインを自動化したり関連する監査ログを残したりする必要はありますが、日々の運用負担はかなり軽減されます。

この研究ではこの2つを比較して、Clear change processのほうが望ましいとしています。もちろん「簡単な方が楽だからこっちにしようぜ!」という単純な比較ではありません。Accelerate §7.2には4パターンの変更管理ポリシーを比較して、フォーマルなやり方ではFour Keysのうち変更失敗率には相関関係になく、残りの3つのメトリックには負の相関があることなどが示されています。フォーマルなやり方では目的を達成できず、むしろ承認プロセスが無いところにすらパフォーマンスで劣っているということが如実に示されているわけです。

承認プロセスとか運開分離とか、特に気にせずそういうものだとして入れてしまうところもあるとは思うんですが、こうした研究を踏まえて「同じ目標をより望ましい手段で達成できないか」考えてみるのはとても重要です。本研究は組織文化や技術プラクティスについても研究されており、様々はヒントを得られると思います。

注意するところ

本研究は「組織としてパフォーマンスを上げたければ、ソフトウェアのデリバリを改善する必要がある」という立場に立っています。自組織に本研究の知見を適用する場合、この前提がどこまで正しいのかは考えておいたほうが良いと思います。例えばUIの変更がエンドユーザーに混乱をきたしたりその教育にコストがかかったりする場合、デリバリ頻度を上げることでかえってエンドユーザーとのコミュニケーションコストが上がり、組織としてのパフォーマンスが低下することも考えられます。

ハイパフォーマーが必ずしも不具合やトラブルのないチームを意味しているわけではないことにも注意が必要です。前述の通り、Total cost of downtime per yearなどいくつかの指標ではローパフォーマーが(局所的とはいえ)優れていることもあります。ハイパフォーマーを目指しますと錦の御旗を立てたあとで「前よりUI変更や障害に起因する対応が増えた、パフォーマンスが落ちているのでは?」という疑問が提起されるシナリオは回避したいところですし、人命に影響するシステムなどでは特に何をどこまで変えられるか・何が譲れないのかをしっかり見つける必要があるでしょう。

もちろんこうした場合でも、Feature ToggleKeystone Interfaceによって高頻度デプロイと安定したUIの実現は可能です。また「対応が増えた」のは「今まではまとめて起こっていた問題が散発的に出るようになっただけで、個々の解決はむしろ楽になっている」可能性もあります。ここで言いたいのはこうした仕組みを用意する必要性に先んじて気づきたいですねという話、関係者の期待値調整をあらかじめしておきたいですねという話です。

またこの研究ではソフトウェアと言いつつもアプリケーションやウェブサービス開発を前提にしている節があります。例えばFour Key Metricsの定義ではFor the primary application or service you work onという表現が使われています。ミドルウェア、デーモン、組み込みなどこの定義から外れるかもしれないソフトウェアに適用する場合は、各研究の前提に注意を払う必要があると思います。 個人的にはアプリケーションやウェブサービス開発においても、歴史ある資産の運用保守には直接適用できないことがあると思います。そうしたプロジェクトでは組織パフォーマンスではない「別のもの」を大切にすることがしばしばあるからです。それでも法対応や脆弱性対応を考えると高速高頻度なデリバリは必要になることも多いはずですが、結局のところビジネス要件しだいというやつです。

まとめ

AccelerateとState of DevOpsレポートを基にすることで、一定の信頼性と普遍性が担保されたプラクティスを学ぶことができます。 そしてDevOpsの問題意識として、運開分離や承認プロセスを重んじてきた慣習を見直し、高頻度のデリバリー、リスク管理のアプローチの変化、そして軽量プロセスへの移行こそが大切だという変遷を見ることができます。 自組織への適用には注意を要するところもありますが、どのようなベストプラクティスでもそのようなものなので、少しずつでも取り入れてみてはいかがでしょうか。

新しくチームを持ったときに伝える、開発体制に求めること 2021

2021年に書いた下書きが出てきたので整理して供養します。今見るとチームが十分に大きいことを前提にしていますね(レビュアーを2人確保するとか)。


ぶっちゃけIndividual Contributor各位が快適に開発できれば何でもいいんですが、一応ビルドやリリース周りを長年囓ってきているため伝えられることもあるはずということで、新しくチームを持ったときには今のやり方の課題や改善方法、OSSプロジェクトや他社における事例など共有しています。だいたい毎回似たようなことを話している気がしてきたので、一旦ここにまとめてみます。

JavaあるいはTypeScriptのウェブアプリケーション開発プロジェクトを前提としています。チームリーダーに対して支援する立場で書いています。

大方針

チームの成果として何を評価するか

  • サービスや社内向けツール、プラットフォームを手掛けるチームの場合「そのユーザがどれだけの利益を得られたか」を基本的な指標にします。
    • 何がユーザに求められているかは状況により、また実際に作ってみないとわからないことも多いため、ScrumやLean Software Developmentのような経験主義に基づくチーム運営を目指します。
    • 「ユーザの利益を増やす」ためのアプローチとして「試行錯誤の回数を増やし効率を高める」ことを採用します。Continuous Deliveryを重視するのはこのためです。
  • コードの量や解決したチケットの数、ストーリーポイントなどは評価の対象ではありません。
    • チケットの数を評価しないというのは「トラブル対応や不具合修正は評価しない」という意味ではなく、「早期に低コストに行える体制をつくる必要性がある」という意味です。
    • その他にも「ユーザの利益を増やす」ことに直結しない手続きは極力低コスト化、あるいは省くことを目指します。

計画、朝会、振り返り

ある程度の規模のチームでは、タイムボックスを固定して定期的にイベントを作ることで、効率良く働くために改善する機会を見つけやすくなります。 ここでは2週間スプリントを回していくことを念頭に話します。

  • スプリントのはじめに計画の機会をチームで設けてください。
    • "sprint planning" と呼ばれるものです。やるべきことリスト(プロダクトバックログ)から扱うものを選び出し、細分化してタスク化します。
    • 各タスクの「完了」の定義を明確にしてください。主に対象環境へのデプロイと動作確認になるはずです。
  • スプリントのおわりに振り返りの機会をチームで設けてください。
    • "sprint retrospective" と呼ばれるものです。期待通りのパフォーマンスが出たのか、何がブロッカーになったのか、誰のどんな動きが良かったかなど、今後の改善に活かせる情報を共有し議論します。
    • チームでデータや意見をひとつのテーブルに乗せて議論することが大事なので、しっかりめに時間を確保します。
  • 毎日「昨日何をやったか」「どんな障害があったか」「今日は何をするのか」を共有する機会を設けてください。
    • ミーティングの体制を取るならば、 “daily scrum” などと呼ばれるものになります。
    • 準備をしてこないと意味がないのと、一人ひとりが発言すると時間がかかるので、チケットに最新の情報が上がるように・チケットを見れば次にすべきことがわかるようにします。

開発技術

branch運用

  • default branchからtopic branchを作成してPull Request(PR)を作成、ふたり以上のチームメンバーからLGTMをもらってからマージします。
    • チームリーダーやテックリードだけレビューする体制はSPOFだし単純に負荷だけ見ても早々に崩壊するので、ベテランはもちろん新人も早いうちからレビュアーにします。
    • レビュアー同士のコミュニケーションを通じて、暗黙知を形式知にする機会と捉えることもできます。
  • default branch以外のすべてのブランチは生存期間が短いほうが好ましい
    • 3日以上長生きするtopic branchにいいヤツはいない、くらいの理解でだいたいあってる
    • チケットが大きすぎるか、互換を保ったままマージする方法がないか、いずれにせよContinuous Deploymentをする条件が整ってない

パイプラインと自動テスト

https://leanpub.com/agiletesting-condensed-japanese-edition

継続的デプロイのパイプライン(Agile Testing Condensed Japanese Edition第4版、37Pより引用)

関連記事

プログラミング言語が抱える課題を解決するには言語を乗り換えるのが一番いい、かもしれない

この記事は集まれKotlin好き!Kotlin愛好会 vol.47の懇親会でちょっと触れた内容を、膨らましてブログ用にまとめ直したものです。

注意点として、Java用静的解析OSSの開発保守を長年やってきたJavaプログラマがKotlinに乗り換えて1年経ったころに書いている、という強力なコンテキストがあります。また「何十年前の話をしてんの?」という部分が多く存在しますが見逃してください 🙇‍♂️

プログラミング言語の成長はすべてを解決する

どんなプログラミング言語にも固有の問題は必ずあります。私が一番長く書いてきたプログラミング言語であるJavaでも、いくつかの課題が指摘されてきました:

  • 不要な同期を取りすぎている(StringBuffer, Hashtable, Vectorなど)
  • シリアライズ・デシリアライズが遅い(Serializableインタフェース)
  • コレクションにどのようなインスタンスが入っているのかわからない
  • null安全ではない
  • 記述が長くなりやすい

こうした問題に対して、Javaとそのコミュニティはとても良く対応してきたと思います:

  • StringBuilder, HashMap, ArrayListなどの同期を取らないクラスが標準で提供された
  • シリアライズ・デシリアライズ用ライブラリが充実した
  • ジェネリクスが実装されてコレクションに入っているインスタンスがわかりやすくなった
  • Optional が標準で提供されるようになった
  • より抽象的に扱えるように、try-with-resourcesやStream APIなどを順次導入してきた

これに限らず様々な改良も進んでおり、JVM(Java仮想マシン)の改善も相まってこれからも強力な言語で有り続けるだろうと思っています。また言語とは別の外付けの改良も進んでいて、インクリメンタルビルドの実現、アノテーションによるコンパイラやツールへの情報提供、ツールやIDEによる静的解析なども盛んです。

実行環境に対するコントロールが効かないアプリやオンプレサーバの開発ではわかりませんが、一般にこうした言語や周辺環境の成長の恩恵を受けることは近年とても容易になってきています。こうしたアップデートを即座に取り込む、あるいは自分で作りに行くことは、多くの生産性の課題を解決するうえでとても重要です。

それでも成長による課題解決には限界がある、特に初学者にとっては

それではJava言語にはもうコーディングの現場で考慮すべき問題はないのでしょうか。もちろんあります。むしろ解決済みのはずの問題にすら気を配らなければならないケースがほとんどです。

StringBuffer, Hashtable, VectorなどのクラスはまだJava言語に存在します。個人的につらいなと思っているのは Stack クラスです。「スタック構造がほしいときは Stack じゃなくて Deque を使いましょう!」なんて一見意味の分からない注意事項が現役なので。。。 Properties が現役なのもわかりにくい。

シリアライズやデシリアライズは言語機能ではなくライブラリを使いましょう、というのも初学者にはつまづきやすいポイントだと思います。しかも聞く人によってkryoがいいよ、いやGSONでしょ、あれJacksonじゃないの?なんてことにもなるわけで、やはり標準が定まっていないのはわかりにくいなと思います。

ジェネリクスや Optional は便利ですが、プロジェクトの依存先を含め多くのインタフェースで利用されて初めて価値が出ます。特に長命のプロジェクトでは、導入が難しいこともあるでしょう。また「 null が入りそうだからこのフィールドは Optional にしよう」みたいな誤用の機会も多く潜んでおり、正しく使うのはいつでも難しいものです。

強調したいのは、自分はJavaとJVMが提供する強力な互換性はとても好ましいと思っています。またJava Platform Module System (JPMS、旧称Project Jigsaw)を使って不要な部分を取り除いたJVMを自分で作れる未来は来るだろうとも期待しています。

が、それが実現したとしてもそれは今ではないですし、ここに挙げられていないいくつかの課題はきっと残るでしょう。そのうえ更に「ここは歴史的経緯で2つ選択肢があって、今はこっちを使います」のような要考慮点はきっと増えていると考えると、初学者にとってはちょっと辛そうだな、という印象です。

外付けの改良は中長期的には開発体験を損なう方向に作用する

ではアノテーションやIDE、ツールなどを駆使していけば良いのでは?という発想が次に来ます。SonarQubeのようなサービスを導入し、こうした課題をPull Requestレビューの段階で洗い出せば、初学者でも学びながらプログラムを書いていけるのではないでしょうか。

実際にこれは可能だと思います。私自身、JenkinsやTravis CI、GitHub ActionsなどでJSR305やPMDやFindBugs、SpotBugsにGoogle erorr-proneなどを組み合わせて使ってきました。IDE組み込みの解析機も良いものですし、GitHub code scanningやSonarLintも魅力的な選択肢です。

ではこれが永続的な解決かというと、ちょっとそうは思えないなというのが私の意見です。プロジェクトの成長に伴って実行時間がかかるようになりますし、どの警告を受け入れてどの警告を無視するかという判断も必要になりますし、棚上げした課題の棚卸しも必要です。インクリメンタル分析によって速度を改善しようとすると変更しなかった部分との咬み合わせがうまくいかなかったりしますし、俯瞰的に見て初めて見つかる課題をどうやって見つけて対応しようという課題もあります。

ので外付けツールはケアレスミスを洗い出したり中期的な改善施策を検討するうえでの材料にはなりますが、経験者によるPull Requestレビューに比べての教育効果はそこまででもないのでは…と思っています。そもそも言語の課題なのにさらに計算機資源と時間をつっこんで解決しないといけないということ自体が非効率という思いもあり、頼り切りたくは無い感じです。

言語を乗り換えると問題を一網打尽にできる、かもしれない

Kotlinに乗り換えれば、null安全やジェネリクスの課題は改善されます。またコードの長さも短縮されます(愛好会で事例をひとつ紹介しました)。ひとつのアクションで多くの課題が解決されるのは、新しい言語が人類が発見した知見を取り入れて設計されているからです。

外部ツールへの依存が減ることで、開発体験を改善することも期待できます。残念ながらKotlinのコンパイルはまだ遅いですが(手元で試した限りではK2もあまり解決にならない)、静的解析ツールの必須度が大きく減っていることから、相対的には改善されているかなと思っています。

もちろん言語を乗り換えても解決されない問題はあります。Kotlinでも古いコレクションは使えますし、外付けツールに頼っている問題発見もまだまだあります。ので私はここ5年とか10年とかはこうした解決を積み上げながら、また一網打尽にできる言語の登場を待つのでしょう。Flixみたいな実験的な言語をウォッチしているのも、新しい言語が得た知見を不格好でも今の言語に持ち込めないかと期待しているからです。

生成AIがすべてを解決するかもという期待

生成AIによるゲームチェンジを期待しているのが、こうした「人間が気をつけなければいけない」問題を劇的になくしてくれるのではということです。外付けツールとして今まで以上に優秀な解決を提供してくれるかもしれないですし、そもそも人間に書かせないことで問題を根っこから解決してくれるかもしれません。

ただ実行時間がどうしても遅いというところで、まだ自分が期待する「1分以内にフィードバックを返してくれる、開発体験を改善する存在」には遠いかなというイメージですが、これもあと数ヶ月したら変わってるかもしれないですよね。楽しみです。

あわせてよみたい

spotbugs-gradle-plugin v6のリリース候補版(RC版)をお試しください

spotbugs-gradle-plugin v6のリリース候補版(RC版)が出たので、GradleでSpotBugsを実行している方はぜひお試しください。

github.com

主なBreaking Changes

effortreportLevel を型安全に書けるようにした関係で、ビルドスクリプトの更新が必要なケースがあります。 特にGroovyでビルドスクリプトを記述している場合に対応が必要です。

またAndroidプラグインとビルドする都合上、classファイルをJava 11で出力するように変更しています。 いまだと最終成果物としてJava 8のclassファイルが必要な場合でもGradleはJava 17以降で実行していることが多いと思いますので、ブロッカーになることはないと思いますが注意してください。

他にも今まで明示的に有効にする必要のあったJava Toolchain対応が標準で有効になったり、非推奨になったGradleのAPIへの依存を減らしたりしています。 リリースノートを踏まえて使ってみて気になる点や分からない点があれば、Issueを起票していただけると助かります。 よろしくお願いします。

元toB系プログラマが医療情報技師の勉強をして面白かった部分

今年の医療情報技師能力検定試験に向けて、医学医療編・医療情報システム編の学習を進めてきました。toB系プログラマとして働き始めてから見てこなかった単語や発想がたくさんあって面白かったので、印象的だったところをまとめます。

医療現場はロールベースかつイベントドリブン

医療現場では(乱暴に言うと)各部門やシステムの間を「オーダ」をはじめとしたメッセージが飛び交っている、というモデル化ができそうです。 多くの役職だと何ができるかが法で定められていて、そうした役割をどう組み合わせるかも予め想定されており、そのコラボレーションをメッセージで行っているということです。

これはけっこう医療現場というものを特徴づけるものだと思っていて、パッと思いつくところでも以下のような事が考えられます:

  • 業務の属人性を下げるための仕組みとして機能することが期待される。
    • アクターのTODOや期待されるアウトプットが明確。特に医療行為や看護行為は国際的なマスタがあり、世界的に定義が明確っぽい。
    • アクターの専門性に対する期待も明確なので、教育や評価も(簡単とは言わないけど)比較的やれそう。
  • アクターのロールやコミュニケーション方法が全医療機関共通なので、転職も比較的しやすそう。
    • プログラマだと言語や利用してるクラウドが同じでも現場の働き方はぜんぜん違うけど、医療現場だと少なくとも部署間コミュニケーションは似ていると期待できそう。
    • 紙カルテ&電子カルテみたいな、採用している仕組みが違うと細かいやり方は大きく違ってくるとは思うけど。
  • アクター=部署あるいは資格持ちの人間なので、病院というシステムを動かすための最低限の人数が多くなる。
    • コーダー兼デザイナー兼テスター兼広報です!みたいなことが法的にやりにくい。医師ひとりの診療所で在宅医療やるぞみたいな例はあるみたいだけど……。
    • 情報の交通整理や決断が困難かつボトルネックになる可能性が高い。実際医師や看護師の長時間労働などが問題になっている。

Team Topologiesに親しんでるとStream-aligned Teamに権限を移譲していかにスムーズに動かすかという発想になるんですけど、病院というシステムだとそもそもどこがStreamなんだっけとか、各種検査というComplicated Subsystemをどう動かすべきなんだろうとか、普段使ってない頭の部分を使っている感じがしていいですね。

科学的知見を幅広く活用するための「ガイドライン」

コロナ禍を通じて私にもランダム化比較試験が強いらしいみたいな雑な理解はあったのですが、医療情報技師の学習をきっかけにEvidence-Based Medicine(EBM)という考え方があってランダム化比較試験よりも強いやつがあるということを知りました。システマティックレビューやメタアナリシスがそれです。強い研究を統合してもっと強くするみたいな雑な理解でいますが、人間の叡智を集結して現在のベストを導き出すというのはなんか知性の総力戦という感じでいいですね。

さて医療の世界には診療ガイドラインというものがあり、医療機関ごとの医療の質を底上げしたり医療資源を効率的に扱ったり提供された医療の評価に使ったりしています。日本では医師会や厚生労働省から出ているものが多数あるようです。国立研究開発法人国立がん研究センターがシステマティックレビューやメタアナリシスも含めた説明をしているのでおすすめです:

ganjoho.jp

医療が研究の山の上に成り立っていることはなんとなく知っていたつもりでも、医療関係者がどう知識をアップデートしているかとかはイメージがなかったため、なるほどこうやって国として知識を共有し医療の質を保っているのだと感心しました。

ちなみに医療機関向け情報セキュリティの世界でも3省2ガイドラインというものが提供されています。医療情報技師なら内容を把握していることが求められますし、医療業界向けのサービス提供をする場合も必ずこれを読むことになります。これは診療ガイドラインではないのでメタアナリシスとかは関係ないかもしれないですが、少なくともIT業界標準の考えは多く盛り込まれているように感じます:

www.mhlw.go.jp

www.meti.go.jp

医師の相互監視に課題がありそう

転職する前に医療業界に抱いていたイメージとしては、インシデント対応ができてなさそうというのがありました。いや、個人的体験としては特に不満を感じることもなかったですし、インシデントにぶち当たったこともたぶん無いのですが、「失敗の科学」の印象が強かったのです。この本は「航空業界にあって、医療業界にないもの」とデカデカと書いてあるレベルで(アメリカの)医療業界にダメ出ししています。

失敗の科学

失敗の科学

Amazon

ところで医療情報技師の学習範囲にはインシデントの扱いや医療安全や医療過誤、原因分析や再発防止などが含まれています。RCA(Root Cause Analysis)やProblem SolvingあたりはtoBプログラマなら扱ったことあることも多いと思うのですが、これに加えて4M5E分析とかSHELモデルとかも扱っていて自分は初見だったので勉強になりました。また国内の事例や記事なんかを追いかけても真摯に課題に向かっている方が多く、結構やれてるじゃんという感想になった、んですが、残念ながらこの事件が起こってやっぱダメなところはダメなんだなという現実を思い知ったところがあります:

www3.nhk.or.jp

少なくとも医師同士の相互監視は、セカンド・オピニオン(厳密には監視ではない)やカウンターサインを除けばあまりなさそうだなというのが今の自分の認識です。もちろん日頃から院内で情報交換(カンファレンス)を行っていたり、インシデントレポートが提出されれば然るべき検討が行われたりするはずですが、少なくとも前述の事例ではカルテを読み合うようなことはやっていなかったのでしょう。

医師が長時間労働していることを踏まえるとここはシステムが余力を創出することで貢献できる部分かもしれないなとは思いますし、カルテ記載事項の質の判断とかは機械学習でなんとかできそうな気もします。

病院の壁を超えたPDCAサイクルが回せるように情報が公開されている

診療ガイドラインの実施率であるとか、病床機能の割合であるとか、様々な各病院から提出されたデータが統計されたうえで公開されています。例えばこのへんとかです:

hospia.jp www.mhlw.go.jp

これ普通の企業の活動だとちょっと考えにくいというか。強いて言えば離職率とか初任給とかは他と比較して改善の参考にはすると思うのですが、じゃぁ他社製品の単体テストカバレッジとか変更のリードタイムとかMTTRとかはそもそも公開されていないので参照できない事が多いと思うのですよね。ところが医療機関の場合は医療サービスというコア機能のデータが世に出ているわけで、いやこれすごいなって思います。もちろん病院側だけじゃなくて、ガイドラインとか政策とかの側でも参考にしているのでしょう。

ちなみに海外だと病院ごとだけじゃなくて医師ごとのデータとかも見られるらしいです。すごい。

まとめ

元toB系プログラマが医療情報技師の勉強をして面白かった部分として、医療現場がロールベースかつイベントドリブンっぽいなぁということと、診療ガイドラインやデータに基づく改善が回る仕組みがあってすごいなということを書きました。またインシデントを隠さず業界全体として次に活かすための体制や仕組みはありそうなので、あとは実行の浸透が重要=やっぱり医療DX大事だなぁと改めて感じました。

医療情報技師の資格試験は医学・医療編がちょっと重いものの、医療システムのおおまかな構造や他施設との連携などについても学べるので、私みたいに医療業界の外から来たプログラマは齧って損はないと思いました。おすすめです。

2023年10月5日 追記

合格しました。

twitter.com

私がとあるOSS開発から手を引いた経緯

ホットな話題に乗っかって、私がSpotBugsというJava向け静的解析ツールのOSS開発から手を引いた理由をまとめてみます。

自分がJavaを使わなくなった

先のブログでも指摘されている通りで、自分がそのソフトウェアを必要としなくなったというのは大きな理由になりました。Kotlinに乗り換えたことでJavaを書く機会がなくなり、Kotlinが生成したclassファイルの解析はSpotBugsには向かなかったので、SpotBugsを使わなくなりました。

SpotBugsにKotlin対応させることは技術的には可能ですが、ソースコードも考慮して解析できるdetekt(ktlint, diktat)がある世界でわざわざやることではないという感想です。

リターンが無かった

自分が使わないツールのメンテナンスを継続するには、やはりある程度の見返りを求めたいというのが自分の気持ちとしてありました。Github Sponsorsをはじめてみたり、Who uses SpotBugs?をまとめてみたりしましたが、いずれも自分が納得できる程度には至りませんでした。

冗談半分で「控えめに言っても日本人で、ひょっとするとAPACでもclassファイル静的解析で片手の指に入るんじゃないですかね」とか言うことがあるんですが、これは6年間の活動の結果を分かりやすく人に伝えることで少しでもリターンを稼ぎたいなという気持ちが裏にあるわけです。

まぁ世の中にはOSS開発者を表彰するような動きもいくつかありますし、金銭的フィードバックをコントリビュータに返せているコミュニティもいくつかあるようなので、あと数年続けていれば結果が出た可能性はあります。ただ私としてはその時間を新しいことに使いたいと思い、資格試験や副業に充てることにしました。

個人的には、Javaで中~大規模開発してる会社なんてだいたいSpotBugsを使ってるだろうし、Javaバージョンを上げる際などに課題もいくつか出ているだろうし、ひとつくらいSponsorしてくれる会社が出てきてもおかしくなかったんじゃないかなぁどうかなぁとは未だに思っています。が、そういうところもSonarQubeのような有償ソリューションに鞍替えした方がトータルではベターだろうなとも思います。Java使ってる会社だと、有償ソリューションの方が稟議の通りが良さそうというかなんというか。

ユーザ対応がきつい

どこでも言われていることなので割愛します。リリース依頼を有償化する動きが一部であって、これがあたりまえになるのもひとつの解決のカタチなのかもしれないですね。

次があったらどうするか

コントリビュータを大切にする企業のプロジェクトに絞って貢献するとか、not open contributionなプロジェクトを立ち上げるとかを試してみたいと思っています。

それはそれとして課題を見つけたプロジェクトに対して“辻PR”を送る活動は続けていますし、Github Sponsorsで四半期ごとに自分の活動を報告すること自体は自分自身学びも多く継続していきたいと思っていますので。少しでも面白そうだなと思った方は、ご支援いただけると嬉しいです。スポンサーの方は報告のバックナンバーをご覧いただけるようにもしています。

追記