詳解 インシデントレスポンス - Forkwell Library #48に参加してきた

forkwell.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

インシデント対応には、様々な専門分野の知識を必要とし、様々な分野のトレーニングを継続的に受ける必要があります。

本書は、セキュリティ侵害を試みる攻撃者の活動に対し、日常的に予防・検知・対応を行う実務家によって書かれた実務家のための書籍で、2022年1月に発売されました。 今回は訳者の石川 朝久 氏をお招きし、本書の概説をしていただいたのち、実践的な技術の学び方や本書に関連する技術の学び方などをお話しいただきます。

また、ブルーモ証券の取締役CTOの小林 悟史 氏、バックエンドエンジニアの下村 拓 氏にも事例講演としてご発表いただきます。

会の様子

セッション1 〜『詳解 インシデントレスポンス』で学び倒すブルーチーム技術〜

ランサムウェアをもとにした事例研究と本の全体感の紹介

ランサムウェアによる攻撃が発生して3台の被害端末が暗号化されていることが判明し、最低限の処理が済んでいるという事例を題材にインシデント対応に関する話がありました。

まず、インシデント対応をする前にはProcess/People/Technologyの「備え」が重要だという話がありました。
具体的には、指揮命令系統やチームへの連絡係を事前に決めておくことなどが挙げられているということです。

次にトリアージパートとして、目に見える被害はないが同じセグメントにいるなど技術的・論理的に考えて被害を受けた可能性があるサーバの取り扱いにまつわる問題(=スコーピング問題)の話がありました。
こういったときはトリアージを実施するということで、具体的な技術としてWMICやPowerShell、サードパーティ製品などが書籍内で紹介されているということです。

次に保全パートの話がありました。
本の中では、法医学の文脈にあるロカールの交換原理が紹介されているということで、状況に応じてデータの保存手法や保全対象を選定する必要がある*1ということでした。

続いて、解析パートの話がありました。
解析パートでは、ネットワーク・端末間の分析*2と端末・端末のアーティファクト分析*3が紹介されているということです。

最後に改善パートの話がありました。
解析が終わった後は影響範囲と根本原因が判明した後のアクションが記載されているということで、本書では脅威ハンティングなどの手法が紹介されているそうです。

さらなるブルーチーム技術の向上方法

更にブルーチーム技術を上げたいときの方法として、

• 技術を磨く(学習向けのイメージを使って分析練習を行うか、ラボ環境を構築して攻撃→分析を行う)
• 技術をアップデート(DFIR Summitをはじめとしたカンファレンスやブログなどの情報をキャッチアップする)
• 関連技術を学ぶ(Linuxやモバイル・フォレンジック、クラウドフォレンジックといった関連書籍を読む)

の3つが紹介されていました。

セッション2〜東証障害報告書を読み解く〜

障害当日に起こったこと

最初に障害自体の説明がありました。以下、経緯を常体かつ箇条書きで整理していきます。

• 7:04 : NAS1号機でメモリ故障が発生して異常発生のアラートが鳴った。さらに、NAS2号機への切り替えが起きなかった
• 7:06 : 一部端末で売買管理画面、運用管理画面へログイン不可となる
• 7:10 : 富士通に連絡
• ~7:30 : 処理されるべきバッチ処理が行われていないことを確認
• 7:37 : 障害対策本部の設置
• 8:00 : 証券会社から注文が送られてきて受付は正常に処理できたが、売買管理や運用管理画面の操作はできない
• 8:37 : 全銘柄の売買停止を通知
• 8:54 : 証券会社とArrowheadとのロードバランサの接続を強制遮断
• 9:00 : 証券会社との接続は切ったものの、約定処理などは停止できなかった
• 9:11 : 相場情報配信側のロードバランサも切断

障害の原因(NAS1号機からNAS2号機に切り替わらなかった理由)

パニック通知電文受信時のon_panic設定が間違っていたことが障害の根本原因だったという話がありました。

これは、途中でNetAppの仕様変更が入ったことに追従できていなかった(デフォルトの仕様変更があったことに気が付かなかった)が故に発生したということです。

調査委員会の見解

調査委員会としては、誤った仕様変更をしてしまった富士通の責任は重いと考えつつも、テストケースを作れなかった東証の責任も一定数あると判断したそうです。
一方で事故当日の対応に関しては妥当だったという判断をしたということでした。

再発防止策としては、高可用性を堅持しつつ、障害回復力を高めていくことが上げられたそうで、NASをはじめとしたあらゆる機器の点検や切り替え手段のマニュアル整備、網羅的なテストの実施、市場停止や市場再開のルール整備が挙げられたそうです。

