AWS Summit Tokyo 2023:セッション、探索、そしてインサイトに満ちた冒険

こんにちは、BaseconnectのエンジニアのEndratno Alvinです!今回、AWS Summit Tokyo 2023に参加してきたので、体験したことや学んだこと、気づいたことを記事にしたいと思います。

背景 - AWS Summit Tokyo 2023に参加を決めた理由

私はR&Dエンジニアとして、クライアントの方にインサイトを提供し、大量のデータを処理できるデータプラットフォームを構築するために、チームと一緒に取り組んでいます。私たちは、様々なクラウドコンピューティングソリューションを探求しており、AWSさんは常にこの分野のトップと信じています。

ですから、AWS Summit Tokyoイベントについて聞いたとき、私は参加したいと思いました。AWSさんのサービスやツールについてできるだけ多くの情報を集め、より信頼できてスケーラブルなプラットフォームを構築するためのヒントを得たかったのです。

しかし、私がこのイベントに参加する理由は純粋に仕事だけではありませんでした。私はAWSさんの大ファンであり、最新の開発や革新についてもっと学びたいと思っていました。そしてもちろん、このイベントを業界の他のプロフェッショナルとネットワークする絶好の機会と見なし、新しいつながりを作ることができる可能性があると考えていました。

As a Research and Development Engineer at Baseconnect, my team is working to build a data platform that can handle large volumes of data and provide insights to our clients. We've been exploring various cloud computing solutions, and AWS has always stood out as a leader in the field.

So when I heard about the AWS Summit Tokyo event, I knew I had to attend. I wanted to gather as much information as possible about AWS services and tools that could help us build a more robust and scalable platform.

But my reasons for attending the event weren't purely professional - as a big fan of AWS, I was also excited to learn more about the latest developments and innovations in the field. And of course, I saw the event as a great opportunity to network with other professionals in the industry and potentially make some new connections.

AWS Summit Tokyoについての簡単な説明

AWS Summit Tokyoは、Amazon Web ServicesAWS)さんが主催する年次イベントで、クラウドコンピューティング、AI、機械学習、サーバーレスアーキテクチャなど、最新の技術動向について、ユーザーやパートナー、専門家が集まって学ぶ場です。

今年のイベントは、COVID-19後、初めてのオフラインサミットであり、前回のAWS Summit Tokyoから4年がたちました。イベントには基調講演、ブレイクアウトセッション、ハンズオンラボ、パートナーエキスポ、そしてCertified LoungeやDeepRacerなどの特別エリアがあります。

AWS Summit Tokyo 2023の最初のセッションの写真

AWS Summit Tokyoは、業界のプロフェッショナルが学び、ネットワークを構築し、自分たちの経験や専門知識を共有する絶好の機会を提供してくれます。

The AWS Summit Tokyo is an annual event hosted by Amazon Web Services (AWS), bringing together users, partners, and experts to learn about the latest developments in cloud computing, AI, machine learning, serverless architecture, and more. ​ This year's offline event was the first summit after COVID-19 and marked four years since the last AWS Summit Tokyo. The event included a keynote address, breakout sessions, hands-on labs, partner expo, and special areas like the Certified Lounge and DeepRacer.

The AWS Summit Tokyo provides a great opportunity for professionals in the industry to learn, network, and share their experiences and expertise.

セッション

AWS Summit Tokyoでは、クラウドコンピューティング、AI/ML、サーバーレスアーキテクチャなど、様々なトピックをカバーした10のセッションに参加する機会を得ました。

AWS Summit Tokyo 2023で発表されたセッションの写真

以下は、私がイベントで特に印象に残ったトップ3のセッションです。

  1. 今踏み出す、変革への一歩

AWSジャパンのCEOによって最初に行われました。彼はAWSが日本で成長し、様々な企業や政府機関に対してどのように支援してきたかについて共有して下さいました。また、AIスタートアップやAmazonが提供する幅広いモデルから選択肢を選ぶ柔軟性を提供する新しいサービスであるAmazon Bedrockが発表されました。利用できるようになったら、ぜひ私も試してみたいと思っています。

  1. AWS の徹底活用で ”守りの IT” から ”攻めの IT” そして "DX” へ

日本気象株式会社からの代表者によって行われました。オンプレミスシステムに直面した会社が直面した課題や、クラウドの採用に重点を置くこと、エンジニアのトレーニングとAWS認定報酬の提供、そしてAWSさんに助けを求めることで、克服した方法について説明して下さいました。最終的に、クラウドを成功裏に活用するだけでなく、短期間でサーバーレス技術を使用したアプリを構築することにも成功されています。

  1. Java on Lambda のコールドスタートを乗り越える、これからのサーバーレスアプリケーション

AWS LambdaでJavaを使用する際のコールドスタート問題を乗り越えるためのヒントやベストプラクティスについての話でした。サーバーレスアプリケーションを実行する際に、アプリケーションのパフォーマンスを向上させ、レイテンシを低減する方法についてインサイトを説明して下さいました。

