
はじめに
このレポートは最高に充実した5日間の記録です。過去にないほど雰囲気の良いチーム開発、的確な質問をくださって建設的な議論を促してくださる講師陣とサポーター、自分自身の行動を思い返して次の行動を常々思考する5日間でした。
CARTA Sunrise の概要
2025年3/23~3/28 の 5 日間でで行われた、クラウド上の Web サーバのパフォーマンスチューニングのインターンです。
↓↓↓ より詳細なSunriseの説明はこちら ↓↓↓
終わってみて振り返ると
実装に対する考え方
学習したところ
-
どうやって問題を解決するのか、が大切ではない
- 以下の問いを持つのが大切
- なぜ問題なのか?(why)
- 何が問題なのか?(what)
- どうやって問題を解決するのか?(how)
- 以下の問いを持つのが大切
-
データに基づいて判断する
- そのデータはどこから取ってきたものなのかを明示する -参考にした記事の URL, メトリクスの画像, etc …
- データは信用できるのか?
- 何に裏付けされているのか?
振り返ってみて
最初はこの問いを建てる意識を具体的に持って開発に取り組むというのがなかなかできていなかったように思います。与えられた課題があったのでそれを達成したいという気持ちがどうしてもあり、素直に問題に立ち向かえていませんでした。しかし一度課題を達成するとその気持ちが解消され、私たちが実際に何をしたかったのかに今一度立ち返りました。そこでサービスが何を目的にしていたのかの認識をチームの中で擦り合わせて、それを達成しようと思う中で自分たちがどの場所にいるのかを共有でき、チームの目的を達成するために再出発できたと思います。
チーム開発
学習したところ
- ポジティブなフィードバックはチームの成果を向上させる
- 褒められると嬉しい
- 褒めると楽しい
- 積極的な話合いがチーム内での情報の認識のずれを無くす
- 遠慮なく話し合うと意思決定が楽になる
- 気になったことはすぐに質問して、分からないを無くす
- 作業している自分の状態をすぐに共有して、伝わっていないを無くす
- 遠慮なく話し合うと意思決定が楽になる
- issue, PR を早く見る(課題を共有する・Howの結果にフィードバックする周期を早くする)
- 途中からissueは話し合いの中で書いていたので、課題の共有という部分ではチーム内でほぼ時間の誤差なく伝達していた
- PRを早く見ると、その人はすぐに新しい課題を考察したり、次の作業にいち早く取り掛かれるので、メリットがめちゃめちゃ大きい
- それぞれが問題に向き合う意識があって、課題を見つけて、解決したいと取り組む姿勢が大切
- それぞれが自分の問題として取り組んでいると、私自身も肩に力が入るというか「しっかりやらないと!」という気持ちになる
- 指示を中心で出す人がいなくてもチームが回るので、チームとして課題に取り組める時間が増える
振り返ってみて
今回のチーム開発は過去にないくらいのいい雰囲気で行えていて、なかよしでおだやかだったと思います。それにはやっぱり、それぞれが話す姿勢であったり、ポジティブなフィードバックが盛んだったり、質問や現状の報告が常に行える状態があったからだと考えています。他のチームメンバーがチームに対してどのように接するのかを見て、どんどん取り入れていこうという気持ちで、ポジティブなフィードバックを行えたのが良かったのだと思います。これからチームで何かをするときにはもっと積極的に褒め合って、信頼し合えるようにしていきたいと思いました。またPRやissueを放置せずになるべく早く見て、無駄な時間が生まれないようにしていくのも重要であると感じました。
Go による実装
学習したところ
- goroutineとchannelによるHTTPクリエストを横断した処理
- そのような処理が可能であるのを知らなかった
- そもそもHTTPリクエストの度に新しいgoroutineが走っているのも知らなかった
- そのような処理が可能であるのを知らなかった
- メソッドチェーンの実装の仕方
- ライブラリなどで実装されているので、これまでも使う機会はあったが、実装した機会はなかった
振り返ってみて
Go言語の最低限は理解しているだろうと思っていたのですが、ほんとうに他の言語でも同様にできる部分しか理解していなかったのだと感じました。チームに私よりもGoの書ける方、バックエンドの実装に知見のある方がいたので、その人たちと壁打ちできたので、開発の手が止まらずに次へ次へと実装がスムーズに行えたように思えます。
メトリクスの監視
学習したところ
- AWS の CloudWatch によるメトリクスの見方
- 何を判断の材料として用いるのか
- なぜそれを判断の材料として用いるのか
振り返ってみて
最初はそもそも何の情報が集まるのか、何の情報があれば判断が可能になるのかが全く分からず、その中で自分にできることを考えていました。なので情報を集めてくる中でそれが何を示しているのかを考えるのを意識していました。データがある程度見えるようになって、ツールの使い方がわかるようになってからは、講師の方が出すAWSのワードを拾って、メトリクスとしてどのように見えるのかを中心に分析できていたのが良かったかなと思います。
他の人に見てもらうためのissueの残し方
学習したところ
- 見るべき情報を見える場所に置く
- 関係のあるテーマで集合させる
- 比較するデータの対照関係を明確にする
振り返ってみて
個人的にはこの部分がチームの中で自分の能力として一番優れていたと感じました。なので積極的に自信を持って取り組めたかなと思います。他のメンバーが私の書いたissueからまとめ方や、Markdownの使い方を吸収してくれたみたいなので、チームに還元できたのが嬉しいです。他のチームの発表を見る中で、やはり私のいるチームの発表は見やすいものにしたい気持ちがあった。ただ途中開発と検証に手一杯のときがあり、その部分にコミットできなかったのですが、チームメンバーが補填をしてくれて、わかりやすくまとめてくれたのがとても嬉しかったです。
ただ終わってからグラフ化は完全にいい選択肢ではなかったかもしれないと少し思いました。生データから抽出されたデータには製作者の意図が介在するので、公平性に欠ける部分があります。ただ今回の発表ではそのような意図を持ってはいなかったのですが、生データに比べて情報が欠損しているのは確かなので、気をつける必要があると考えました。
不足していたところ
-
ギリギリを攻めない開発をしていた
- インスタンスを建てる数によってボトルネックになる可能性があった
- ボトルネックとなったときに予期せぬ状態にならないように、常時インスタンス数に余裕を持たせて意図的に失敗を避けえうように立ち回っていた
- これは実際に起こりうるエラーの検証を避けているとも取れるのではないか?
- それでは実際にサービスが正しくない状態になったときに、どういう状態になってしまうのかが想像できないのでは?
- これは実際に起こりうるエラーの検証を避けているとも取れるのではないか?
- ボトルネックとなったときに予期せぬ状態にならないように、常時インスタンス数に余裕を持たせて意図的に失敗を避けえうように立ち回っていた
- インスタンスを建てる数によってボトルネックになる可能性があった
-
データの分析
- 今回は時間がそもそもなかったので、統計的に分析できるまで複数回データを取得するようにはできなかった
- しかし、逆に一回の測定を信じすぎていた部分もあった
- 本来であればもっと、入念に何度も調べる必要があった
- ただそうした中で実際に何が信じられるのか、というのを判断するための統計的な知識が不足していると感じた
- 本来であればもっと、入念に何度も調べる必要があった
- しかし、逆に一回の測定を信じすぎていた部分もあった
- 今回は時間がそもそもなかったので、統計的に分析できるまで複数回データを取得するようにはできなかった
その他の部分
- DevOps(CI/CD)
- チームメンバーにお願いしていた
- メンバーが個人的に積極的にやるべきタスクだと認識して行動を行っていたのでおまかせしたかった
- 信頼して任せたのが良かった
- メンバーが個人的に積極的にやるべきタスクだと認識して行動を行っていたのでおまかせしたかった
- チームメンバーにお願いしていた
総括的なまとめ
今回のインターンの中で感じたのは、チームの良い雰囲気は成果に良い影響を与えるということです。話し合いができて、意見が出て、質問ができて、行ったことに対してポジティブなフィードバックがもらえる環境がどれだけ、課題に取り組みやすいかというのを実感しました。成果を出すのは作業ではなく、人間なんだと感じました。
また技術的にもこれまで中心的に触れてきたフロントエンドやXRアプリ開発の部分とはだいぶかけ離れた領域だったので、AWS(クラウド)を中心に分からないことだらけでしたが、その分吸収できる事柄が多かったと感じています。学生のうちにこうして自由にAWSを触ってやらせてくれる環境があるというのが本当にありがたいです。
それに加えて、現状あるデータや検証結果から、次に問題となるものを考えて、その問題を切り分けて、仮説を立てて、検証を行い、判断を行うというサイクルがとても取り組みやすいと感じました。現状自分が何のために行動しているのかに迷う時間が減らせて、現状のタスク確認のために、過去の決定を振り返る量が減るので取り組みやすかったです。またこのフローの進め方が研究活動に似ていると感じて、この一年の自分自身の成長を感じられたもの嬉しかったポイントでした。
チームでの話し合いを重ねると意思決定の速度が早くなって、議論の内容も深くなっていって、そうしてサイクルを重ねていくのが楽しい経験でした。
最後に
私たちのチームはUNISONというチーム名を掲げていて、UNISONには同音を奏でる複数の楽器が同じ旋律を同時に奏でるという意味がありました。そのチーム名の通りにそれぞれがそれぞれの良さを引き出して、課題を見つけてアプローチを行い、Sunriseのとりあえずの目標とチームの目標が達成できたのが嬉しかったです!
UNISON:〈一つの音〉の意味であり,同音で構成される音程を指す。複数の楽器(楽器群)または声部が,同じ音符あるいは旋律を同時に奏すること。 コトバンク
これからもこのSunriseで出会った仲間との繋がりを大切にしていけたら嬉しいなと思います。
Sunrise 写真たち
美味しかった焼肉弁当

Gardenのカフェオレ

最終日の懇親会
