00:00
お疲れ様です。EUR-Tech第7回始めていきましょう。
ソフトウェアエンジニアをやっている、はくたけです。
お疲れ様です。ソフトウェアエンジニアをやっている、みつながです。よろしくお願いします。
よろしくお願いします。
さて、今日なんですけど、自分がネタを持ってくる回なので、
読んだ本の話をまたしようかと思ったんですけど、
今回はちょっと前に、State of DevOpsっていう毎年出てるやつがあるんですけど、
Accelerateとか、Linint DevOpsの科学とか、
あの辺で有名なForkiesとかの話がよく出てくるやつですね。
それの2022がついこの間出たということを知ったんですよ。
私も今、はくたけさんから聞いて知りました。
GCPのDevRelの方ですね、トンプ山口さんっていう方のツイートで、
出てるんだと思って。
なるほど。
この方がツイートのスレッドで、2021年から大きな変化がありましたよとか、
セキュリティ周りの調査が多くあったよって言ってたんで、
読んどかないとなと思って読んだ感じです。
この収録終わったら私もちょっと読もうかな、時間かけて。
一応ダウンロードして、PDFなんで、
Google翻訳とか聞かせられなくて、分かんない単語とかきつかったんで、
あれ、完全にPDFをそのまま翻訳にかけて、
てって。
読み合わせながら見てました。
結構やっぱりイマイチで、
普通に英語の方を読んで、これかこれかってなりながら読みました。
結構日本語に翻訳すると意味が通じにくかったりしますもんね。
しますね、この辺。
リライビリティエンジニアリングとかでいいのに、
信頼性エンジニアリングとか入ってあると、
あら、ん?ってなったりするんで。
なんならリライビリティエンジニアリング知らない人が最初にその言葉見たら、
何のこと言ってんだろうってなりますもんね、きっと。
なります。
ここは訳してくれなくていいんだろうな、
まあまあ普通にありましたね。
なるほど。
で、一応ザーっと目は通したんですけど、
中の詳しいところとかは、
もう本当読み飛ばしぐらいにしか読んでなくて、
一番最初にエグゼクティブサマリーっていうのがあったんですね。
そのサマリーをガーッと読んで、
で、そのさっきのツイートにもあった、
2021年がすごく変わったところ、
サプライズイーズのところを読んだ感じですかね。
2021年だとコロナ禍とかそういうタイミングの話ですかね。
一応あったはずなんですけど、
でもですね、今回の傾向で変なのがちょっと交じってたんですけど、
03:06
それの理由としてコロナ禍を理由に挙げてるところがあったんで、
もしかしたら2021までのやつはあれだったのかな。
その前の研究のあれだったのかもしれないですね。
なるほどなるほど。
ざっといってみますか。
はい、お願いします。
まず、ざっくりこのレポーター何なのかっていうのが書いてあって、
ソフトウェアデリバリーパフォーマンス、
これ普通のデリバリーのパフォーマンスですね。
オペレーショナルパフォーマンス、これは運用のパフォーマンスですね。
オーガナイゼーショナルパフォーマンス、組織のパフォーマンス。
っていうのについて、
ケーパビリティとかプラクティスがどんな風に関係しているか、
どういうのが影響するかみたいなのを調査しているレポートです。
って書いてあります。
セキュリティの話っていうのが強調されてたんですけど、
次にもうドンと載ってきてて、
セキュリティの中でもサプライチェーンセキュリティですね。
セキュアリングザソフトウェアサプライチェーン。
なんかそのセキュリティ、フレームワークみたいなのがあって、
Salsa、S-L-S-Aってやつですね。
と、SSDFっていうのがあるらしくて、
セキュリティのためにこういうプラクティスがありますみたいな。
そういうのがある程度標準化されてるんですね。
あるみたいですね。
レベル分けとかがSalsaはされてて、
これをやってる、これをやってる、これをやってる、
じゃあレベル3ですねみたいな感じだったりするみたいですね。
なるほど。
それに基づいてレビュー、質問とかしたみたいですね。
このサマリーによると、ほとんどの回答者が、
そこにあった全プラクティスを部分的にでも採用はしていますと。
なので結構すごい結果でしたねみたいな感じで書いてありましたね。
その良い方向でのってことですか?
そうですね。
いろいろあるのに、そのアプリケーションレベルでの
セキュリティチェックを自動化しているとか。
はいはいはい。
そういうのがちゃんと、一部分だけでもっていうことなんで、
どういう感じだろうな、例えば自動化してないとかなのかな?
わかんないですけど、ちゃんと詳しいところまで見れば書いてあるんでしょうか。
一応いろんなことに対して、部分的にでもやっている人がほとんどだったという感じです。
はい。
で、これはさまりで最後の方とかにまでずっと出てくる大事なところなんですけど、
技術力が高い組織よりも、
心理的安全性の高い組織の方が、
06:03
セキュリティの新しいプラクティスを採用しやすいということがわかりましたと書いてあります。
ほー、すごく面白い結果ですね。
心理的安全性は、役としては適切じゃないかもしれないんですけど、
要するに、どこあったかな、これ下の方にも書いてあるんですけど、
ウェストラム博士っていう人が定義している、
ハイトラスト&ローブレイムのカルチャー。
ハイトラストだから高信頼、高い信頼。
高信頼、批判が少ない文化。
はいはいはい。
そういうところの方が、新しいプラクティスを採用しやすい。
その文化が醸成されていると、
その組織の中では挑戦しやすくなっているとかっていうところに繋がるんですかね。
そういうことですね。考えてみると、
それはそうだよなっていう感じではありますけど、
ここでも驚きは、そういった影響力の方が、
単純に技術力が高いということよりも影響力が大きいということみたいですね。
そうですよね、確かに。
さらに、この資料ですね、
結構バンアウトについても、燃え尽き証拠群ですね。
はいはいはい。
バンアウトについても結構調査したっぽくて、
セキュリティに注力しているチームの方が、
バンアウトが少なかったらしいです。
えー、それって何かこういう理由なんですっていう説明とかってありました?
えーっと、あったかな。
セキュリティに注力する。
直接的なのはなかったかもしれないですね。
なんでかっていうのは。
データとして解析結果が出てきたってことですよね、これって。
そうですね、それに対しての仮説はあったと思います。
セキュリティに注力しているチームの方が満足度が高いとかだったかな。
えー、そうなんだ。
そういう感じで結局バンアウトが少なくなるみたいなことですかね。
すごく興味深い内容ですね。
そうですね。
かつ、自分のチームを他人に進めやすい。
自分たちは良いチームだよって言いやすいってことですかね。
なるほど。
そこに関連性あるんだって思いましたね。
セキュリティの注力とかと。
セキュリティっていう言葉の定義が
このレポートの中でどれぐらい広くされているのかっていうところが気になってるんですけど。
そうですね、ちゃんと見てみないとですね。
セキュリティって言ったら、全般的にサプライチェンスセキュリティへのプラクティスを実行しているかみたいなところだと思います。
なるほど、なるほど。
そこに注力しているチームの方が自分のチームを進めやすいっていうのは
まだいまいちイメージが湧かないですね。
09:03
ピンとこないですね。
ピンとこないですね。
ただ読んでいくと、いくつかが関連していて最終的にそうなるんだなってなんとなく想像がつきましたね。
最後のほうのまともりにも確かなってた気がする。
じゃあ一旦ちょっと先に行きますよ。
はい。
どこまで行ったっけ?
ここか。
さまりの一つ目がそのさっきのセキュリティで、
次がドライバーズオブオーガニゼーショナルパフォーマンス。
その指揮のパフォーマンスを、ドライバーズだから牽引するとか、よくするとかそういう感じですかね。
っていう要素が3つあって、オーガニゼーショナル&チームカルチャー、カルチャーですね、文化とリライビリティとクラウドです。
ここにリライビリティが出てくるんですね。
出てくるんですよ。
ほう。
最後のクラウドっていうのは本当にクラウドを使ってるっていうシンプルなことなのか。
この水準のPDFというか資料リソースで、このレベルの話なんだと思ったんですけど、
やっぱり世の中にはクラウドを使ってないところが多くて、ということなんだと思いました。
なるほど。
なのでクラウドを使ってるとも、割とそれだけで結構そのパフォーマンスが良くなるよっていう。
変化に対応しやすいですからね、シンプルに考えて。
そうですね。あと、調達コストとか当たり前のメリットがありますからね、組織のパフォーマンスにしたら。
確かに。
っていうところですね。
まとめの3つ目が、コンテキストマターズ、文脈が大事みたいな感じですけど、
当然ある組織でうまくいくことが別の組織でうまくいくことが限らない。
よくある話ですよね。
そうですね。っていうのがあった上で、ここも結構後のほうの驚きポイントに上がってたんですけど、
この資料ではソフトウェアのデリバリーパフォーマンスと運用パフォーマンスというのが明確に分けられていて、
オペレーショナルパフォーマンスが高くないと、デリバリーパフォーマンスが高くても、組織のパフォーマンスには寄与しないって言う結果が出たらしいです。
じゃあ、例えばデリバリーするまではすごく早いんだけれども、その先の運用がお隣になって、例えば対応が遅いとか色々あった場合って、
結果的に組織の成果にあまり結びつかないよってことですか?
そういう感じのことが書いてありました。
ほう。
だから変更失敗率高いとか、運用でエラーとかが出まくるような状態とかだとダメってことですかね。
だからあれか、何でしたっけ、FociMetrixとかで定義されてるデプロイ頻度と変更の速度、変更のリードタイムと、
12:07
あと障害復旧時間と変更失敗率の4つのうちの、多分後半2つが今の話で言うとオペレーショナルパフォーマンスにあたるところなんですかね。
それがここの分類だと違くて、その4 keysがソフトウェアデリバリーパフォーマンスです。
そこ自体がもうそうなんだ、なるほど。
オペレーショナルパフォーマンスはリライビリティだけですね。
リライビリティ、また計測が難しそうな。
これも後で説明しますけど、2020年までかな、はずっとアベイラビリティだったらしいんですよね。
この資料で計測してるの、可用性だったんですけど、それってリライビリティの一部でしかないよねって話で、
去年からリライビリティに変わったらしいです。
ついにそういうところまでリライビリティという言葉がカテゴライズされるようになったんですね。
なったということですね。
文脈のやつでいくと運用パフォーマンスが良ければよいっていうのと、
あとSalsaのようなサプライチェーンセキュリティの実装があるとまた良いと。
この辺がコンテキストの一部ってことですね。
こういうのがあるといいよねっていうコンテキストですね。
なるほどね。
リライビリティエンジニアリングを実践したとしても、実はある一定のレベルまでは効果が出ないらしいです。
組織パフォーマンスに寄与していない。
でも、そのリライビリティのレベルが上がってきて、ある一定のレベルを超えると組織パフォーマンスに影響を与え始めるっていう。
なるほど。
そうですね。線形ではないって表現がされていました。
どこかで一定のレベルのポイントがあって、それを超えると初めて成果を実感できるというか効果を実感できるようなものなんだろうな、きっと。
そういう感じでしたね。
へぇ~。
個別の技術的なプラクティスがあります。
CICD。ここで言われていたのが、疎結合なアーキテクチャとかバージョン管理って言われていたんですけど、それぞれは単品で導入しても一応効果はあるんだけども、
それぞれが例えば1の効果があるとしたら、4つ導入すれば4の効果ではなくてもっと高い効果。
総称効果になると。
っていうことが書いてありましたね。
ほうほうほう。
この章のまとめのほうがさらにまとめとして、
「継続的に改善する必要性を認識しているチームは、そうでないチームよりも組織のパフォーマンスが高くなる傾向があります。」って書いてありました。
15:01
う~ん、まあ、そうだよなっていう感覚になりますよね。
この辺は驚きポイントではなくて、まあ、そうですよねっていう感じですね。
ですね。
はい、サマリーでした。
はい。
それの補足だったりとか、そこに書いてないことがいくつかあったんで、その下にペーって書いてみました。
ほうほう。
はい。
で、えーっと、アクセラレートといえばやっぱりFour Keysだと思うんですけど、
5番目のメトリクスとしてリライビリティが追加されたっていうのが結構でかいところみたいで。
これって、その、Four Keysだった以前って、
じゃあ今回の表現でいうと、基本そのソフトウェアデリバリーパフォーマンスの部分に対して非常に着目してたけれども、
今回の2022年のレポートでは、オペレーショナルパフォーマンスも重要だってことが分かって追加されたみたいな感じですかね。
だと思います。
はぁはぁはぁ、なるほどなぁ。
なんか今までは、このソフトウェアデリバリーパフォーマンスが直接的に送還があったみたいなんですよ。
あの、組織のパフォーマンスに、オペレーショナルパフォーマンスに。
でも今回はそうではなかったっていうのが書いてありますね、この後。
なるほど。
うん。
まあ、リライビリティの話がさっきしたやつですね。
うんうん。
で、えーっと今回、2022年のこの調査では、全体的にデリバリーパフォーマンスが低下したみたいなんですよ。
へぇー、それはちょっと興味があるというか、どうしてだろう?
なんか一応、明確な理由みたいなのはなくて、仮説の一つとして、今回はやっぱパンデミックが、
はいはいはい。
チームの知識の共有とかコラボレーションとか、そういったものを阻害していたんじゃないかっていう仮説が立ってるみたいですね。
あー、なるほど。
ただこれですね、図を見たら分かったんですけど、
はい。
えーっと、三沢さん、このGoogle Cloudのブログのサマリーっていうのが貼っていたんですけど、これ見れます?
アクセスしました。はい。で、図が?
えーっと、丸が結構出てくるやつが中程に。
The industry continues to evolve.
はい、これですね。
はいはいはい。
これ見ると分かるんですけど、2022ではエリートがなくなってるんですよね。
ですねですね。
はい。けど、それぞれのクラスの定義が一緒じゃないんですよね。
なるほど。なるほどね。
はい、だから、前回までのメディアムが今回のメディアムと同じ定義じゃないから、純粋に増えた減ったってなってないみたいなんですよ。
新しく定義されたら該当してなかったぐらいの感じなんですかね。
18:05
そうですね。でも、そういうのは抜きにしても、全体的にやっぱりパフォーマンスが下がってるっていうのはそうみたいですね。
なるほど。
というのが書いてなかったことかな、サマリンに。
で、もう一つが、さっきクラウドの仕様が組織パフォーマンスにプラスの影響を与えたっていうのは書いてあったんですけど、
はい。
そこにただしみたいな感じでですね、マルチクラウドしてたりとか、音符含むプライベートって書いてあったんですけど、多分音符のことだと思います。
マルチクラウドとかを使用していると、デリバリーのパフォーマンスにマイナスの影響がありましたっていうのが書いてありました。
うーん、ま、
複雑になるかな。
そうですよね。想像するに複雑性が上がる分、大変コストがかかってるのかなって感じですよね。
そうですね。ただし、高いレベルのリライアビリティがない場合って書いてありましたね。
じゃあ、マルチクラウドにしていたとしても、リライアビリティエンジニアリングが一定以上のレベルを保てていれば、
差はないはずだ、マイナスの影響はないはずだってことか。
高かったってことでしょうね。
まあ、どう捉えるかですよね。マイナスの影響が出ないぐらいリライアビリティを高めてること自体はすごいことなんだと思うんですけど、
そこまでして、マルチクラウドを選択する背景が何だったのかってところですよね。
そうですね。
単純に言葉が循環してますけど、マルチクラウドを選択するのってリライアビリティのためだと思うんですよ。
そうですね。
あるクラウドがダウンしても、こっちのクラウドでは大丈夫という。
そういう場合ってどうなんですかね。もちろん、そういう戦略をとっている企業の形態によると思うんですけども、
リライアビリティエンジニアチームってどうなっちゃうんですかね。
例えば、マルチクラウドだった場合に、AWSとAzureとかを例に挙げるとしたら、AzureのリライアビリティエンジニアとAWSのリライアビリティエンジニアがいて、
それぞれ各々の責務を全うしてやっているのか、それとも実は両方のクラウドに対してちゃんと知識を持っていて、
全体を見通してやっているようなスペシャリスト集団なのかっていうと、どっちなんだろうなって思っちゃいましたね。
21:04
どんな感じなんでしょうね。
さっき自分が言ったような言おうとでのホットスタンバイというか、みたいな感じで使っているならば、同じチームがやってそうな気がしませんか。
そうですよね。そうですよね。
でも、能力で分けている場合、例えばよく聞く話が、メインのアプリケーションとかはAWSとかAzureでやってるけど、
ビッグクエリのためにGCP使ってますとかっていうパターンはまあまあある気がしてて、
そういう風に機能でマルチクラウドになっている場合はもしかしたら違うチームがやっている可能性もありますね。
そうですね。確かに。
なるほどなぁ、かなっていう感じだなぁというのが書かれてさまりに無かったことで、
最後がこのサプライズのところですね。
サプライズが6個書いてあって、今まで話してきたことも結構あるんですけど、
1つ目がトランクベースデベロップメントっていうのがあると思うんですけど、三谷川さんこれわかります?トランクベースデベロップメント。
はい。いつだったかな。今のプロジェクトを始めたとき、始めてから半年ぐらい経ってトランクベースにしましょうって切り替えた気がしますね。
なんだって?
ただチームが非常に増えてからトランクベースじゃなくなってしまいましたね。
もしかしてトランクベースやるためにあれですか?フィーチャーフラグ入れたんですかね。
そういうところあります。
そういう感じでですね、デリバリーのパフォーマンスにようやく影響を与えるというのがもう通説というか。
そうですね。
今回の調査では2014年からずっとプラスの影響だったのに、2020年で初めてマイナスの影響になったらしいんですよ。
これは全然理由とかもわかってないっぽくて。
先ほどの白武さんの話で少しあった、全体的にソフトウェアデリバリーパフォーマンスが低下した仮説の中に、パンデミックがチームの知識共有、コラボレーション、イノベーションを阻害したって話があったじゃないですか。
特にトランクベースって結構コミュニケーションとかコラボレーションの部分って重要だと思っていて、そこが阻害されるとトランクベースやってるのめちゃめちゃ危険な感じがしません?
しますね。形だけできてても実はトラブルが起きてるとかありそう。
そう。っていうのも実は少し原因としてあったりするのかなって話を聞いてて思いましたね。
そうかもしれないですね。この調査にもコミュニティから説明とかがあれば聞きたいとかって書いてあったぐらいなんで。
24:03
聞きたい。
いろんな原因が予想されるんでしょうね。
2番目が、これさっき言ったやつですね。運用のパフォーマンスが高くないと、いくらデリバリーのパフォーマンスが高くても組織のパフォーマンスには寄与しない。
今までの調査、2021年までかな?では直接的な関連があったみたいです。
なるほどね。
だから今回のこの結果からもそのリライアビリティが、つまりオペレーショナルパフォーマンスが大事っていうことがわかったってことですね。
3つ目が、これもなんかこれだけ見ると本当かよって思ったんですけど、ドキュメンテーションプラクティス?
が、デリバリーのパフォーマンスにマイナスの影響を与えたみたいなんですよね。
なんと!
これだけ聞くと、ドキュメント書いてるからデリバリー遅くなるんだよみたいな感じになるじゃないですか。
ですねですね。
今まで逆だったみたいなんですよ。
今回は逆、マイナスになっちゃったんで、ここに書いてあった仮説の一つとしては、コンパフォーマンスのチームはそもそもドキュメンテーションを自動化している。
ああ。
なので、ドキュメンテーションのプラクティスやってますみたいなところはそもそもパフォーマンスが低い。
ドキュメンテーションのプラクティスを自動化しててもやってますって表現はしていい気がするんですけど。
確かに。どういうことなんだろう?
ちょっと不思議な感じがしますよね。
そうですね。
だからこういう風に書いてあるっていうことは、ドキュメンテーションを手で書いているっていうことなんですかね。
可能性高いですよね。
ドキュメンテーション・プラクティシーズって表されてるやつは。
確かに。
で、手で書いていると、そのプラクティスの数が多ければ多いほど、その分時間はかかりますよねっていうところに繋がるので、結果マイナスの影響を与えてしまったってことなのかな。
そうかもしれないですね。これも仮説だったんで。
なるほど。
っていうのが3つ目。
で、4つ目が、いくつかその技術的な能力、ケパビリティがトランクベース開発とかいろいろあると思うんですけど、これがですね、バンアウトに繋がっていたっていう結果が出たみたいなんですよ。
えー!恐ろしい!
この辺をよく実施しているチーム、開発者はバンアウトしやすいみたいな結果がきっと出たんでしょうけど、
これについても仮説があって、今回の調査の対象者が若年層みたいなんですよね。
若年層とか、キャリアが短い人なので、キャリアが短いかつ、割と疎結語アーキテクチャとか、CI、CDとかっていうのは難しいプラクティスなので、
27:13
それに耐えきれずにみたいな、難しくてできずにバンアウトに繋がったのではないか、みたいなことが書いてありました。
そっちなんですね。てっきりいくつかのケパビリティを導入したことによって、モチベーションが枯れてしまってじゃないですけど、やることやったわってなってバンアウトなのかなって思ってたんですけど、そういう仮説じゃないんですね。
そういう意味でのやることやりきった感だと、バンアウトはしない気がしてるんですけどね、自分は。
次のことに取り組めそう。
ああ、また確かにそうですね。
あまりに取り組みがきつすぎたときに、もう休みたいみたいな感じになっちゃうのがバンアウトじゃないかなという想像があるんで。
なるほど。
はい、という仮説が4番目。で5個目が、これもさっき言ったやつですね。違うか。
これ結構驚きじゃないですか。
これ違うやつだ。リライビリティエンジニアリングが、デリバリーのパフォーマンスにマイナスの影響を与えたっていう結果があって。
はっはっはっは。
これも言い訳がましいかもしれないですけど、直接的な因果関係は認められていなくて、今回の調査するにあたっていろんなクラスタ分けしたらしいんですよね。
これがオペレーショナルのパフォーマンスがこのぐらいで、デリバリーのパフォーマンスがこのぐらいのグループをこういうクラスタとするみたいな感じで、それも資料の中に書いてあるんですけど、
その中のとあるクラスタでは、リライビリティを重視しすぎるがあまりに、デリバリーのパフォーマンスを無視するみたいなことが、っていうクラスタがあるっぽくて、そこの結果ではないかっていう感じですね。
でもこれ、ちょっとだけ、もしかしてああいう時だったのかなっていう近い体験があって、一時期やっぱりチームプロジェクトの中で、デリバリーを担当するチームと、リライビリティを担当するチームというふうに分かれてたんですよ。
分かれてて、もちろんチームって役割が違って、でもみんな立場は平等なんだよっていうのは大前提ではあると思うんですけども、
とはいえ、そのチーム感でパワーバランスが絶妙に存在してるパターンがあって、
例えばリライビリティを重視するっていう表現、重視するっていうと表現は柔らかくて大事にしてるんだなっていうのは伝わってくるんですけど、
30:02
逆にリライビリティチームがデリバリーのフェーズゲートみたいになってしまった時期があったなって思ったんですよ。
それがすごく、今ここで挙げてるリライビリティを重視して、ソフトウェアデリバリーパフォーマンスを無視することがあったっていうところに近い状態だったんじゃないかなって思いましたね。
その例って、特にSLO運用とかで難しいところなんじゃないかって自分思ってて、
SLO運用でよく言われるのが、SLOを割ってしまったら真剣のデプロイヤー無しにするとかってよく聞くじゃないですか。
ありますね。
あれ本当に可能なの?とか思ったことあるんですよね。
私も博武さんと同じ意見です。
本当にできてるところはあると思うんですけども、少なくとも自分の現場では、そんなこと本当にできるの?って思っちゃいますね。
SLOを割っちゃったからこのデプロイヤーダメですって言って、ソルダクトマネージャーとかが納得するかな?
ちょっとありますよね。
ありますあります。
そういうのがちょっとあるのか、ちょっと余談でしたけど。
最後の6個目が、調査するチームの最初の予想では技術的能力が高ければセキュリティの実践にプラスする。
その実践にプラスの影響を与えるでしょう?みたいな感じで考えてたんですけど、その逆であったっていうのがあって、
セキュリティをちゃんと実践している、それがソフトウェアデリバリーパフォーマンスとか、オーガナイゼーショナルパフォーマンスにプラスの影響を与えている。
この逆だったっていう部分も、どの視点から見てそう捉えるかなんじゃないかなと思ってしまうんですけど。
そうですね。どっちかが欠けてたら、前提としてみたいなことなんですかね。
例えば、今この白武さんの話を聞いて、頭の中でイメージしてしまったのは、
セキュリティの実践をやるには技術的能力がある程度高くないとダメなんじゃないかって思ってしまったんですけど、
でも、多分そうじゃなくて、技術的能力に関係なく、セキュリティの部分を実践することが大事だよねっていうふうに、
共通認識を持てている組織が、結果的にデリバリーとオーガナイゼーショナルパフォーマンスが高くなってるってこと?
なんか直接的にあんまり繋がるイメージがないから、そういう相関な気がしますよね。
33:01
そうそうそう。
そういうチームということは?みたいな。
っていう感じですよね、きっとね。
だと自分も思いましたね。
うん。結構、なんだろう、理解するのが難しいなっていうか。
難しいし、これ、でもかなり可能性としてあるのは、単純に自分が読み違えてるっていう可能性があります。
なるほどね。
じゃあ私もう一回読んで。
はい、読んでみてください。
なんかこれだからあれなんですよ、内容でこういうことって日本語で説明してくれてる人とかもいなくて。
あー、みんなで読みたいぐらいのやつですよね。臨時会したいぐらいの。
本当、英語話者とかの人に説明してほしい。
確かに。
結構興味深い結果が2022年は出てますよね。
そうですね。
これまでの常識がちょっとこう、およって思わされるような結果?
ただ、大枠ではちゃんと改善していこうというチームが良いということは変わらないし、
近年は当たり前になっているリライビリティがちゃんとしてないと全体的なパフォーマンス上がらないよねっていうのも、ですよねっていう感じではありますしね。
そうですね。そこに関しては特に矛盾なくというか、スッと入ってくるんですがってところですよね。
そうですね。それに加えて、このセキュアリングザソフトウェアサプライチェーン。
ここも大事ですよねっていうのがすごい強調されてたんで。
なるほどね。
やっていかないとって感じですかね。
ただ、ついついプロダクトの開発とか今まで経験してると、なかなかセキュリティの話が前半に出てくることって少なくないです。
そうなんですよね。
ある程度形作られて、よしじゃあ次はそろそろセキュリティだねみたいなケースが今までたくさん経験してきたので。
何なら最後、それが出てくるだけでもすごいと思いますけどね。
確かに。
そうなんだよな。セキュリティってこの認識が甘いことはわかるんですが、セキュリティって保険みたいなイメージがあるというか。
うんうん、わかりますわかります。
起きたときのためにやっておかなきゃいけないことみたいな。
やってますよ、ほらねっていう、起きたときに提示できるものを作ってるくらいありますよね。
あともしくは、あまりにもひどいことが起きないようにするためとか、ぐらいのイメージしかないからそうなんですよね。難しい。
意外とその辺が、セキュリティに関して考えるところが、あれなのかな、ウォーターフォールチックになってるのかな、いまだに自分たちが。
そうですね。それで言うとあれですもんね。最近はシフトレフトでなるべく先の方にやっておこうっていう考えだから。
36:04
そうそうそう。
そうなんだよな。でもあとあれも、アメリカだとほら、あれですよね。Sボムだっけ?かなんか強制になったんですよ。
そうなんですか。
じゃなかったでしたかね。なんかやんなきゃダメって法律かなんかで決まったような話を聞いたことがあるような。
じゃあ何か多分ソフトウェアを提出するときというか、納品するときにSボムが必ずついてきますっていう状態になってるんですかね?
何らかそういうこのセキュリティをちゃんとしなきゃっていうか、そうするための力が働いていた気はします。
うん。それで考えてもやっぱりSボムが出るのも結構最後の方じゃないですか。最後って言うと言い過ぎですけど、
ソフトウェアがある程度形作られるとき、でもSボムもあくまでセキュリティのプラクティスの1つでしかないので、
それはそのタイミングで出るけれども、他のプラクティスに関してはもっとシフトレフトで早めにできるものがあるんだよって感じなのかな。
そうですね。とりあえずこのSalsaとかSSDFもそうだけど、Salsaの方が何か詳しく乗ってそうだったから、どういうチェック項目があるか見てみようかなと思った。
そうですね。ちょっと興味深いですね。どういうチェック項目があって、自分たちは無意識のうちに何かやってるのかやってないのかっていうとこも気になるし。
多分無意識のうちにちょっとやってると思うんですよね。
そうですね。多分ほとんどの回答者が全プラクティスを部分的にでも採用してるっていうところに当てはまってはいると思うんですけどね。
だと思います。ちょっと意識してだから自分たちがレベルいくつにあるのかで、次はこういうことをやると良さそうだなみたいな指標に使えそうですね。
確かに。
はい、という感じでした。いやこれPDFで60~70ページぐらいかなとかなんで。
そんなにあるんですか?
いやー頑張ってほしい。
はい、頑張ってみます。内容はすごく興味があるので読みます。
これ実はあだった以後みたいなあれがあったら教えてください。
はい、フィードバックしますね。
はい、お願いします。
よし、じゃあ今日はこのぐらいしておきますかね。
はい。
はい、じゃあ質問や感想はマシュマロで投げてください。お待ちしています。
Twitterでは#YURUTEKUをつけてツイートお願いします。
今日はありがとうございました。
ありがとうございました。
さあ