During the AWS Summit Tokyo, I had the opportunity to attend 10 different sessions covering a range of topics in cloud computing, AI/ML, and serverless architecture. ​ Here are my top three sessions from the event:

  1. 今踏み出す、変革への一歩: This was the first session of the event and was presented by the CEO of AWS Japan. He shared how AWS has grown in Japan and helped many companies and government organizations in various ways. He also announced a new service called Amazon Bedrock, which provides flexibility to choose from a wide range of models built by leading AI startups and Amazon to find the model best suited for your needs. I'm excited to try it out once it becomes available.

  2. AWS の徹底活用で ”守りの IT” から ”攻めの IT” そして "DX” へ。: This session was presented by a representative from Nippon Kasei, a weather forecasting company. He discussed the challenges the company faced with on-premises systems and how they overcame it by doubling down on cloud adoption, providing training and certification rewards for engineers, and getting AWS to help them grow. In the end, they not only successfully utilized the cloud, but also built an app with serverless technology in a short timeframe.

  3. Java on Lambda のコールドスタートを乗り越える、これからのサーバーレスアプリケーション: This session covered tips and best practices for overcoming the cold start problem when using Java on AWS Lambda. The speaker provided insights on how to improve application performance and reduce latency when running serverless applications.

ブース

スポンサーブース

AWS Summit Tokyoでは、AWSさんと他の企業とのさまざまなブースが展開されました。私はデータプラットフォームに興味があるため、既存のデータウェアハウスにデータを統合し、AI/MLの目的に活用するためのツールを探していました。残念ながら、ブースで提供されているサービスのほとんどは、DevOps、セキュリティ、コンサルティングサービスなどのトピックに焦点を当てており、私のユースケースに関連するものはあまりありませんでした。

At the AWS Summit Tokyo, there were a variety of booths from both AWS and other companies. As someone interested in data platforms, I was specifically looking for a tool that could help integrate data into our existing data warehouse and utilize the data for AI/ML purposes. Unfortunately, most of the services available at the booths focused on topics like DevOps, security, and consulting services, with only a few being relevant to my use case.

AWS Summit Tokyo 2023におけるアイレット株式会社さまのブースの様子

AWSブース

運がいいことに、AWSブースで価値ある情報を見つけることができました。まず、カスタマーサービス代表として機能するボットを作成することを希望していることを専門家の方に相談してみたところ、Amazon KendraとAmazon Lexという2つのサービスを紹介してもらい、実験してみたいと思っています。

2つ目に、AWSパートナーになることの利点について知れました。さらに調べた結果、私たちの会社がAWSさんの専門知識やサービスを活用してビジネスを拡大するための素晴らしい機会になると考えています。

AWS Summit Tokyoでは、AWSさんによって特別なスタンドが設置され、参加者にユニークでインタラクティブな体験を提供しました。残念ながら、参加者の方とのネットワーキングは思ったほどできませんでしたが、これらのエリアを探索するのはとても楽しかったです。私が注目したいくつかのものを紹介します。

私がAWS Certified Loungeの前で3つのステッカーを持っている写真

  1. Certified Lounge: AWS認定プロフェッショナル専用のエリアでした。参加者は、認定レベルに応じたステッカーを受け取ることができました。私はAWSの認定資格を6つ持っているので、すべてのステッカーがもうすでになくなってしまったことに少しがっかりしました。

  2. AWS JAM: パズルを解いたりチャレンジをクリアすることを目的としたチーム対抗のゲームでした。他の参加者が参加する様子を見る機会があり、楽しみながら学び、他の参加者とのネットワーキングができる良い機会のように思えました。

  3. AWS DeepRacer: AWS DeepRacerは、AIモデルを構築して、他の参加者のモデルと競争するハンズオンアクティビティでした。私自身はモデルを構築する機会はありませんでしたが、他の人たちがモデルを構築し、競争する様子を見るのはとても興味深かったです。

AWS Summit TokyoにおけるAWS DeepRacer

AWS Summit Tokyoを通じて、楽しくインタラクティブな方法でAWSサービスやテクノロジーと関わるユニークな機会を得ることができました。ネットワーキングは、特に大規模なイベントやカンファレンスの場合は難しい場合がありますが、私はこのイベントから貴重なインサイトと経験を得ることができました。

Fortunately, I found valuable information at the AWS Booth. First, I spoke with an expert about our desire to create a bot to act as a customer service representative, and they introduced me to Amazon Kendra and Amazon Lex, two services that I am eager to experiment with.

Second, I learned about the benefits of becoming an AWS partner. After researching it further, I believe that proposing this to my manager could be a great opportunity for our company to leverage AWS expertise and services to grow our business.

At the AWS Summit Tokyo, several special stands were set up by AWS, providing attendees with unique and interactive experiences. Unfortunately, I didn't get to network with other attendees as much as I had hoped, but I still had a great time exploring these areas. Here are a few that caught my attention:

  1. Certified Lounge: The Certified Lounge was an area exclusively for AWS-certified professionals. Attendees could receive stickers according to their certification level. As someone with six AWS certifications, I was disappointed to learn that they had run out of stickers for some of the certification levels, and I only received three stickers.

  2. AWS JAM: AWS JAM was a team-based game that involved solving puzzles and completing challenges. I had the opportunity to watch others participate, and it seemed like a great opportunity to network with other attendees while having fun and learning. ​

  3. AWS DeepRacer: AWS DeepRacer was a hands-on activity that involved building an AI model and racing it against other attendees' models. I didn't have the chance to build a model myself, but it was fascinating to watch others build their models and compete against each other.