セッション3〜ブルーモのインシデントレスポンス〜

ブルーモでは、疑わしき以上は全て報告することと意思決定は全て文書化することが基本ルールとしてあるそうで、そのうえでレスポンスフローを整備したということです。

具体的には、

• 手動アラートによるフィルタリングと集約で判断フローを単純化し、Slack Workflowで自動化
• 判断できる人間が捕まるまでエスカレーションし続ける
• 異常時はチャンネルを自動作成して、ストック情報とフロー情報を分けて整理
• ST環境で1週間実験

という部分を工夫したということでした。
インシデントレスポンスを整理したことで、

• 金融関連かつ少人数の条件でも実践可能なフローは作れる
• フローを可能な限り単純にしてドキュメント化しても浸透はしない
• 業務プロセスの導入やヘンコではドキュメント化に加えて実体験とFBの繰り返しが重要

という学びが得られたということです。

Q&A

セッションの後はQ&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。

インシデントレスポンスを的確に行うための事前準備を知りたい

• 訓練や教育を重視している。もしこれが起きたら？という観点でディスカッションを頻繁に行っている
• 障害対応にまつわるいろいろなソースを事前にキャッチアップしておく
• 事故が起きたときに元気になる人を大切にしている
• 意思決定をなるべく早く行えるようにする

インシデントレスポンス未経験者はどう本を読んだらいいか？

• まずは保全の部分を読んでほしい。そのうえで解析パートを読んでもらえるとよい

インシデントレスポンスであったベースラインの把握に効果的な方法はあるか？

• 毎週定期的に監視して差分をチェックする

会全体を通した感想

セッション1でインシデントレスポンスの話を聞きながら、自分が経験した大きな障害である東証の障害を思い描いていたら、次のセッションで東証の障害の話が出てきてめちゃくちゃ驚きました笑

インシデントは起こる前提で日頃からどのように準備していくのか？という部分は非常に重要なので、そこにまつわる体系的な整理や実践事例が聞けてよかったです。

*1:大量のメモリを搭載し続けているサーバに関してはPCと動揺のメモリダンプの取得は不適切な可能性がある

*2:ネットワークセキュリティ監視、横断的侵害の分類

*3:イベントログ分析、メモリ解析、マルウェア解析、ディスクフォレンジック

オブジェクト指向のこころを読む会 Vol.12

yr-camp.connpass.com

今週もこちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

最初にいつも通り読んできた章(12章)のあなたの意見に関してディスカッションをしたあと、今日はモデリングの品評会をしていきました。

会の様子

著者のアレグザンダーへの傾倒

この本の著者は銀の弾丸などないと言いながらも、「アレグザンダーを読んだ結果人生における物事の真価が分かった」「アレグザンダーの理論を適用した結果素晴らしい結果を得ることができる」と言った具合に激推ししているので、読んだときに動揺したという話からスタートしていきました。

あなたの意見2

音楽理論だと、理論通りに進行することが望ましいという話もありつつも、同じくらい意図的に外すというテクニック*1も受けているそうで、人によってこれが好き、これが嫌いみたいなものが分かれているという話がありました。(ただし、現代では外す流れの方が受けている傾向がある)

日本ではAメロ->Bメロ->サビメロみたいなパターンが王道ではありますが、海外ではあまり好かれないというのもあったりして、文化圏の違いも出ているのではないかという話も出ていました。

モデリング品評会

モデリングの品評会をしていきました。
以下、箇条書きかつ常体でそれぞれのモデルのポイントを記載していきます。

モデル1

• 室外機とかの部分がうまく表現できていない
• ControllerをかませてModeを操作するようにした
• operation()を常に回すことで温度を監視&取得するイメージ

モデル2

• Clientから直接Modeを操作させるのではなく、Controllerを一度かませるようにした
• 冷房/暖房それぞれが室外機と室内機をいじれるようにしている
• 具体的なメソッドとかまでは考えられていない

• ドメイン知識を得て全体的にモデルに反映させた
• 冷房/暖房それぞれが室外機と室内機をいじれるようにしている
• 室内機の制御はinterfaceを経由してコントロールするようにしている

• 空気を調整する際は、冷暖房の変化による調整と温度変更による調整と風量による調整それぞれで違うので、リモコンがModeを直接いじれないようにした
• 空気の調整は室外機と室内機それぞれがあったり熱媒体の話があったりというのは分かったのだが、理論を理解しきれなかったのでモデリングに反映できていない

• 浴室のエアコンに対しては適用できない
• 一部屋に二つエアコンをつけることは想定していない
• 意図的にエアコンより広いコンテキスト(部屋など)も含めている
• Stateパターンを将来的に使用することを想定
• マスタ側のエアコンと操作する側のエアコンを意図的に分けている(アナリシスパターンにあるようなテクニック)

