両利きの経営（増補改訂版）―「二兎を追う」戦略が未来を切り拓くを読みました。自分の15年間の社会人経験は探索と深化が半々という感じだったこともあり、マネジメントに加えて現場の人間の感覚でも楽しく読むことができました。

この本の結論はとても単純で、おそらくA4用紙1枚にまとまると思います。また言っていることには特に驚きはないので、うんそりゃそうだよねという感想で自分が流してしまいそうだなという直感がありました。ので自分の言葉でまとめて記憶の定着を狙おうと思います。

両利きの経営、できなくて誰が困るのか

両利きの経営ができないとビジネスが先細ってやがて食えなくなる、それ自体は別に自然であり、悪いことでもないはずです。経営者としてはたまったものではないでしょうが、従業員は次の職場でまた深化を極めていくこともできるでしょう。

私が読み始めたころは自分がERPベンダ経験者ということもあり、潰れたらインフラと化したサービスが継続できなくなると考えて、現存する顧客に対しての責任から両利きの経営を目指そうという話だと思ったんですね。ただ「カネボウはとっとと繊維から撤退すればよかったのに」などの描写から、本書の問題意識はそうではなさそうです。あくまでも法人が存続することに主眼が置かれています。

株主に対する責任であるとか、従業員の雇用を守るであるとか、激動の時代に誰も探索しなかったらほとんどの企業が破綻してしまうなどの問題意識もありますが。この本を読んでなるほどと思ったのは、両利きの経営は「大企業の組織能力や資源、顧客基盤を持ったスタートアップ」という機会を生み出す経営手法だということです。時代のニーズに応えるべく生まれたスタートアップが応えられないまま潰れていくのはよくありますし、より体力のある大企業がイノベーションに挑戦することは、社会貢献の観点からも重要な経営手法でもあるのでしょう。

のでできないと困るというよりは、できることで大企業が新たな存在価値を生み出せる経営手法だという認識を持ちました。

組織がひとつの目標に向かって動く、ときの「組織」と「目標」の捉え方

この本では深化する人と探索する人との間に適度な距離感を持たせることの必要性が語られています。「適度な」というのは、近すぎても遠すぎてもだめだということです。近すぎると深化のためのベストプラクティスや運用の工夫が探索を殺してしまいますし、遠すぎると探索が必要な資源や支援を得ることができません。私の経験を振り返っても、こういう問題は確かにあると思いました。

この本の例ではハイアールの小微（シャオウェイ）のような独立企業やHPの準部門の例が紹介されていますが、一貫しているのはそれぞれの組織が独立した目標や運用を抱えている一方で、すべての組織に共通する価値観・文化があるという点でしょう。各々の組織で直近の目標ややっていることは違っていても、企業体としての存在意義が一緒なのでひとつのまとまりとして存続し協力しあうことができると理解しました。つまり存在意義を持つ企業体の中に、目標を持つ組織が入れ子になって存在している形です。組織の間には協力関係はあっても従属関係はなさそうです。

これを普通に運用すると、組織を束ねる上級幹部はとても仕事がしにくいと思いました。なぜなら：

• 自分のところの工数や資源を他の「組織」に貸す必要があるが、そのリターンが見えないことが多い（自分の成果を犠牲にしてほか組織の成果に賭けることを意味する）
• 特に深化の組織は持ち出しが多く、顧客や市場からのプレッシャーと板挟みになることが容易に想像できる
• 深化の組織ではその部下から「探索の組織が自由気ままにやっているが自分は規律のもとに数字を追いかけている」という不満が出てきそう
• 探索の組織でも同様に、安定した深化の組織を横目に「売上が上がらない、結果が出ない」ことに対するプレッシャーと向き合わなければならない

この本で出している解決策は「上級幹部の評価を自部門の成績で行わない」こと、すなわち企業体としての成績を持って評価することなのですが。責任を負うものと評価対象がねじれていて本当に機能するのか（他部門の悪状況に引っ張られている場合に上級幹部が転職を検討しそう）とか、じゃぁその下の管理層はどう評価するのか？とか考えると、やはり一筋縄では行かないですよね。上級幹部の下に深化と探索の両部門を置いて上級幹部の裁量でよしなにやってくれ、ということにする誘惑はけっこうありそうですが、それでは失敗するというのが第8章のハヴァスの事例から明らかなので、企業体として向き合わなければなりません。

考えられる最善は、上級幹部が人事評価の裁量を持ったうえで、他の組織に資源を貸し出したことを前提に本業の成績を持って部下を評価する……というものでしょうか。不満や不安も上級幹部が粘り強いコミュニケーションで自組織内で解消させる必要があります。これも言うのは簡単だがというやつで、上級幹部に人徳や公平性，タフネスといった超人性を求める運用になりそうです。

まとめると、この本では「組織を入れ子構造にすることで、存在意義や組織能力などの共有を実現しつつ運用や目標は分けると」いう矛盾を管理可能な形に落とすことを推奨しています。 この矛盾を維持するにはCEOや上級幹部の献身が欠かせません。特に組織（我々）という主語がコンテキストによって変わるであろうことを考えると、上級幹部にかかる部下への説明責任は非常に大きいものと感じました。マイシスの事例の「我々は800万ドル削減する必要がある、ただし探索組織の予算には手を付けない」が象徴的で、都合のいいときだけ一心同体だと言いやがってみたいな反応は普通に出てきそうだなと思います。この問題こそが両利きの経営が難しい理由であり、優秀なトップひとりではなく上級幹部を巻き込んで組織を作っていく必要性を強く裏付けるものだと思いました。

上級幹部ではない従業員として何ができるのか

やっぱり気になるのはここなんですが、直属の上級幹部ときちんと話をして両利きの経営を意識してもらう、くらいしかできることがない気がします。トップが変わったときに探索部隊をどうするか、深化と探索のバランスを考える人なのかを見る上ではこの本が紹介する知識や事例は役に立つと思いますが、その結果探索を縮小・停止する人だなと判明したときに、それを覆すのはほぼ無理ですよね。その人が入った時点で既定路線のはずなので。

ので自分が深化を極めたいのか、探索で結果を出したいのか、両利きの経営を実践するリーダーとして伸びていきたいのかを日頃から考えておいて、深化や探索のバランスが変わったらそのシグナルを早期にキャッチして動いていく、しかない気がします。

あとは深化と探索は異なるものでそもそも相容れないのだ、ということを頭に入れておくとコミュニケーションがやりやすい局面はありそうですね。多様性多様性と言われますが、何がどう多様でコミュニケーション上の要配慮点はどこかを知っておくだけでも助かることは多いので。深化は厳しいんだ、探索は心細いんだ、ということをざっくり踏まえておくだけでも、同僚の仕事を知って尊敬する機会はすごく増えると思います。

前回書いたのがもう4年前でビビったのと、最近いろいろ進展があったのでまとめてみます。

actions/setup-java の依存キャッシュを使わない

これ自分が実装した機能なのでホント申し訳ないんですけど、今なら gradle/gradle-build-actionを使ったほうが良いです。 利点は公式が説明しているので読んどいてください。

github.com

spotlessApplyして差分が出たらSuggest Changeする

reviewdogが action-suggesterという素敵なアクションを提供しています。GitHub Actionsでフォーマッタを実行して差分ができた状態でこのアクションを実行すると、GitHub Pull RequestのSuggest Change機能を使ってフォーマットを提案してくれます。

github.com

フォーマット適用箇所が多いと手元で ./gradlew spotlessApplyしたほうが早いなってケースもまぁあるとは思うんですが、やって損は無さそうです。 もちろんSpotlessに限らずktlintやPrettierのような他のフォーマッタでも利用できます。

まとめ

だいたいこんな感じじゃないですかね。リリース自動化には release-please とか semantic-release とかお好きなソリューションをご利用いただければと思います。

on:pull_request:push:branches:- main

jobs:build:runs-on: ubuntu-latest
    permissions:contents: read # actions/checkoutのために必要pull_requests: write # reviewdog/action-suggesterのために必要steps:- uses: actions/checkout@v3
      - uses: gradle/wrapper-validation-action@v1
      - uses: actions/setup-java@v3
        with:distribution: microsoft
          java-version:17 # toolchainで指定したバージョンと同じものを使う- uses: gradle/gradle-build-action@v2
        with:arguments: spotlessApply build --scan
      - uses: actions/upload-artifact@v3
        if: always()
        with:name: Gradle reports
          path: build/reports
      - uses: reviewdog/action-suggester@v1
        if: github.event_name == 'pull_request'with:github_token: ${{ secrets.GITHUB_TOKEN }}
          tool_name: spotless

またワークフロー最適化の観点ではGradleのRemote Build Cacheが非常に効果的です。勤め先ではgradle-gcs-build-cacheを使ってGoogle Cloud Storageを活用した最適化を行っています。