AWS Summit Tokyo provided a unique opportunity to engage with AWS services and technologies in a fun and interactive way. While networking can be challenging, especially in larger events like conferences, I still gained valuable insights and experiences from the event.

最終的な感想

AWS Summit Tokyoに参加することは素晴らしい経験でした。異なる業界や多くのエンジニアやプロフェッショナルがAWSサービスやテクノロジーについて学ぶために集まる様子は素晴らしかったです。イベントは活気に満ち、多数の企業が自社のサービスや製品を展示していました。

AWS Summit Tokyo 2023会場で記念撮影

AWSさんは本当に大規模な企業であり、彼らの運営の規模や提供する多岐にわたるサービスの幅を見ることは印象的でした。多くの方が参加されており、とても楽しく、情報もたくさん得られるイベントでした。

私がAWS Summit Tokyoから得た重要なことは、Amazon Bedrockを使ってAI/MLモデルの柔軟性を理解すること、そしてカスタマーサービスボットを作成するためのAmazon KendraとAmazon Lexの可能性を探求することでした。

まとめると、AWS Summit Tokyoはクラウドコンピューティング機械学習などの最新のイノベーションやトレンドについて学ぶ絶好の機会でした。この経験に感謝し、今後もこのようなイベントに参加することを楽しみにしています。

Attending the AWS Summit Tokyo was a fantastic experience. It was amazing to see so many engineers and professionals from different industries and backgrounds come together to learn about AWS services and technologies. The event was bustling with activity, and there were numerous companies showcasing their services and products.

AWS is a truly massive company, and it was impressive to see the scale of their operations and the wide range of services they offer. Despite the crowds (which can be overwhelming for some, including myself), the event was incredibly fun and informative.

My key takeaways from the AWS Summit Tokyo include understanding the potential of Amazon Bedrock for AI/ML model flexibility, learning how AWS services helped companies like Nippon Kasei overcome on-premises limitations, and exploring the possibilities of Amazon Kendra and Amazon Lex for creating a customer service bot.

In conclusion, the AWS Summit Tokyo was a great opportunity to learn about the latest innovations and trends in cloud computing, machine learning, and more. I'm grateful for the experience and look forward to attending more events like this in the future.

A Visitor's Guide: What to Expect at an AWS Summit

Hi, I am Endratno Alvin, an engineer at Baseconnect! I attended the AWS Summit this year and would like to share with you an overview of the event.

Attending AWS Summit Tokyo 2023 was an unforgettable and immersive experience. This premier event, hosted by Amazon Web Services, offers a unique opportunity to connect with like-minded professionals, expand your knowledge, and discover the latest innovations in the cloud industry. In this blog post, I will share my personal insights on what you can expect at an AWS Summit, based on my time at the Tokyo event.

Warm Welcome and Registration

Upon entering the building, I was greeted by numerous friendly staff members who guided me to the reception area. I received my name tag, which was essential for navigating the event and understanding the roles of others. At AWS Summit Tokyo 2023, the name tag colors indicated: black for visitors, white for staff, orange for AWS members, and green for sponsors.

Event Content: Sessions, Booths, and Special Events

The AWS Summit was a treasure trove of informative sessions, interactive booths, and unique special events that catered to a diverse audience. From tech-savvy professionals to industry newcomers, there was something for everyone.

Key Sessions

The event kicked off with the key sessions, which featured high-profile speakers such as CEOs and government officials sharing their vision for the future of cloud technology. With a runtime of 90 minutes, these sessions were offered in two languages and streamed online for those who couldn't attend in person. A DJ filled the venue with lively music, setting an energetic tone for the day ahead.

Case Study Sessions

Case study sessions provided real-world examples of how companies were using AWS to transform their businesses. These insightful presentations included in-depth discussions from company representatives and high-level architecture overviews, enabling attendees to understand the practical applications of AWS services.

AWS Sessions

These informative sessions, led by AWS employees, focused on the strengths and benefits of AWS services and how they could be used to solve various business challenges. I found these sessions particularly helpful in deepening my understanding of AWS. They also used a unique silent presentation format, which allowed attendees to listen to their chosen presentation using receivers. Below is photo of join stage and receiver.

Booths: AWS and Sponsor Booths

Booths were divided into two main types: AWS booths and sponsor booths. Each booth provided an engaging and interactive experience that brought AWS services and partner solutions to life.

AWS Booths

At the AWS booths, I witnessed firsthand how AWS services were being used in specific sectors. I saw demonstrations of AWS Amplify being used to create an MVP and AWS QuickSight being used to quickly create a dashboard. The knowledgeable AWS employees were eager to answer any questions and even followed up with an email the next day if I wanted to learn more.

Sponsor booths showcased cutting-edge technology and services from various companies. This was an excellent opportunity to explore potential solutions for my company, discuss my requirements with industry experts, and even collect some fun swag!