会全体を通した感想

今日は新たにモデリング品評会をやってみて、多種多様なモデルが見れたのでよかったです。
ドメイン知識が足りていなかったり、練りきれていない部分が自分も含めた皆さんがあるということで、次回もやることになったので、今日聞いた話やオブジェクト指向のこころを参考にモデリングを洗練させていきたいと思います！

*1:厳密に言うと外し方にも癖が出ている

大人のソフトウェアテスト雑談会 #206【付け焼き刃】に参加してきた

ost-zatu.connpass.com

今週もテストの街葛飾に行ってきたので、会の様子と感想を書いていこうと思います。

出ずっぱりな人々

最近色々なイベントやPodcastなどにEmiさんが出ており、出ずっぱりですよねとおおひらさんとRyoさんが言っていたのですが、おおひらさんもRyoさんも最近ずっと出ずっぱりなので、ブーメランを食らっていました。

知花さんの行動力

知花さんのことを知花さんとみんな呼んでいるのか？里香さんと呼んでいるのか？という話から、知花さんの驚異的な行動力の話になりました。

具体的には、知花さんはコーチングアジャイルチームを読んだあと、特に面識がないのにも関わらずすぐにLyssaに連絡を取りに行ったり、Lyssaに影響を受けてWomen in agileをやりたいと言ってすぐにサポートを求めたりしていたのがすごかったという話を聴いていきました。

森崎先生のイベントはハードルが高い？

森崎先生が生成AIを活用したコードリーディングのイベントを今度開催する予定だそうですが、これの人数を増やすにはどういうことができそうか？という話をしていきました。

前回のイベントは、技術的負債の数値化という意味だとあまり世の中に出ていないトピックなので真新しさがめちゃくちゃあったのに対して、今回はLLMを使ったソースコードリーディングということで、ちょっと検索したら資料がたくさん出てくるのが原因ではないかという仮説や、JavaやGoFに詳しい年代とLLMに詳しい年代が違うのではないか？という仮説が出ていました。

他にも色々とノウハウや裏話などが出ていましたが、あんまり書きすぎると色々と妨害行為になりそうなのでやめておきます。

Vim-Easymotionを使ったプレゼンづくり

Ryoさんがふりかえりカンファレンスの資料を作っていたのですが、そこでVim-Easymotionを使いながら資料を作っていました。
途中、トラブルシューティングができる人を探していましたが、誰もいませんでしたw

全体を通した感想

今日は色々とオフレコの話もあったので途中aki.mミュートをかけられる場面もありましたが笑、色々な裏話が聞けたのでよかったです。

そして、いつか知花さんのとんでもない行動力を観測してみたいなと思いました笑

Kubernetesマイクロサービス開発の実践 - Forkwell Library #47に参加してきた

forkwell.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

第47回目では『Kubernetesマイクロサービス開発の実践』を取り上げます。

コンテナ、Kubernetesおよびそれに関連する技術を活用して、アプリケーションの開発と運用を行う方法について解説している本書をテーマに、Kubernetesおよびクラウドネイティブ技術を効果的に活用して実装、運用する方法を学んでいきましょう。

今回は著者の早川 博 氏、監修の北山 晋吾 氏のお二人をお招きし、Kubernetes上で動作するアプリケーションに対して、頻繁な更新とサービスの安定性を同時に実現するための様々なプラクティスをお話しいただきます。 また、モデレータに株式会社サイバーエージェントの青山 真也 氏をお迎えし、さらにDeepなところまで深掘りしていただきます。

会の様子

基調講演1〜マイクロサービスは本当に必要だったのか？〜

K8sの成熟度

2018年にK8s完全ガイドが出たことに加え、SRE/Platform Engineeringをはじめとした運用の役割定義分割が発生していることから、K8sはキャズムに入ってきたのではないかな？という感覚で北山さんはいるということでした。

アプリモダナイズへの投資状況

現在は既存アプリケーションをどのようにコンテナ化するのか？という部分に関心が移りつつある*1ということでした。細分化すると、

• Repurchase(完全に置き換えしたい場合に取る方法)
• Refactor(アプリケーションを分割してまでビジネスが伸びる見込みがある場合に取る方法)
• Replatform(移行費用や工数を抑えながら保守性のあるシステムを作るが、システムが古いと改善箇所が増えてしまう方法)
• Rehost(移行費用や工数はかかるが保守性を最適化したサービスができる)

に分かれるそうです。