久々に古い知識を整理していて、けっこう更新されているものが多いのでここにまとめる。

JDK Mission Control (JMC)

JMCはOracleのウェブサイトからダウンロードできる。

標準ではOS標準のロケールが利用される。UIを日本語化する場合は jmc.iniで user.languageシステムプロパティを設定する。これはJVMに渡す設定なので必ず -vmargsよりも後ろに書く（Eclipseの設定と同じ）。

-Duser.language=ja

利用するJVMは jmc.iniで -vmシステムプロパティを設定する。これはJVM起動前に使うので -vmargsよりも前に書く。

-vm
C:\Program Files\Java\jdk-17.0.7.7\bin\javaw.exe

ThreaddumpとJFR

昔はThreaddumpファイルを複数取ってIBM Thread Dump Analyzerなどで解析していたが、今ならJFRファイルにスレッドダンプの情報が含まれるためJFRを取得すれば充分そう。

JFRファイルはJMCで取得するのが一番手軽。

組織の話が好物なので色々読んできたのですが、結局ティール組織はよくわからないままでした。最初に本を読んだのが5年も前なんですね。

ティール組織は面白くなかったというか、個人的にはそこまで響かなかった。歴史書読んでるみたいな感覚で……。リーンスタートアップは部署レベルで実践できそうだけど、こっちはそうは思えなかった。

— 絶賛異世界転生中 (@Kengo_TODA) July 6, 2018

で、自分なりに考えた結果、大きく2点においてよくわからないのだと思ったのでメモしておきます。

以下、「ティール組織」と書いた場合は書籍「ティール組織」を指します。なお昔読んだ本を読み返しながら書いているので読み飛ばしによる誤解などはあるかもしれませんし、ここ5年で新しい発見があったとしても私はそれをキャッチアップできていないことにご留意ください。

組織に人間の弱みを補う機能を求めたいのに、スキル常時発動を前提に議論が展開される

やっぱ組織を作るのは「専門家を集めてひとりじゃできないことをやる」に加えて「ひとりがダメでも他の人がいる」ことを実現したいというのはあると思うんですよ。 多様性だVUCAだバス係数だなんて難しい話は置いといて、さて自分や家族が体調を崩したときにどうするんだっけ？って単純な話ですよね。

体調管理ができてないなんて社会人失格だァなんて考え方もあるにはありますが、自分はもちろん特に家族の体調はcontrollableではないなぁというのがひとりの父親としての実感としてあります。 のでやはり柔軟にスケジュールを調整できたり他の人がフォローに入れたりしたほうが、組織としては強いと思うわけです。

で、ティール組織では以下の記述があります：

私達が自分自身のエゴから自らを切り離せるようになると、進化型への移行が起こる

進化型では、意思決定の基準が外的なものから内的なものへと移行する

なるほど。で、自らをエゴから切り離せない日はどうするんですかね？ 意思決定が外的なものになってしまいがちな日は？

階層型組織では組織を機能させられない場合のためにエスカレーションがあり、Scrumだと透明度・検査・適応ができない日のためにスクラムマスターがいます。うまくいかないときに他者の助力を得る仕組みがあるわけです（そしてこれが上司の能力が組織の能力のキャップとして機能するとか、スクラムマスターに超人性を求めてしまうとかの失敗に繋がったりする）。

しかしティール組織の記述には、「上司の不在」の節におけるビュートゾルフをはじめとしたいくつかの具体的な事例が出てくるだけで、一般化が見られません。「たしかにそこに難しさがあるよね、でもうまく行ってる組織もあるしなんとかなるよ！」と言われてハイそうですかとは、さすがにならないかなと。

個人的には、組織の構成員がお互いがカバーしあうことや「助言プロセス」による意思決定を期待するのであれば、適切なタイミングでカバーに入るための情報公開・共有であったり持続可能な評価制度であったりまで踏み込んで初めて組織論と呼べるものになると思います。こうした事柄に関する記述は確かにこの本にもありますが、いずれも既存組織に多く共通するものを紹介するに留まっていて、個人的には再現性を感じませんでした。

問題解決のための手法ではない

めちゃくちゃ粗い理解として、この手の本は「上司が存在しない」ことに一定の価値を見出しています。上司がなくても組織は回る、そのために意思決定や権限管理や解雇をどうするか？という論理展開が行われます。これは一見課題に対する解決案の提示に見えますが、そもそもの「なぜ上司がいると問題なのか」の掘り下げが行われていませんし、「上司を取り除くことで解決されるのか」「上司がなくなって表面化するリスクとどう向き合うか」もあまり検討されていません。

例えば「経営陣はなく、ミーティングもほとんどない」の節にはミーティングが増えて生産性が下がることを問題として、定例ミーティングをなくし有機的なコミュニケーションで置き換えることで解決とする記述がありますが、これは上司がいるからダメというよりはマネジメントとリーダシップを混同するからコミュニケーションがうまくいってなかったやつなのでは？というように私には見えます。Team Topologyのようなチーム間コミュニケーション整理であったりチームへの権限移譲（Empowerment）であったりは今どきの階層型組織でも普通に行われることなので、何も上司をなくすなんて劇薬を持ち出さなくても……という「目的と手段のはき違い」感があるのです。

ので「上司がいなくても組織は回る」のは真だと思いますが、「上司がいても組織は回る」のも「上司がいると便利」なのも真なので、あまり組織論としては魅力的ではないなという感想になりました。Project Oxygenにぶつけて打ち勝てる本じゃないなというか。

個人的にはやっぱりこういう本は問題に対する解決手法を提示してほしいんですよね。わかりやすい例としては組織論ではないですがドラッカーの「お前の仕事は顧客の創造だ、顧客の創造にはマーケティングとイノベーションが必要だ、それぞれのためにこう考えて動け」というMECEな説明が入りやすかったです。 仮に解決を論理的に提示できず、世の成功事例を集めてその傾向を分析するに留まるとしても、Accelerateくらいのファクトに立脚した考察はほしいですね。

まとめ

結局は良い上司に恵まれてきたので「上司、いいじゃん！」が自分の意識の根底にあって、これが違和感を作ってるんだろうなと。あとまぁ人間の可能性を信じすぎというか、負の可能性から目を離しすぎというか。

今から読み直すような本ではないと思うので、マネジメントだけがリーダシップを握ることに限界を感じている方には「チームワーキング」をおすすめします。これは再現性があると感じさせてくれるというか、問題を要素に分解したうえで現状を変えるためのTODOが整理されているのでとっつきやすいです。

チームワーキング　ケースとデータで学ぶ「最強チーム」のつくり方

• 作者:中原淳,田中聡
• 日本能率協会マネジメントセンター

Amazon

ホットな話題に乗っかって、私が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使ってる会社だと、有償ソリューションの方が稟議の通りが良さそうというかなんというか。

ユーザ対応がきつい

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

持続可能なOSS開発と言えば、SLF4JのChampioning a Releaseの仕組みはちょっと普及に期待してます。自分はリリース自動化しちゃうからまずやらなさそうだけどhttps://t.co/oc6YKTM7cf

— 絶賛異世界転生中 (@Kengo_TODA) May 8, 2023

次があったらどうするか

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

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

追記

抜けた私が言うのも妙ですが、よろしくお願いします！https://t.co/jaFNWk2j6P

— 絶賛異世界転生中 (@Kengo_TODA) 2023年7月23日

今年の医療情報技師能力検定試験に向けて、医学医療編・医療情報システム編の学習を進めてきました。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.jpwww.mhlw.go.jp

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

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

まとめ

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

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

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

github.com

主なBreaking Changes

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

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

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

この記事は集まれ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分以内にフィードバックを返してくれる、開発体験を改善する存在」には遠いかなというイメージですが、これもあと数ヶ月したら変わってるかもしれないですよね。楽しみです。

あわせてよみたい

• JavaのRecordでは配列を使わないほうが良いという話 - Kengo's blog
• Javaの7大禁じ手 - Kengo's blog

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

関連記事

• 内製化をすすめる知人へのアドバイス
• draft: より良いチームを作る2019
• 考察：Reactive Workflowが生まれた背景とその狙い

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を継続的に評価し改善することが重要であると述べています。これもまた自組織をどう変えていくかを議論するための良い道標となるでしょう。

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

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

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

研究はまず「ソフトウェアのデリバリは組織のパフォーマンスを左右するのか」を疑うところから始まっています。結果的にこの仮説は証明され、例えば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 ToggleやKeystone Interfaceによって高頻度デプロイと安定したUIの実現は可能です。また「対応が増えた」のは「今まではまとめて起こっていた問題が散発的に出るようになっただけで、個々の解決はむしろ楽になっている」可能性もあります。ここで言いたいのはこうした仕組みを用意する必要性に先んじて気づきたいですねという話、関係者の期待値調整をあらかじめしておきたいですねという話です。

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