Other AWS Booths: Special Experiences

In addition to the technology and information-related booths, AWS also presented some unique experiences that I would call "Special Booths."

The first one was AWS DeepRacer, where visitors could build a machine learning model and integrate it into a small autonomous car (I have no idea how that works either!). The car then raced around a track, competing for the fastest lap time. The winners received special merchandise as a reward for their achievement.

Another engaging experience was AWS Jam, a team-based game that involved solving puzzles and completing challenges related to AWS services. I had the opportunity to watch others participate, and it seemed like a fantastic opportunity to network with other attendees while having fun and learning about AWS in a hands-on environment.

Conclusion

AWS Summit Tokyo 2023 was a whirlwind of learning, networking, and inspiration. Whether you're a cloud enthusiast, an AWS expert, or exploring potential solutions for your company, attending an AWS Summit is a must. The event offers a diverse range of sessions, booths, and special events, ensuring that there's something for everyone. So, if you ever have the chance to attend an AWS Summit, don't hesitate—dive in and experience the future of cloud technology!

リモートモブワークをやってみてます

プロダクト開発チームの富田です!

現在、15時頃から「モブワーク」時間を2時間、毎日確保しています。

元々、この時間はフロントエンドの引き継ぎをすることになり、学習のために始めました。

このモブプロの体験がとても良く、TDDもこの時間に経験することができました。 TDDに関しては、同じチームの御園さんが「TDDをやってみた感想」という記事でまとめてくれています。

この後、他の作業もモブプロ(モブワーク)でやり始めました。

いつもはリモートでやっていて、月1回の飲み会の日はオフラインで開催しています。

オフライン開催時のモブプロの風景

使っているツール

エディタ

Visual Studio CodeLiveShare機能を使っています。 各個人環境で動かす事ができるのと、Driverがどのコードを見ているのかすぐに分かるのが良いです!

また、ターミナルを共有出来るのも地味に重要です。 CLIの各種ツールは開発に必須なので、同じ環境で作業で出来ることは心強いです。

タイマー

タイマーは↓のような機能が欲しい感じです。

  • slackで知らせて欲しい
  • Driverが変わる時に通知して欲しい。変わる前に予告の通知も欲しい。
  • 時間や参加者を柔軟に変えることができる

結局、良いツールが見つからず自家製を使っています。雑な作りですが、必要十分です。

どんな作業をやっているか?

例えば、↓のようなものです。

  • 属人化しがちな作業
    • インフラ(AWS)の設定・構築
    • フロントエンド
  • 複雑な処理のレビュー
  • DBからのデータ出力対応

特にフロントエンドを変更する場合は、モブでやることが多いです。 現在のメンバーは全員フロントに強くないので…

全部モブ?一部だけ?

モブで行う作業は、一部だけです。 毎週月曜のスプリントプランニング時に、どのタスクをモブワークでやるか相談します。 モブ向きの作業が無い場合は、無理して開催していません。

調査作業等、一人で対応した方が効率が良さそうなことは、モブではやっていません。 フルでモブプロやっている会社もあると聞きますが、どんな風にやっているでしょうか、、、気になります。

やってみた感想

属人化しがちだったタスクをシェアすることで、暗黙知を潰せていることが出来ているかなと思います。

また、各メンバーの技術の底上げや、コーディングスタイルを共有することで良い刺激になっていると思います。「そんな書き方があったのか!」と驚くこともシバシバです。

今後も、このモブの時間を継続していくことが出来れば、と思います!

TDDをやってみた感想を物語風に書いてみた

こんにちは、Baseconnectエンジニアの御園です。 最強寒波の時「気温がunsigned intになってくれない」とか「冷たいからrangeでチンする」とか色々と思いついたのですが、どこに吐き出すでもなく一人ほくそ笑んでいたおもしろ系エンジニアです。 別にそんな事はどうでもよく、そもそもTDDとは何か?について、そしてやってみた感想を記事にしてみたいと思います。

introduction

例えば貴方が学校に通っているとして、今にも遅刻しそうだとします。 すると当然のことながら大半の人は走って間に合おうとするでしょう。(少数の人は諦めて開き直り、歩くかもしれません。そのような人々はExceptionです。)

その時、食パンを加えた美少女が角から飛び出してきたら貴方はなすすべもなく衝突してしまうでしょう。 そして美少女に文句をつけられ、結局遅刻し、散々な目に合うかもしれません。

その後、学級ではどこからともなくリークされた転校生の話題でfullですが、貴方は脳RAMをそんなものに割く余裕もなく、今朝の事でムカついてしまい、うまくGCする余裕もありません。

やがて訪れた朝の学級会で、担任の先生が転校生を紹介した時、その転校生は今朝貴方とシノニムを起こしたばかりの美少女で、お互いに指を指し合って「あの時の!!!」となり、そこから青春のストーリーがプロセススタート……

おっと、ブラウザバックするのはまだ早いです。 OK、ゆっくり、まずはコーヒーでも一杯飲みながら、続きを読んでみて見ください。 読者の”あなた”が読んでいるのは、「TDDをやってみた感想」という題名のブログ記事で間違いありません。