移行影響としては、Rehost、Replatform、Refactorの順に高く、コストを抑えながら保守性を高められるReplatformがトレンドの一つになっているということでした。(=マイクロサービスへのリファクタリングというのは実はほとんど行われていない)

基調講演2〜Kubernetesで、アプリの安定稼働と高頻度のアップデートを両立するためのプラクティス〜

近年のアプリケーションに求められるもの

アプリケーションは頻繁なアップデートを理由に様々な理由で再起動されるため、頻繁に再起動があっても安定して稼働し続けることが求められているという話がイントロダクションとしてありました。

具体的には、

• 十分な準備
• 意図しないクラッシュの予防
• GracefulなPodの終了

という3観点に分かれるということでした。

十分な準備

Pod内のコンテナはReadyになるまでにリクエストを受け付けるための準備が必要であるため、アプリケーションごとに対応の必要があるということでした。(DBとのコネクション確立、初期ヒープメモリの確保、キャッシュを読み込む、暖機運転を利用したコンパイラ最適化...)

具体的なプラクティスとしては、initCotainersやPodStart lifecycle hookなどが利用できるということです。

意図しないクラッシュの予防

コンテナの停止をはじめクラッシュの原因も様々ありますが、

• 負荷試験とチューニングの実施(requests, limitsの設定)
• GCの特性を踏まえた設定変更
• 不安定にならないためのlivenessProbe

といった内容が必要だということでした。

GracefulなPodの終了

Podが終了する際は、コンテナの終了&トラフィックの停止が起こる上に動作には決まった順序がないため、preStop lifecycle hookによる待機を活用したり、Gracefulシャットダウンの無効化を設定しておくことなどが重要だという話がありました。

Q&A

基調講演の後はQ&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。

Rehostを選択して運用が大変になった事例はあるか？

大体大変になる印象はある。IPアドレス周りやログ、セッションレプリケーションなどのトラブルが多い印象はある。

マイクロサービス化はどこまで必要か？

• アプリケーションの更新頻度を基準に考えると思う
• 保守性を基準に考える。なお、保守性はチームの技術力にも依存するので、もしK8sを触ったことがないチームなら大きいままでも放っておいた方がいいかもしれない

トラフィックの停止を待つのにsleepコマンドで待っていたが、ネットワークなどを監視してトラフィックがなくなったことを認識してから終了することはできるのか？

アプリケーションのメトリクスをPrometheusのエクスポート的な形で出しておいて、SIGTERMが来たら処理待ちするみたいな連動の仕方になると思われる。ただし、sleepで我慢するほうが結果的に楽になる気がする。

ヘルスチェックを導入している時、DBとの接続チェックは行うべきか？通常通り動作するロジックは提供し続けることはできるのか？

しない方がいいと思っている。アプリケーションが停止したからといってDBが復旧するかはわからないのであまり意味がない気はしている。そのため、DBの状態とアプリケーションの状態は連動しないほうがいいと思う。後半部分はサーキットブレイカーが近いのではないかと思っている。

暖機運転は本当にいるのか？

• JITコンパイラを進めるという意味だと、暖機運転の手前にやることがあるはずだとは思う
• シビアにパフォーマンスを求められる環境だと必要な場面は出てくる

商用環境でK8sはどのくらいの頻度でupdateするのか？アップデート対応を効率的にやる方法はあるか？

• アプリケーション側のE2Eテストを作って段階的なバージョンアップをしていくと早くupdateできるようになるはず
• 基本は3ヶ月に1回

会全体を通した感想

業界のトレンド的な話や一般的な話を北山さんがしてくれて、実際の業務で使えるプラクティスの話を早川さんがしてくれたので、流れが見事にできていて良いイベントでした。

RefactorよりRehostというトレンドは体感と一致していましたが、正式なリサーチ結果として出ているのは知らなかったので、レポートを読んでみようと思いました。

*1:Research conducted by lliminas参照

スクラムフェス金沢のプロポーザル募集を開始しました！(スクラムフェス金沢の打ち合わせ第10回目)

今日もスクフェス金沢の打ち合わせをして、今日からプロポーザル募集をオープンしました！

ということで、今日はプロポーザルオープンにあたって会話したことをブログにしていきます。

www.scrumfestkanazawa.org

confengine.com

セッション締切日

セッション締切日は元々4月末を予定していましたが、プロポーザル提出までの時間がかなり短いことを元々運営で気にしていたことに加えて当初の締切がGW中だったため、5/8に締切日を設けることにしました。

採択結果の連絡

今回スクフェス金沢の運営メンバーはセッション採択経験がないメンバーが多いということもあり、少し長め(1ヶ月)にセッション採択までの期間を取ることにしました。

