00:03
はい、6月26日月曜日ですね。時刻は昨日、37分になりました。
今日から6月最終週になりますね。はい、もう上半期終了というところもあって、まあ、いろんな企業さん、締めの向かえる
会社さんもたくさんあると思います。しっかり、前半頑張っていきたいと思いますし、それぞれですね、また、あの前半の
上半期の振り返りをしていただくいい時期でもあり、たりしますので。
学生さんだと多分4月スタートなので、まあ、とりあえず第1次半期ですね。
終了というところで、まあ、いろいろ振り返りのタイミングでもあるのでね。
ぼちぼち、皆さんでもその辺を発信していただけた、しております。はい、おはようございます。めみーのキースことくわはらです。
では、本日も朝から始めていきたいと思います。
えーとですね、前半ってか、昨日すみません、あのー、個人的な都合で
スキップしてみましたけど、えー、今日はですね、おととい土曜日に読む予定だった
本、タイトルの記事ですね。ヤフーでは開発迅速性と品質のバランスをどうとっているか
2022年っていう記事がありますので、こちらを読んでいこうと思います。
その1個前にですね、金曜日に読んでいた、ヤフーさんの
開発生産性のインタビュー記事がありまして、その記事がすごく参考になったし、めちゃくちゃ面白かったんですけど
あそこでリンク貼られていた、えーと、記事ですね。
があったので、それがこの記事だったんですね。こちらをちょっと今日は読んでいこうかなと、はい、思っております。
では、えーと、さっそく入っていきましょう。今日はですね、プーさんですね。おはようございます。ご参加いただきありがとうございます。
えー、今からダラダラと読んでいこうと思ってます。では、本文を入っていきたいと思います。
えー、ヤフーでは、開発人測定と品質のバランスをどうとっているか、2022年というところで、
でも、この記事自体は2023年の2月6日に公開されたものになりますね。
では、えー、本文を入っていきたいと思いますが、本記事は
2022年11月に開催したテックバース2022で発表したセッションを予約したものになります。
アーカイブ動画を文末にも掲載していますので、見てみてください。
質疑応答の様子も収録されてますよ、というところでした。
えー、みなさんは、ノーメジャーメント、ノーインプルーブメントという言葉をご存知でしょうか。
まあ、これ、測れないものは改善できないという意味で、
熱力学者であるウィリアム・トムソン博士の言葉とされております。
これ、いいですね。測れないものは改善できない。ちょっと、一発目からすごくいい言葉と出会ってしまいましたね。はい。
これは、ぜひぜひ、ちょっと僕も使っていこうと思います。
下の図ですね。画像が貼られてるんですけど、下の図は、Google社のDORA、
DevOps Research and Assessmentですね。というものを参考にして作成をしました。
開発スピードとサービスの品質を改善するためには、計測が必要になりますと。
計測のための4つの指標を紹介しております。
で、まあ、一枚ぺって画像が貼られてるんですけど、ちょっとこれ、音読するの大変なんで、
えーと、みなさんの方で見ていただければと思いますが、大きく2つの
四角で囲われていて、ディベロップメントスピードと、サービスクオリティですね。
はい。品質と開発速度というところを、大カテゴリーとしてあって、その中にそれぞれ、
小カテゴリー、サブカテゴリーとして、言葉が2つずつ貼られてますね。
ディベロップメントスピードの方は、チェンジとリードタイムですね。
はい。リードタイムです。もうまさしく。というのと、デプロイフリークエンシーですね。
デプロイ頻度というところですね。
03:00
まあ、これはまさに、DORAが作った、
4 keys っていうのを、ディベロップメントスピードと、サービスクオリティというところで、
カテゴライズしたというだけなんですね。これ。
で、サービスクオリティの方はMTTRです。
Mean Time To Repairと、Change Failure Rateですね。というものです。やっていますと。
で、4つの指標で計測して、開発スピードとサービスの品質を改善していきます。
っていうお話ですね。次で。
開発スピードの分析に利用する指標というのは、1つ目が、
チェンジリードタイムですね。開発が始まってから、本番にデプロイされるまでの時間。
で、2つ目が、デプロイフリークエンシーですと。本番にデプロイされる頻度になります。
で、サービスの品質の分析に利用する指標というのは、1つ目がMTTR。
はい。Mean Time To Repairですね。
発生した事故の平均修復時間ですね。これは。
で、もう1つ。2つ目が、Change Failure Rateですね。本番にデプロイされたもののうち、
システム事故が発生した割合ですと。まあ、障害発生率と言ったりしますね。
で、チェンジリードタイムっていうのは、GitHubとCICDツールである
Skrewdriver.cdっていうののデータを活用して計測をしています。
Skrewdriver.cdっていうのがあるんです。で、続いて。
具体的には、デプロイの際にその情報をAPI連携し、集計システムにデプロイ情報を蓄積。
その情報からGitHubのファーストコミットを見つけ出し、集計していますと。
で、デプロイフリーケンシーっていうのは、デプロイの際のAPI連携の回数っていうのを計測しています。
ああ、そういう感じなんですね。それなんかGitHubのAPI叩くとかではなくて。
まあ、多分叩くと思うんですけども、GitHubとCICDツールであるって言ってるので。
まあ、この辺を使っていこうってとこですね。
で、Change Failure RateとMTTRっていうのは、社内ツールである事故報告ツールのデータを利用しています。
Yahooさんはその辺を自作してるらしいですね。
で、Yahooでは事故が発生した場合、発生時間と応急処置完了時刻っていうのを報告する義務があるので、
その報告内容から集計をしております。
次に、371プロダクトの指標の計測結果を示した4つのグラフを紹介していきたいと思います。
グラフの青信号は良い結果、赤信号は悪い結果、黄色信号はその中間点を示しております。
そうですね。前回読んだ通りですけど、Yahooさんって371プロダクトもあるらしいです。
ざっくりYahoo Japanで言ってますけど、Yahooメールとかも含めて371個に以上切り分けられているってことですね。
で、1つ目、Change Read Timeですけども、
ソフトウェアデリバリーのChange Read Timeっていうのは、短ければ短いほど良い結果とは言えます。
これの指標だけを言えば、早い方がいいよねって話ですね。
お客様からのフィードバックが高速に反映され、それを受けて進路変更も素早く行えるからです。
で、Change Read Time見てますけども、
グラフ見てて単純にあれですね、半ピレのグラフみたいな感じになってますね。
単純に時間がEarlyかRateで、Rateになればなるほど赤信号です。
で、Earlyっていう下に行けば行くほどグッドだと思うんですね。
はい、緑色になっていきます。
で、Read Timeのところのランクもそうですけど、
左に行けばLowで、右に行けばHighで、Highに行けば行くとやっぱり緑だと思うんですね。
はい。
まあちょっとこれは、僕はグラフ見てるので、皆さんのお手の丁度見てみてください。
続いて、デプロイ頻度になりますけど、
06:00
デプロイ頻度、開発スピードに関するもう1つの計測指標っていうのがデプロイ頻度でして、
皆さんは複数の変更要件が入った大きなプロリクエストをもらったとき、
レビュー式に出ないと感じることはないでしょうかと。
はい、まあその通りですよね。
人間のメインメモリーで記憶できる要領には限界がありますからね。
デカすぎるデプロイとかプロリクエストとかは、
僕らがこれ何だっけっていうのを覚えておける限界量ですからね。
で、作業サイズの削減によって得られる効果っていうのは、
お客様からのフィードバックの高速化とリスクの削減、
コストとスケジュールの膨張抑制になりますと。
ただ、ソフトウェアの場合、作業サイズは目に見えないため、
代わりにデプロイ頻度っていうのを計測しようにしました。
はいはい、まあこれもよくやるやり方ですよね。
プロリクエストのサイズを小さくするとか、
例えば1回のプロリクエストの変更行数を200行以下にするとか、
これ結構よく使われる指標なんですけど、
とかにするとか、各メンバー1日に最低3プロリクエスト足すとか、
3は結構厳しいので2とかしてもいいですけど、とかにする。
これを1回ルールにするんですね、エイヤーで。
で、3プロリクエストって結構重いルールだったりするんですけど、
それを作る代わりにプロリクエストって小さくなっていくんですね、みなさんね。
小さくなればなるほどレビューも早くなるし、
レビューのクオリティ、品質も上がっていくわけですよね。
結果デプロイのクオリティも上がるし、サイクルも早くなるので、
実はプロリクエストのルールを厳しくした方がいいんじゃないのっていう、
いろんなアクションと結果も結構出てたりするんですよね。
っていうので、デプロイ頻度が上がっていくっていうところの、
一つの指標というか、やり方っていうのもいいなと思いました。
では続いてMTTRですね。
平均修復時間になりますけど、
複雑なシステムが急速に変化する現代のソフトウェア開発に、
失敗っていうのはもちろんつきものですので、
サービスをいかに迅速に復旧できるかっていうのが鍵になります。
そこでインシデントが発生した場合に復旧までにかかった時間を表す、
平均修復時間っていうのを計測費用にも一応してますと。
もちろんこれも短ければ短いほどいいですし、
ランクが高ければ高いほどいいよっていう話ですね。
最後、チェンジフェイラーレートです。
稼働に失敗したケースの発生率、障害発生率ですね。
開発現場で一度失敗をすると、
復旧作業と影響調査で予定外の作業が増えてしまいます。
エンジニアの心理的にも、
なるべく失敗率はもちろん少ない方が健全になります。
そのため稼働に失敗したケースの発生率も指標の一つにはしていますと。
Yahoo!社内ではサイトチェンジサクセスレート、SSRとも呼んでおり、
品質評価指標となっていますと。
この辺に関してYahoo!さん独自の社内システムとかで検知してたりするので、
この辺は本記事では触れられていないので、別の記事とかあったら見てみたいですけどね。
でも、ちゃんと障害発生率っていうのもしっかり見てますと。
さすがにYahoo!さん371個プロダクトもあったりするので、
かつユーザー数もかなり大きいんで、
これ全然無視できないんでしょうね、ビジネスインパクティックにも。
続きのセクションですけど、
各指標をどうやって評価するかっていうのが次のお話ですね。
はい。開発のスピードとサービスの品質っていうのは、
開発現場において相反する場面が結構多くありますと。
例えばテストを強化すればサービスの品質は上がりますが、
09:00
提供までの時間っていうのは増加してしまいますと。
逆に急ピッチに開発をした場合、
十分なリスク検証というのができていなくて、
サービスの品質というのは低下していきますと。
そこで開発スピードとサービスの品質をバランスよく改善するために、
指標ごとに下位クラス、中位クラス、上位クラスの3つに分けて、
評価基準を定めていきましたと。
はい。ここで注意すべきは、
指標単体での評価っていうのは、
プロダクトの状態を容易には判断できないってことですね。
例えばスピードは速いけどインシデントが多い場合は、
そのプロダクトをどのような状態と見れば良いでしょうか。
そこでスピードと品質について4つの指標の中で、
最も低い評価となった指標を、
プロダクトが属する総合クラスってもので払わせてみましたと。
こうすることでスピードと品質のバランスを取りながら、
プロダクトを評価でき、
自身のプロダクトの状態を見ながら、
より高いクラスを目指して改善に取り組みますと。
で、可視化については、
計測のためにデプロイパイプラインへ、
特別な設定を組み込まなければならず、
Yahoo全社で統一した計測を行うことについて、
理解を得るのには非常に苦労しましたと。
しかし結果として、全社を相対的に数字で見られるようになりましたと。
今回一番お伝えしたいこととしては、
開発について、あの手この手でとにかく見える化することだっていうことだそうです。
で、チェンジリードタイム、デプロイフリーゲンシー、MTTR、チェンジフェーラーレートですね。
まあ4つの指標、あのGoogleの4キーズですね。
こちらを見える化の手段として用いました。
他にも計測している数値は実はありますけども、
私はこの4つが最もバランスが良い計測だとやっぱ思いますと。
はい、まあこの辺に関してはですね、
前回読みましたYahooさんの開発生産性のインタビュー記事があるので、
こちらで詳しく述べられていますので見てみてください。
続いてですね、プロダクトへのアンケートを行い、
数値改善に有効な開発習慣というのを見ているところです。
開発習慣っていうのはサービスの特性に関係がしていますと。
例えば課金系システムであれば品質が最重要、し、され、
常にミスのない状態が求められるため、
テスト自動化っていうのが開発習慣としては発達します。
開発習慣はプロダクトのライフサイクルにも関係しています。
スタートアップのような生まれたてのサービスでは、
素早くシステムを作り上げ、何度も機能調整することが必要となるため、
デプロイ自動化っていうのが開発習慣として発達しますと。
多くのサービスを提供しているYahoo!では、
開発習慣についても多くのバリエーションが存在しています。
様々な開発特性がある中、
何をすれば数値改善につながるのかっていうのを明確にするため、
プロダクトへのアンケートを行い、数値データとの関係性も調べました。
アンケートでは開発習慣に関する6つの大項目を設定しました。
1つ目がトランクベース開発、2つ目にアーティファクト管理、
3つ目にデプロイ自動化、4つ目はテスト自動化、
5つ目テストデータ管理、そして最後、素決合化、この6つだそうです。
この項目は社内においてベストプラクティスと呼ばれており、
CICDを中心とした開発スタイルっていうのを参考としております。
アンケートでは回答誤差が生じないように質問内容を具体化し、
はいかいいえのどちらかで答えられるものにも設定しております。
下の図はアンケートの回答結果と各クラスの関係性をグラフで示したものです。
12:02
これを見ていくことで開発習慣とプロダクトが属するクラスの関係が見えてきます。
上位クラスになればなるほどベストプラクティスな開発習慣が定着していることはわかりますよと。
この画像ペッて貼られてるんですけど、後ほどツイートしますので皆さんに見てみてください。
割と参考になると思いますし、はいかいいえっていう質問だけでどこまで具体化するか結構難しいんですけど、
最初はざっくりとした質問に入って、そこから細かく細かく詳細な質問に切り分けていって、
最終的にはかなりエッジケースでのはいいいえってところまで落とし込んでいった質問形式になってるんですよね。
それを回答していった結果、皆さんの中で何が上位クラスに採答するのかっていうのが結構見えてくるってことですね。
はい。
アンケートの内容をもうちょっと詳しく見ていきますと、テスト自動化に関しては3つの説問を用意しました。
説問は回答が進むにつれ難易度が高くなるように設定していますと。
例えば単体テストが自動化されている、テストがCICDツールで実行されている、などのプラクティスは社内で定着しつつある状態です。
反対に結合テストの自動化については上位クラスでもまだ十分ではない状態でした。
ここから考えられることは、現在下位クラスであるチームは結合テストに注力するよりも単体テストの自動化や、
テストがCICDツールで実行される状態にフォーカスする方が上位クラスになるための効果的だっていうところですね。
実際の開発現場は様々な問題を抱えており、より効果的なプラクティスを優先的に実践するというのが可決ですよということですね。
今回のアンケートの結果で意外だったのは、基本的なプラクティスの集計結果は僅差だということだそうです。
僅差ではあるものの、上位クラスは基本的なプラクティスを徹底的に習慣できているというふうに感じています。
導入自体はできているけど、それがちゃんと習慣まで落とし込めているかっていうと、そこがやっぱり分け目なんですね。
続いて、改善のためのアクションを開発現場で実践という話です。
次は改善のためのアクションについて、あるプロダクトの例をちょっと紹介していきたいと思います。
あるプロダクトは4つのステップで改善のためのアクションを起こしました。
1つ目はGプロダクトの数値を知ると、2つ目はGプロダクトの開発習慣を知る、3つ目は上位クラスと比較する、最後が通常業務と並行しながら改善すると。
で、また図がペッと貼られていますけども、さっきの4keysの数字が貼られていまして、まずリードタイムが平均すると213.05hだと。
結構重いですね。213時間かかるんですね。
で、デプロイフリークエンシーは月に0.66回ですと。月に1回もデプロイできてないらしいですね。
ここはやっぱりローですねと。さっきはミディアムだらしい。
MTTRは0%、チェンジフェーラーレイトも0%。
超高品質でデプロイができているのでここはもうハイクオリティですね。
その代わりフリークエンシーが下がっているっていうのが改善ポイントですと。
これはもうわかりやすい結果ですね。
上記の図っていうのはスピードに関する指標、右が品質に関する指標で、これを見ると品質に関する指標は2つの上位クラスにあって問題ないと。
一方左側のスピードに関する指標というのは下位クラスになっており改善が必要ですと。
このチームは運用作業に追われていて、デプロイフリークエンシーの数値が低くなっておりましたと。
15:02
そのため先ほどのバランスをグラフにプロットすると、総合的には下位クラスに即していましたと。
そこで課題を見つけるためにチーム全員にアンケートを回答してもらいました。
そこから見えたお話ですけども、そこから見えてきたのが、チーム内でも開発ルールの認識に差があって、回答にばらつきがあるという結果でしたと。
なるほどね。
そこでばらつきについて議論することで、チームの開発ルールについて再確認することもできました。
次のデータチャートの図はアンケートの集計結果を平均として表したものですよ。
はいはい、これもちょっと後で見てください。
このチームではテストの自動化の習慣というのが実は低いことがわかります。
先ほどまとめた自身のプロダクトの数値に上位クラスの平均値を重ねてグラフで比較しながら、チーム全員で開発習慣について議論してきましたと。
様々な開発経験を持つメンバー構成なので、これまでは白紙の状態から意見をまとめるということに時間がかかっておりましたと。
しかし今回はベストプラクティスと数値データという物差しを用いたことで、客観的な視点につながり、アーティファクト管理とデプロイ自動化、テスト自動化のベストプラクティスに開発メンバーが次々と改善点が出てきましたと。
通常業務もありますので、改善というのはアプローチしやすいところから実施するのが良いでしょうと。
このチームにとってテスト自動化というのは言語的ハードルもあり、チーム内で対応が難しいというような意見が多数あったため、まずアプローチしやすいアーティファクト管理から改善を始めましたと。
アーティファクト管理の全環境で同一のパッケージ、イメージ構成管理ができて利用しているとの質問に対し、本番環境での構成管理ができていたものの、全環境で統一の部分ができていませんでした。
プロダクトが成長を遂げる過程で増築していた新しい検証環境の構成管理が不十分だったのです。
これはよくある話ですね。
検証作業の度に変数を手作業で上書きしていて非効率的でした。
また、担当ごとにこの変数に関する知識にわらつきがあり、情報共有に時間がかかっていました。
そこで全ての環境変数をコードで管理できるように変えて、同一の構成管理に刷新しました。
つまり要はマンパワーとか人が手を介して更新していたってことですよね。
要は自動化できていなかった話なんですね。
その中でも高品質にデプロイできていたり、繰り開発ができていたって、そこはそこですごい話ですけどね。
でもそこを自動化できていなく、チーム内でもできていなかったのは結構びっくりです。
でもそれをちゃんとアンケートを取って見えるか言語化していたっていうのもまたいい話ですね。
次に全環境でデプロイ手順が同じである、デプロイは自動化されているというデプロイ自動化のプラクティスにも取り組みました。
本番へのデプロイ自動化はできていたんですけど、設模の中の全環境でデプロイ部分ができていませんでした。
ステージング環境や開発環境へのデプロイ自動化はできていないため、デプロイに不要な手作業が発生していました。
こちらもデプロイパイプラインというのを改良して全て自動化しました。
これら2つの設模に関して改善したことで、コミュニケーションロスや手作業のための設定ミスに悩まされているということだけでなく、すぐに目的の作業にも着手できるようになりました。
また時間が取られていた運用作業というのも効率的に変化していくことにより、リソースにも結構余裕が出てきました。
18:05
テスト自動化というのは未対応のまままだ残ってますけど、半年後には数値に変化が出てきたよということですね。
チェンジリードタイムが213時間から134時間へ改善しました。
デプロイフリーケンシーも0.66回から8回まで大きく改善しました。
これデカいですね。月8回って結構いいサイクルでデプロイできたんじゃないですかね。
この結果、半年間の改善アクションで下位クラスから上位クラスへとも移行できました。
効果が明確であるため改善に向けてエンジニアのモチベーションも上がり、ポジティブフィードバックがうまく回っている状態とも言えます。
開発効率が良くなったことで作業に余裕が出てきたので、今後は課題であったテスト自動化のために改善が進んでいくというのでここから手放したらしいですね。
開発生産性の向上というのは結構ダイエットにも似ています。
もし自分が太ったなと思えば体重を測って、歩数計をつけ、食事のカロリーを計測して、それで運動量の減少が原因だとわかればその部分を改善しようとするじゃないでしょうか。
開発生産性も同じです。まずスピードと品質を計測し、開発習慣を可視化すれば的確に改善点を見つけられ、生産性向上への成功へと導けます。
開発生産性におけるナレッジを全社に展開し、暗黙値から形式値へというのが次のセクションです。
Yahoo!には長年培われた開発に関する様々なナレッジが存在し、個々のサービスやプロダクトに留まっていて、暗黙値化しております。
この暗黙値というものは先ほど紹介したようなベストプラクティスのように明確な形式値とはなっておりません。
例えばベストプラクティスを実践するにあたり、テスト自動化をチームに普及させるにはどうすればいいのでしょうか。
また、作業サイズを小さくするにはどうすればいいのでしょうか。
その答えを他のチームが持っているとしたらどうでしょうか。
開発生産性を向上させるにはナレッジを再現可能なノウハウとして展開する必要もあります。
そこで私たちはナレッジマネジメントにも取り組んでいます。
個人やプロダクトが持つ暗黙値は共同化、表出化、連結化、そして内面化という4つのプロセスを経ることで組織全体の共通の知識になっていきます。
開発生産性におけるナレッジをこのプロセスを使ってYahoo全社にも展開しています。
具体的に各プロセスについて紹介していきます。
まず1つ目の共同化ですけれども、共同化とは日々の業務を通じて個人が持っている暗黙値を他人に共有できるようにすることになります。
数値の可視化や開発習慣に関するアンケートを全社に公開し、暗黙値を他人と共有できるようにしています。
2つ目に表出化ですね。
表出化とは暗黙値を言葉やチャートを用いて具体的に形に変えていくことですよと。
私たちは開発生産性が優れているチームへヒアリングをし、有料な事例を具体的な数値とデータ、方法としてまとめ、社内技術ドキュメントで紹介しております。
続いて3つ目が連結化ですね。
連結化とは形式化された知識またはデータをさらに結びつけ、最終的な形に落とし込むことになります。
21:01
開発プロセスに関する最終的な形式値として、社内技術ガイドラインにエンジニアの遵守事項として提示されています。
はいはい、いいですね。ガイドラインを作ってガイドラインをしっかり遵守するというような事項まで持っていくと。
最後内面化です。
内面化とはさっき言った連結化によって組織として形式化されたものを個人に取り込んでいくフェーズになります。
ここでは社内カンファレンスを活用しています。
開発生産性で成果を出しているプロダクトを社内カンファレンスで成功事例として紹介し、より身近に改善を感じてもらうことで開発現場に導入しやすくしていくと。
まずルール、そして形式値化、それを各チームでまず形から入っていって個人の中に落とし込んでいく。
その結果成果が出たチームを最終的に社内全体で表彰するみたいな感じですね。
これを会社全体でやっているという良いサイコロですね。いや素晴らしい。ヤフーさんみたいなでかい会社でやられているというのがかなり良いですね。
これら4つのプロセスを通してヤフーで培われている有料のナレッジの展開にも努めております。
開発現場におけるスピードと品質の両立は個人の力でなせるものではなく、チームや組織で相互理解をしながら取り組むことが大切です。
従来感覚的に語られていた開発生産性よりも具体的な数値で全員が共通理解できる状態として、組織文化として生産性が常に保たれる状態を作るということが大切だと感じております。
ヤフーには多種多様なサービスがあり、プロダクトはそれぞれのサービス業種及び業態特性を考えながら最適な開発習慣やプロセスを考えております。
そして作業が円滑にミスなく行われるようにCICDとか自動化の仕組み作りというのもしています。
さらに効率的な開発を実現することでお客様への価値あるサービスをスピーディーに提供し、そして安全に利用できるようにして取り組んでいきたいと思いますという言葉で締められておりました。
アーカイブ動画ですね。こちらの本記事のアーカイブ動画がyoutubeにも上がられていますので、この辺も見ていただくとより詳しく具体的になっていいんじゃないかと思いますので、後ほど見ていただければと思います。
トーキーズをうまいこと活用しつつも社内の文化にどう取り込んでいくかっていう具体例のお話までとても参考になったので、これぜひぜひ参考にさせていただきたいし、
社内でも、弊社の中でも生産性、なかなかまだ可視化できてるようでできてないし、文化として醸成できないので、ここは後半戦しっかり取り組んでいきたいなと僕らも思っていますというところで、
今日の朝勝ちはここで締めていきたいと思います。本日時間オーバーしている中、たくさんの方々で参加していただきありがとうございました。
ちょっと全員の皆さんの名前読んでいくと時間かかってしまいますので、ここでごめんなさい、切らせていただければと思います。
では今日から6月最終週ですね、上半期締めというところもありますので、今週頑張っていけたらなと思いますし、
また皆さんの方でですね、一度振り返りのいい時期でもありますので、上半期の締め、学生さんはまあ第一四半期の締めですけども、
しっかり自分の振り返りをしていただいて、また次のペースで頑張っていけたらなと思いますので、やってみていただければなと思います。
それじゃあ終了したいと思います。お疲れ様でした。