このイントロダクションのような出会いを、実際に目にしたこと、あるいは経験したことがあるでしょうか? もしそのような事がexistsな方々は、幸運としか言いようがありません。

残念ながら私はありません。というか普通の人はないと信じたいです。たいてい、ドラマか、アニメの中の話でしょう(最も、最近はそんな王道展開の物語も少ないかもしれませんが)。

筆者、御園とTDDとの出会いは、まさに上記のような感じでした。TDDという言葉はやんわりと聞いたことがあったのです。日本語訳が「テスト駆動開発」というのもなんとなく知っていた程度ですが、本当にその程度の知識です。

しかし実際にTDDに触れ、TDDを知り、そして実践していく中で、その出会いは確実にまさに衝撃と呼べるものでした。少し誇張していて興奮気味ですし、読者の中には「おいおいそれは言いすぎだぜ」と思う人もいるかも知れません。

これからの文章は、あくまで筆者の感想として捉えていただき、しかしながら生暖かい目で見守っていただき、それでいてTDDへの理解が少しでも深まれば幸いと思って書くことにしますので、アイスブレイク的にゆっくりと楽しんでいただければと思います。

TDDの導入

冒頭のストーリーを思い出しましょう。 今度は貴方はそのストーリーの主人公ではなく、ストーリーの実装者です。 簡単な、ゲームのようなものを作ると考えてみてください。 ストーリーを完成させるには、まず主人公は学校に遅刻しており、そして間に合わせるために走らなければなりません。 擬似コードを書いてみます。

main_character.set_state('遅刻')
main_character.run

なんとなくRubyチックに書いてみましたが、あくまで擬似コードなのでそこまで気にしなくて良いです。 さて、ここでストーリーを完成させるための冒頭を開始したわけですが、実際には上記のコードが上手く動いているかを確かめる必要があります。 つまり”テスト”を書くということです。 簡単に書くならばこんな感じでしょうか。

expect(main_character.get_state()).to eq('遅刻')
expect(main_character).to receive(:run)

主人公の状態が遅刻になっているかと、”走る”が呼び出されているかを確認しました。

さて、通常の開発フローであれば何も違和感がないように思えます。 ですが、今回の主題はTDDでした。

Test-Driven Development

つまり、テスト駆動開発は、その名の通りテストを主軸に置いた開発を行います。 TDDにおいて、開発の一番最初に行うのは、テストを書くことであり、もっと言えばそのテストが落ちることを確認します。 先程の例を基にしてみましょう。

expect(main_character.get_state()).to eq('遅刻')
expect(main_character).to receive(:run)

TDDにおいては、一番最初に書くべきコードはこれであり、そしてこのテストが落ちることを確認します。 実装が何もなければこのテストが落ちることは自明です。 テストが落ちることを確認したなら、次にやるべきことは「このテストを通すこと」です。 ここで面白いことが起きます。このあと、同じように

main_character.set_state('遅刻')
main_character.run

と実装を進めていくわけですが、その目的が「テストを通すこと」にTDDでは成り代わっていることに気づいたでしょうか?

もちろん「遅刻していて、走り出す」という実装をすることには間違いないのですが、TDDではない最初のやり方だと、

・「遅刻している」「走る」を実装する

・それらの実装があっているかを確認する

の順序になっていたのに対し、

TDDでは

・「遅刻している」状態をテストする。落ちることを確認する。

・「走る」が呼ばれているかテストする。落ちることを確認する。

・テストが通るようにする。(「遅刻している状態にする」を実装する、「走る」を実装する)

と、最終的な実装は「テストが通るようにする」ところからスタートするのです。 ここにTDDの妙が詰まっています。

保証されたリファクタリング

TDDでは、「まずテストを通すこと」を一番大事にします。そのため、”綺麗にコードを書く”事は一旦意識しなくて良いのです。 例を見てみましょう。例えば、先程のテストを持ってきてみます。主人公が遅刻しているということを確認するテストです。

main_character = MainCharacter.new
expect(main_character.get_state()).to eq('遅刻')

このテストを通すために、最低限どのようなことをすればよいでしょうか?

シンプルに考えることが大事です。 それはつまり、

・MainCharacterクラスに遅刻を返す get_state メソッドがあれば良い

という事に他ならず

class MainCharacter
    def get_state
        return '遅刻'
    end
end

という実装をすればよいのです。ちょっと待って……。貴方が言いたいことはわかります。 普通の精神をしてたらこんなコードは書かないです。

でも、TDDではある意味”これが正解”なのです。 なぜなら、「テストが通るようにする」という目的はこの実装で達成されるのですから。

では、何が気に入らないのでしょう?

・get_stateで遅刻しか返らない。本来なら他のいろいろな状態を保持するようにしたいはず。

当然の疑問です。それは正解です。ではそのように少しコードを変えてみましょう。

class MainCharacter
    def initialize
        @state = '普通'
    end
    def set_state(state)
        return @state = state
    end
    def get_state
        return @state
    end
end

MainCharacterクラスがインスタンス変数 @state を持ち、これによって様々な状態を保持するようになりました。セットするための set_state 関数も実装されています。