また、その結果、スクフェス金沢で残念ながらrejectすることになってしまったプロポーザルをすぐにスクフェス大阪にCloneして回すということが可能であるため、なるべく早く採択か不採択かの連絡はできるといいよねという話が運営の中で出て、「採択のご連絡」ではなく「採択結果のご連絡」を5月中には行う旨を追記しました。

発表場所

他のカンファレンスと異なり、発表場所は全員現地を想定しているため、その旨を明記しました。

初登壇の方の応援

スクフェス金沢では、初登壇の方を支えたいという気持ちがあるため、セッション内容次第ではありますが、初登壇の方を何枠か意図的に採択することを考えています。

そのため、初登壇の方は自分が初登壇であることが分かるようにしてもらいたく、Tagをつけてほしい旨を記載しました。

カテゴリ

金沢カテゴリ以外は過去に実績のあるカテゴリを踏襲していますが、過去に実績のあるカテゴリでも「このカテゴリの話を聞きたい」というのを選びました。

特に、前述したように初登壇の方を応援したい気持ちがあるため、

• はじめの一歩をいれる
• この話カテゴリに沿っていないからできないかな...をなくすためにOthersをいれる
• Advancedセッションが多くなりそうなカテゴリ(新しい提案や実験など)は外す

の対応をしました。

全体を通して

いよいよプロポーザルをオープンにできて、わくわくしています！

期間が短いこともありプロポーザルが集まるかどうか不安に思っていますが、そんな不安がどこかに吹き飛ばされるべく、皆さんからたくさんのプロポーザルが集まることを願っています。

コーチングアジャイルチームス - Forkwell Library #46に参加してきた

forkwell.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

第46回目では『コーチングアジャイルチームス』を取り上げます。 世界中で好評を得ている原書の翻訳が今年1月に発売されました。

本書は、アジャイルチームの力を最大限に引き出せるコーチになるためのアイデアに満ちた、アジャイルなチームに関わるすべての人にとって必読の1冊です。

今回は訳者陣の中から、田中 亮 氏、知花 里香 氏のお二人をお招きし、チームのパフォーマンスを最大化させるためには、どのように始め、どのように発展させていけばよいのか、お話しいただきます。

会の様子

基調講演〜「アジャイルチームをコーチングするってどういうこと？ - 始まりはあなたから」〜

アジャイル開発のスタート

どこかムーブメントの起源なのかというと諸説ありますが、OS/360で繰り返しシステムを作るプロジェクトからアジャイルの元祖となるムーブメントがスタートし、それがThe New New Product Development Gameやアジャイルソフトウェア開発宣言に繋がっていったという話がありました。

コーチングアジャイルチームスとは

PMOだったLyssaがアジャイルコーチになるまでの道のりを示した本で、Lyssaのブログ記事をもとにして作られたという話がありました。
そのため、本の中に書かれている出来事はどれも非常にリアルで、どんな体験をしたのか？というのが追体験できるということです。

また、本書は3部構成になっており、どのように読むのかはまずは本書にある本の読み方を見てほしいということでした。

どんな人におすすめか？

メインターゲットはアジャイルコーチやスクラムマスターになりますが、プロジェクトマネージャーや開発者などが読んでも学びがある内容だということでした。

この本を読むとできるようになること

本を読むと、

• アジャイルプロセスや原則を用いてチームを立ち上げ、うまくいけば浸透させられる
• どのようにチームや組織を観察するかがわかる
• 個人的な感情や偏見、価値観に気がつくことができる
• ハイパフォーマンスなチーム・組織の構成要素や探求方法を知ってコーチの立場でなすべきことがわかる

章の紹介

章の簡単な紹介がありました。以下、常体で内容を記載していきます。

1章...アジャイルコーチとは何であるのか？ということが書かれている

2章...パフォーマンスが高いチームとはどんな特徴があるのか？ということが書かれている

3章/4章...コーチングの前にまずは自分自身が変わる必要があるという話が書かれている

5章...コーチ自身のメンターになることもあるし、コーチがコーチを育てることも多くなっているので、その育て方に関する話がある

6章/7章...紹介が飛ばされていました笑

8章...システムコーチングの文脈で、「問題」に関して丁寧に話が書かれている

9章...Ryoさんが好きな章で、チームに問題があってもいいという話が書かれている。コンフリクトをレベル分けし、それぞれのコンフリクトをどのようにナビゲートするのかが書かれている

10章...ハイレベルのチームが成功例として出されることが多いが、いきなりそういうところに行くのは難しいよね？という話が書かれている

11章...困ったときに開くような部分。うっとくることが多い