まとめ

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

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

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

github.com

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

speakerdeck.com

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

株式会社ヘンリーでSREなどをやっている id:ellerです。 この記事は株式会社ヘンリーAdvent Calendar 2023の4日めの記事です。一昨日の記事はkobayangさんのアラートを早く上げる・早く拾うでした。

さて、以下は筆者の日頃の業務を切り取った図です。みなさんはこちらを見て、どのように思われますでしょうか？

なんだコイツ偉そうだなとか、真面目そうとか、厳しそうとか、そういう印象をお持ちの方が多いのではないでしょうか。実際は柔らかく優しい人格かもしれないし、いつもニコニコして話しやすい人かもしれないし、背後で体調悪くて学校を休んだはずの小学生が飛び跳ねてるかもしれないですが、そういう個性や雰囲気はチャットに頼りがちなフルリモートではなかなか伝える機会がないものです。

書かなければ伝わらないが、書いてるものは個人のイチ側面しか反映していない

本日お伝えしたい最大のトピックは「フルリモートワーク環境においては、書かなければ伝わらない」です。大切なのでもう1回くらい書いておきましょう、人間「書かなければ伝わらない」のです。そしてそれは「書いたものから伝わっていく」ことと同義です。

私の今のロールはSREやセキュリティで、社内規定策定とか認証取得とか開発手順策定とかのウェイトが大きく、どうしても依頼・強制に関する書き物が増えます。これが続くと「社内の自由を狩り尽くし、総てをコントロール下におきたい管理者」像が確立される可能性すら否定できません。そしてセキュリティは従業員の日頃の意識や協力体制に強く立脚するもので、この像は目標達成の障害にはなれど強みにはならないと言えるでしょう。

他の側面を露出することがフルリモートワークを円滑に進めるためには重要

そしてこの実体と印象の乖離問題はほかのエンジニアにも常につきまとう問題だと感じています。例えばプログラマにつきものの「PRレビューを個人攻撃として受けとられてしまう」問題も、PRレビューの内容やその言葉遣いから受ける印象をその筆者そのもののイメージと混同してしまうことに起因します。PRレビューで使う言葉を優しく簡潔なものにしたとしても、この問題は完全に解決することにはなりません。PRレビュー以外のコミュニケーションを増やしてその人の他の側面に光を当てることで、はじめて解決されます。

ちょっと前に弱みを見せることが重要なコミュニケーションであるという議論が活発になされていたように思います。それと同じで、仕事を円滑に回してお客様に価値を届けるためには、ドライなプロフェッショナリズムだけではない人間としてのウェットなコミュニケーションも重要ということですね。

cybozushiki.cybozu.co.jp

この問題の解決としてよく知られているのは分報でしょうか。またSlackではソーシャルチャンネルという、仕事に関係のない話をする場を設けることも提案しているようです。業務だけの関係では見せられない側面を開示する機会を作ることが色々と模索されている時代だと言えるでしょう。

プログラマという言葉のプロフェッショナルにはダジャレが適している

さて前置きが長くなりました。いよいよ本題であるダジャレについて触れていきましょう。

私のようなプログラマという生物は、常に言葉に対する高いアンテナを張っています。一見同じような言葉、例えば「作る」「創る」「造る」「つくる」のうちどれが最も文章に当てはまるものなのかと悩んだり、いやこの行為は何かを作るのではなく別世界から召喚しているのでは、あるいは既に存在するものを空間に投影しているだけなのでは、そもそもこれを作っている人はなぜそれを作っているのだろうか……などと際限なく考えることを生業としています。

そんなはずはと思われた方、隣のプログラマを捕まえてみて「名付けに悩んだことある？」と聞いてみてください。まず間違いなく、ほろ苦い体験をひとつやふたつ持っているはずです。

プログラマとは作家のようだ、と思われた方は本質をついています。プログラムとは人間にもコンピュータにも読んで理解できる文章であることが求められるため、プログラムとは文芸であると言っても過言ではないのです。よって良いプログラマは良い作家のように、語彙や類義語や対義語といった表現のストックが増えていき、言葉に対する「深み」が自然と醸成されます。

それと同時に物事をシンプルに伝えるための比喩・抽象・近似という道具も扱うようになり、全く異なるものから似た概念を見出すことすらできるようになるのです。画面の中のナニカに対してプログラマが「生きてる」「死んでる」などと表現するのは、非生物に対して生物的な特徴（ライフサイクル）を見出しているからにほかなりません。そしてプログラマが非生物の中に生物らしさを見出すにとどまらず、生物らしさを生み出しうる存在であることは、以下に挙げる著作や最近の生成AIのトレンドを見ても明らかでしょう。

techbookfest.orghoneshabri.hatenablog.com

そして言葉に対する深みと抽象を扱う能力、これら2つが融合する総合芸術こそがダジャレなのです。ダジャレこそがフルリモートワークにおいて自らの側面を見せ、業務上関係の薄い人へもアプローチでき、プログラマにとっては主たる能力と関心を発揮する類まれなるソリューションであることは疑いの余地がありません。

いやいやそんなまさか、とお考えの方、無理もありません。しかし例えば以下の投稿で紹介したGoogleの事例は、7年前から今日というこの日まで認められ、親しまれ、愛されてきているわけです。業界をリードする企業がメンテナンスする著名OSSプロダクトでこれなのです。フルリモートワークにおいてもプログラマにとって有効なソリューションとなるであろうことは疑いの余地はありません。

OSSで良い設計やコードを学ぶのはいいんですが、OSSにも気を抜くとモンスターが潜んでいてやけどするので注意は必要です（棒https://t.co/c8GfVoJDXd

— 新米医療情報技師 (@Kengo_TODA) 2022年5月6日

最後にもうひとつ実例として、私の事例とその効果を見てみましょう：

こんな自由奔放なやつが「社内の自由を狩り尽くし、総てをコントロール下におきたい」人のはずがない、ということは容易に伝わるかと思います。むしろ自由さを今後も維持できるのか、と心配されています。

いいですね。なんか他のことを気にしたほうがいいような気もしますが、当初に挙げた懸念は払拭されたのでヨシということにしましょう。

まとめ

フルリモートワークでは書いたことだけが相手に伝わります。依頼・強制に関する書き物が多い立ち位置にいるプログラマは、その能力を活かしてダジャレを投稿することで自由を束縛する機械的なヤツであるという印象を打ち破ることができます。ウェットなコミュニケーションのきっかけにもなりますし、同僚を勇気づける・クスッとさせることもできますし、一石三鳥です。あなたもぜひ。

株式会社ヘンリーAdvent Calendar 2023、明日はgiiitaさんの「全ての台所へ贈る浸透圧」を予定しています。お楽しみに〜。

補足

定義

面白くなくて全然笑えないギャグを真のオヤジギャグという https://t.co/OQ9gzQmf2d

— み　ぽ (@nekomath271828) 2023年11月13日

2年前のブログが未だにブクマされるので、念のため掲題の件について書いておきます。 端的に書くと、あのブログで挙げた懸念事項が解消されたのでどんどん使うと良いと思います。

SLF4J v2の安定版がリリースされた

良かったですね。ちなみにv2.0.9から slf4j.providerプロパティでproviderを指定できるようになったので、Service Loaderによるprovider探索をガツッとスキップできます。多くのユースケースでは利用したほうがログの単純化や起動の高速化に有効のはずです。

SLF4Jの活動は最近活発

JIRAのデータを見れば一目瞭然。私もGitHub Issueで回答に回ったりしますが、著者の方も頻繁にコメントしてくれてます。最近のLogbackの脆弱性への対応も充分に早かったのではないでしょうか。

ということで、好きにすればいいと思います。もちろんLog4j2も適材適所でどんどん使っていきましょう。

おまけ：依存を小さくするためという誘惑に負けずにSLF4J使っとけ、という話

SLF4Jを使ったソフトウェアを配布される方、最近なかのひとがこちらの投稿をされていたのでご参考まで。

In order to reduce the number of dependencies of our software we would like to make SLF4J an optional dependency. Is that a good idea?

This question pops up whenever a software project reaches a point where it needs to devise a logging strategy.

Let "Wombat" be a software…

— qos_ch (@qos_ch) 2023年11月21日

ChatGPTによる要約を掲載しておきます。なおここで言うoptional dependencyとはMavenで言う <optional>true</optional>な依存のことではなく、独自のログAPIを提供したうえでクラスパスにSLF4JがいるかどうかによってそのAPIの挙動を変える書き方を想定していると思われます。