さて、先程のテストは通るでしょうか?

main_character = MainCharacter.new
expect(main_character.get_state()).to eq('遅刻')

当然、落ちます。 なぜなら主人公を遅刻させるための set_state が呼ばれていません。 このテストに set_stateを使う必要があるようです。

main_character = MainCharacter.new
main_character.set_state('遅刻')
expect(main_character.get_state()).to eq('遅刻')

テストが再び通るようになりました。

ここで示したのは極端な例ですが、TDDを行う時は「まずテストを通るようにする」という事が大事です。 そしてその先にリファクタリングがあるのです。

そしてそのリファクタリングも、最終的には「テストを通すようにする」に帰結しています。 テストが通ることは、コードの変更前と変更後で、期待する結果が得られていることの保証になり、心理的に開発者を安心させることになるのです。

  1. テストを書く
  2. テストが落ちることを確認する
  3. ”取り敢えず”テストを通るようにする
  4. 3.で生まれたリファクタリングポイントを解消していく
  5. テストがすべて通るようにしておく

これが私が実際に体験したTDDのポイントです。リファクタリングはあとなので、例えばテストのファイル単一に全ての実装コードを書くこともあります。 本来なら実装段階でいくつかのファイルに分けて綺麗に書きたいところですが、TDDでは単一のファイルに書いてから、後で外側のファイルに吐き出す。という事をしました。

動作はテストが保証してくれます。 リファクタリングしたいな、と思うメモの項目一つ一つを解決していく際に、テストが通るという保証が付き添ってくれるので、安心しながらリファクタリングをすすめることが出来るのです。

そして、実装を変更したいときも、テストがついていれば「テストを通るように」すればよく、常に私達は目的を見失う事なくコーディングが出来るというわけです。

放課後(ただの感想)

TDDを体験した時、私が一番の衝撃を受けたのが、”リファクタリングが後”という事でした。 (殆どの人がそうだと私は信じていますが)私はコードを書く時に「いかに綺麗に、保守しやすく、他の人が読みやすいコード」を意識しています。

だからクラスは別ファイルに階層を意識して書くし、テストも通常別ファイルです。 ですが、私のチームで実践したTDDでは、テストのファイルに実装も一気に書いてしまい、テストが完全に通るようになってから、ちゃんとしたファイルに書き出す(私にTDDを教えてくれたメンバーはこれを"extract"と表現していました)事をしています。

なんて原始的で、でも着実なんだろう。と思いました。

プログラミングを学びたての頃は、単一のファイルに数百行以上のコードを書くなんてことはありましたが、クラスやモジュール、名前空間などのファイル毎に分けるようなテクニックを学んでからは、ほとんど単一のファイルに大量のコードを書くことなんてありませんでした。

ですが、TDDではそれがありえてしまうのです。

一旦全て実装を書ききってしまい、テストが動くという保証を基に、適切な位置にコードを配置していく。 バグはテストが動かないということそのもので見つかる、なんて素敵なんでしょう。

ここまで感想を述べると、まるで私がTDDの事を完璧に思ってるように見えます。 ですが、不満もあります。いくつか見ていきましょう。

  • 開発時間は多くなる

先程示したとおり、非常に小さなステップもテストとともに進んでいくので、開発時間はどんどん多くなっていきます。

完璧なプログラマなら最初からリファクタリング済みの完璧なコードをかけるような時間に対して、TDDは”着実に”進んでいくので、どうしてもコードを書く時間は伸びるのです。

  • 正しいテストかどうか、テストを書く人(見る人)に委ねられる

それが求めている仕様を表すのに本当に正しいテストかどうかは、よく吟味しなければなりません。 やもすれば、全然意図しない間違ったテストを基に実装してしまうことは、開発そのものを破綻させてしまいます。

本当に正しいテストかどうか、テストの質はどうか、そもそもテストを設計しにくい仕様だと長いテストを書いてしまわないか…… テストが正しいということを前提にした開発は、テストがそもそもちゃんとしていなければならないのです。

それはどうやって保証していけばいいのでしょうか。

私のチームではあまりそういった事はなかったのですが、例えば仕様変更などによるテストのメンテナンスコストなども、話には聞きます。 仕様変更に追従してテストを大幅に、やもすれば1から書き直さなくてはいけない。 後からテストを書くケースに対して、この場合はテストも実装もまるごと変わっていくので、大変なのは想像に難くないでしょう。

よければ、TDDを教えてくれたメンバーの記事もご覧下さい! techblog.baseconnect.in

Outro

さて、いかがだったでしょうか? TDDとはどういうものなのか、そしてそれに関して私が感じたことを少しでも共有できたなら幸いです。 一つ言えることは、TDDを導入したからといって、遅刻した時に曲がり角で美少女と運命的なシノニムを起こすということはないということです。ですが、それを補って余りあるTDDの恩恵があることは確かなので、試験的に導入してみてもい良いのではないでしょうか?

Baseconnectでは美少女と出会う時のように、新しい技術に出会った時に運命的なドキドキを感じるエンジニアを募集しています。 興味が湧いた方は、テストケースを握りしめて以下の採用ページを覗いてみましょう。