12章...アジャイルコーチのロードマップやキャリア形成に関して書かれている

13章...実際にアジャイルコーチになった人の体験談が淡々と書かれている

知花さんの旅

知花さんのアジャイルコーチとしての旅の話がありました。

知花さんはエンジニアとしてのバックグラウンドがあるわけではなく、たまたまスクラムに出逢ってそこで覚えた感動が旅の始まりだったということでした。
ただ、旅を始めて最初の方は「スクラムの奴隷」として振る舞っていて、「それはスクラムでありません」という話をチームにしてしまってスクラムを辞めることになったりした経験もあるそうです。
その後は部門全体をリードする立場になり、そこで外部から支援するという文脈でアジャイルコーチを名乗れるようになったそうですが、その後にいろいろな人と会うたびに自分って何者で何が持ち味なんだろう？と悩みだしたということでした。
その後パーソナルコーチングを受けている中で、「あなたは価値ある人間なんだから価値を探そうとしなくてもいい」と言われ、そこからアジャイルコーチとしての旅が楽しくなったということでした。

Ryoさんの旅

仕事をしている中でアジャイルに出逢ったRyoさんですが、会社で広めようとしても広まらない現実が辛く、スクラムができる会社に転職したそうです。
その後は一定の成功はしたものの、チーム内部でもめ、スクラムを更に広めようと外資系企業に転職したそうですが、英語ができないことに苦しむ日々が続いたということでした。
ようやく英語ができるようになったタイミングで、会社から追い出され、そこからyamanecoに転職してからは乱高下がありながらも楽しく仕事をしたということでした。

Q&A

講演の後はQ&Aがありました。以下、一問一答形式かつ常体で記載していきます。

当事者としての視点とコーチとしての視点を切り替える時どんな心がけをしているのか？当事者視点になっている場合どんなことがきっかけで気づくことが多いのか？

• コーチのポジションをとっていく
• 五感をすごく使う
• 当事者であるときはコーチの視点はあまり使わないようにしている
• 「コーチの視点で発言して良い？」という話をする

企業に所属するコーチというイメージがわかないのだが、どういう立場の人がコーチになるといいのか？全く別なのか？

アジャイル推進室の人たちがやるみたいな例は多い

アジャイルコーチとして大変なことやもっとこうすればよかったとかあるか？

• チームがネットワークセキュリティの問題に立ち会った時、ついコーチとしての立場ではなく問題解決を自分でやってしまった
• 改善をリードする立場になったとき、自分 VS 他の人という構図になって動けなくなってしまった

問題解決を優先するときに、Problemとして見ずにPeopleとして見るためにできることは？

EQを勉強して感情を学び、自分が何でそんな感情になっているのかを深呼吸して考えてみてる

人間関係よりも業務を優先してオリエンテーションという部分は直感と反していたのが、どう考えるか？

• 人間関係も大切だけれど、生産性が上がらないとどうしようもないので直感から外れてはいない
• 業務を共通項にして話せるようになることが大事なのでまずはプロジェクトからというのもある
• ここにかかわらず、日本の文化と違う部分もあるので、直感と違うというのはあると思う
• 0/100ではないので、人間関係を無視するわけではない点に注意

「価値」よりも"生産性"のような言葉が横行している現場でどうふるまうか？

まずは言葉を合わせるところからやる

ジュニアメンバーが多いチームで、スクラムマスターの素養がある人を見つけるときに考えることは？

• プロセス面など現状に課題感を抱えているか？を見る
• 周りの声を拾うのが上手な人を探す
• コミュニケーションスタイルとして押し付けが強い人は向いていないと思う。ただし、そういった人でも淡々と「そのやり方は間違っているよ」という話を続けることで変わった事例はある

会全体を通した感想

Ryoさんと知花さんのテンポ良い会話を聞いている感じで、すごくリラックスして話を聞くことができました。

自分も翻訳レビューに参加した思い入れある書籍なので、書籍の内容が気になった方がいればぜひお手にとってもらえればと思います！*1

*1:自分には一円も入りませんが笑

mtx2sさん・ログラス飯田さんと考える！コード品質が及ぼすビジネスへの影響に参加してきた

findy.connpass.com

会の概要

以下、イベントページから引用です。

昨今、プロダクトの品質がビジネスに与える大きなインパクトについて語られる場面が多くなっています。一方で、「コード品質」についての問題やそれに関する議論はエンジニアの中で留まってしまい、経営者やビジネスマネージャーに認識される機会は少ないという話も見受けられます。

