🤖

Technology Radar Volume 28 まとめ

januswel

2023/05/31に公開

Technology Radar についてはここにまとめている。

この記事では次のことがわかる。

今号のテーマ
各カテゴリーごとの Adopt / Hold / ピックアップを紹介
- ピックアップは将来的に影響がありそうなものや面白そうなものを選んでいる
- 個人的な思いなども書いているので参考に

その他のまとめ

今号のテーマ

実用的 AI の隆盛: The meteoric rise of practical AI

ChatGPT や GitHub Copilot など、最近の機械学習分野は実用性の高いプロダクトが多い。社会的なインパクトも大きいため、改めて言われなくとも知っている方も多いだろう。

meteoric rise は一時的なブームという意味合いも持っているため、少し挑発的なタイトルだ。ガートナーのハイプ・サイクルで言えば「過度な期待のピーク期」だろうか。

利用可能なアクセシビリティ: Accessible accessibility

アクセシビリティの実現は近年より一層ハードルが下がっている。 SDGs への取り組みが追い風となっている側面もあるだろう。エンジニアリングとしてはテストツールが整い、実現に必要な知識を学習可能になってきたことが大きい。

AWS Lambda の泥沼化: Lambda quicksand

サーバーレス関数にこだわりすぎると困難な状況に陥る。 AWS Lambda が言及されているが、他の実行環境でも同様だ。

分析や AI 領域におけるエンジニアリングの困難: Engineering rigor meets analytics and AI

エンジニアリングの難しさが分析や AI 領域でも目立ってきた。そういった課題を解決するためにエンジニアリングで得られた知見や実績のあるツールを持ち込むという動きが多い。

宣言的な定義 vs プログラム: To declare or program?

DSL で宣言的に記述するか、プログラムで柔軟に書くかの判断は難しい。チームに最適な選択肢をとっていくのが良いだろう。

Techniques

Adopt

社内プラットフォームにプロダクトマネジメントを適用する

日本では社内システムは片手間で構築 / 運用したり、情シスが取りまとめたりなどが一般的だ。しかし、社内システムにはターゲットがおり、開発において種々の制約が存在するなど、プロダクト開発と同様の性質を持っている。これに対してプロダクトマネジメントの領域で得られた知見を適用しよう、というのは極めて自然な態度だろう。

企業の規模によって課題が異なるので一概に言えないが、 10 名以上の組織ではこの blip を意識してよいだろう。プロダクトマネジメントを実践するのは片手間では難しいが、知識として知っておくだけでも随分違うはずだ。

マネージド CI/CD サービス

この blip が何を対象としているのかがきちんと説明されていないので理解が難しい。のだが、次の点からマネージドな CI/CD サービスの説明と推測して解説を書く。

この blip が新規で登録されていること
例として GitHub Actions 、 Azure DevOps などが挙げられていること
比較対象として自前での CI/CD 構築が記述されていること

一般的な開発において大抵の目的はマネージド CI/CD サービスで解決できるようになっている。また、ハードウェアも含めたテストでもセルフホストランナーでなんとかなる場合も多い。

ただ、 2021 年のセキュリティインシデントの例もあるので機密情報を扱う場合は CI/CD におけるゼロトラストセキュリティなどに従って防御が必要だ。

依存を削る

この blip の要点はサプライチェーン攻撃への防御、これに尽きるだろう。

説明ではフレームワークを用いてコード生成した際の不必要な依存の削除についても触れられている。しかし、生成されたコードの構造をよく理解していないとフレームワークの恩恵が受けられなくなってしまう。あるていど運用し、わかってきた段階などで実施すると良い。

アーキテクチャーの適応度関数としてコストを考慮する

適応度関数とは乱暴に要約すると、もともと遺伝的アルゴリズムにおける好ましさを関数として表現したものだ。アーキテクチャーの好ましさを、実行環境やビジネスなど周辺環境への適応度によって測ろうという思想だろう。

エンジニアはアーキテクチャーを決定する際に様々な要因を勘案する必要があるが、今まではコストがあまり意識されてこなかった。これはコストを可視化し、承認のためのルールをきちんと決めておこうという blip になる。

毎月のランニングコストを可視化して予測線を描いたり、よりエンジニア的に解決するならば CI 時点で変更に関わるランニングコストを算出し、 CD 実行承認時にひとつの指標として用いるなどが考えられる。

Hold

カジュアルな webhooks 設定

Slack などチャットツールに対して外部サービスからメッセージを投稿したい場合は多い。こういった誘惑は様々な状況で発生する。

もちろん CI/CD や chatops のための設定は必要だが、 webhook 設定時に払い出されるものはクレデンシャルだ。知らずに GitHub の public repo などにアップロードしてしまうといたずらされるおそれがある。

かくいう自分も個人の Slack ワークスペースに「漏れてるから削除したほうがいいよ」というメッセージを投稿されたことがある。親切な方からの忠告だったのだが驚いてしまい、変な汗が出た。

これは意識や気持ちの問題ではあるのだが、怠惰でありたいのが人情というものだ。幸い、 secretlint には Slack 用のルールもあるので、機械的にチェックして git commit できない状態を作るのが良い。次の記事で設定方法を書いているので参考に。

Lambda ピンボール

ピンボールについては次のページを見てもらったほうがわかりやすい。

https://en.wikipedia.org/wiki/Pinball

AWS Lambda 上の関数から別の関数を呼び出すことを連続的にすると、どの関数がどういった前後関係で呼ばれるのかの把握が非常に難しい。ピンボールのボールは次々に様々な仕掛けにぶつかるが、こういった様子に似ているとして揶揄したものだろう。

起動順番が読めない程度ならば影響はないだろうが、稀に前提となる処理が終わらないうちに後続の関数がキックされてしまう現象などが発生してしまうと途端にデバッグが難しくなる。

これは AWS Lambda だけでなく、いわゆるサーバーレス関数実行環境であれば発生しうるものだ。Cloud Functions であろうと、 Azure Functions であろうとこの blip は発生する。

ひとつのプロビジョニング単位で複数の関数を配置してキックさせる、というのは誰でも思いつくことだ。が、それは本当にプロビジョニング単位をまとめなければならないのか？ DDD の文脈でいうところのコンテキストが異なるのではないか？といったことを考える必要がある。

リソースをフル活用したスプリント計画

作業量にまったく余裕がないスプリント計画のことを指している。初期開発中であっても PMF するまでは変更の連続だし、運用が入ってくると何が起こるかわからない。他にも、今の課題への解決策を探ったり、学習時間を確保するためにも余裕を作っておかなければならない。

blip の文脈としては SCRUM の話だが、その他の開発プロセスでも同様だ。期日までの時間をフルで使えると仮定することがまず誤り。複数プロジェクト関わっているならスイッチングコストが必要なことも考慮する必要がある。

ピックアップ

Verifiable Credentials

本人確認書類の電子版。W3C で議論されている。夢が広がりそうな blip だったので取り上げた。

https://www.w3.org/TR/vc-data-model/

例えば国から発行されたクレデンシャルがあればマイナンバー代わりとなるし、所属組織から発行されたクレデンシャルによってアクセス可能な情報を制御可能となる。学校から発行されたクレデンシャルによって課程修了や一定レベルの知識を持っていることが検証可能となるだろう。ユースケースを見るとかなりアトミックなものが書かれており、想像次第でいかように使うことができるように読める。