このテキストでは、ソフトウェアプロジェクトがロギング戦略を考える際に、SLF4Jを任意の依存関係にすることについて議論しています。SLF4JをWombatというライブラリの依存関係に加えることは、新しい依存関係を生み出します。一部の開発者はSLF4Jのラッパーを作成して、SLF4Jを任意の依存関係にすることを検討するかもしれません。しかし、このラッパーは将来的な変更に対して複雑さを増すだけでなく、SLF4Jの内部インターフェースに依存するため、メジャーバージョンによる互換性の問題が生じる可能性があります。さらに、各ライブラリが独自のロギングラッパーを持つと、ユーザーは複数のロギングフレームワークを扱う必要があり、これは利用者にとって煩わしいことです。そのため、開発者は独自のロギングラッパーを書くことに抵抗すべきです。

私は最近gRPCを使うんですが、あれはJUL（java.util.logging）のロガーに依存しているので、jul-to-slf4jとかいうおまじないを強制されるんですよね。こんな感じのコードを main()直後に埋めて回る必要があるわけです：

// io.grpc がJULを使っているため、JULがSLF4Jを経由してLogbackに送るようにする
SLF4JBridgeHandler.removeHandlersForRootLogger()
SLF4JBridgeHandler.install()

Java標準APIでさえこれなのに、配布ソフトウェアが独自のログAPIを提供していたらもっとめんどくさいだろうなというのは想像できます。JVM世界でコードを書くなら難しいことを考えずにSLF4Jに乗っとくくらいがちょうどよいのは実際そうでしょう*1。

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

概要：OSS活動はもっと減った

GitHubのプロファイルページによると今年は8,153 contributions、過去最多でした。ただこれはprivate repoでの活動を含む値で、これを除くと514 contributionsと昨年や一昨年よりも少ない数値になりました。 昨年以上に減りましたね。ただ昨年7月に転職していることを考えると、昨年7月以降のContributionペースはあまり変わってはないのかも（昨年の方が多いのは1〜6月の影響が大きいか）。

自分でメンテナンスしているもの

だいたい絞れてきている感じです。gradle-semantic-release-pluginは470リポジトリで使われていて、代表作になりつつあります。

• https://github.com/KengoTODA/actions-setup-docker-compose
• https://github.com/KengoTODA/gradle-semantic-release-plugin
• https://github.com/KengoTODA/errorprone-slf4j
• https://github.com/KengoTODA/promisified-properties

actions-setup-docker-composeは docker composeコマンドの登場を受け、今後メンテナンスモードに入れていきます。 errorprone-slf4jはもう自分では使ってないので、当該コードをerrorproneあたりに寄贈するべきなのかもしれない。

あとはいくつかの実験的実装プロジェクトを走らせていますが、あまりコミット数は無いですね。

貢献しているもの

現時点ではほぼ一点のみです。これもやっぱり自分では使ってないですが、Gradleプラグインの新しい機能や実装を試すのにちょうどいいサイズだというのと、統合テスト自動化をしっかりやったので安心して開発できるのとでしばらく手を入れていくとは思います。

• https://github.com/spotbugs/spotbugs-gradle-plugin

できれば自分が今使っているツールのプラグインを書きたいので、引き続きアンテナを立てていければと思います。

記事にしたやつ

職場でオススメされた「両利きの経営」を読んで記事にしました。「知識創造企業」もオススメされているので来年読みたい。

blog.kengo-toda.jp

医療関係

医療関係エンジニアのはしくれとしてある程度の情報収集は心がけているのですが、今年読んだ中ではこの「再考・医療費適正化」がダントツで面白かったです。医療費問題は医療の持続可能性を考える上で避けて通れないのですが、実は地域性も色濃く出る問題なのだということがよくわかりました。

再考・医療費適正化 -- 実証分析と理念に基づく政策案

• 有斐閣

Amazon

医療情報技術関係の雑誌もいくつか試していますが、現時点では新医療がダントツで読みやすいです。特集もセキュリティ寄りの医療情報技師である自分の関心に近いものが多く、また連載もけっこう楽しいです。多要素認証は大切だけど、医療現場でどう運用するんだ*1みたいな疑問もきちんと掘り下げた話を載せてくれていたりします。医療情報技師なら事業者側でも医療機関側でも読んで損はないんじゃないでしょうか？

読んだ。移動をなくして患者対応に使える時間をコンスタントに増やした話とか、情報交換の場だったナースステーションが無くせた話とか、IT活用の事例がたくさん載っていてありがたい。透析排水が水道管に与える影響の話も興味深かった

月刊新医療 2023年5月号https://t.co/xCThhARBZD

— 新米医療情報技師 (@Kengo_TODA) 2023年5月8日

エンジニアリング

大工に縁のある人生だしマイクラみたいなゲームも好きだしエンジニアリングでご飯を食べてもいるので、建物や設計についてはちょいちょいつまみ食いをしています。今年読んだ中では「一級建築士矩子の設計思考」が面白かった！図面を書くときのワクワク感がすごい伝わるし、設計や構築の裏側にある考察や気配り、法制度なども見えてきて知識欲が満たされます。

お酒や建築関係の知識がちょいちょい出てくるのも面白く、私はこのコミックスをきっかけに最寄りの蔦屋書店で商店建築を買うなどしました。都心の呑んべぇにはまた違った価値がある本なのだろうと思います。

一級建築士矩子の設計思考　1

• 作者:鬼ノ仁
• 日本文芸社

Amazon

こっちの「船の科学」も良かった。モジュールごとに開発して最後に組み上げるとか、納品前に性能試験をするがその際のやり方が国際的に決まっているとか、こちらもソフトウェア開発に通じるところがありそう。

ソフトウェアエンジニリングの現場感というか勝ちパターンのようなものが見えてくると、こうして外の分野におけるやり方から学ぶことで変な常識を頭から外せると思っているのですよね。そういう意味でシステム開発のワークフローを作っている人には参考になると思いますし、もちろんものづくりのプロセスやその背景にある科学について興味がある方もぜひ読んでみたら良いと思います。

最新図解　船の科学　基本原理からＳＤＧｓ時代の技術まで (ブルーバックス)

• 作者:池田良穂
• 講談社

Amazon

その他

「結婚するって本当ですか」完結おめでとうございます！ラブコメで引き込みつつも、わかりやすくデフォルメされつつも丁寧な描写で家族や愛について考えさせてくれる名作です。この家族がこれからも幸せに生活できることを願っています。

結婚するって、本当ですか（１１） (ビッグコミックス)

• 作者:若木民喜
• 小学館

Amazon

「ダンジョン飯」完結おめでとうございます！モンスターを食うという奇天烈さをもって売り込まれた第一巻でしたが、完結まで追ったら普遍的かつ本質的なテーマを地盤に持っていたのだと再発見させる内容でした。また最初から読み直したら新たな発見がありそうです。

ダンジョン飯 14巻 (HARTA COMIX)

• 作者:九井 諒子
• KADOKAWA

Amazon

「誰も農業を知らない」子供に何を食べさせるかを日々考える立場として、とても考えさせてくれる内容でした。遺伝子組換え作物も農薬も、こうしてきちんと論じられると有り難みがわかりますね。どちらも（自分の中では）最初の印象でだいぶ損をしていたので、こうして実態を再整理して認識しておくことは今後の生活に役立つと感じました。

誰も農業を知らない: プロ農家だからわかる日本農業の未来

• 作者:民雄, 有坪
• 原書房

Amazon

そして最後、今年読んだ一番面白かった本を聞かれて答えたのがこちらの「うんち学入門」です。対話を通じて掘り下げる書き方をしていて変わっているなぁというのが第一印象でしたが、その書き方が内容にマッチしていてすごく読みやすいんです。本としての起承転結に結びつくのもそうですが、すでに学んだ内容とのつながりの指摘や新たな疑問点の提示などがキャラクターによってなされることでここまで科学的な読み物が読みやすくなるのか！というのは感動的な発見でした。

この本には組成のようなうんちそのものについてももちろん書いてあるのですが、うんちを起点とすることで生物や進化、生態系まで幅広く学べるのが特徴的です。知識欲を満たすのに最適な一冊だと思います。

うんち学入門　生き物にとって「排泄物」とは何か (ブルーバックス)

• 作者:増田隆一
• 講談社

Amazon

本エントリーはJava Advent Calendarシリーズ2の19日目です。

qiita.com

OpenTelemetryの自動計装機能を調べていたら、 ServiceLoaderとjavaagentを活用した実装になっていました。これ前知識がないと魔法に見えるやつだなって思ったのですが、 ServiceLoaderはともかくjavaagentなんてなかなか使わないだろうなぁと思ったので簡単な説明を書いてみます。

ServiceLoaderはJVM標準のDI技術