本イベントではコード品質がビジネスに与える影響を紐解いた上で、ご登壇者の所属企業では実際どのようなコード品質向上のための取り組みを行っているのか、またそれらを経営陣やビジネスサイドとどうコミュニケーションを取れば良いのかを考えられる場を目指します。

会の様子

ビジネスとエンジニアリングの接合点、そしてコード品質がそこに及ぼす影響（v1.1）

最初に松本さんから講演がありました。

プロジェクトのスタート

プロジェクトは、ビジネス担当者からエンジニアに対して相談が行き、その内容を理解したエンジニアが見積や計画を通してビジネス担当者と調整するものだという話がありました。
こう考えると、見積や計画はビジネス担当者とエンジニアの調整結果とも言えそうだということでした。

プロジェクトの評価基準

CHAOS REPORT 2015の基準を使うと、プロジェクト成功の評価基準は、予算通り/スケジュール通りなだけではなく、顧客に価値提供ができているかも含まれているという話がありました。

予算通り/スケジュール通りにするためには、正しい計画を立てることが重要なわけではなく、途中で起こる様々な困難をモニタリング&コントロールする必要があり、価値提供するためには実験による検証(仮説→実験→検査→適応、のサイクルを回す)を素早く回してEBMで言うT2Mを短縮することが必要だということです。　

コード品質がビジネスに与える影響

コード品質が低いと、見積もりが難しく欠陥が多く開発時間が長くなるため、誤ったプロジェクトプランニング、不適切なプロジェクトコントロール、長いT2Mに繋がってしまうということでした。

この結果、エンジニアは見積を長く出すようになり、欠陥があることを想定してもっと大きなバッファを取るようになりT2Mがどんどん悪化していくため、ビジネス担当者はエンジニアに対して不信感を抱くようになり、信頼関係が崩れてしまうということです。

改善が上手く進まない例

以下のようなすれ違いが起こってしまうという話がありました。

• 改善提案したつもり VS 愚痴を言っているように聞こえる
• 技術視点に特化した話をする VS 技術課題の解決には興味があまりない(ビジネス課題を解決したい)
• 情報の非対称性 VS さっぱりわからない
• 計画化していない VS 意思決定できない
• 信頼関係がない VS 本当にできるのか？

これらは、コード品質が「目的」として捉えられてしまっており、状況を「説明」するものでしかない点に対する考慮が足りていないことが原因であるということで、現状とありたい状態を示したうえで解決策を話すようにすることが重要ではないか？ということでした。

ログラスにおけるコード品質でビジネスに貢献する仕組み・カルチャー

次に飯田さんからの講演がありました。

コード品質に対する考え方

コード品質を考える際は、保守性*1をもとに考えることができ、これに加えてログラスではLTV FirstのValueを掲げることで長く走り続けることができるシステムづくりを目指しているということでした。

また、ログラスでは品質=コード品質とは捉えておらず、QAが文化を作りながら組織全体で品質とは何かを考えるにようにしているそうです

コード品質を維持・向上させるための仕組み

まず、設計標準を作っているということでした。
設計標準は「完全にこれにしたがってください」というものではなく定期的にアップデートをしているそうで、創業時のコードの考え方から進化した考え方が組織の中で生まれ続けているということです。

次に、技術的課題解決スクワッドを形成しているということでした。
特定の個人が品質をリードすることもできますが、それではスケールしないため、チーム横断で技術課題に立ち向かうチームを作っているということでした。

最後に、コードの外観をとらえているということでした。
組織全体での仕組みというよりは飯田さんの趣味に近いところもあるということですが笑、コードの総量と単一責任原則違反指数を集計し、負債の蓄積具合にまつわる状態を可視化するようにしているということでした。

アウトカムとの接続

「リファクタリングによってXX%開発速度を向上させます」といった提案をしたくなる場面がありますが、同じコードでも誰が実装するかで速度は変わるし、開発速度に寄与する変数は他にも数多くあるため、定量的な説明は難しいと考えているそうです。

そこで、お客さんの課題を解決することに対してコミットメントをし、その上で生じる不確実性に関しては開発とビジネスの相互理解によって対応をしているということでした。

ビジネスサイドの声

ここまで説明したようにログラスの開発組織ではコード品質向上のために動いているそうですが、実際にビジネスサイドのメンバーにアンケートを取ってみたということでした。アンケートでは、

• 事業目標に良い影響を与えていると感じている人が60％ほどいる
• ビジネスサイドも技術的負債に関しては意図しているものと意図していないものがあることを知っている
• 入社前から、エンジニアバックグラウンドではない代表から技術的負債にまつわる話があったので把握している
• 機能クローズにもメリットがあることを理解している

といった意見があり、

