こんにちは。アットウェアでアジャイルコーチやスクラムマスターとして活動している梶平です。
アットウェアは、2022年9月22日(木)にオンラインで開催される Scrum Interaction 2022 にスポンサーとして協賛します。
個人的な話になりますが、前回の Scrum Interaction 2019 では、ジェフサザーランドさんと、野中郁次郎さんが同じ場所にいらっしゃるという奇跡的な場で、私自身とても興奮したことを鮮明に覚えています。
更に組織変革の事例を多く知ることができたり、参加者同士のグループディスカッションもとても楽しく、学び多き時間を過ごせました。
興奮。楽しさ。学び。
それだけではなく、場から発せられているエネルギーのようなものが自分の中に入っていくような感覚もあり、自身の日々の活動について応援されているような、ありがたい気持ちにもなれました。
今回もアジャイルの力に助けてもらいつつ、自身・チーム・組織の変革に取り組まれている事例や、その中で感じる悩み・モヤモヤを聞き、そして参加者の方々と話し合えることがとても楽しみです。
２１年度新卒採用インタビュー その１
第１段は多拠点エンジニアを目指している吉井さんです。以下のようなことを聞いています。
自己紹介
アットウェアを選んだ理由
アットウェアに入っての感想
入社した時の研修
仕事に慣れていく過程
現在の仕事の進め方
挑戦したいこと
どんな人にアットウェアを勧めるか？
株式会社アットウェア 採用チャンネルはこちら
株式会社アットウェア 代表 牧野隆志 インタビュー動画 第２段として、牧野が最近挑戦していることについて聞いてみました。アットウェア、アットウェアベトナム、個人としてどんなことに目を向けているでしょうか？
株式会社アットウェア 採用チャンネルはこちら
２０２１年１１月
株式会社アットウェア 代表 牧野隆志 インタビュー動画 第１段として、株式会社アットウェアの経営理念である「システムで人々をしあわせにする」について話を聞きました。
株式会社アットウェア 採用チャンネルはこちら
２０２１年１１月
アットウェアの魅力を映像でお伝えしたくて、採用向けYoutubeチャンネルを開設しました。今後不定期ではありますが、動画をアップロードしていく予定です。
第１段としては、アットウェアの簡単な紹介ムービーです。
「システムで人々をしあわせにする」をミッションとしている、株式会社アットウェアの会社紹介動画です。
弊社のSI（システムインテグレーション）事業は、主にエンタープライズ（企業向け）に特化し、顧客企業のビジネスを動かす上で必要不可欠なシステムの開発を行っています。
システム開発をする上で、顧客企業と「恊働」を行うためのワンチームを結成します。 株式会社アットウェアの社員は、お互いフラットな関係で働いています。上司・部下という関係や、役職（部長、課長、係長）というものはありません。一人ひとりが自分の働き方をし、創意工夫、意思決定おこない生き生きと活動しています。また、個々の能力を最大化できるよう自律型組織の文化を形成しています。
私達はWeworkコミュニティを通して出会う様々なタイプの人と共創により価値を作り出すことも非常に重要であるとの狙いを持ち、2019年2月に横浜みなとみらいのWeworkに入居しました。残念ながら2020年初頭より新型コロナウィルス感染症の蔓延により、現在はテレワークを強く推奨している状況です。一日も早い、コロナウィルスの収束を願っております。
こちら、Vyondというアニメーション動画作成ツールを利用して作っています。
こんにちは、21年新卒の中山と申します！
21年新卒の研修が、7月いっぱいで終わり、8月からOJTという形で新卒４名（西川、平澤、吉井、中山）がそれぞれ違うプロジェクトに参画し、少しずつ開発に入っております。
そこで、このブログでは
についてお伝えしたいと思います！🔥
中山：
吉井さんに、「研修を通してどんな成長を感じられたか」について伺ってもいいですか？🙋
吉井：
僕たちの今年の研修は、自身で得たい価値に即した目標を設定するセルフ・コントロール型研修だったので、自身で設定した目標を確実に達成し成長していく実感が得られました。
今までは目先の結果に注力してしまい今やる必要がないことはやらないことが多かったのですが、研修中は自分が結果を出し続けていくために必要な土台作りとして、今すぐ必要はないものの重要なことに注力し学ぶことができました。
技術面だけではなく、人として成長をし続けられる良い習慣を身につけることが特に成長した点だと感じています！
中山：
めちゃめちゃいいですね。
確かに、自分で得たい価値に即した目標を設定するから、中長期的な視点でどんなことを研修ですべきか考える必要があって、緊急性は低いけど、着実に良い習慣を身に付けるような考え方は僕も勉強になりましたね🔥
吉井さん、ありがとうございました！🎉
中山：
それでは、平澤さんに、「研修で難しかったところ」について伺ってもいいですか？
平澤：
そうですね。僕は、「セルフ・コントロール」という言葉を「何事も自力で解決すべき」と解釈してしまっていた場面が多くあったので、研修の初期では、何か困ったことがあってもなかなか仲間を頼れなかったんです。けど、このままだとよくないなと思い自ら質問をできるだけするようにしたんです。そうすると、少しずつ「何事も自力で解決すべき」という考え方から外れることができて、チームで協力して、それぞれの得意分野を出し合いながら進めていけるようになりました！
中山：
セルフって言葉を聞くと確かに、「自分で」という意味になるので、一人で全て決めて目標決めて頑張る、ように思ってしまうかもしれないけど、仕事は一人ではできないし、チームで成果を出すものですもんね、、。僕自身、平澤さんが徐々に自分が分からないことなどを同期とか先輩に積極的に聞いていて、とても素敵な姿勢だなあって思ってました☺️
平澤さん、ありがとうございました！🎉
中山：
それでは最後に、西川さんに「配属に向けての意気込み」を伺ってもいいですか？
西川：
はい👍
配属先のプロジェクトでは、日本とベトナムのメンバーが混じったチームでBtoB向けのソフトウェアを開発します。
英語メインのチームで常に考えることが求められる環境ですが、自ら配属希望を出しました。
異なるバックグラウンドを持った人々と関わる中で、エンジニアとして成長し、プロジェクトのさらなる拡大に寄与したいと思っています。
中山：
西川さん、入社した当初からすごくベトナム推しだったので、配属希望出したときに「やっぱり！」と思いましたね笑
英語メインのプロジェクトで大変なこともあるかと思いますが、西川さんのガッツで乗り切ってください🔥
西川さんありがとうございました！
中山：
はい、ここまで21年新卒の同期3人に研修についての感想を聞いてみました！
アットウェアでは、それぞれの社員がどんな姿になりたいか、どんな価値を生みたいかを考え、そしてその姿になるためには、またその価値を生み出すためにはどんな目標を立てどんな研修をするかを自分たちで決めます。研修中には、悩んだり、一人では達成が難しいこともありますが、そんな時は仲間と相談しながら研修を進めていきます。アットウェアに何となくでも興味がある方はぜひ下のリンクなどからお問い合わせください！それではまたのブログ更新をお楽しみに！
春ですね。弊社に、新しい仲間が４人入社いたしました！
本年度の研修もスタートしています。
昨年度から、セルフ・コントロール型研修を実施しました。研修が終わり、そのふりかえりを行い、本年度の研修を見直ししました。 このブログでは、昨年の研修のふりかえりと、本年度の見直した部分をお伝えしようと思います。
短くいうと、研修者と運営者が設定したゴールを共有して、ゴールまでのプロセスを研修者の裁量で決める研修です。
弊社で取り組んでいた過去の研修内容を参考に、どのような研修内容を行うか、「カリキュラムは？」や「タイムテーブルは？」「担当は？」など組み立て、社員のいろいろなアイデアを募って、紆余曲折しながら、研修の設計をしていました。
並行して、一昨年の弊社で 『７つの習慣』読書会 を行ってました。
『７つの習慣』の「Win-Winのマネジメント・トレーニング」を読んで、「セルフ・コントロール型研修」に、手段を本人に任せることで、個々人の潜在能力を最大に活用し、主体性をはぐくむ実践経験ができる理想の研修を見出しました。
私達は、研修者が研修後にどのような能力を身に着けているべきか明らかにして、研修者を全面的に信頼し、手段を押し付けないことで、早く目標達成しようと意欲的になり、望む結果にも、相手の成長にもいち早くつながると、考えました。
そこで、セルフ・コントロール型研修になるように、研修者へ全面的なデリゲーション（手段は自由に選ばせ、結果に責任をもたせる）のもと、何が期待されているかお互いに理解し、納得するために「実行協定」をまとめました。
「実行協定」
カリキュラムは、ハードスキルとソフトスキルを体系化し、各課題のゴールを設定しました。
研修が終了し、KPTにそって、ふりかえりを行いました。
Keep
Problem/Potential
Try
ふりかえりを受け、今年の研修は、事前に、内定を承諾頂いて以降、新入社員の方々と研修内容のすり合わせの時間をいただきながら、研修内容を組み立てました。
そして、研修後のイメージ・目標を見出すことを先に行うために、セルフ・コントロール型研修より、前に以下のイベントを行うことにしました。
今年の研修は、もう一つ願い（テーマ）を込めました。
「P/PCのバランス」
研修は、P（成果：Performance）よりも、PC（成果を生み出す能力：Performance Capability）に重きを置いて、活動する。
（すでに始まっていますが、）これから、新しい仲間が、ワクワクして成長に取り組めるような研修にしたいです。
研修の終わりには、研修をうけたみんなより、レポートをお伝えしようと思います。
株式会社アットウェアは、新型コロナウィルス感染症の日本国内での感染拡大に伴い、弊社従業者を原則在宅での勤務としております。 在宅勤務中におきましても可能な限り業務遂行を維持する体制を取って参りますが、郵送物の取り扱いの遅延ならびに弊社代表電話からの担当者への取次時など、ご不便をおかけすることが予想されます。 お取引先様各位におかれましては、ご理解のほど何卒よろしくお願い申し上げます。 なお、お急ぎの場合は、名刺等に記載の担当者連絡先へ直接ご連絡ください。
私たちはミッションである「システムで人々をしあわせにする」の実現に向け、プロフェッショナルなソフトウェアソリューション・サービスを提供しておりますが、在宅勤務中におきましてもこれまでと変わらぬあるいはそれ以上の価値の創造を果たしていけるよう、日々の改善と努力を積み重ねて参ります。新たな挑戦故、ご迷惑ならびにご心配をおかけすることも多々ございますが、ご容赦いただけますようお願い申し上げます。
この難局を乗り越え、一刻も早く日本および世界の全ての人、社会が再び平静を取り戻し、またさらなる経済発展と平和の実現に向け、地域社会の一員として弊社社員一同取り組んで参る所存です。
※※※ 2020年6月30日更新 ※※※
株式会社アットウェアは、新型コロナウィルス感染症の日本国内での感染拡大を受け、3月中旬より弊社従業者を原則在宅勤務としておりました。
5月25日に首都圏の緊急事態宣言が解除されてから一ヶ月ほどが経過し、間もなく当初在宅勤務期間として予定しておりました6月30日となりますが、未だ従業者が安心して安全にオフィスに通勤ならびに就業できる状況とはいい難く、また通勤が避けられないエッセンシャルワーカーの方々などへの接触を少しでも避けるため、引き続き在宅勤務を推奨して参ります。期間については、現時点では明確には定めず、概ねワクチンが広く行き渡るなど状況が改善されるまでといたします。
なお、弊社はこれまでも従業者個人の状況に応じて在宅等での勤務も認めておりましたが、今後はより自分らしい働き方・生き方に重きをおいた多様な就業形態も視野に社内で議論を進め、取り組んで参りたいと考えております。
期間： 2020年6月30日まで 未定（概ねワクチンが広く行き渡るなど状況が改善されるまで）
縁あって@kmizuこと水島宏太さんに社内の技術推進活動の支援をいただいています。
その活動のひとつとして勉強会を開催したのでご紹介します。 コロナ禍の影響でオンライン勉強会です！
水島さんの経験や得意分野を踏まえ、弊社社員からテーマをリクエストさせていただき、アカデミックな話題も混ぜつつ、時にはマニアックな内容も盛り込んでもらっています。
ブログでは紹介できていませんでしたが、昨年より勉強会を開催してきました。
この記事では、先週開催された「Javaのジェネリクスを知ろう」の勉強会レポをご紹介します。
この発表テーマをお願いする時に、実は他にもラムダの話を聞きたいというリクエストがありましたが、ラムダはジェネリクスを理解していることがキーポイントになるため、先にジェネリクスに絞ってお話をしていただくことに。内容はJavaを学び始めた新卒者に役立つような内容でありつつ、ベテラン向けにマニアックな話も入れて欲しいという、やや無茶なお願いをしました。それをうまく落としこんで私たちが聞きたい内容に仕上げてくださいました。ありがとうございます！
発表はJava 1.4までジェネリクスがなかった時代背景から話が始まり、Object型を使うとダウンキャストが必要となり安全性に問題があることをコード例を添えて解説。その後にジェネリクスが導入されるきっかけや歴史に触れて、概要や機能の話をしてくださいました。
発表時間は1時間弱で基本的なところがしっかり押さえられており、初学者でもわかりやすい内容だったと思います。その中でも私が興味深く感じたのは以下の話題でした。
ジェネリクスの機能の一つであるワイルドカードは、リリースされてだいぶ時間が経ってから、安全性の面で問題あることがわかったそうです。OOPSLA2016で公開された Java and scala's type systems are unsound: the existential crisis of null pointers という論文を引用しつつ、自身の考えを述べてくださいました。
危険視すべき問題なのかというと、水島さんの考えではそうではなく、「ワイルドカード単体では発生する問題ではないので、一概にワイルドカードが駄目だという話ではない」ということでした。nullや上限・下限ワイルドカードと組み合わせた時に発生するというもので、nullとワイルドカードという機能の組み合わせによって、安全性上の問題が発生してしまったよと。ユースケースなどの多面性や言語仕様として取り入れられた経緯を追いながら、なぜこの機能は存在しているのか、何がヤバいのかというのがわかって話を聞いていて面白かったです。
コーナーケースなので知らなくても実務では困ることは少ないかもしれないけど、知ったうえでJava APIやフレームワークのコードを読むと、見えてくる世界も違うかもしれませんね。
他のベテラン層の参加者に参加した感想を聞いてみたら「ワイルドカードの元になった理論を発明したのが日本人だって知らなかったし、他の言語でのジェネリクスの話が個人的によかったです。ScalaとKotlinが激似とか、Goでの話など。」と言っていて、新しい発見や新鮮さを楽しめたようです。
2020年にジェネリクスを取り上げていただいたわけですが、時が経ったからわかった事もあり「今だから言える事だけど実はワイルドカードは必要なかったかもね……」というような話ができるのも、今だからできる話題ですね。
たのしかったです。
先日（3/11）、技術評論社刊 「みんなのJava OpenJDKから始まる大変革期！」 を弊社牧野のもとに献本いただきました。
以下、そのときのやりとり
牧野「『みんなのJava OpenJDKから始まる大変革期』を献本いただきました！」
私「明後日発売の本じゃないですか！」
周り「せっかく献本頂いたたんだし速攻読んで書評を書いてツイートをしましょう！」
… 翌日 …
周り「そろそろツイートしようと思いますが読みました？」
隣の席の若手「ざっくり読んだのでこんな感じで簡単な感想書きました」
私「手元にまだありません」
隣の席の若手「私さんどうぞ」
私「」
という感じで空気を読んで書評を書くことに。
が、さすがに発売前には間に合わなかったので、機動力のある若手にツイート を譲りましたが、この週末を利用してようやく読むことができたので、遅ればせながら書評（というか感想）を書いていきます。
結論からいうと、「Java が OpenJDK としてオープンソースとなったことで、Java の進化が加速していることがわかり、Javaの躍動が感じられる本」でした。
全6章に渡る本ですが、各章ごとにテーマ・内容が異なっているので各章ごとに書きます。
ちょっと前に混乱をもたらした Java のライセンス変更は記憶に新しいですが、それ以外にも、Java 界隈では Java9 以降現在にいたるまで様々なことがありました。短期間にたくさんのことがありすぎて、情報がオーバーフローしてしまった方もいるのではないでしょうか（少なくとも私はそうでした）。また、その情報も、テック系ブログをはじめ、さまざまなところに分散していて、まとめるのも大変でした。
この章では、その Java 界隈の状況の変化が見通しよくまとめられています。
内容としては、Java 界隈の変化を押さえ、Java 開発体制から、Java9 〜 14 までのリリース内容概要、新しい言語仕様の紹介、これからの機能などがわかりやすくまとめられています。
過去と比較して、何ができるようになったかが把握できるのもさることながら、紹介されている機能・仕様が「何故そのようになっているか」にも言及されていて、現在の Java の機能がいかに使いやすくなっているかがよく理解できました。
Java リリースモデルの変更があり、その後、雨後の筍の様にたくさんのJDKディストリビューションが現れました。これらのディストリビューションのうち、どれを業務で利用するか迷った経験をお持ちの方は多いのではないでしょうか。
この章では、JDKディストリビューションの歴史から、現在どのようなJDKディストリビューションがあり、どのような特徴をもっているのかが網羅的に解説されています。さらに、どのように選ぶべきかという方針についても言及されています。
これを読んでおけば、JDKディストリビューション選択時のステークホルダーに説明する材料に困ることはないでしょう。
個人的には、BellSoft Liberica JDK が初耳だったので、ちょっと試してみたいと思っています。
20年ぐらい前にJ2EEを使っていましたが、そのときは設定が多く、柔軟性が少ない堅い印象。Java EE7 のときはてらだよしおさんが JJUG ナイトセミナーですごく推してた記憶。その後は進化が滞っていて、今後は余り使うことはないだろう。個人的にはそんな印象の Java EE ですが、 近年開発が再び動き出しています。そんな Enterprise Java の過去から現在についてまとめられています。
この章では、Enterprise Java にフォーカスして、その歴史やアーキテクチャの変遷、最新の Jakarta EE 8 の機能について、網羅的に解説されています。
序盤の歴史の部分は、J2EE を触ったことのある私からすると歴史書的な印象もありましたが、Jakarta EE8 の新機能の部分では、モダンな Java フレームワークの機能を積極的に標準化していこうとする姿勢がよくわかり、変わろうとしているんだ、ということが感じられました。
Enterprise Java の標準としてまとまることで、より開発しやすくなることに期待します。
前章をうけて、Java EE から派生したマイクロサービスのためのAPI、MicroProfile について書かれています。マイクロサービスは流行っていますが、実装パターンは様々で、開発に時間がかかってしまう印象です。そんなマイクロサービスの実装でみんなが苦労している部分を標準化しようというのが MicroProfile です。
この章では、MicroProfile が産まれた経緯と、その実装方法、機能、そして今後の発展について説明されています。
マイクロサービスとして開発するかどうかは要件によってかわるかとは思いますが、いざマイクロサービスを利用する、となったときにこうした標準があることは助かると思いました。個人的には、今後の発展に含まれていた、「Reactive対応」「LRA対応」が興味深かったです。とくに、LRA（Long Running Actions）についてはマイクロサービスを作る上でいつも悩まされていたことなので、今後の動向に注視していきたいです。
昨年行われた JJUG CCC などのイベントでも、GraalVM と名のつくセッションは人気でした。その事実からもわかるように、GraalVM は、おそらくいまJava開発者の間でもっとも興味が惹かれている技術ではないでしょうか。
しかし、昨今のFaaS勃興の背景から、GraalVM はどうしてもネイティブコンパイラにフォーカスしがちです（私もその一面しか見ていなかった感じです）。しかし、GraalVMはそれだけでなく、多言語実行環境としての一面もあります。
この章では、GraalVM と HosSpot VM の内部構造を比較し、Graal VM がどのように動作しているのか、如何にして多言語実行環境を実現しているのか、ネイティブコンパイラがどのように動作しているのか、などが記載されていて、いままで曖昧だったGraalVMの全体像が明確に見える思いでした。
また、GraalVM の具体的な適用事例も幾つか紹介されており、この中でも興味深かったのは、リアクティブストリームを使ったアプリケーションにおいて、JITコンパイラをGraalVMのものに置き換えることで、最適化が図られる可能性があるという内容でした。
このことが必要になる大規模なプロジェクトはそう無さそうですが、今後の引き出しとするためにも、手元で試してみたいと思います。
最後は、最近のJavaというより、Java界隈のフレームワークについての内容です。
Javaのフレームワークは、現在では Spring Boot が隆盛を極めているように思えますが、システムのクラウド化にともなうフレームワークに対する要求の変化から、新しい軽量なフレームワークが数多く誕生しています。その中から、Micronaut / Quarkus / Helidon を実際の実装・コード例を通して紹介しています。
実際に記載されている内容通りに手を動かすことで、ハンズオン的に各フレームワークの機能を知ることができますが、個人的に重要と感じたのは、最近のフレームワークに求められているものについての記事でした。
昨今のクラウドやマイクロサービスが求められているなかで、新しい軽量フレームワークには可搬性（Portability）や観測性（Observability）、非同期処理などが求められているとのこと。とくに「観測性」については、強く言及されている印象で、私も業務中、実装しているときに忘れがちな側面ではあるので、紹介されている軽量フレームワークを試しながら、どのように実現されているのかを確認したいと思います。
Java開発をやってきた人の中には、長く進化が止まっていた時代のイメージから、「枯れた技術で長く続ける」という発想を持っている人もいるかと思います。しかし、時代は移り、Java は半年ごとに機能追加が行われ、常に新しいパラダイムを取り込むようになりました。
そうした状況の中、この本は、Java 開発者が今まさに読んでおくべきものだと感じました。一年後では遅いです。なぜなら、今の Java は進化を続けていて、数年後には、この本に書かれていることに加えて、さらに新しいパラダイムがやってきているかも知れません。
Java を使う開発者である我々も、常に新しい技術を学んで、この先生きのこれるようにしなければなりません。また、世の中のシステムが陳腐化することも避けたいです。
この本の序文において、著者の一人であるきしだなおきさんは以下のように書かれています。
Java はみんなで作るものになりました。
この言葉は、言語開発者にだけ向けられた言葉ではないと思っています。 我々開発者も、新しい技術を学び、学んだ知識を共有して、よりよいシステムをつくれるようにしていきたい。
この本を読んでその思いを新たにしました。
すえなみさんが主催している「すえなみチャンス」が面白そうだなと思って、アットウェアで逆すえなみチャンス的なことが開催できたらいいなという所から、トントン拍子で話が進み実現しました！
「すえなみチャンス」についてご説明をすると、参加者はすえなみさんの知りたい話をトークする代わりに、すえなみさんに焼肉をご馳走してもらえるというイベントです。それの逆バージョンをしてみたいというのが、今回の趣旨です。
開催レポを書いたのでご紹介します。
第一部は、スライドを使ったオーソドックスな発表形式で、お話を聞かせていただきました。
発表者はすえなみさんと、すえなみさんをご紹介頂いたかとじゅんさんをお招きし、2名の発表となりました。
一人あたり30分から1時間程度の発表時間でお願いしていましたが、当日はお二人で1時間30分ほどとなり、発表のボリュームとして駆け足にならず、じっくりお話が聞けて、ちょうど良かったです。
すえなみさんがT字形ERの E-E 関連についての考察を話している姿
MSA（マイクロサービスアーキテクチャ）がテーマです。
昨今、世の中でマイクロサービスについて言及されたり・取り組んでいる事例があるなかで
というようなを切り口にして話してくださいました。
最初、「過去の文献や実践者とのディスカッションの中でも、最適解は見つかっていないけどドメインで分割すると良さそうという流れがある」というところから話が始まりました。そうやって歴史から紐解いていくことで、マイクロサービスの意義へと繋がり、幅広い参加者に向けた話なんだなと、発表への期待を持ちました。
私の所感を書く前にアットウェアの背景をお伝えしておくと、アットウェアでは技術的裁量があることを大事にしています。ビジネス要件やお客様の状況や運用のことも考えて、枯れた技術だけでなく、事前に試した上で最新の技術まで組み合わせているほか、言語やツールも選定して、アーキテクチャや運用の仕組みを考えて設計していきます。そういう背景を持ち合わせている聴衆に向けて、マイクロサービスのメリットの一例として以下のような事を紹介されていました。
当日の話で一番印象に残っているのは、システムの構造には組織構造が大きく関わるという話です。
マイクロサービスアーキテクチャは、システムは人が作っているという事実を踏まえて、うまくやっていくためのアプローチがコンセプトとして込められているといいます。 個人的に分散化やクラウドなどの技術は関心が高い分野なのですが、それだけでなく、チーム開発という観点からも言及されていたのが、一層の興味を引き立てられました。 発表を聞いて、組織構造には利用者だけでなく、開発者・運用者として関わる私たちも含まれており（あってますでしょうか）、システム間の認識合わせやRESTインタフェース定義などに集中しすぎて、視点が狭くなりすぎないよう、モジュール化のさじ加減も大事なんだということを改めて意識しました。
最後にいくつかあった質問の中から興味深い内容をご紹介します！
Q. マイクロサービスの分割はトランザクションの単位で分けるという考えについてはどう思うか？やっている人の事例を聞くと2フェーズコミットすごく大変そう。分割労力に見合うのかと考えてしまう時がある。
A. サービスが別れると2フェーズコミットが必要な時はあるが、関心が強いものだけど業務が違うといったようなケースでは分割が難しい場合がある。そういう疑問こそ分散システムの難しさでSpotifyがとったアプローチは「モジュラモノリス」というトランザクションを共有するやり方をとっている。
この質問のやり取りを聞いて感じたことは、そうするとデータベースの共有のことを考えたり、DevOpsの事情で立戻って考え直したりすることあるだろうし、システムを作るのって面白いなぁと思いながら質疑応答を聞いていました。
というテーマを事前にリクエストして発表準備をしていただきました。
当日は、ソフトウェアアーキテクチャを軸に置いてコミュニケーションすることで、エンジニアとビジネスサイドが意思疎通できるという切り口で話をしてくださいました。
ソフトウェアアーキテクチャの説明で「抽象化と問題分割によって複雑性を減らす」ということが言及されて、かとじゅんさんの発表の繋がりがあってすごくいい感じでスタートしました。
Lean Architectureという書籍に書いてある「what system is」と「what system does」というフレーズを紹介してくださり、システムの特性には2つの観点があり「そのシステムが何か（システムの構造や状態を示す）」「そのシステムは何をするのか（システムの振る舞い）」があるとのこといついて解説頂きました。
それに加え、ソフトウェアアーキテクチャは「what system is」を規定するものなんだけど、これ以外に「what system can't （システム制約）」も含まれているのだという持論も述べてくれました。
開発者以外とのコミュニケーションについて話題にした時は、キングダムという漫画の「法治」という概念を言語化していくシーンをメタファとして、ソフトウェアアーキテクチャとの関連性を説いてくれました。 ソフトウェアアーキテクチャが発するメッセージ性の意味について、しっかりと受け止めました！ 「法とは願いだ」というフレーズが意味するところ、「結果から考え始めるべきではない」というあるべき論、開発者を楽にしたり都合をよくする為ではなく「実際に利用するユーザ」のこと、「誰にとってどういう価値を提供したいのか」を示すという所に通じている、という考え方。すえなみさんの話を聞いて、普段から自分の行動や考えを深掘りしていこうと心に誓ったのでした...
繰り出される問題提起や持論が「いい話」ばかりで、心の中で頷くばかりでした（笑）
「実際にビジネス価値を生み出すのはアーキテクチャ自身ではなく、その上に乗っかるユースケースがビジネス価値だしていく」という考え・姿勢を持たれているからこそ、普段からコミュニケーションもうまくいくんだろうなと想像（すえなみさんと仕事をする人達の姿や顔なども）できました。
「顧客のビジネスをアクセラレートするシステム開発では、抽象化はビジネスを阻害したり促進もすることがあって、実際の現場のことを理解することで、求められている抽象化に繋がる」と述べられていたのは、ここでもやはりコミュニケーションコストを費やすことの重要性を感じました。
やはり、アーキテクトは顧客に近い位置で活動するのが大事ですね。 切り口や考察の視点が面白くもっと話が聞きたくて、あっという間に時間が過ぎてしまうのが惜しかったです。
雑な感じのスクリーン
場所を焼肉店に移し、お肉を食べながら技術談義をするという感じで開催しました。 すえなみさんに「いつもどんな風にやっているんですか？」と聞いたら、「形式は決まっていなくて、集まる人や回によってバラバラです。食事前に済ませてからやるって事が多いです。ただこのスタイルも興味深いので全然アリです！」とのこと。
お店の一角にバッテリー駆動のモバイルプロジェクターを持ち込ませていただき（事前にお店には電話連絡しご了承いただきました）、参加者全員がLTスタイルでネタを持ち寄って、お酒の肴にしてワイワイやりました。
スクリーンはホワイトフィルムに木の骨枠を組み付け、雑に作って投影しました（骨枠は事前に用意してあった割り箸を雑につなぎ合わせて作成）。 細長のテーブルで奥の人にもしっかり見えて、とてもいい感じにできたのでバーベキューやお花見など野外でも応用できるポテンシャルを感じました。
カジュアルな感じのスタイルで美味しい食事というのがよくて、一番良かったのは、アットウェアからの参加者の6名、1部で発表したすえなみさん、かとじゅんさんを含め、全員がしゃべったこと。そして、社内のメンバーが社外技術者に自分の言葉で感じていることや取り組んでいることを伝えたうえで、コミュニケーション（ラフに雑談）できたというところでした！
技術を肴に楽しむ・共感する・悩みを相談する（考えていることの言語化やアウトプットからのフィードバック）ということを、研修スタイルだけでなく懇親会スタイルで1テーブルで行えるというのはいいですね。お肉も美味しかったし貴重な時間を過ごせました。
技術談義をすることは仕事のようで仕事ではない。そんなよくあるフレーズを実感したひとときでした。 自分たちのあったらいいなが実現できたことはうれしいですし、機会を第一部の形で社内全員に機会も創出できたというのも良かったです。
「また、やりたいですね！」と最後に言ってもらえて、お二人にも楽しんでいただけたのも嬉しかったです。 よかったという話しかしていませんが、これからも積極的にどんどんこういう活動を広げていきたいと思います！
dotDataの木村宗太郎さんを招いて、「ストリームデータ処理入門」と題した社内勉強会を開催しました。
今回の勉強会のきっかけは、弊社で大規模のストリーム処理を扱うプロジェクトのメンバーでストリーム処理について雑談していたときでした。
そのプロジェクトメンバーの一人である私がストリーム処理に対する技術的興味をもっており、そのことを知った別のメンバーが、過去に ScalaMatsuri 2017 で木村さんがストリーム処理について発表されていたことを教えてくれました。
そこで「社内勉強会をお願いしよう！」と発案があり、共通の知人を経て木村さんにオファーをして快諾いただけたことで、今回の勉強会が開催されることとなりました。
勉強会のタイトルは「ストリームデータ処理入門」でしたが、タイトルに書いてある「入門」以上の充実した内容でした。
「ストリーム処理とは何か？」という基本的なところから、その基盤や構造、利用方法まで、開発者がおさえるべきポイントを幅広く解説され、そのカバー範囲の広さはまさに「全部のせ」。
アジェンダを資料から引用してみましたが、その内容の充実ぶりがおわかりいただけるでしょうか。
当日はこちらの資料を使ってお話してくださいました。
それぞれの項目の内容もとても充実した内容で、木村さんも知識を共有しようと熱く語ってくださいました。 その情報量はあたかもバックプレッシャーのないストリーム処理のよう。 私も、情報を取り逃すまいと集中して聞いていました。
特に印象に残っているのは、「バッチ処理はストリーム処理のサブセットである」という概念。 「バッチ処理は、無限であるデータストリームを、一定時間ごとに区切って処理する、ストリーム処理の限定的なモデルである」という考え方ですが、今までバッチ処理とストリーム処理の関連性を意識していなかった私にとっては、目から鱗が落ちるような思いがしました。
今回の勉強会は内容が盛りだくさんで、私もいまだ全て消化し切れていません。
しかし、これまで大まかな理解だった大規模ストリームデータ処理について、どのように構築して、どのようなところに注意するべきか、イメージが明確になったと感じています。 また、弊社で進めているストリームデータを扱うプロジェクトにおいては、勉強会で紹介された処理基盤プロダクトではないKinesisなどを利用していますが、質疑応答でKinesisならではの課題をディスカッションできました。勉強会中で学んだ問題点や解決方法などはプロダクト内容に関わらず、幅広く活かすことができそうだとも感じました。
今後ますますデータは増え続け、リアルタイムに処理しなければならない事例はもっと増えていくことと思います。そうした時代においてのソリューションの一つの選択肢として活用できるよう、この勉強会をきっかけとして更に技術を磨いていきたいです。
かとじゅんさんをお招きし、2回にわたってEventStormingの一種である Big Picture Workshop を開催しました。
EventStormingは、近年注目されている、情報システムの概観を掴むための手法の一つです。ThoughtWorks社のTechnology Rader Vol.19では、当社の考える産業で採用していくべきテクニックの一つとして取り上げられました。
EventStormingでは、関係者が集まりシステムを取り巻く環境を大きな壁と付箋を使って互いに発表しあいながら、システム化の対象とシステムへの期待を共有していきます。
EventStormingの特徴は、システムを利用するにあたって発生するイベント（ドメインイベント）に着目している点です。イベントから始まり、それを時系列順に並べ、関連する利用者や外部システム、金銭の発生を洗い出していくことで、システムの全体像を掴むことができます。
今回は「かつてない図書館」を企画するというテーマで、10人程度の参加者が集まって、アイデアを出し合いました。
進めながら気づいたのは、議論を促進するような仕組みが随所に取り入れられていることです。 最初は発散させ後で収束させるようにしたり、全員が立った状態で全員と情報を共有しながら認識合わせをして、座って議論しないようにしたりと意見を言いやすい環境を整え議論の価値を高める効果を感じました。
最初は参加者が各自の思い思いのイベントを付箋に書いて、タイムライン（時系列順）に並べていきます。 イベントは、動詞の過去形で書くように決められていて、動詞の過去形で書くことで、イベントでないものを出さないように誘導したり、後の工程で「□□した」のが誰なのかに視点を誘導する効果があります。
イベントが出揃ってきたら、タイムライン強化を行います。タイムライン強化では、システムを利用する上で必要不可欠で価値の高い、重要なイベントにフォーカスしてその前後のイベントや関係のあるアクター、外部システムなどを充実させていきます。
次のウォークスルーでは、イベントの流れを言語化しながら、考慮不足や抜け漏れを発見していきます。まずこのイベントが起こって、次はこのイベントが起こる、というように、流れに沿って説明することで、あのイベントが抜けているのではないかということに気づきやすくなるそうです。
実際にやってみると、タイムライン強化の最中は気にしていなかったイベント同士の前後関係の違和感や足りていないアクターが明確になり、タイムラインを充実させることができました。
こうした考慮不足に早い段階で気づけるのは、EventStormingの大きな利点だと感じました。
ウォークスルーで拡充したタイムラインについて今度は逆方向からそのイベントを起こし得るのに、その前のイベントは適切かという視点を持ちながら言語化しました。
逆方向から読んでいくとそのイベントを起こすためにはその前のイベントは重要だがそれだけでは足りないといった、依存の不足が見つかりました。
また、エンジニアはお金の話が抜けがちということであえてお金について考えるフェーズが用意されていて、実際この辺りの話はいくら素晴らしいビジネスモデルやアイデアがあったとしても無い袖は振れないので、ステークホルダーが一同に介して認識合わせができるタイミングで一緒にお金について考えるフェーズを設けるのは合理的に感じました。
一通り終わったところで今回のワークショップの中でリスクになりそうな問題やその解決策を洗い出し共有しました。
ステークホルダーが一堂に会して曖昧な部分を明らかにし合意を形成するため、お客さんやチーム内での認識合わせなど、実際のプロジェクトで有用なテクニックだと感じました。
関係者と顔を合わせながら合意を得るという点で、同様に情報システムに対する期待を取りまとめる技法である、リレーションシップ駆動要件分析（RDRA）と似ている点がありそうです。それぞれの違いを見定めて、各プロジェクトに適した手法を取り入れられるよう理解を深め活用していきたいです。
今回のワークショップで体験した Big Picture EventStorming は、プロジェクトを立ち上げる際に使うものでしたが、他にもプロジェクトの別の場面で使える手法があるそうです。 中でも、設計者や実装者の観点に寄った Design Level EventStorming という技法があるそうで興味を惹かれました。
最後になりましたが、かとじゅんさんに感謝の意を申し上げます。
この度は貴重な体験の機会を作ってくださり、ありがとうございました。
2年連続でプラチナスポンサーとなったVimConfが終わりました。
スポンサーに加え、昨年のブログで書きましたが2年連続で筆者はコアスタッフもさせて頂きました。
この記事では、この2年間スポンサー・スタッフ・そして一個人として感じてきたことを語ろうと思います。
そんな、過去と未来を繋げるこのカンファレンスに、筆者個人・所属会社として今できる最大限の貢献は何か？と真っさらな状態から考え、プラチナスポンサーとして申し込みさせていただきました。（この辺りのことはまた当日話せる機会があればお話ししたいです）また、筆者個人としても開催に向けて協力できることがあればしていきたいと考えております。
Bramさんが来日するVimConf2018のプラチナムスポンサーになりました — 株式会社アットウェア
（2年間の想いを詰め込んだので、ポエム調で本記事をお届けすることをご容赦ください。）
今回のVimConfですが、企業としてのコミュニティやIT業界への貢献だけでなく、私の想いも詰め込んだカンファレンスにすることができました。
当日のスポンサーセッションでは、「弊社のような小さな企業でも社員の活動できる間口は広く、コミュニティに大きく貢献できるんだ」ということを話しました。
社内でも、プラチナスポンサーのような規模の企画を立ち上げるのは特別なことで、実はプラチナスポンサーになるかどうか、それなりに悩んでいました。それでも、自分たちにできる最高のことができれば、企業として価値のあり、周りからも素晴らしいと言ってもらえると信じて、スポンサーとなることを決めました。私以外の社員からの後押しがあったのも大きいです。
最初はプラチナスポンサーの提案にもすくんでいたのが、今では自信を持って「素晴らしい事をした！」言えるようになりました。それは、行動に移して、皆さんからの反響を感じたからこそわかった事でした。以前に私が感銘を受けたDropboxの創業者がMITの卒業式スピーチで「良い行動」を示す表現として言っていた、「テニスボール」と「サークル」を例にしたエピソードに似た体験をできたのではないかと感じています。
誤解を恐れず大げさに言うと、「一企業がこうやって貢献できたということに、無限の可能性が秘められているんだ」ということを伝えたいです。 実際に活動してみると、テーマとビジョンを持って「最高のものにしたい」と心の底から思い、本気で取り組んでいるVimConfコアスタッフの皆さんの考え・意思決定・アクションは凄くて、そこから刺激を受けながら、自分もスタッフの一員としていい経験ができました。
こういったスポンサーや個人活動は、弊社くらいの小規模の会社で働いている人にとってもすごくお勧めできるアクションだと言える実感を持ちました。なぜなら、一個人や企業ができることは多くはないかもしれないけど、一人が何かを成し遂げたいと思う原動力（私の場合は「今と未来を繋げるこのカンファレンス」に最大の貢献をしたいという気持ち）は凄まじいと感じたからです。そうした皆の気持ちを、スポンサーとして応援することができれば、世の中にとって掛け替えのないことが実現できると信じています。社内でもこういう事例があと数個でたら、すごいこと（いい意味で）になりそうだと想像してしまうほどでした。
私はVimというモノを通して、使う人の思考や姿勢、工夫が色濃くでることが好きで、今年のテーマ「Vimでより生産的になる方法」はそういう意味でも自分が聞いてみたい話を多く聞くことができました。 個人の主観だけではなく、VimConf2019は昨年に負けず劣らず、素晴らしい場だったと思います。
最後になりましたが、鮭とば（とばっとうぇあ）の印象が強くなってしまいましたが、大事なアピールもさせてください！
弊社ではソフトウェア開発が好きで、顧客の課題解決に自身の技能を全力で注ぎ込める "エンジニア" を積極的に募集しています。
こんな企業で働いてみたいという方、カジュアル面談も開催できますので、ぜひご連絡を！！
リチャード 伊真岡さんをお招きし、「OSSコントリビューションの始め方」「Akkaについて」という2テーマで社内勉強会を開催していただきました。
Scala関連のカンファレンスやbuildersconなどで登壇されているリチャードさんにお越しいただいて話が聞ける大変ありがたい機会でした。
前半は「OSSコントリビューションの始め方」というタイトルで、OSSへのコントリビューションの貢献のモチベーション・仕方・程度などは多様で、まずは「気軽に始めてみましょう」というお話でした。
普段お世話になっているOSSに恩返しの気持ちも込めて、簡単なところから始めてみようと考える機会になりました。
Akkaの歴史から始まり、akka-cluster, akka-persistenceの解説や、 弊社のバックグラウンドに合わせてAkka + SpringBootという切り口で、よく採用しているSpringBootを軸にした視点で比較・解説くださり、盛り沢山な内容でした。
中でも私が印象に残っているお話がAkkaで構築するクラスターとKubernetes等のコンテナオーケストレーションを使ったマイクロサービスという視点でのクラスターの関心の違いについてでした。
図のようにAkkaが意識しているのは1つのアプリケーションとしてのスケールで、Kubernetes等のコンテナオーケストレーションツールではマイクロサービスのようなサービス群としてのクラスターを意識しているということでした。
Akkaクラスターの得意/不得意について実際の利用シーンを交えて説明してくださり、使い分けのイメージが湧きました。
発表を通じてOSSコントリビューションやAkkaについて理解を深めることが出来ました。
今回は座学が中心でしたが、発表の中でAkka Clusteringのハンズオンを行いたいというお話もありましたのでそのような手を動かす機会や、社内勉強会を通じてAkkaへの理解をより深めていきたいです。
リチャード 伊真岡さん、素晴らしい発表をありがとうございました。
近日リチャード 伊真岡さん主催のEventStormingワークショップが開催されますのでご興味のある方は、是非参加してみてはいかがでしょうか。
昨年のVimConfに引き続き、2年連続でプラチナスポンサーになりました。
その想いをご紹介いたします。
VimConf2018でBramさんが登壇され、直接コミュニケーションがあった空間、リアルタイムでのTwitterをつかった感想やフィードバック、あの場が特別であったことは言うまでもありません。
それはコミュニティの情熱、OSSへの貢献、日々の活動の積み重ねの上に実現した場であり、そしてカンファレンスのスタッフがコンセプトを掲げ1年かけてたくさんの議論を経て準備をし開催されていることを深く体感できるものでした。
ニッチかもしれないけど、受ける影響や内容は素晴らしく、自身で体験したいこと・ありたい未来そのものです。
今年はBramさんはいないけど、そんな去年の場を経験した参加者からの発表、新しい息吹を感じさせる基調講演があります。
今一度、「筆者個人・所属会社として今できる最大限の貢献は何か」と考え、最高のイメージを描いたとき、やっぱり今年も継続してプラチナスポンサーをしようという結論に至りました。社内の他メンバーからの後推しをもらって、スポンサー締め切り最終日にプラチナスポンサーをさせてくださいと申し込みました。
我ながら2年連続でプラチナスポンサー（と3年連続スポンサー）になるってすごいことだなと思っています...
当日はスポンサーとして話す時間を頂けるので、思いの丈をお話しさせていただきます！
前回に引き続きかとじゅんさんによる勉強会の第4弾で、ドメインモデリングワークショップの2回目を開催していただきました。
前回のワークショップでは、かとじゅんさんのドメインモデリングワークショップを参考にWalletアプリケーションで登場する概念のモデリングを行いました。
今回のワークショップではそのモデルを利用する側や保存する側などにもフォーカスして、アプリケーションの1つの機能として通して動作するよう実装していきました。
始めに前回のワークショップのおさらいと、1つの機能を通して実装するに当たりクリーンアーキテクチャの解説をしていただきました。
その後JavaチームとScalaチームに分かれ、各チームはモブプログラミングの形式で実装を行っていきました。
前回のワークショップで作成したアプリケーションを、まずはクリーンアーキテクチャの構成に変更していきました。
かとじゅんさんのクリーンアーキテクチャの記事で紹介されている構成を参考にinterface-adaptor、contract-interface-adaptor、use-case、domain、infrastructureというプロジェクトを作成し、依存関係を定義しました。
以下はその記述の一部です。（JavaチームではGradleを使用しています）
build.gradle
project(':interface-adaptor') {
dependencies {
compile project(':contract-interface-adaptor')
compile project(':use-case')
compile project(':domain')
}
}
project(':contract-interface-adaptor') {
dependencies {
compile project(':domain')
}
}
project(':use-case') {
dependencies {
compile project(':contract-interface-adaptor')
compile project(':domain')
compile project(':infrastructure')
}
}
project(':domain') {
}
project(':infrastructure'){
}各プロジェクトが上位のプロジェクトに依存しないことを実装者に強制するために、パッケージではなくプロジェクトで分けるという方法が印象的でした。
今回取り組んだのはウォレットの作成というユースケースでした。
アドバイスをもらいながら、Walletの識別子をULIDを用いたものに変更したり、金額をint型からMoney型という値オブジェクトに変更するというリファクタリングを進めつつ、今回新たに作成したuse-caseやinterface-adaptorについても実装していきました。
interface-adaptorに作成したWallet用のRepositoryはメモリ上に保存する実装をしたのですが、これはcontract-interface-adaptorにあるWalletRepositoryというinterfaceを実装しています。
後に保存先がDBになった場合でも、contract-interface-adaptorに定義したinterfaceを守った上で新しいRepositoryを実装することでuse-caseやdomainが隔離されinterface-adaptorの変更に左右されなくなるので、クリーンアーキテクチャのメリットを体験できる良い機会になりました。
今回のかとじゅんさんによるワークショップではDDDとクリーンアーキテクチャを用いて実際にアプリケーションの1つ機能を通して実装しました。
ドメインモデリングのワークショップを始めるにあたって、参加者から「Evans本やIDDD本を読んだが実際のプロジェクトにどう適用していけばいいかわからない」という意見をもらっていたのですが、この2回のドメインモデリングワークショップに参加して、「ずいぶん実装のイメージが掴めた」という言葉を貰え、非常に有意義な勉強会となりました。
今後は実装に対する理解を深めていきつつも、よりドメインを深く理解するという考え方や手法についてもフォーカスして知見を深めていきたいと考えています。
アットウェアでは、2018年12月より、柴田芳樹さんを講師に迎えて『Effective Java 第3版』研修を開催しています。
『Effective Java』は、かねてよりJavaプログラマにとって必読の書と言われてきました。その最新改訂版として昨年10月に『Effective Java 第3版』(Joshua Bloch著、柴田芳樹訳、丸善出版社)が出版されました。およそ10年振りとなる今回の改訂では、Java9 までの新しい構文・機能が網羅され、現代的な構文を Java ではどのように記述するべきか、示唆に富んだ内容になっています。社内では、普段から読書会が開催されており、当初『Effective Java 第3版』も有志を集めての読書会というかたちで開催する予定でした。しかし、翻訳者である柴田芳樹さんを講師に迎えるという幸運に恵まれたこともあり、研修という形での開催となりました。
柴田さんは、古くからJavaに関わられており、Javaの黎明期から業務としてJavaを利用してきた経験をお持ちです。また、『Effective Java』だけではなく『プログラミング言語Go』の翻訳や、『プログラマー"まだまだ"現役続行』の執筆など、多方面で活躍されています。そんな柴田さんのお話を伺おうと、研修には、入社１・2年目の新人から、開発経験10年以上のベテランまで、10名の社員が参加しています。
研修は、基本的には輪読・記載されている内容の解説・質疑応答という形で進められていきますが、解説される内容は書籍に記載されている内容だけにとどまらず、さらに掘り下げる形でJavaの言語仕様やJVMの仕組み、コンピューターサイエンスにまで踏み込む講義をされることがあります。とくに言語仕様やJVMの解説では、なぜJavaの文法がこのようになっているかという側面から話がすすめられるので、説得力をもったないようで語られます。また、折に触れ柴田さんの業務での実体験が話としてされることがあり、エンジニアとして業務を推進する姿勢や開発に対する意識など学ぶことが多くあります。経験に裏付けられた柴田さんの講義は、新人だけでなくベテランにまで良い刺激になっているのではないかと思います
研修も既に6回を数えており、和やかな雰囲気で進められています。研修の中で書籍のミスを発見する出来事もあれば、休憩時間には『Java PAZZLERS』の問題を解いたり、柴田さんから90年代のJava開発の話を聞くなど、講師と参加者の距離も縮まっており、楽しい時間を過ごしています。
研修は6月で終了予定ですが、この研修を通して、エンジニアとしてより大きく成長したいと思っています
4月18日に三回目となる、かとじゅん(@j5ik2o)さんを講師に招いて、分散処理フレームワークAkkaに関する勉強会を開催しました。 かとじゅんさんは、Chatworkにおいて分散処理の設計に携わったり、技術カンファレンスでAkkaに関する発表をされたりと、Akkaに関する知識の広さを力に活動をされています。
近年、アットウェアでは一部の社員の間でScalaへの関心が高まっています。Scalaを社内に広め、実業務で役立てるための技術推進活動の一環として、今回の勉強会を開催することになりました。社員からは10名程度が参加しましたが、Scala経験者だけでなく、これまでにScalaを触ったことのない社員も参加し、ScalaやAkkaに対する注目度の高さを感じました。
今回の勉強会は、分散処理フレームワークのAkkaを実際に触りながら学べるハンズオン形式で行いました。
ハンズオンの前半では、『Akka実践バイブル』 1〜2章の内容を参加者全員で振り返りました。 アクターモデルが注目されている理由やLet it crash（クラッシュするならさせておけ）、イベントソーシングといったAkkaの基礎的な概念について触れました。
アクターモデルを用いたAkkaアプリケーションが典型的なWebアプリケーションと大きく異なるのは、扱うデータの多くをアクター単位で、なおかつオンメモリで扱うという点です。 アクターという小さな単位で分散処理を行うため、プログラマでもスケールの単位を理解しやすく、またスケールの柔軟性も高い、という点が魅力的に感じました。 また、典型的なリレーショナルデータベースによる設計では、オブジェクトとテーブル構造のインピーダンスミスマッチに悩まされることがありますが、オンメモリであれば、そのミスマッチに悩むことは少なくなります。 一方、永続化や適切なアクターの分割単位のような、今までRDBMSに任せていたことを意識する必要があり、開発者には高度な知識が要求されます。アクターの良さを活かすためには、どういう点に注意するかについて、事前にしっかり押さえておく必要がありそうだと感じました。
ハンズオンの後半の様子です。グループに分かれて、サンプルアプリケーションを改修しています。みんな真剣な表情です。
ハンズオンの後半では、実際にAkkaで作られたサンプルアプリケーションを改修しながら、Akkaへの理解を深めました。 サンプルとして用意されたのは、送金や請求が行える決済アプリケーションです（ j5ik2o/wallet-akka ）。 前回開催したドメインモデリングワークショップと同じお題ですが、前回のクラスベースの実装とは違い、今回はアクターモデルにより実装されています。
参加者は3つのグループに分かれ、実装されていないテストやメッセージの受信処理などを各々実装しました。
サンプルは、前回と同様にDDDのエッセンスが含まれているほか、通常のAkkaで実装されたアクターに加え、メッセージを型安全に扱えるakka-typedを利用したアクターの実装例が含まれており、新しいAkkaの機能にも触れることができました。 かとじゅんさんによる解説やコードリーディングを通して、アクターはどのような単位で作るべきなのか、メッセージのフォーマットはどのようにすべきかなど、アクターモデルで設計するうえでの基礎的な考え方を学ぶことができました。
あるグループがサンプルアプリケーションを改修している様子です。いい笑顔ですね。
今回のハンズオンを通して、Akkaの具体的で実践的な書き方に触れることができ、たくさんの学びがありました。 百聞は一見にしかずというように、実際に使ってみることで学び取ることができることは非常に多いと感じました。 かとじゅんさんには、今回のハンズオンを快く受け入れてくださり、当日も親身になって丁寧に教えていただきました。ありがとうございました。
アットウェアは、これからも新しい技術を学びながら、日々成長していきます！
ヌーラボ木村さんを招いて発表形式の勉強会を開催しました。
Kubernetes Meetup Tokyo #14 に弊社メンバーが参加した時に「イイ話だった。もっとお話を聞きたい」という声が出て、オファーをださせて頂き、快諾頂いて実現するに至りました。今回の為だけに業務を調整して、福岡から飛行機で駆けつけくださり感謝です。
最近、このような頻繁にゲストを招いて勉強会の開催が実現している様子をみると、普段の社内の声って大事だなとつくづく感じます。一歩踏み出し、アクションをすることができれば、色んなわくわくすることができたり、向かいたい方向へ前進できてイイ感じです。
そして、今回のKubernetes勉強会の内容の話題に移っていこうと思います。
開催にあたり、参加者の層やどんな話が聞きたがっているのかを事前に会話させてもらい、以下のようなテーマを候補を出していただきました。
ついつい全部関心があると言ってしまいそうになるところですが、参加者をアットウェアエンジニア全員として案内をする予定なので、基礎や浅いところにも触れていただき、なぜKubernetesにしようと思ったか、調査や導入前段の思考をお話を聞けると、幅広い層にもリアル感が伝わっていいかなと考えています。
というようなご相談をさせていただきました。
また、Kubernetsに特に関心があったりKubernetes Meetup Tokyoに参加したメンバーの中で以下のような話も聞いてみたいというニーズがありました。
これらのお話は「ぜひ懇親会でも更にお聞きできたら」ということを木村さんにお伝えし、当日の勉強会のテーマが決まっていったのでした。
開催された勉強会では、木村さん自身が関わっているCacooの開発を続ける中で、積み上げられた歴史を知る木村さんだからこそ伝えられる、オンリーワンなすごくいい発表を聞かせていただきました。
書きたいことは他にもいっぱいありますが、控えめに言って最高すぎたということで、この辺りで筆をおきたいと思います。 今回の内容とは全く同じではありませんが、木村さんがKubernetes Meetup Tokyoで発表されていた動画が公開されています。ご興味ある方は、ぜひ一度見てみてはどうでしょうか。
素晴らしい発表どうもありがとうございました！