https://herp.careers/v1/baseconnect/requisition-groups/9607685a-4d6c-4b90-9f44-ac654b11d986

herp.careers

RSGT2023に初参加しました!

はじめに

こんにちは、開発部門で採用や組織改善に携わっている寺尾です!

今回1/11~1/13の3日間にわたって開催された、スクラムのカンファレンス「Regional Scrum Gathering Tokyo 2023」に初めて参加してきたので、記事にしてみたいと思います。

Day1

場所は御茶ノ水ソラシティ カンファレンスセンターで開催されました。会場に入ると、すぐ目の前にスポンサーブースが出展しているエリアがあり、ブースの周りなどいたるところで多くの人が会話をしている様子が見られ、活気と熱気がある雰囲気に包まれました。

私は初参加だったので、名札に「First Timer」というシールを貼ったのですが、他にも「CSM(認定スクラムマスター)」など様々はシールがあり、どういうステータスなのか?が一目で分かるようになっていました。(私も来年はCSMのシールを貼れるように頑張ろうと思います!)

セッションはただ聞くだけでなく、参加者同士でディスカッションをしましょうという機会が多かったのですが、こういった自分のステータスを表すシールがあることで「初参加なんですね」といった、会話のきっかけになったのが有り難かったです。

そんなこんなで、一緒に参加していたプロダクト開発チームの富田さんと合流しました。ドキドキしながら開始を迎えたのですが、まずはじめにRSGTになぞらえた寸劇が始まり、驚いたのと同時に、会場内も笑いに包まれて、気持ちがほぐれました。

その後は、David Bernsteinさんによるkeynoteが始まり、いよいよスタートです。

▽David BernsteinさんによるFive Development Practices for Building Software with Scrumのスライド

speakerdeck.com

CI, CD, TDD, リファクタリング, ペアプログラミングについて、なぜそれが有効なのか、ポイント等の紹介がされています。

そこからは、各部屋ごとにセッションが行われて、参加者は自分の興味のあるセッションに参加することができます。

▽当日のスケジュール

https://confengine.com/conferences/regional-scrum-gathering-tokyo-2023/schedule

私も事前にスケジュールを確認して、参加したいセッションの目星を付けていたのですが、途中で知り合った方に誘われて、新しいセッションに参加してみるなど、リアルの場だからこそ生まれる偶発的な出会いを楽しむことが出来ました。

Day2

Day2はLyssa Adkins さんによる「The Agilists’ Emerging Superpower and Our Planetary Challenge」というkeynoteから始まりました。アジャイルとは何なのかという話から、地球規模の課題である気候変動に対して私たちはどう振る舞うべきか?という大きなテーマの内容でした。

▽Lyssa Adkins さんによるThe Agilists’ Emerging Superpower and Our Planetary Challengeのスライド speakerdeck.com

参加したセッションの中でも印象的だったのは、スタメンさんによる「事業部全体を巻き込んだ アウトカム文化への道のり」です。

組織内で「価値の流れ」に関するコミュニケーションが高コストで行われているという課題に対して、EMの役割の定義の見直しや組織体制の見直しを行い、よりアウトカム文化を根付かせていった取り組みが参考になりました。

▽スタメンさんの事業部全体を巻き込んだ アウトカム文化への道のり

speakerdeck.com

また、森さんによる「楽しいだけじゃない、次の一歩を自分で踏み出し続けられるふりかえりへ~」も印象的でした。

チームでより良い未来に向かっていくために、チーム全員で立ち止まり、より良いやり方を見つけるために話し合いをして、行動を少しずつ変えていく活動は改めて大切だなと思いました。

その他にも、Day1やDay2が終わった後に、参加者同士で近くのお店に行き、参加した感想などをシェアする交流の機会があったのが、とても良かったです。

ご飯を食べながらだからこそ出来る話や、盛り上がりもあって、たくさんの出会いや繋がりが生まれました。(RSGT歴5年目の富田さんとご一緒させていただけたおかげで、沢山の人に出会えたので、とっても感謝です!)

Day3

最終日は、OST(Open Space Technology)に参加しました。OSTとは、ワークショップの進め方の1つで、参加者自身が話したいと思っているアイデア、解決したい議題などを持ち寄って、皆の前で発表し、興味を持った他の参加者がそれぞれのテーマごとに集まりディスカッションを繰り返していくというものです。

あっという間に30以上のテーマが集まり、ディスカッションが開始されました。途中での参加や中抜けに制限がないので、参加者も色々なディスカッションを見て回ることができます。

共通の課題感を感じて、ディスカッションに参加しているので、初対面の人同士も、あっという間に白熱した議論になっていきました。とても活気のある空間が生まれて、こういった場を社内でも生み出していきたいなと強く感じさせられました。

おわりに

今回初めて参加させてもらいましたが、アジャイルに関わる方の温かさや、良いプロダクト開発をしていきたいと共通の目的を持った人々が集まる場を実際に体感できて、すごく良い経験になりました!