ServiceLoaderとはJava 1.6から提供されている仕組みです。ので現代で使われているJVMでは必ず使える機能のひとつですね。

サービスとは、既知のインタフェースおよびクラス(通常は抽象クラス)のセットです。サービス・プロバイダとは、特定のサービスの実装です。通常、プロバイダのクラスによって、サービス自体に定義されているクラスのインタフェースとサブクラスが実装されます。 https://docs.oracle.com/javase/jp/8/docs/api/java/util/ServiceLoader.html

ServiceLoaderを端的に説明すると、Javaプログラマに通りのいい表現としては、DIのようなものです。このインタフェースを実装してるクラスの実装がほしいよ〜、というコードを書いておくと、それをCLASSPATHから探して渡してくれるんです。

classよくあるDI {
  @InjectよくあるDI(Collection<適当なインタフェース> 引数) {
    // 指定したインタフェースの実装をコンストラクタに渡してくれる
  }
}

class ServiceLoader動作イメージ {
  void method() {
    ServiceLoader serviceLoader = ServiceLoader.load(適当なインタフェース.class)
    serviceLoader.iterator() // 指定したインタフェースの実装をイテレートするIteratorを返してくれる
  }
}

なお実装のインスタンスはデフォルトコンストラクタによって作成されます。このため複雑なインスタンスを作ることはできませんが、特定の処理を開始する起点としては充分なことが多いです。

例えばログファサードライブラリであるSLF4Jでは、この機能を使ってバインディングと呼ばれるインタフェースの実装を探しています。SLF4JはLog4j2やLogbackなどのロギングライブラリに処理を委譲しますが、このときに「Log4j2が使えるのか、Logbackが使えるのか？」を判断するのにService Loaderを使っているわけです。

OpenTelemetryでは InstrumentationModuleの実装を探すのに ServiceLoaderを使っています。何からデータを集めたいのか（RDB、gRPC、HTTPサーバなどなど）に応じたライブラリをCLASSPATHに入れておけば、起動時に ServiceLoaderがよしなに必要なコードを拾い集めて初期化してくれる、そういうコードが簡単に書けるわけです。業務ロジック側では、それらのライブラリの存在すら認識する必要はありません。

ちなみに ServiceLoaderでインスタンス化される側のコードを書く場合、ほぼセットで利用するのがGoogleのAuto Serviceです。Service Loaderでインスタンス化される側のコードを書く際に「Service Loaderに実装の居場所を教えるためのファイル」を作成する必要があるのですが、これをアノテーションから自動的に生成してくれます。便利ですね。

main関数以前の処理を実現するjavaagent

次にjavaagentの話をします。皆さんがJavaプログラマであれば、 public static void main(String[] args)な関数を一度は書いたことがあるでしょう。え？ public staticなんて今ドキ書かないって？2023年ですね。

ところでJVMはこの main関数を実行する前、何をしているのでしょうか。メモリの確保とか、GCの準備とか、 ClassLoaderの作成とか、プロセス引数から String[]を作るとか、色々やってそうですよね。そこで自分のコードを動かせたら最高じゃないですか？例えば ClassLoader作成に一枚噛めるということは、これは事実上JVMが利用するほぼすべてのクラスのロードに介入して改変できることを意味しています。実際OpenTelemetryではメソッドの実装に介入してメソッド実行時に引数を差し替えるなんて芸当をしています。

実際こういう実装の差し替えとかやりはじめると、考慮することが結構あって大変なんですけどね。bytecode manipilationと呼ばれる分野で、筆者の好物のひとつでもあります。

さてjavaagentの話に戻ります。javaagentは java.lang.instrumentパッケージに説明があります。javaagentにはそのままズバリの premainという関数を実装すればよさそうです。なるほど、 main関数の前に呼び出されそうな名前ですね。さらにクラス定義を差し替えるためのメソッドなども提供されていて、いかにもJVMをハックするためのAPIという感じです。

のでひとつ注意点があって、javaagentは使うとどうしてもJVM起動速度にペナルティがかかります。迅速に起動を終わらせてリクエストを受け付けられるようにしたいんだという場合、javaagentの利用を避けて手で各種初期化を行うことも検討せざるを得ない……ということもあるでしょう。

以上でざっくりした説明を終わります。OpenTelemetryは ServiceLoaderとjavaagentの合わせ技で、javaagentのCLASSPATHに入っているインタフェースの実装を main関数実行前に使うことで、 ClassLoaderに手を加えて計測対象モジュールに対して自動的に初期化を行っていました。一見便利ですがjavaagentの持つ速度的なペナルティや、javaagentのCLASSPATHが大きくなりがちという問題も潜んでいます。ご利用は計画的に。

人の一生は重荷を負うて遠き道を行くがごとし、とは徳川家康の言葉らしいですね。この記事では人生という旅路を振り返ること無く歩んでしまうと自己成長と健康に良くないので、ちょいちょい振り返りをするといいですよ、そのためにはコーチングというものを知っておくと捗りますよ。という話をします。

エンジニアにとって振り返りというとポストモーテムのイメージがあるかもしれませんが、今回対象にしているのは個人の活動に対する組織的な振り返りのことで、人材育成の文脈でフィードバックと呼ばれるものです。目標管理（MBO-S）とかOKRとかもこれに含まれます。

読み手としてはマネジメントも想定しますが、どちらかと言えば新社会人ないし組織運営の観点を補強したい方に向けています。コーチングは「コーチングのしかた」という技法も重要ですが「コーチングというものがあるのだ」という認知もまた自己成長と健康に役立つと考えています。よってコーチングを受ける側の新社会人の方にも役立つでしょう。

フィードバックとは教えることと答えを出す助けをすること

まずフィードバックを定義しましょう。私は中原先生の定義が好きでよく使っています。「Feedback = Teaching + Coaching」というもので、明確な答えがあることを教えるティーチングと、自ら答えを見出すことを助けるコーチングをあわせてフィードバックと呼ぶわけです。

ティーチングは学習機会を提供することで、例えば業務や事業領域についての知識を伝えることを指します。例えばJavaの書き方とか、サイバーセキュリティ教育とか、PRレビューのやり方とか、社史であるとか、こうした学習機会の提供は多くの職場でやっていると思います。特にオンボーディング（入社時教育）で頻出のイメージがあります。ティーチングは答えがあるものを扱うため、理解度を試験で確認することができます。

コーチングは逆に、答えのないものを扱います。前述の書籍から説明を引用します：

コーチングを最も簡潔に要約してしまえば「他者の目的達成を支援する技術」です。それは、育成する相手に「現状」と「めざすべきゴール」のギャップを、第三者からの「問いかけ」によって意識化させ、振り返り（リフレクション／内省）を促し、「今後、何を為していくべきか」の行動指針や行動計画をともに作っていく技術です。

（フィードバック入門 耳の痛いことを伝えて部下と職場を立て直す技術 第一章）

問いかけを受けて足を止め後ろを振り返ることが、旅路には有効に作用することも多いんですね。これ単体でも掘り下げて話せるような深い話題ですが、今回は話に具体性を持たせるため、メジャーなコーチングの場である1on1に絞って話していきます。すなわち職場において部下が、上司や同僚による「現状と目指すべきゴールのギャップ」についての問いかけを受けて振り返りを行い、今後の行動指針や行動計画をともに作っていく場面を想定します。目標管理やOKRの現場ではよくある姿ですね。

1on1の真の価値、あるいはなぜ1on1に準備が必要なのか

皆さんは1on1を定期的に開催していますでしょうか？筆者としては、月1度でいいのでぜひ定期的に1on1をしてほしいと思っています。相手としては自分のロールやフィールドに詳しい人がベストですが、そうでなくとも傾聴ができて問題解決プロセスにある程度明るい方であれば良いと思います。周りに適当な方が見つからない場合は、フィードバックに興味がある同僚を見つけて相互にフィードバックしあう形が始めやすいかもしれません。

1on1のよくある失敗パターンは、進捗共有と雑談だけして終わるパターンと、「今日は話すことがないのでスキップします！」パターンです。1on1をコーチングの場として、すなわち「自分で見つけなければならない答えを見出すヒントを得るための場」として見たときに、まず必要なのが「答えのない問い」です。事前に問いを用意して失敗パターンを回避しましょう。すでに心のなかにあるならそれを持っていけばいいですが、ぱっと思いつかない場合は次のように自問自答してみます：

• 自分の働き方や貢献に満足できていないことはあるか？
• どのようになりたい、何をもって覚えられたいという想いに反した現状が目の前に横たわっているか？
• 3ヶ月前、6ヶ月前、1年前の自分といまの自分を比べたときに、胸を張って成長したと言えるか？

