Yesリファクタ。Noコード変更
Yesリファクタ。Noコード変更
誤解されたリファクタリング
最近、職場で「リファクタリング」という言葉をよく聞きます。過去の技術的負債を解消したり、コードを整理してわかりやすくすることは、ソフトウェアの寿命を延ばすうえで重要です。そうした意識がエンジニアの間で広がるのは、良いことだと思います。
ただ、残念ながら、テストコードがない状態で行われるリファクタリングも見受けられます。例えば、テストコードもエビデンスもないまま、単なる手動テストだけでリファクタリング後の動作を確認した、というものです。
こうした対応は、単なる「コードの変更」であって、リファクタリングとは言えません。単なる変更で予期せず動作が変われば、単なる無責任なコード改修となります。
リファクタリングとは
『リファクタリング 既存のコードを安全に改善する』（Martin Fowler, 第2版）には、次の定義があります。
つまり、単なるコードの整理だけでなく、「元のコードの動作が保証されている」という大前提が必要です。元の動作が保証できないのであれば、単なる変更、あるいは不具合を生み出す「無責任なコード改修」に過ぎません。
そうした「リファクタリングもどき」によってソフトウェアの挙動が変われば、障害が発生し、結果としてプロダクトや組織へ大きなダメージを与えかねません。
リファクタリングのやり方
リファクタリングの基本的なお作法は次の通りです。
- テストコードを先に用意し、現行の動作を保証する
- テストが通る状態でコードを改善する
- 改善後もテストが通れば、動作が保証される
テストコードがない状態でリファクタリングを行う際は、次の手順で進めることを推奨します。
- 現行ロジックの動作を保証できるテストコードを追加する
- リファクタリング後、テストコードが全てパスすることを確認する
例：現行ロジックのテストコードを先に作成する
例えば、以下のATM手数料の計算ロジックを例にします。
public Fee chargeFee(UseDateTime useDateTime) { if(this.atmType.equals(AtmType.銀行ATM)){ if(WorkingTime.銀行ATM.isWorkingTime(useDateTime.getUseTime())){ return new Fee(0); } return new Fee(110); }else if(this.atmType.equals(AtmType.コンビニATM)){ if(useDateTime.isSaturdayOrSunday()){ return new Fee(330); } if(useDateTime.isWeekDay()){ if(WorkingTime.コンビニATM.isWorkingTime(useDateTime.getUseTime())){ return new Fee(220); } return new Fee(330); } throw new RuntimeException("コンビニATMの手数料が算出できません"); } throw new RuntimeException("ATMの種類が特定できません"); }
先にテストコードを追加し、次の5パターンのテストを書きましょう。
def "chargeFee_#usecase"() { setup: AtmEntity atmEntity = new AtmEntity(atmType) UseDateTime useDateTime = new UseDateTime(dateTime) when: Fee fee = atmEntity.chargeFee(useDateTime) then: fee == expected where: usecase | atmType | dateTime || expected "銀行ATM営業時間内"|AtmType.銀行ATM | LocalDateTime.of(2023, 1, 6, 9, 0, 0) || new Fee(0) "銀行ATM営業時間外"|AtmType.銀行ATM | LocalDateTime.of(2023, 1, 6, 22, 0, 0) || new Fee(110) "コンビニATM土日" | AtmType.コンビニATM | LocalDateTime.of(2023,1,7,22,0,0)|| new Fee(330) "コンビニATM平日_営業時間内" | AtmType.コンビニATM | LocalDateTime.of(2023,1,6,9,0,0)|| new Fee(220) "コンビニATM平日_営業時間外" | AtmType.コンビニATM | LocalDateTime.of(2023,1,6,21,0,0)|| new Fee(330) }
上記では各手数料の金額単位のテストを行いました。テストケースの粒度は境界値単位などもあります。品質保証したい単位を加味してテストケースを作りましょう。 テストコードを先に追加することで、元のロジックが保証され、後からリファクタリングを行ってもその動作が保証される状態となります。
リファクタリング後の約束
リファクタリング後、テストコードがそのまま通れば、「元の動作が保証されている」ということです。そのため、リファクタリング後のテストコードは変更してはいけません。テストコードもプロダクトコードも一緒に変更してしまうと、「元の動作が保証されている」という前提が崩れてしまうからです。
もしテストの漏れが発覚した際は、後からテストだけ追加できる別のマージリクエストで対応し、リファクタリングと同じマージリクエストにテストコードの修正を混ぜ込むことはやめましょう。
おわりに
リファクタリングの本質は、元の動作を保証したうえで改善することです。
保証されない状態で行う変更は、デグレードや予期せぬ障害の原因となり、結果としてプロダクトや組織へダメージを与えます。テストコードによる保証を徹底し、保守しやすいコードベースを共に育てていきましょう。
Clineを使ってみよう
Clineと共に開発を始めてみる
最近AI使ったコード開発増えてきましたね。 Devin（※１）を使った人の話を聞いていたら、若手エンジニアと同じくらいの成果出るよとって言う人が多く興味が沸いてきました。ただ、2025年4月時点で月額プランで500ドル/月です。日本円にすると約7万円です。個人で触るにしてはお高いなと躊躇ってしまいます。 そこでAIを使った開発をするために無料であるCline（※２）と無料枠のあるAIを組み合わせが手軽に使える環境として考えられました。 今回はClineを使ってみてClineができることを紹介します。
Clineとは
ClineはVSCodeの拡張機能であり、AIによる開発支援ツールです。 Cline自体はOSSのため無料で私用することができ、以下の作業を行うことができます。
- コードの解析
- コードの新規作成、修正
- ターミナルによるコマンド操作
- コマンドやテスト実行結果の解析
ClineはGoogle Gemini（※３）など複数のAIモデルに対応していて、AIモデルを選択できることも特徴です。 今回はGoogle Geminiを使った例で記載します。
使用するAIモデルによっては有料であり、また無料枠を超えてしまった場合に課金されることもあるので、使用するAIモデルの課金仕様を把握して使ってください。
Clineの始め方
VSCodeにて、拡張機能のアイコンを開き、検索エリアにClineと入れるとClineの拡張機能が見つかりますので、インストールします。
インストールすると左側のアイコンの一覧にClineのロボットのようなアイコンが表示されますので、選択します。
次に右上の歯車マークを選択して以下の手順を実施してください。
以上で準備は完了です。 これでClineが使えるようになりました。
補足 Google GeminiのAPI発行
下記にアクセスして、APIキーを作成ボタンを押下します。 そうすると、以下のようにAPIキーが払い出されるので、Clineに設定します。 https://aistudio.google.com/app/apikey
これで準備は完了です。
Clineでできること
AIに開発支援でまず思いつくことがコードを書いてもらうことかなと思います。 早速書いてみます。
コードを書く
外部のAPIアクセスをまとめたクラスのメソッドにSteam（※４）のAPIで指定のユーザの直近プレイしたゲームを取得するメソッドを追加しようとします。 API仕様書からエンドポイント、リクエストが定義されていますので、これらから要件を指定してメソッドを作ってもらいます。 ゲームのプラットフォームに社内からアクセスは出来ないので、個人の端末で試してます。
まずチャット欄に指示を入れると以下のように対象のコードを読み込みを求めてきます。
読み込みだけなので、Approveをしてもコードが変更されることはありません。AIに触れて欲しくないコードや個人情報を含むファイルなどであれば拒否してください。
解析をすると、コードの修正差分を表示してくれます。
この結果をみて、コードとして反映したければ、Saveを押して保存します。
一部修正したい場合は、Saveした後に、再度提案して是正することもできますし、Saveせずに修正点を指摘して再度書いてもらうこともできます。
この作業を繰り返してコードを作成します。他のAI開発支援ツールでも同じですが、小さいタスクを積み重ねていく方がClineも向いています。そのため、Gitなど小まめにコミットを切り、テストなどで意味あるまとまりになった段階でマージしていくようにする手順での開発のやり方がお勧めです。
Clineでコードを作るまでの流れは以下になり、これを繰り返していきます。
- Clineがコードを読み込む
- Clineが解析する
- Clineがコードを修正
Gitで動作保証ができた単位でコミットを切っていれば、とりあえず変更を反映してましょう。 意図とずれていたら戻しをすればいいので、コードの修正の受け入れは気軽にはできます。
ターミナルの操作できる
他のAIツールでもできるかもしれないですが、Clineを使って便利さを痛感したことがターミナルのコマンド操作ができることです。
pythonで開発する場合にライブラリをプロジェクト入れることがあります。
例えば、以下の画面はSQLAlchemy（※５）を入れています。pipを提案されましたが、poetryでパッケージを管理したかったので、受け入れずに軌道修正しています。
コマンドを受け入れる場合に、「Run Command」を押下すると、実行されます。
VS Codeのターミナルでコマンドを実行してくれます。実行コマンドによっては開発環境全体へ影響のあるコマンドが実行される恐れもあるため、コマンドの実行は特に確認してから実行させるようにした方がいいです。
コマンドの実行結果も読み込める
Clineがコマンドを実行できるとを紹介しました。 Cline経由でテストを実行させ、テストが失敗したとします。
上記画面のテスト失敗の時にターミナルにでているエラーは以下です。
期待値とテスト結果の差分あるエラーがでました。 Clineは実行したコマンドの結果を読み込んでいて、結果を受けた修正の提案をしてくれています。 テストのエラーのため、あとはコード書いて直してくれましたが、インストールのコマンドエラーであれば、エラーを受けたコマンドを提案してくれます。
最終的にこのエラーを解消のため、テストコードのテスト結果を修正してもらい、再度テストを実行し、全てのテストが通ることの確認までしてもらいました。
承認していくだけでエラーを解消できることもあり、開発のしやすさ速さを痛感することになりました。
Clineでの開発をしたメリット
今回Pythonでコードを書いてみましたが、私はPythonを業務で書いたのは今年が初めてです。 ほぼ初めての言語でもClineを使えば他のオブジェクト指向言語での開発をした経験があるのであれば、開発できるレベルまでClineがサポートしてくれました。 自分が開発で使っている言語でもプロジェクト内の他のコードから類似部分をコピー＆ペーストして持ってきてから修正していくことも多いのですが、Clineだと日本語で詳細仕様を伝えてると大体欲しいコードを書いてくれるので、開発のスピードとしては上がったと思います。
私が１番便利に感じたことはコマンド実行を行い、かつコマンドの実行結果を読み込んで対応してくれることでした。環境の定義などローカルで動かして是正していましたが、コマンド実行できることによって、Clineがエラーのフォローをして、実行までしくれるので、コマンドの影響だけ考慮して実行させるだけでもローカルでAPI実行できるようなコードと環境の立ち上げすることができました。
試しに無料で使える範囲で使ってアプリケーションを作りましたが、Clineなしで開発するのは厳しいと思うほど、便利さを感じました。 現場にも動いてくださった部署があり、社内のAIモデルを使ってClineが利用できる予定です。
参考
※１ DevinCognition 社が提供している自律協調型のAIソフトウェアエンジニア ※２ GitHub - cline/cline: Autonomous coding agent right in your IDE, capable of creating/editing files, executing commands, using the browser, and more with your permission every step of the way. Cline公式ページ ※３ Google が提供しているAI Gemini ※４ Steam Valve Corporationが開発・運営しているPCゲーム向けのデジタル配信プラットフォーム APIを提供しており、ユーザ、ゲームの情報を参照できる。 ※５ PythonのORMapperのライブラリ SQLAlchemy - The Database Toolkit for Python
読書メモを試したお勧めのメモの取り方
読書メモを始めてみたよ
技術書の読書術に書いてあったアウトプットすることによって、理解できてないことを認識するきっかけになるよとあったので、試してみました。
また、本の内容を自分の言葉にかみ砕いて書くことによって、理解を深めるために言語化はしてみたかったこともあり、始めてみることにしました。
使用ツール
使用したツールはScrapBoxです。
Googleドキュメント、VSCodeなど使っていたツールの中で比較し、使おうと思った理由は以下です。
- 無料で使える
- 自宅のPC、スマフォの両方から編集ができる
- タグ付けで技術書の読書メモでグルーピングができる
メモの構成
１冊の本で１記事にして、技術書タグでまとめました。 ざっくり構成は以下です。
タイトル 第N章 メモ ←各章ごとの自分が気になった点のメモ 読書期間 #技術書 ←グルーピング用のタグ
タイトルは他人に紹介するときに内容とタイトルをリンクさせないといけないので、いれてます。
読書期間は現状目的を持ってないのですが、手間が少なく技術書の読書術でもあった項目なので試しにいれてみました。 自分が１冊読むのにどれくらいの期間を使うのかを可視化はできました。
できた読書メモ
「単体テストの考え方/使い方」を読んだ際に作った読書メモです。 https://amzn.asia/d/99UAUFW
例のメモの一部を残した目的は以下がありました。
- 良い単体テストの柱に記載している４つの過剰書きの観点が単体テストの評価観点だったので、本の主張である観点が何かを見返せるように
- コンストラクタのテストの話は自身の経験の開発の中でアンチパターンを踏んだ経験があったので、本の主張としてNGな理由を付け加え、仕事で取り入れるように
メモすること
章ごとに気になった点をメモしました。
メモを目的としない
技術書を読むことが目的だったので、理解が進まずメモできるまで言語化できないときはメモは取らず、読み進めることを優先しました。
振り返りのメモにする
メモは外向きに説明するためのメモにせず、自分が見返した時に自分が解釈した本の主張を書いたり、自分の意見を書いたりしてました。
読んだ際に、共感、反対などの意見を持った内容を残すようにしておくことによって、印象に残った本の内容を振り返れるようにすること目的にしてました。
理解を深めるメモを書く
また、本の内容を受けて取り入れるならこうするとか、自分の持ってる他の知識の言葉に置き換えたりして、自分の認識にあった言葉でメモするようにしてました。
自分の経験と本の主張を結び付けるようにして、理解を深めることの目的にしてました。
結果として、文章化に詰まったりする点が気づきとしてあり、理解した気になってると気づけたことが収穫でした。
読書メモを作ってみて気づいたお勧めポイント
- メモは文のまとまりを読み切ってから書こう
- メモを目的とせず、ハードルをできるだけ下げよう
まとまった文を読み切ってからメモする
共感できる点をメモしていたので、文の途中でメモを取りたくなることがありました。
ただ、文をまとまった単位で読み切ると、メモするほど重要ではないなと感じたり、書いたメモと本の主張に齟齬が起きてることに気づくことがありました。
そのため、本にある文章の隙間が作られるような文のまとまり単位を読み切った時に書くようにしました。
これによって、文章全体を通した主張を捉えることができるようになったことがメリットでした。
メモのハードルを下げる
理解しきれなかったことを無理にメモには残さないようにしてました。 技術書の読書術にもありましたが、本の内容を理解できないことによって本を読む習慣をやめてしまうことが１番もったいないので、割り切りました。 メモを取ることによって、技術書を読む機会を失わないようできる範囲でメモをするにしてます。
また、自分用のメモの位置づけにしていたため、主張を誤解釈したことを書いてもよく、読んだ結果を言語化して残すだけにして、極力ハードルを下げました。
おわりに
技術書を読むだけよりはメモをする分の負担が増えました。
読むだけだと知識が頭の中にしか残らず、どこまで理解してるのかわからないことも多かった課題も感じていました。
理解した気になっていることを気づけたこと、文章化することによって、内容を整理するきっかけになりました。
メモが技術書を読むことの妨げにならず、理解する手助けにできたので、負担ならない程度には続けていこうと思ってます。
推しを探しにデブサミに行こう
デブサミに参加する目的
今回のデブサミに登壇した推し
デブサミ２０２４夏の2日だけ参加してきました。 参加できなかった日も含めて、過去にセッションを聴講した自分の推しの方々がこれだけ登壇されているんですね。
- t-wadaさん
- 石垣さん
- ミノ駆動さん
- ZOEさん
- 成瀬さん
- 藤井さん
推しなので、Xをフォローさせていただいて、 最近の活動だったり、他の登壇の情報や資料を追っかけしてます。
推しなので、自分にとっては、価値観が合う方です。 だから、推しの話を聞いて、新たな気づきを得たり、共感をしたり、自分の行きたい方向の先を実践されていたりと、 自分が仕事をする上で刺激や情報をもらえる機会が得られます。
今の推しだけで満足できなくなってきた
前職に転職してからデブサミなどのカンファレンスに行き始めて4年程度経ちました。 当初は０人だった推しも二桁以上に増えてきました。
みなさん第一人者なので、得られる話は貴重です。 ミノ駆動さんはコードの保守性のリーダブルコードの観点の経験の話が聞けるし、 ZOEさんは部下に対するマネージメントの話が聞けます。 ただ、みなさんには専門、得意分野があり、彼らだけ聞いていては知識が偏ってきてしまいます。 それに今の推しに出会ったようにデブサミに登壇するまだ見ぬエンジニアとの出会いがなくなってしまうことはもったいないなと思ってきたわけです。
デブサミ２０２４夏で試したこと
今の推しと新たな推しを探すため、デブサミ夏では半分くらい未知の人を聞きに行きました。
今の推しの価値観があった方と違って、専門もどんなスキル持っている方かもわからないので、 自分に合うか合わないかは運です。 割り切るために、推しは半分くらい聞いておいた方が自分に合う新情報には出会えると思います。 会う人に出会えず、カンファレンス自体つまらないって思うのも勿体無いですから、得られる確率が高いセッションにはいくようにしました。
優先度決めて、会いに行く推しを決め、空いた時間にタイトルで面白そうなセッションを聴きに行ってみました。
デブサミ２０２４で得たこと
ミノ駆動さんのセッションのように興味のある分野に対して、新たな情報を得ることができ、満足もしつつ。 半分くらい未知のエンジニアの話を聴いてみました。
新しい推し
自分にとって、聴いた話が自分の経験と被って共感したり、 話を聞いた結果、こうしようと思うセッションを「刺さった」と言っています。
今回２つのセッションが刺さったので、刺さった点を含めつつ紹介します。
強い内製化組織をつくる、“東京ガス”のエンジニア技術選考プロセス～事業貢献するエンジニアを惹き込むには～
東京ガスさんのテックブログを読んでみると、 古くからある会社なのに、モダンな技術を取り入れてたり、メガベンチャーさんと比べても遜色ない環境があるイメージでした。 セッションもイメージと違わず、PMを求めるのではなく、手を動かしてプロダクト志向の開発できる人材が欲しいという思いが共感できました。 そのために、採用のコードテストを入れて、受験者をみたりしてるそうです。 上司にうちの部も取り入れない？って話はしてて、会社に持ち帰って相談したいネタをゲットしました。 スクラムの話も気になるので、次回の発表も見に行こうかなと思ってます。
オーナーシップは誰のものか プロダクトマネージャーに頼らないプロダクトマネジメントへの挑戦
大規模障害などが起きていた会社にて、売り上げが犠牲になりながらシステムを開発していたエンジニアの話でした。 Classiはだいぶ追い込まれていましたが、課題は事業会社のシステム部であるあるなことだったんですよね。
- 実現可能性を加味せず、営業がやりたいことだけで決まるリリース日でスコープ調整不可
- プロダクトの意思決定をしない、できない管理（マネージャー）層
- 各自がお伺いをたてて、意思決定をしようとしない
前職を振り返った時にこれらは経験しました。 その対策として、エンジニアができることの１つにエンジニアの枠組みを超えて、サービスの意思決定するがあります。 鈴木さんも言ってましたが、エンジニアがやりたくないことだ。ただ誰かがやらないといけないし、 他の仲間たちを苦しませたくなくて、犠牲にしてやったそうです。
認め合える仲間を救いたいって、チームで動くことが多いエンジニアとしては共感できるんですよね 似た課題を感じて、打開のためのアクションがあるべきを通していたがこのセッションが刺さった理由でした。
初めてask the speakerでお話しさせてもらい、 自分は似た事象になった前職にて、中心開発メンバーが退職していったので、 支えになった仲間に残ってもらうにはどうするかと伺いました。 自分が一緒に働きたいと思える魅力を持てるようにしていて、今日の登壇もそのためですと。
かっけぇエンジニアでしたよ。 真似はできないけど、憧れたので、Xフォローさせていただきました！
スポンサーセッションが合わないこと
自分が仕事で使う情報を得たいので、施策がこのサービスを使ったらなどの具体的な話はあまり惹かれません。 セッションの中にはSaaS企業などのこのサービスを使ったら〜というセッションもありますが、 サービスの宣伝でもあるので、そのサービスを検討していたり、導入してる現場以外には利用できる情報が少ないものあります。
いくつかカンファレンスでてみて、 大体スポンサー企業だったなと気づいたので、少しでも自分が興味あるセッションに出会うために、 スポンサーセッションは優先度下げてみる方がいいかもと今回行ってみて感じました。 ただ、サービス宣伝ではなく、エンジニアを集めるために、自社の試みを紹介するところもあると思いますので、 一つの基準にとどめて欲しいなとは思います。
t-wadaさんの開発生産性の観点から考える自動テストを聴講して悔い改めたこと
t-wadaさんのセッションを聴講したこと
2024/6/29に開発生産性カンファレンスに参加してきました。 その中でなんでもかんでもE2Eテストでも実行してしまうことがあるけど、 悪ではないけどデメリットもあるよ。って話がありました。 speakerdeck.com
スライドP47のアイスクリームコーンとピラミッドの図だけはご参照ください。 頭の中にその図が残っているため、前提になってます。
セッションの概要
アジェンダからざっくりお話は
信頼性の高い
誤検知（テストとして正常であるはずがエラーになってしまう）や見逃し（エラーがあっても正常にしてしまう）がないこと実行結果
実行結果値だしたり、エラー原因が特定しやすいテストを書くこと短い時間で到達
確認したい観点を確認できる最小のテストスコープ（単体テスト、結合テストなどの粒度）でテストできるようにすること状態に保つ
短い時間で到達できるように小さいテストスコープがテストケースが多い状態になっていること
そのために、より小さいテストスコープでテストするよう テストダブル（Mockやスタブ含む）を活用して、移行していこう。って話。
余談
「xUnit Test Patterns」という本にてMock、Stubなどのテスト用の代替クラスの定義が決まって、 人によって概念が違うという議論がなくなったらしいです。 なお本はまだ翻訳されてなさそうでした。
聴講前の私
今の現場でE2Eテストの自動化の話があり、Selenoidやplaywrightを使って、自動化してテストを回すようにしよう。 そうなれば、人の手を介さないから単体テストで回すのと工数に差はないよね。 かつ、他のサブシステムと繋いだりしたテストの方がより本番に近いからテストとしての精度が高いはずだ。 だから、自動化されているのであれば、E2Eテストが増えてもいいじゃないかと勘がてました。
思ってたことのどこが悪かったか
関連する他のサブシステムとの連携のテストを確認したいのであれば、E2Eで確認することは適切だと思います。 APIのフォーマットエラーであれば、E2Eをテストするような環境は不要で、単体レベルでもできるテスト観点かもしれない。
確認したい観点に関わらず、E2Eが本番に近いからE2Eテストで実施すればいいという 雑な考えが間違いであることがセッションを聴講して悔い改めたことでした。
なぜ悪いのか
単体テストでできることをE2Eテスト実施するような テストスコープの大きいテストにて、テストしてしまうことは 時間がかかり、テストが不安定になることがデメリットだった。
時間の観点
よりテストスコープが大きい範囲にすることはデータベースを用意したり、他のサブシステムと繋いだりするため、 単体テストに比べてテストの実行時間がかかってしまう。
単体テストで確認できる観点をE2Eで実施してしまうと、テスト結果が出るまでにも時間がかかってしまう。 すると、エラーがあった場合、エラーの検知が遅れてしまい、修正が遅れてしまう。 これは積み重なっていくとリリースの遅れにもつながってしまう。
エラーを早く検知し修正するためにも確認可能な最小のテストスコープでテストを作り、エラーを早く検知できるようにしないといけない。
不安定なテスト
他のサブシステムとのバージョン合わせだったり、用意したフルスタックの環境に一部不備があったりすると、テストしたい観点と別の原因でエラーになってしまう（誤検知） 誤検知かの判断のために時間もかかってしまうし、 誤検知が増えるテストは信用性が失われて、使われなくなってしまう。
他にも過去の現場で他のサブシステムと連携する環境が複数作れないこともあり、評価環境の使う時期の調整の手間も発生していたこともあった。
不安定さを解消することも大事だが、不安定さのあるE2Eテストより小さいテストスコープで確認できる観点はより安定したテストスコープのテストで確認してあげる方が誤検知のリスクを下げていける。
どう変えようと思ったのか
本番に近い形式のテストで実施すればいいという考えをまず捨てる。
その上で継続して、テストによって何を確認したいのか、何を保証したいのかを明確に決めること。 観点が決まれば、どのテストスコープであれば確認できるが決まるはずだからね。
過去のやらかしはテストダブルを使ってテストスコープ下げることは実践としてやってみようと思ってます。
開発生産性カンファレンス2024の2日目参加レポート
- どんなカンファレンス？
- イベントを通して感じたこと
- 参加セッションの資料と参加録
どんなカンファレンス？
初回の開発よりもスタートしたサービスが開始されたシステムにて対して より早く価値を提供し続けるために、計測や仕組みを通じて、開発スピードをあげていく話がメインでした。 そのため、SIerよりは自社開発して事業展開してる会社のエンジニアや、EMなどのエンジニアを束ねるリーダーや事業責任者の方向けのカンファレンスでした。 全体を通して「LeanとDevOpsの科学」の本に書かれているワードに関連したセッションがほとんどであったので、 この本を読んで考えた方が惹かれた方も学べる実践例が多いと思います。
イベントを通して感じたこと
LeanとDevOpsの科学の基礎化
１日目に「LeanとDevOpsの科学」の著者が登壇されていたり、t-wadaさんがカンファレンスの課題文庫だよねっておっしゃってました。 DevOpsの定量、定性の計測だったり、組織の役割の話がメインなので、「LeanとDevOpsの科学」を読んでからきた方がいいなと思った。 同時にエンジニアの前提書籍だなと感じたカンファレンスでした。
参加者の傾向
セッションで運営の方が出してくれた情報で公開してくれた人がいらっしゃいました。 開発生産性と題したカンファレンスだったこともあり、VPoEやPMのポジションの人が多い傾向だったようです。 開発生産性は現場より予算などを管理する層の方の関心が高そうでだなと感じました。
複数のセッションで聞いたワードのまとめ
複数のセッションで聞いて耳に残ったワードをピックアップしてみました。 関心が高かったり、メジャーなやり方になっているとから複数で話にあがってると思うので、これを機に押さえておいた方がよさそうと感じました。
DORAが提唱しているSPACEフレームワーク 本で提唱されてるワードだったのに、覚えてなかったことに気づいた Freeeさんのセッション資料に説明あります
BigQueryのデータ溜めてGrafanaで可視化 FourKeyｓなどの情報を蓄積して図示する仕組みとして一般化したやり方になってそう
テストピラミッド 単体、結合、E2Eのどの範囲で実施するかに課題を感じている現場が多いのかなと印象
参加セッションの資料と参加録
自分が聴講したセッションの資料とそのセッションの概要が気になった点を参加録に記載します。 もし興味を持つセッションがあれば、ぜひ資料も確認してみてください。
LeanとDevOpsのためにE2Eテストができること
参加録
テストツールを作る会社から見て、E2Eテストを自動化する際の失敗談と克服方法の例の話。
現場に持ち帰れそうなこと
今社内のアセットを作るチームにいるので、SaaS会社と同じように解約率？（導入後に打ち切った例）をだしてみるのも作ったアセットの有用性を測る意味でありだなと思う。 社内アセットだと強制力働くことが差分ではありますけどね。
資料
https://speakerdeck.com/magicpod/leantodevopsnotamenie2etesutogadekirukoto
組織横断支援チームによるFour Keys計測基盤の構築と活用に向けた取り組み
参加録
システムや組織の規模が大きくなり、コミュニケーションコスト増や低いデプロイ頻度の改善の取り組みの話。 初期の試験導入チームの選び方は紹介の通り自発性があり、積極的なチームを炙り出す方法が素敵でした。 自発性と積極性のあるチームであったからこそ他のアクションの成功につながっていたように思うので、新規ツールの導入の観点として真似していきたい。
現場に持ち帰ること
FourKeys測定だとTeam+とかSaaSを使った方が導入のハードルは低いと思う。 ただ、現場の制約で難しい点もあるため、この紹介であったOSSのdora-tema/fourkeyが今の現場で使えるツールの１つだった。 そのため、FourKeysを現場に取り入れる案として出していこうと思ってます。
資料
Metrics-informed development; theory and practice
参加録
初めての同時通訳英語セッションの聴講だったのですが、英語の発表資料と少し遅れてくる通訳の話がリンクしなくて、理解が追いつかなかったです。 全体を理解することはできなかったですが、とある現場の数値化にて、２回目以降のリリースでは前回以前のリリースのHotFixが含まれてしまい、徐々に新しい機能のリソースが減っていく話があった。 言われてみれば当たり前かもしれないけど、それを数値化したことによって、 新規機能の開発速度が落ちることは社内で認識合わせられるから数値化することの重要性を再確認できました。
資料
atalog.us-east-1.prod.workshops.aws/event/dashboard/en-US
「開発生産性を上げる改善」って儲かるの？に答えられるようにする
参加録
リファクタリングなどの開発生産性向上の話を現場はする。 けど、自分はそれがどのように事業に貢献できたのかをすぐに言えなかった。 目線の違いの説明やその変換の方法を説明されていて、事業者と開発者の目線が違うことを理解して 生産性の話ができてないことに気づくきっかけになりました。
資料
https://speakerdeck.com/i35_267/is-development-productivity-profitable
アーキテクチャレベルで考える開発生産性
参加録
変更の容易性を上げる方法がDDDだって話がありました。 DDDだと責務わけがしっかりできてるので、コードの場所が絞りやすく変更はしやすかったので、容易性の回答だと実体験と照らすとわかりやすかった。 コードの話でどのクラスの責務にするかの話になってしまうことが多いのだけど、サービスの差別化する点を抽出する戦略的設計が前提で目的と手段の逆転になってることが多いと振り返ってた。 立ち止まって、戦略的設計が前提にあることを置いた上で進めるようにしていかないといけないという学びに繋がりました。
資料
https://speakerdeck.com/minodriven/architecture-and-productivity
freeeにおけるスモールスタートを意識した開発生産性向上の実践事例
参加録
DevOpsの一通りのアクションを導入していった実践例と知見の紹介 一番残ったのはトランクベース開発を組織的に導入したこと。 LeanとDevOpsの科学でも紹介されてますが、早く価値を届けていくために最適なブランチ戦略ではあるものの開発の仕方変えていかないため、導入のハードルが高いと思ってました。 実践した人のリリースフローの簡略化はリリースの事故減らせることは開発者としても運用品質の向上につながるメリットがあると思いました。
現場に持ち帰ること
現場でも障害が発生してから止血までの時間を計測したいって話もあったので、そのプラクティスはやはりチケット（FreeeさんはJIRA）で時刻記録していく方法がスタンダードだよなと再確認した。
資料
開発生産性の観点から考える自動テスト
参加録
描きたい話が多いので、個別で書こうと思ってる。 E2Eテストが自動化されると手運用の労力はないと思っていた。 E2Eは万能ではなく、発表でもあったように単体テストに比べると時間もかかるし、複数のシステムが絡むことによるバージョン不一致などの脆さを兼ねている。 早く問題に気づくためにも、保証したい観点を守れるのであれば、より単体テストに近いテストで実装していく考えは持ち続けておかないとアンチパターンのアイスクリームコーン型（より広範囲で実行するテスト）が継続されそう。
資料
アーキテクチャを突き詰めるオンラインカンファレンスへの参加
きっかけ
- ミノ駆動さん、成瀬さん、増田さんと今までセッション聞いてきて興味ある人が登壇すること
- より変更しやすいシステム開発にするための取り組みの新しい情報が欲しかった
どんなカンファレンスだったか
アプリケーション開発に関する開発手法のセッションがメインでした。 書籍を書いてる人たちや現場で開発をリードする人たちが より開発スピードをあげるため、より安全に変更できるようにするために どのようにシステムを設計するのかその観点だったり、手法を紹介してくれました。
カンファレンスに来てる人たちが関心がありそうなワードはこの辺り。 これらのワードに関心がある人はカンファレンスの資料をみてもいいかもしれない。
- DDD
- クリーンアーキテクチャ
- レガシーコード
セッション
聴講したセッションと概要
- 大きな泥団子に立ち向かうためのソフトウェア設計 本格入門
https://speakerdeck.com/masuda220/big-ball-of-mud
開発が積み重なっていくと、変更が難しいシステムになっていってしまう。
そのために関心ごとを分離して、考える範囲を小さく切り出すことが必要である。
広めたいのは考える範囲を小さくするために挙げられた手法を常識としてとらえられる今の時代だと最低限求めたいなとは感じた - CQRS+ESアーキテクチャ解体新書
https://speakerdeck.com/nrslib/cqrs-es-disassembly-book
スケーラブルなシステムの方式としての案
ES（イベントソーシング）とメッセージ駆動（CQRSを使ってやりたいこと）を組み合わせることによって、リソースの待ち少ない仕組みにつながる
タスクが細分化できるようになるので、クラウドサービスのスケーラビリティにもしやすくなる
口頭説明が多くて資料だけだとわからないので、youtube見た方がいいです。 www.youtube.com - 見えないものに着目すると上手くいく、モデリングの勘所
業務をモデルに落とし込むときは目的を観点に切り分ける。
さらに踏み込んで、禁止事項などの観点を用いて、設計に活かせる観点を挙げてくれます。
https://speakerdeck.com/minodriven/invisible-driven-design
発表資料だけ見たセッション
共有がてら貼っておきます。
- ビジネスの構造をアーキテクチャに落とし込みソフトウェアに可変性を注入する https://speakerdeck.com/monotaro/bizinesunogou-zao-woakitekutiyaniluo-tosiip-misohutoueanike-bian-xing-wozhu-ru-suru
- サービスを立ち上げを終えて追い求める美しいアーキテクチャ
仕事の打ち合わせと被ってあまり聞けなかった
https://speakerdeck.com/takuyatezuka/sabisuli-tishang-gewozhong-ete-zhui-iqiu-merumei-siiakitekutiya - RASKULに見るアーキテクチャの変遷 複数サービス展開への道
仕事の打ち合わせと被ってあまり聞けなかった
https://speakerdeck.com/yusukekishino/raksulnijian-ruakitekutiyanobian-qian-fu-shu-sabisuzhan-kai-henodao
各セッションで得て広めたいこと
全部書きたいですけど、一部セッションだけ書きます。
大きな泥団子に立ち向かうためのソフトウェア設計
大きな泥団子は負債がたまってて、開発が足をひっぱられてる状態。 足を引っ張られる分、変更は大変です。 ただ、その大変さを超えて開発し切ると無駄に仕事した感じは得られるんです。 でも、それってやりたいことするために本来不要な手間が発生してしまってるだけです。 同じような大変さを味わうのであれば、変更しやすいようにリファクタしたり設計を見直していくことに力を注ぐべきですよねってことが根底にあります。
変更しやすくするための手法として、イミュータブルを挙げてました。
スライド１ページが数秒で流れました。それくらい常識だよね。説明する必要ないよねって。
イミュータブルはJavaで言えば全てのメンバ変数にfinalがついた状態になってることを指してます。
これが今の変更容易性を求める現場では常識になってます。
他にも挙げられていますが、挙げられてる手法と自分達が開発しているシステムにギャップがあるのであれば、世の中の常識との差分です。
変更しにくいままでいいシステムは存在しないので、差分に気付き、その差を詰めることに目を向けて欲しいです。
CQRS+ESアーキテクチャ解体新書
イベントソーシングはステートソーシングと比べて、情報が残りやすくするメリットくらいしかわかってなかった。 セッションであったようなイベント駆動、メッセージ駆動の考えにはステートソーシングだと対応できない。 申込、キャンセルとされた場合、それぞれで必要な処理は別だが、最後の状態のキャンセルしかないので、それぞれのイベントに同期して処理完了させないといけない。 イベントソーシングなら、申し込みとキャンセルがそれぞれのイベントとして永続化されているので、非同期で申込イベントに対して、申込処理ができる。 イベントソーシングには、非同期処理ができるメリットがありました。 非同期処理ができて、細かいタスクになっていくと、空いてるリソースを有効に使いやすいのと、 障害が起きた時の影響範囲が縮まるなどの他のメリットにもつながったりします。
見えないものに着目すると上手くいく、モデリングの勘所
モデリングに限らず使える設計の観点になると思います。 セッションの中であげてましたが、道路交通法は交通事故（異常系）を防ぐことを目的として、法律ができてます。 異常系を防ぐために守ったり、決めておいた方がいいことを法律（仕様）になっている訳です。 支払い系のシステムであれば、ユーザが不利益を被る二重請求を防ぎたいという目的があって、 シーケンシャルなチェックIDを使って重複チェックしたり、キュー処理が一度しかされない仕組みを使う設計にもつながると思います。 紹介されている観点をモデリングに限らず、データ駆動のシステムの設計をするときに、深掘りする観点として取り入れるだけでも 今まで考えてなかった観点に気づけるきっかけになるので、ぜひ試して取り入れてほしいです。