また、イベントを運営する・場を作るという観点からも、ワークショップやイベントの合間や終了後など、至るところに、参加者同士の会話や出会いのきっかけ作りの工夫がされており、ただセッションをするだけでなく、人と人との出会いをすごく大切にされているのだなと伝わってきて、運営の視点からも勉強になりました。

学んだ内容を社内でも活かしていきたいですし、来年のRSGT2024もぜひ参加したいと思います。ありがとうございました!

RSGT2023に誘って下さった富田さんの記事もぜひご覧下さい^^ techblog.baseconnect.in

Regional Scrum Gathering Tokyo 2023に参加しました!

プロダクト開発チームの富田です!

1/11(水)〜1/13(金)まで開催されたRegional Scrum Gathering Tokyo 2023(以下RSGT)に参加してきました。 RSGTは、毎年1月に東京で開催されるアジャイル関連のカンファレンスです。

去年も参加したのですが、今年も参加することが出来ました!

スライドはこちらのブログ記事がまとまっていて便利です!

参加してどうだったか?

参加したセッションで印象に残ったものをピックアップしてみます

大規模ゲーム開発におけるリモートモブワークの導入事例

詳細はこちら

私の居るチームでもモブプロを行う時間を設けているのですが、他社の事例を聞くことが出来、とても参考になりました。

モブ毎にふりかえりは行っていなかったのですが、取り入れてやってみたいと思います。

「私考える人、あなた作業する人」を越えて、プロダクトマネジメントがあたりまえになるチームを明日から実現していく方法

詳細はこちら

ProductManagerと開発チームに分断が発生しがちなこと関しては、なかなか身につまされるものがありました。 お互いの価値観を共有することで、見える未来もあるんだ(どんな形であれ)、、

録画された動画を、プロダクト開発メンバーと一緒に見てみたいと思います!

「教えない教え方」を活用してスクラムを理解して実践するワークショップ

詳細はこちら

3日目は、こちらのワークショップに参加しました。

「教えない教え方」自体も興味深かったのですが、ワークを一緒に行ったチームの動きがとても素晴らしく、社内で若干グダグダになりがちだったスプリントの運用をしっかり見直そうと思わされました。

▽記念写真をパシャリ

一緒に参加したメンバーからの感想

今回、私はRSGTに初参加、これだけ大規模な社外イベントに初参戦しました!一番感動したのは、運営の方、参加者の方の熱量の高さです。

良いプロダクトを開発していきたいという共通の思いを持った方々が、国内外問わず一斉に集った、その「場」の熱量は実際に現地に行ってみないと得られないものだなと実感しました。

各セッションもとても学びが多かったですが、OSTを通じて、お互いに自分たちが抱えている課題をテーマに議論し合う中で、社内だとどうしても視点が偏りがちですが、社外からの視点として、新しい意見をもらえてとても新鮮でした。(また私も記事を書いてみたいと思います。)

RSGT2023で学んだことを活かして、自分たちのチームにも貢献していきたいです!

まとめ

去年は一人で参加したのですが、今年は二人で参加することができました。 昼休みや一日の終わりに「どうだったか?」と感想戦をしたり、帰ってから何をしよう?と相談出来たのが良かったです!

また、登壇を聞いたりや他の方と話していると、同じような悩みを抱えている企業は多いとも感じました。 社内には色々な課題が山積みなので、一つずつ切り崩して解決していきたいと思います!

「創業期のスタートアップにおける技術選定とAWS」というイベントに登壇しました

こんにちは、エンジニアの奥野です!

今年の11月にAWSさんのイベントに登壇させて頂いたので、記事にしてみたいと思います。

イベント概要

今回のイベントのテーマは「創業期のスタートアップにおける技術選定とAWS」というものでした。創業前・創業間もないスタートアップにおいて、プロダクトやサービス開発をどう効果的・効率的に進めるべきかについて、スケールを前提とし、 AWSさんのサービスを含めて実例を踏まえて紹介するというものです。

イベントの詳細はこちらからご覧ください。

open.kyoto

当日の流れ

タイムスケジュールは以下の流れで進行していきました。

  • オープニング (18:00-18:05)
  • AWS さまセッション (18:05-18:25)
  • アトモフさまセッション (18:25-18:55)
  • Baseconnectセッション (18:55-19:25)
  • クロージング (19:25-19:30)

会場の様子はこちらです。会場設営準備中の様子。広々としたスペースでした!

登壇の様子

いよいよ登壇の順番になりました。私たちの発表では、事業の創業期から振り返り、その中の開発組織変遷や各フェーズごとの課題についてご紹介させていただきました。 弊社は2017年に創業されたのですが、2022年の現在に至るまで、様々な変化やそれに対する取り組みを重ねてきたものを一連の流れとしてまとめたものになります。

詳しい内容についてはこちらのスライドからぜひご覧ください! (弊社のデザインチームメンバーがスライドを作ってくれました)

speakerdeck.com

終わりに

こういったイベント登壇を通じて、自分たちの取り組みを振り返る良い機会になりました。 今後もBaseconnectではこういったイベント登壇を増やしていきたいと思っています! 色々とお世話になり、このような場を設けて下さったAWSさん、たくさんのサポートをくれた開発チームやデザインメンバーの皆さん、本当にありがとうございました!!