問いが見つかればこれを分解し、自分で解決できることを除いていきます。例えば自分の貢献が足りないなと気づいて分析した結果、睡眠が足りないので朝会に遅刻することが多いという問題を見つけたとしましょう。このとき「早寝早起きする」のがすでに実行可能なのであれば、相談は必要ないでしょう。しかし「夜遅くまで業務が入ってしまう」「ストレスでなかなか寝付けない」などの事実があるなら、これは1on1に持っていく価値がありそうです。

自分で解決できない問いをいくつか用意したら、1on1が始まる前にこれを議事録に書いて相手に共有しましょう。相手は相談の内容に応じて準備するでしょうし、自分もなにが邪魔して「自分で解決できない問い」になっているのかを考える時間ができます。こうした準備がコーチングにおける傾聴と振り返りを可能にします。

コーチングが健康に効く理由

まずコーチングには承認と呼ばれる、あなたの挑戦やできていることを認めるプロセスがあります。これが自己肯定感の醸成につながるため、新しいことに挑戦していてまとまった成果が出にくい時期には特に、コーチングを受ける側のメンタルを守るすべとして期待ができます。ある程度経験を積んでいい意味で鈍感になれば、このようなフィードバックがなくても自尊心を維持できることもあるとは思いますが、特に新卒採用をするときには組織的にコーチングを行う体制が必要になるでしょう。

次に、これは人によるとは思いますが、少なくとも自分は身体の過負荷に対するサインって普通に生活してたらけっこう見逃すんですよ。ので「最近どう？元気？」と聞かれて「いやー全然ダメですね」と答えることはあまりありません。サインに自分で気づいたころにはもう戻れないところまで来ていたりします。

つまり「あっ、このまま行くとヤバいな」と気づくには才能や経験が必要なんですね。よって朝会や飲み会のような「最近どう？」ではなく、1on1という問題を意識的に俎上に載せる場が同僚の健康を守ることに繋がると考えています。

コーチングする側への手引き

もしあなたがコーチングをする側なら、ひとつルールを定めましょう。それは「進捗共有はするな！」です。進捗共有は朝会のようなチームに開かれた定例で充分に行われるべきだからです。不純物は取り除きましょう。

また1on1は業務上の問題を相談する場でもないので、「1on1が開催されるまで問題をしまっておく」ような動きが見えた場合もこれをやめてもらう必要があります。業務上の問題はリアルタイムにチーム内あるいはエスカレーションをもって相談するべきです。マネジメントが忙しそうだとなかなか報連相できない、という方は一定数いらっしゃるものなので、口を酸っぱくして「いつでも来てね！」というスタンスを伝えていく必要があります。自分は以下のルールをオフィスのキュービクルに貼っていました（とあるネットスラングの改変です）。

1. Your boss always has time to talk with you.
2. If your boss seems busy and hard to talk with, see the rule number 1. 

そして自分では解決できない問いだけが1on1の場に残ったとき、はじめて傾聴や質問、承認といったコーチングを行えるようになります。その問いはおそらくコーチングをする側であるあなたにも答えられないものでしょう。もしティーチングが有効そうならコーチングからさっと切り替えてしまってもいいですが、まずは傾聴することを勧めます。

まとめ

コーチングは自己成長と健康のために活用できるテクニックです。受ける側としてもする側としても、きっと学べることがあると思うので挑戦してみてください。特に準備の有無で体験が大きく変わりますので、1on1にマンネリを感じている方もテコ入れの一環としてコーチングを取り入れてみてほしいです。1on1をやっていないという方は、これを機に取り入れてみてはいかがでしょうか。

あけましておめでとうございます。新年早々オープンソースソフトウェア関係でやねうら王さんの記事が流れてきました。同じオープンソースソフトウェアを手掛ける開発者として記載内容の大部分には賛同できないのですが、枝葉は置いといて主幹だと私が思う主張については共感する部分があり、それについて書いてみます。

yaneuraou.yaneu.com

ユーザには無償であること以上に、オープンであることに着目してほしい

さて、そのような経緯でやねうら王はOSSとして公開してきました。やねうら王は、「無償でいいからどうか使ってくれ」ではないのです。まして、「俺はプロ棋士のファンだからプロの先生に使ってもらえたらとても嬉しい」でもないのです。(そういう考えの開発者の方も確かにいらっしゃいます。私はそうではないというだけです。)

繰り返しになりますが、OSSとは、単なる無料のソフトウェア以上の意味を持ちます。

この件については、ちょっとした補助線となるストーリーがあるので紹介します。私が学生だった頃は、この手のソフトウェアをフリーソフトウェアと呼んでいました。例えば当時のフリーソフトウェア配布場所最大手のひとつであるベクターさんでも、オープンソースソフトウェアではなくてフリーソフトウェアという形で説明しています：

www.vector.co.jp

このフリー（Free）には自由という意味を持たせていました。ところがフリーには無償という意味もあり、ソフトウェアの自由を保証すること以上に、無償で手に入るソフトウェアだということが前面に出る使われ方をされるようになります。そりゃそうですよね、命名が良くない。

そこで自由であることを強調するために*1、Free/Libre and Open Source Software（FLOSS）であるとか、単にOpen Source Software（OSS）などと呼ぶようになりました。こうした経緯、すなわち無償ソフトウェア扱いされてきた体験があって、オープンソースソフトウェアを開発・公開している人は「無償ではないんだ」ということを大切にしている人が一定数いらっしゃると私は考えています。

このあたりが気になる方は、詳しいサイトがあるのでこちらの一読をおすすめします：

www.kogures.com

のでオープンソースソフトウェアを使う場合は、無償であることよりも公開されていることや始めやすいことを特徴として捉えていただけると良いかなとは思います。

オープンソースソフトウェアにはだいたい「動作の保証はしないよ」と書いてある

私は、将棋ファンに向けて「将棋ソフトを無料で公開するから是非将棋ファンの皆さん、遊んでください」と考えているような篤志家などではなく、どちらかと言えばOSSの開発にコミットメントしてくれない人たちは、 （引用者略） 有償ならともかく無償ではそういう人たちのサポートをしたくありません。

このあとに書かれているように、大抵のオープンソースソフトウェアはサポートにも手厚い傾向は実際あります。ただすべてのプロジェクトがそうではなく、そうしたプロジェクトはサポートを手厚くすることで貢献のハードルを下げるとかシェアを奪うとかの狙いがあるからそうしている、あるいは成功体験があって無意識にそうしている場合が多いはずです。ですからオープンソースソフトウェア開発者ならユーザを大切にせよというのは、少なくとも違うと思います。

これはオープンソースソフトウェアには必ず含まれている文書にも明記されています。オープンソースソフトウェアはOSSライセンスによって利用者に対してライセンスされますが、このライセンスにはだいたい、以下のような表記を頒布物に含めることを求めています：

このプログラムは有用であることを願って頒布されますが、全くの無保証です。商業可能性の保証や特定の目的への適合性は、言外に示されたものも含め全く存在しません。詳しくはGNU 一般公衆利用許諾契約書をご覧ください。

GNU 一般公衆利用許諾契約書バージョン2でライセンスされるソフトウェアに同梱される文書

適用される法律または書面での同意によって命じられない限り、本ライセンスに基づいて頒布されるソフトウェアは、明示黙示を問わず、いかなる保証も条件もなしに「現状のまま」頒布されます。

Apache License v2でライセンスされるソフトウェアに同梱される文書

本ソフトウェアは、著作権者およびコントリビューターによって「現状のまま」提供されており、明示黙示を問わず、商業的な使用可能性、および特定の目的に対する適合性に関する暗黙の保証も含め、またそれに限定されない、いかなる保証もありません。

3条項BSDライセンスでライセンスされるソフトウェアに同梱される文書

英語で記載されていることもありますが、内容は一緒です。保証はないので自己責任で使ってくださいということです。オープンソースソフトウェアだけど保証がほしいなという場合は、サポートを提供してくれるベンダーを探すことになるかなと思います。

オープンソースソフトウェアを開発している開発者に求めるのは、間違いではないかもしれませんが機能しないことがあることは念頭に置いていただければと思います。このへんは本当にプロジェクトによる感じです。

配布されている無償ソフトウェアがオープンソースかどうかわからなくても、同梱資料を読めばオッケー

ここまで読んだ方は、なんだオープンソースソフトウェアってなんかめんどくさいんだな、とお考えかもしれません。でも実際ユーザが使うときは、ソフトウェアがオープンソースソフトウェアかどうかなんて気にしていないことがほとんどですよね。そこで、使おうとしているのが"めんどくさい"ソフトウェアであることに気づき、扱いを間違えないためのコツをお教えしましょう。それは、配布物に同梱された資料に目を通すことです。