• プロダクトの貢献度が全体 > 個人となっていること
• 解像度にばらつきはあれど技術的負債やコード品質にまつわる解像度が高い方がいること
• ロジカルな説明があれば負債解消や品質向上への取り組みはポジティブに捉えられていること

が見受けられるということでした。

組織文化

エンジニアとしては、ビジネス目標を達成するために最適なコードを書くために保守性が高いコードを書き、ドメイン理解を深めているという話がありました。
また、ビジネスサイドとしては、(裏にあるテクノロジーを含め)プロダクトに対して関心を持って営業されているということです。

こういった文化は、CEOとCTOがマンションの一室でドメインモデリングを行っていた経験から脈々と受け継がれているものではないか？ということでした。

Q&A

講演の後はQ&Aがありました。以下、質問と回答を一問一答形式かつ常体で記載していきます。

ToBe の値を求めるのは難しいと思うが、コツだったり考え方を教えてほしい

シンプルに話し合って決めたものを前に進めながら都度決めていくことが望ましい。なお、他プロジェクトや他チームと比較するのはやめたほうがいいと思う。

SRP単一責任原則のグラフはどうやって計測しているのか？ツールがあるのか？

なにかのブログ記事をもとにシェルで対応している。

ビジネスへの説得材料としてチーム内の生産指標を出すとそれをチームの評価として利用されはじめる懸念があるように思う。何を出すべきかなど具体例はあるか?

• 何を課題としているのかによるが、アクティビティ系の細かい指標を出すよりは抽象度の高い指標(バッファ率や予実)が良いと思われる
• 生産指標は基本出さない。指標を管理/評価の文脈で使われるとハックされてしまうため。不具合発生率などビジネスに影響するものは出す

今、生産性が低いと感じていて、コード品質が低いとも感じているが、この場合、どのようなアクションをすべきか？

• 具体的にどのあたりが低いと感じているのか？みたいな話をまず議論する。テスト容易性みたいな話なら責務分割などのアクションを取ることになると思うので、より具体の課題を打てるようにするために準備していくのが重要
• 文面を見る限りまだ一人が感じているように見えるので、周囲も同じ意見を持っているのか聞きながら仲間を集めていくのが次のアクションになると思う

解消されてきた技術負債はどのような種類の負債が多いなどの感覚はあるか？例えば、インターフェイス設計が使いにくい、データ構造が実態と一致しない、循環的複雑度が高いなど

観点としてこういう見方をしたことがないので回答が難しいが、普段は保守性(テスト容易性/変更容易性/理解容易性)のテスト容易性にフォーカスすることが多い

コード品質の定量的な計測方法を知りたい

• 色々ツールはあるが、ツールで見た数値をもとに細かいアクションを出すのは継続性がないと思うので、それよりも現場でコードを書いている人が課題に感じていることをバックログ化して対処していくことの方がROIが高いと思っている。外観を把握するくらいのものであれば良いと思う
• 欠陥の発生率や手戻り率、見積もり精度などを見る。リーン開発の現場にあるように定性的評価を組み合わせる

コード品質の基準は組織で一番経験ある人の基準が上限となる以外の方法はないのか？

• 社内だけで見ればそうだと思うが、品質に関する取り組みを社外でアウトプットしてフィードバックをもらうことは重要なのかな、と思う
• 世の中の標準を導入すればいいと思う。コード規約やTDD、ペアプロなど

技術的負債の返済が必要となった場合経営層にどのような情報を用いて提案するのか？

• 負債とまではいかないが、直接顧客価値に結びつかない開発(フレームワークのリプレイスなど)はした記憶がある。その際は、もし対応しないと起きること(採用が難しくなる、オンボーディングコストが高くなる...)を説明した。組織が大きくなると比例的にコストが高くなることを示すことが重要。また、どこまで細かいものを求められるのかは信頼関係によっても変わってくると思う
• 何かを話すときは、相手から問題や課題に対して共感を得ないといけない。そうすると相手の視点で話をする必要があるので、相手の関心を知ってその観点で話をするのが大切だと思う。また、上でも言っていたように信頼関係が必要。過去に失敗した場合は、なんで失敗したかをふりかえったうえでその失敗を起こさないような取り組みをセットで話すとよい

会全体を通した感想

コード品質というと具体的なメトリクスの話やその運用の話が中心になることが多いですが、ビジネス価値という視点での話がお二人共中心だったのが非常によかったです。

松本さんの話で世間一般で言われている部分で特に大切なことがまとめられ、そこから実践的な取り組みの話が飯田さんからされるという流れもお見事でした。

*1:副特性でいえばモジュール性、再利用性、解析性、修正性、試験性