あなたが入手したソフトウェアには十中八九、READMEとかLICENSEとかNOTICEとか、あるいはライセンス通知やエンドユーザーライセンス契約（EULA）などと名前のついたファイルが同梱されているはずです。インストーラが表示してくれる場合もあるかもしれませんね。

これらのファイルにはソフトウェアを利用する上で何に合意する必要があるか、このソフトウェアを利用するということは何を作者に許諾する必要があるか、などが書かれています。ユーザサポートについてはもちろん、商用利用時の可否についても書かれています。仮にオープンソースソフトウェアではなかったとしても、作者があなたの端末からどのような情報を得るか（！）などが書かれていることもありますので、目を通すに越したことはありません。

本当はオープンソースソフトウェアは決してめんどくさいソフトウェアではなく、ソフトウェアの自由と発展を考えて作られてきた運用であり文化だというのも伝えたいことではありますが、それは別の機会に譲ります。

まとめ

オープンソースソフトウェアのユーザには、とりあえず同梱の資料には目を通しましょうということを知っていただきたいです。そこにはユーザが知るべきこと、作者が伝えたいこと、双方の権利を守るための重要な通知が含まれています。

また無償であることを前面に出すことは、ソフトウェアの自由と発展を考えて作られてきたオープンソースソフトウェアの歴史、あるいは開発者個人の経験から、オープンソースソフトウェア作者にはあまり良い印象がないかもしれません。公開されていることや始めやすいことに感謝し、ブログで紹介するとか感想を伝えるとかの形で貢献（還元）することもご検討いただければと思います。

とはいえオープンソースソフトウェアとひとくくりに議論するには、この世のプロジェクトは多すぎます。つまり、私が書いたことを気にしない、あるいは他のことを大切にしている開発者も多くいるでしょう。ソフトウェアの向こう側にはその作者やメンテナーがいるのだとご理解いただき、その人がどんな人かに関心を持っていただくことが、そのソフトウェアを真の意味で大切にする行為なのかもしれません。

そりゃ間違ってるんだけど、ではどうするべきなのかが見えてないなぁという話です。

事業が大きくなると組織という仕組みの重要性が上がる

同僚が何千人といたメガベンチャーから社員数20数人のスタートアップに転職してから1.5年経ちました。ここまでに自分が貢献した内容にはSREや医療情報技師としてのものも当然あるのですが、マネジメント経験のあるIndividual Contributorという立場から組織の成長や組織における連携について補足や関連情報を提供するということも意外とありました。例えば社内ブログや社内勉強会で触れたものには以下のようなものがあります：

• コーチング紹介
• ヒューマンスキル紹介
• 爆速アウトプットを組織的に支える施策
• 事業の急成長における表側と裏側
• 稟議入門

こうした知識や観点を個々人が持つことは、ボトムアップと呼ばれる自発的な行動を支援する意味では大きな意味があります。そして少ない人数で尖った成果を出すことが求められるスタートアップ立ち上げ時には、これで充分でもあると思います。

一方で事業と組織が急成長していくフェーズでは、これでは足りないというのも事実です。もちろん個人の知識や観点を伸ばしていくことは引き続き大切ですが、人数が増えたことによるコミュニケーションの混乱や事業拡大による着眼点の増大についていくためには、底上げ的な施策や目標の明確化、すなわち組織をマネジメントするための動きが必要になります。トップダウンが必要だということではなく、ボトムアップを続けるためには最も情報を多く持つトップがきちんと情報や要求を棚卸しして、従業員に共有し続けなければならないということです。

事業目標の明示と共有に、トップの演説。
燃え尽き症候群対策に、ピープルマネジメント。
従業員の成長支援に、教育とコーチング。
従業員エンゲージメントの向上に、定期的な面談や人事施策などの実施と評価。
従業員の常識を合わせるための、定期的な従業員教育や統制。

このような「組織をマネジメントするための動き」をトップがやっていたら事業成長に時間を使えなくなりますし、専門家を採用して任せようということになります。こうしてスタートアップは組織化され、専門家が進み、より質の高い課題解決をお客様に提供できるようになっていきます。

組織化はチームマネジメントの負担を高める

しかし人事部があればそれでオッケーかというと、そういうことにはなりません。各部署やチームごとに働き方や求められる専門性、扱う情報などは異なりますし、職場に求めるものは個人レベルで異なります。そうした異なるニーズに対して人事部がケアしきることは事実上不可能です。

この問題に対する解決策でよくあるのが、人事部はルールやツールの整備をし、実行の多くをチームマネジメントが担う方式です。つまり部長や課長に相当する中間管理職に対して、その部下への「組織をマネジメントするための動き」を期待する方式です。部長や課長であればそのチームがどのような働き方をしているのか把握していますし、部下それぞれの個性もわかっていますし、面談を通じてコーチングすることもできます。よってチームマネジメントが「組織をマネジメントをする動き」をすることは合理的であり、組織としてスケーラブルな施策であるとも言えます。

しかし待ってください、チームマネジメントにはもともと他の役割を期待していなかったでしょうか。それはプロダクトマネジメントかもしれないですし、プロジェクトマネジメントかもしれないですし、コードレビューや渉外かもしれないですが、とにかくチームを結成してここに代表者を置いた時点で何らかの機能を持たせていたはずです。チームマネジメントはその道の専門家であって、ピープルマネジメントだ従業員エンゲージメントだ統制だとあとから役割を増やすことにはいくつかの問題があります：

1. その人には「組織をマネジメントするための動き」に対する知識や関心がないかもしれない。チームを率いるものとして組織に全く関心がないということはないかもしれませんが、そんなの人事でやってくれという声を聞くことは珍しくないのでは。
2. その人の「組織をマネジメントするための動き」を評価してフィードバックすることが難しい。前提の整理やゴール設定を中央管理的にできないからチームマネジメントにお鉢が回ってきているわけで、そのチームマネジメントがきちんとできているかを外部から評価することは意外と難しい。

言い換えるならば、組織化はチームマネジメントに対して多彩な要件をつきつけます。経営者が経営に必要なすべてを担い、スクラムマスターがスクラムの運用に必要なすべてを担うように、組織化はチームマネジメントにチームが機能するために必要な全てを背負わせます。そして事業の成長とともにチームとそのメンバーに対する期待値も高まり、チームマネジメントへの負担も向上します。

これは組織を運営する我々が、チームマネジメントに超人であることを求めていると言えないでしょうか。チームにおける単一障害点（SPOF）であるチームマネジメントにここまで高い負荷をかけることは、組織運営上正しいことなのでしょうか。

求められるのは「組織をマネジメントする動き」の専門家か、それとも「組織をマネジメントするための動き」のコモディティ化か

浮上した課題に対して組織化によって対応したこと自体は、大きな間違いではないと思います。two pizza teamを作ってこれをまとめることで事業と組織を大きくすることは、今やシステム開発におけるベストプラクティスのひとつだと言っていいでしょう。となると「中央管理を諦める」か「分散実施をチームマネジメントによって実現する」のどちらかに課題があると思われます。

ただ中央管理にこだわるのは、事業成長のどこかで破綻するのではないかと考えています。もちろん人事部はミッション・ビジョン・バリュー（MVV）を整理して全従業員が共通言語で話しあい評価しあう組織を志向するべきですし、そのレベルでは中央管理もするべきです。しかし前述のとおり、チームや従業員ごとの個性に対する配慮なしには「組織をマネジメントするための動き」は実現できないため、どこかで破綻するだろうというのが自分の考えです。

よって解決は「分散実施をチームマネジメント以外の仕組みで実現する」になるでしょう。しかし、具体的にはどうすればいいのでしょう？

ひとつのアイデアは組織をマネジメントする動きを提供する専門のチームを作ることです。部下からは専門性（チーム）の上長と、人事的メンタル的な上長を持つ形になります。 これはちょっと難しいかなと思っていて、というのも専門性の上長と人事的メンタル的な上長の間のパワーバランスってどうなるんだろうという。メンター制度によってある程度はメンタルのケアや教育の実施を上長から外すことを実現できている事例は聞くのですが、完全な代替にはなっていなさそうです。

もうひとつのアイデアはチームマネジメントだけではなく従業員全員が「組織をマネジメントする動き」をすることです。上長によるトップダウンではなく、チーム内での相互作用によって組織をマネジメントしていくことです。 これはある意味で理想的なんですが、事業成長において必要な（比較的に）大量の人材を採用するときのハードルとなってしまいます。「組織をマネジメントする動き」には合う合わないもありますし、単純に習熟と時間を必要とするからです。それこそ新卒採用なんて無理じゃねって感じですね。またこの手のアプローチには再現性がまだなさそうだなと思っているということは、「ティール組織わからん、を掘り下げる」にもまとめています。

組織という仕組みで解決することの難しさ、あるいはマネジメントに超人を求めるのは間違っているだろうか

事業拡大における組織化の重要性と、その際にチームマネジメントの負荷向上という問題について書いてきました。組織化は重要だけど組織という「仕組みで解決」する過程でどうしても個人に依存しちゃうねという。正直まだいい解決は見つかっていないと思っていて、チームマネジメントに高い負荷をかける今までのやり方をチームマネジメントの様子を見ながらやっていくのが現実解かなぁと思っています。その点で、人事部が真にやるべきなのはチームマネジメントに対する教育とコーチングなんでしょう。

現職はまだこういう悩みとは無関係なのですが、自分が統制をかけていく側のロールなのでうまいやり方を見つけていきたいんですよね。このへん読むといいよって感じの推薦図書とか講演動画とか、もしあればTwitterやはてブ、本記事へのコメントなどで教えていただけると嬉しいです。

JavaやNodeJSには多数のビルドツールがあります。ものによってはビルドツールではなくタスクランナーとかワークフローとか名前が付いてるかもしれませんが些細なことです、ここでは以下のようなツールのことをまとめてビルドツールと呼びます：

• Apache Ant
• Apache Maven
• Gradle
• Bazel
• yarn
• pnpm

一方で言語公式のビルドツールを用意している言語もあります。これによってプロジェクトごとに異なる技術を学ぶ必要性が減りますし、一貫性のある開発体験を得ることができます。javacjavadocのような単純なコマンドしか提供しないJavaとは異なる方針を言語として持っていることは明らかでしょう。

では言語のエコシステムにビルドツールがたくさんあることはモダンではなく不便なのでしょうか？そんなことはないだろうというのが自分の考えです。もちろん欠点がないとは言いませんが、以下に私見を述べます：

プロジェクトによってビルドツールに求められる役割は異なるため、きめ細かな選択肢を選べる

例えばプログラマが若干名のプロジェクトでは、コンパイルやテストが一箇所にまとまっていてフットワーク良く改善を回せていけることが望ましいでしょう。複数リポジトリやサブプロジェクトを作る必要性もまだ薄いでしょうし、そこまで統制について考えることもありません。自分なら開発が活発でパフォーマンスも良いGradleを選択することになると思います。

一方で何百人ものプログラマが関与するプロジェクトでは、ビルドツールやワークフローについても統制を考えるケースが出てきます。 mvn testを実行したらテスト実行結果が必ずJUnitのXML形式で target/surefire-reports/TEST-*.xmlに吐き出されなければならないとか、Reproducible Buildsに準拠するとか、developブランチにマージしたらSonarQubeを実行せよとか、ビルドするにはJava 8を使わなければならないとか、そういったベースとなる要求をすべてのプロジェクトに守らせることでリポジトリ横断的な品質改善に役立てたりするわけです。

今だとこういった要求もGradleで満たせそうですが、7年くらい前？に自分が似た状況にあったときは、Mavenのparent projectによる制約の中央管理とバージョン管理が非常にマッチしました。DSLがないので自由度が低く、統制側としては考慮すべきことが減るというのもあります。中央管理する以上は各リポジトリの困りごとをきちんと拾い上げる姿勢は必要になりますが、その工数を考慮してもMavenに軍配が上がることはあるでしょう。

ビルドツールの思想に種類があることを学べる

そもそもこうした違いはどこから生じるのでしょうか。モダンな技術を使って開発された新しいビルドツールは常にレガシーなものよりも優れているべきではないのでしょうか？実はそうではなく、むしろ最もレガシーなApache Antと最もモダンなGradleはかなり近い特徴があります。

Apache AntとGradleはタスクを繋いで有向非巡回グラフ（DAG）を作るという発想で作られています。テストはテストケースのコンパイルに依存し、テストケースのコンパイルは実装のコンパイルに依存し、実装のコンパイルはアノテーションを使ったコード生成に依存する……といったタスクの間の依存関係を明示することで、タスクを並列実行したり不要なタスクの準備を省いたりして高速化ができるのです：

graph LR;
  annotation-processing --> compile --> testCompile --> test --> check --> build;
  compile --> jar --> assemble --> build;

特定のタスクだけ実行する・特定のタスクだけ除外するといった操作も簡単に行なえます。プロジェクト固有のタスクや概念を導入することも容易ですが、一方でタスク実行時に必要な入力がすでに生成されているかどうかを管理するため、タスクの入出力を宣言したり、タスクが依存するタスクを明記する必要があります。DAGをメンテナンスする責任をユーザが負い、それを前提にタスクの内部実装を気にせずに済むようになっています。

Mavenはビルドライフサイクルという概念があり、すべてのプロジェクトはこのライフサイクルに従うことを期待されています。ビルドライフサイクルをゼロから作ることも可能ですが、かなり重い作業です。

ビルドライフサイクルにはフェーズが定義されており、このフェーズにプラグインのゴールを紐付けることで、どのようなプロジェクトでも同じビルドライフサイクルで臨んだ結果を得られるようにしています：

graph LR;
  subgraph compile
    compiler:compile
  end
  subgraph test-compile
    compiler:testCompile
  end
  subgraph test
    surefire:test
  end
  subgraph package
    jar:jar
  end
  compile --> test-compile --> test --> package

そのフェーズに入った時点で以前のフェーズはすべて完了していると信じられるため、ゴールの入力がすでに生成されているかを気にする必要は比較的薄いでしょう。フェーズ内で実行する処理に依存関係がある場合、 compiler:compileゴールがアノテーションプロセッシングとコンパイルの両方を行うように、ひとつのゴールにまとめてしまうことで単純化します。

一方でやはり柔軟性には欠けます。ライフサイクルの一部だけ実行したい場合、例えばテストを再実行してレポートを生成する場合など、必要なプラグインのゴールを特定してそれを直接実行しなければなりません。逆にテスト以外のすべてを実行する場合も、プラグインの実装を理解して -DskipTestsオプションを指定するといったことも必要です。依存先のゴールを自動的に推定・実行することもないためゴールの入力が不正になることも多く、昔は「とにかく mvn cleanしてやりなおす」ということもよくやっていました。おそらく多くのMavenプロジェクトでは、開発時の混乱を避けるためにREADME.mdやCONTRIBUTING.mdにこういうときはこうするというコマンド一覧が載っていると思います。

長くなりましたが、すべての状況にマッチするツールが存在しないのは、ツールの根底にある思想によって適した現場がそれぞれ異なるからだと考えられます。これらの思想そのものは20年以上変化していない時代の荒波に揉まれたものですので、一長一短はあれど使い所が合えば価値の高いものだと言えます。ビルドツールの多様性は、それすなわち言語の活用幅の広さだということなのでしょう。

単に歴史が長いのでビルドツールが数多く生まれてきた

特にJavaは言語としての歴史が長いので、多くのビルドツールが作成され検討されてきたという側面はあると思います。例えばApache Antを使っているfb-contribは2005年からあります。当時からJavaのビルドツールが成長せず、Antだけでここまで来れたかというと、ちょっと考えられませんね。最近（と言っても8年前ですが）Java Moduleにネイティブで対応するビルドツールも提案されていたりして、今でも新しい形が模索されています。

それで言うと今はひとつしかビルドツールを備えていない言語も、もしかしたら今後はビルドツールが2つ3つと増えてくるかもしれませんね。どんなニーズにもひとつのツールチェインで応えようとすると収集つかないこともありそうなので。

とはいえ新しいツールに乗り換えたほうがいいこともある

古いビルドツールをずっと使い続けると技術革新の恩恵を得にくいみたいなところはありますので、ビルドツールをモダンなものに変えていく努力はしたほうが良いことはあります。これからも活発に変更を入れていくプロジェクトであれば特に、更新が活発なビルドツールに移行したほうが良いでしょう、私もFindBugsをSpotBugsにforkするときはAntとMavenを使っていたプロジェクトをGradleで書き換えるという経験をしました。

異なる思想を持つツールに移行する場合は両方のツールに詳しくないと思わぬところで失敗するなんてこともあるので、一時的に有識者に手伝ってもらうことも検討しましょう。私もビルドツール移行の副業を受け付けております（唐突な宣伝）：

youtrust.jp

まとめ

エコシステムにビルドツールがたくさんあることは悪いことではありません。キャッチアップが大変とか、コミュニティの知見が分散してしまうとかはもちろんあるのですが、コミュニティの抱えるプロジェクトの多様性を担保し、歴史あるプロジェクトと新鋭気鋭なプロジェクトとが同居する上でとても重要な貢献をしています。

キャッチアップコストが気になる場合はREADMEを整備するとか情報の多い新しめのツールに乗り換えるとか、自衛策を取ることもできます。最初からビルドツールがひとつだったら払わなくて済むコストでは確かにあるのですが、言語の歴史と実績に思いを馳せていただければと思います。