株式会社アットウェア 代表 牧野隆志 インタビュー動画 第２段として、牧野が最近挑戦していることについて聞いてみました。アットウェア、アットウェアベトナム、個人としてどんなことに目を向けているでしょうか？
株式会社アットウェア 採用チャンネルはこちら
２０２１年１１月
株式会社アットウェア 代表 牧野隆志 インタビュー動画 第１段として、株式会社アットウェアの経営理念である「システムで人々をしあわせにする」について話を聞きました。
株式会社アットウェア 採用チャンネルはこちら
２０２１年１１月
アットウェアの魅力を映像でお伝えしたくて、採用向けYoutubeチャンネルを開設しました。今後不定期ではありますが、動画をアップロードしていく予定です。
第１段としては、アットウェアの簡単な紹介ムービーです。
動画内容の概要
「システムで人々をしあわせにする」をミッションとしている、株式会社アットウェアの会社紹介動画です。
SI事業について
弊社のSI（システムインテグレーション）事業は、主にエンタープライズ（企業向け）に特化し、顧客企業のビジネスを動かす上で必要不可欠なシステムの開発を行っています。
働き方について
システム開発をする上で、顧客企業と「恊働」を行うためのワンチームを結成します。 株式会社アットウェアの社員は、お互いフラットな関係で働いています。上司・部下という関係や、役職（部長、課長、係長）というものはありません。一人ひとりが自分の働き方をし、創意工夫、意思決定おこない生き生きと活動しています。また、個々の能力を最大化できるよう自律型組織の文化を形成しています。
オフィスについて
私達はWeworkコミュニティを通して出会う様々なタイプの人と共創により価値を作り出すことも非常に重要であるとの狙いを持ち、2019年2月に横浜みなとみらいのWeworkに入居しました。残念ながら2020年初頭より新型コロナウィルス感染症の蔓延により、現在はテレワークを強く推奨している状況です。一日も早い、コロナウィルスの収束を願っております。
こちら、Vyondというアニメーション動画作成ツールを利用して作っています。
始めに
こんにちは、21年新卒の中山と申します！
21年新卒の研修が、7月いっぱいで終わり、8月からOJTという形で新卒４名（西川、平澤、吉井、中山）がそれぞれ違うプロジェクトに参画し、少しずつ開発に入っております。
そこで、このブログでは
- 研修を振り返ってみて研修がどうだったか
についてお伝えしたいと思います！🔥
研修を振り返ってみて研修がどうだったか
研修を通してどんな成長を感じられたか
中山：
吉井さんに、「研修を通してどんな成長を感じられたか」について伺ってもいいですか？🙋
吉井：
僕たちの今年の研修は、自身で得たい価値に即した目標を設定するセルフ・コントロール型研修だったので、自身で設定した目標を確実に達成し成長していく実感が得られました。
今までは目先の結果に注力してしまい今やる必要がないことはやらないことが多かったのですが、研修中は自分が結果を出し続けていくために必要な土台作りとして、今すぐ必要はないものの重要なことに注力し学ぶことができました。
技術面だけではなく、人として成長をし続けられる良い習慣を身につけることが特に成長した点だと感じています！
中山：
めちゃめちゃいいですね。
確かに、自分で得たい価値に即した目標を設定するから、中長期的な視点でどんなことを研修ですべきか考える必要があって、緊急性は低いけど、着実に良い習慣を身に付けるような考え方は僕も勉強になりましたね🔥
吉井さん、ありがとうございました！🎉
研修で難しかったところ
中山：
それでは、平澤さんに、「研修で難しかったところ」について伺ってもいいですか？
平澤：
そうですね。僕は、「セルフ・コントロール」という言葉を「何事も自力で解決すべき」と解釈してしまっていた場面が多くあったので、研修の初期では、何か困ったことがあってもなかなか仲間を頼れなかったんです。けど、このままだとよくないなと思い自ら質問をできるだけするようにしたんです。そうすると、少しずつ「何事も自力で解決すべき」という考え方から外れることができて、チームで協力して、それぞれの得意分野を出し合いながら進めていけるようになりました！
中山：
セルフって言葉を聞くと確かに、「自分で」という意味になるので、一人で全て決めて目標決めて頑張る、ように思ってしまうかもしれないけど、仕事は一人ではできないし、チームで成果を出すものですもんね、、。僕自身、平澤さんが徐々に自分が分からないことなどを同期とか先輩に積極的に聞いていて、とても素敵な姿勢だなあって思ってました☺️
平澤さん、ありがとうございました！🎉
配属に向けての意気込み
中山：
それでは最後に、西川さんに「配属に向けての意気込み」を伺ってもいいですか？
西川：
はい👍
配属先のプロジェクトでは、日本とベトナムのメンバーが混じったチームでBtoB向けのソフトウェアを開発します。
英語メインのチームで常に考えることが求められる環境ですが、自ら配属希望を出しました。
異なるバックグラウンドを持った人々と関わる中で、エンジニアとして成長し、プロジェクトのさらなる拡大に寄与したいと思っています。
中山：
西川さん、入社した当初からすごくベトナム推しだったので、配属希望出したときに「やっぱり！」と思いましたね笑
英語メインのプロジェクトで大変なこともあるかと思いますが、西川さんのガッツで乗り切ってください🔥
西川さんありがとうございました！
最後に
中山：
はい、ここまで21年新卒の同期3人に研修についての感想を聞いてみました！
アットウェアでは、それぞれの社員がどんな姿になりたいか、どんな価値を生みたいかを考え、そしてその姿になるためには、またその価値を生み出すためにはどんな目標を立てどんな研修をするかを自分たちで決めます。研修中には、悩んだり、一人では達成が難しいこともありますが、そんな時は仲間と相談しながら研修を進めていきます。アットウェアに何となくでも興味がある方はぜひ下のリンクなどからお問い合わせください！それではまたのブログ更新をお楽しみに！
春ですね。弊社に、新しい仲間が４人入社いたしました！
本年度の研修もスタートしています。
昨年度から、セルフ・コントロール型研修を実施しました。研修が終わり、そのふりかえりを行い、本年度の研修を見直ししました。 このブログでは、昨年の研修のふりかえりと、本年度の見直した部分をお伝えしようと思います。
セルフ・コントロール型研修
短くいうと、研修者と運営者が設定したゴールを共有して、ゴールまでのプロセスを研修者の裁量で決める研修です。
弊社で取り組んでいた過去の研修内容を参考に、どのような研修内容を行うか、「カリキュラムは？」や「タイムテーブルは？」「担当は？」など組み立て、社員のいろいろなアイデアを募って、紆余曲折しながら、研修の設計をしていました。
並行して、一昨年の弊社で 『７つの習慣』読書会 を行ってました。
『７つの習慣』の「Win-Winのマネジメント・トレーニング」を読んで、「セルフ・コントロール型研修」に、手段を本人に任せることで、個々人の潜在能力を最大に活用し、主体性をはぐくむ実践経験ができる理想の研修を見出しました。
私達は、研修者が研修後にどのような能力を身に着けているべきか明らかにして、研修者を全面的に信頼し、手段を押し付けないことで、早く目標達成しようと意欲的になり、望む結果にも、相手の成長にもいち早くつながると、考えました。
そこで、セルフ・コントロール型研修になるように、研修者へ全面的なデリゲーション（手段は自由に選ばせ、結果に責任をもたせる）のもと、何が期待されているかお互いに理解し、納得するために「実行協定」をまとめました。
「実行協定」
- 望む結果(カリキュラムの各ゴール)
- ガイドライン（守るルール）
- リソース（望む結果を達成するために使える人員・資金etc）
- アカウンタビリティ(研修なので、理解度の報告)
- 評価の結果（OJTへの移行の可否）
カリキュラムは、ハードスキルとソフトスキルを体系化し、各課題のゴールを設定しました。
昨年度のふりかえり
研修が終了し、KPTにそって、ふりかえりを行いました。
Keep
- ボリューム総量がちょうどよかった。
- コロナ禍以降も、担当＆研修者で制御できた。
Problem/Potential
- 報告のフォーマットを用意したことで、報告書を書くことがゴールと捉えられ、ゴールまでのプロセスに自由度（創意工夫）が制限された。
- 研修後、どんな姿になっているかを描いていないので、各課題を消化するだけになってしまった。
Try
- カリキュラムは最低限を定義し、研修者に研修後のイメージ・目標を最初に想像していただき、カリキュラムに入れたいこと（希望）を盛り込む。
- 報告の手段も自由にする
今年のセルフ・コントロール型研修
ふりかえりを受け、今年の研修は、事前に、内定を承諾頂いて以降、新入社員の方々と研修内容のすり合わせの時間をいただきながら、研修内容を組み立てました。
そして、研修後のイメージ・目標を見出すことを先に行うために、セルフ・コントロール型研修より、前に以下のイベントを行うことにしました。
- ドリームマネジメント：自分の夢の解像度を上げる。
- ミッションステートメント研修：自分の軸（原理・原則）を見い出す。
今年の研修は、もう一つ願い（テーマ）を込めました。
「P/PCのバランス」
研修は、P（成果：Performance）よりも、PC（成果を生み出す能力：Performance Capability）に重きを置いて、活動する。
（すでに始まっていますが、）これから、新しい仲間が、ワクワクして成長に取り組めるような研修にしたいです。
研修の終わりには、研修をうけたみんなより、レポートをお伝えしようと思います。
株式会社アットウェアは、新型コロナウィルス感染症の日本国内での感染拡大に伴い、弊社従業者を原則在宅での勤務としております。 在宅勤務中におきましても可能な限り業務遂行を維持する体制を取って参りますが、郵送物の取り扱いの遅延ならびに弊社代表電話からの担当者への取次時など、ご不便をおかけすることが予想されます。 お取引先様各位におかれましては、ご理解のほど何卒よろしくお願い申し上げます。 なお、お急ぎの場合は、名刺等に記載の担当者連絡先へ直接ご連絡ください。
私たちはミッションである「システムで人々をしあわせにする」の実現に向け、プロフェッショナルなソフトウェアソリューション・サービスを提供しておりますが、在宅勤務中におきましてもこれまでと変わらぬあるいはそれ以上の価値の創造を果たしていけるよう、日々の改善と努力を積み重ねて参ります。新たな挑戦故、ご迷惑ならびにご心配をおかけすることも多々ございますが、ご容赦いただけますようお願い申し上げます。
この難局を乗り越え、一刻も早く日本および世界の全ての人、社会が再び平静を取り戻し、またさらなる経済発展と平和の実現に向け、地域社会の一員として弊社社員一同取り組んで参る所存です。
※※※ 2020年6月30日更新 ※※※
株式会社アットウェアは、新型コロナウィルス感染症の日本国内での感染拡大を受け、3月中旬より弊社従業者を原則在宅勤務としておりました。
5月25日に首都圏の緊急事態宣言が解除されてから一ヶ月ほどが経過し、間もなく当初在宅勤務期間として予定しておりました6月30日となりますが、未だ従業者が安心して安全にオフィスに通勤ならびに就業できる状況とはいい難く、また通勤が避けられないエッセンシャルワーカーの方々などへの接触を少しでも避けるため、引き続き在宅勤務を推奨して参ります。期間については、現時点では明確には定めず、概ねワクチンが広く行き渡るなど状況が改善されるまでといたします。
なお、弊社はこれまでも従業者個人の状況に応じて在宅等での勤務も認めておりましたが、今後はより自分らしい働き方・生き方に重きをおいた多様な就業形態も視野に社内で議論を進め、取り組んで参りたいと考えております。
期間： 2020年6月30日まで 未定（概ねワクチンが広く行き渡るなど状況が改善されるまで）
縁あって@kmizuこと水島宏太さんに社内の技術推進活動の支援をいただいています。
その活動のひとつとして勉強会を開催したのでご紹介します。 コロナ禍の影響でオンライン勉強会です！
水島さんの経験や得意分野を踏まえ、弊社社員からテーマをリクエストさせていただき、アカデミックな話題も混ぜつつ、時にはマニアックな内容も盛り込んでもらっています。
ブログでは紹介できていませんでしたが、昨年より勉強会を開催してきました。
- ガベージコレクションの基礎と歴史
- 基礎の学び方
- コンピュータサイエンスって何だろう？
- Scala教育悲喜こもごも
- Javaのジェネリクスを知ろう
この記事では、先週開催された「Javaのジェネリクスを知ろう」の勉強会レポをご紹介します。
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章に渡る本ですが、各章ごとにテーマ・内容が異なっているので各章ごとに書きます。
第1章 Java 9 から 14 までに起こった変化から見るこれからのJava
ちょっと前に混乱をもたらした Java のライセンス変更は記憶に新しいですが、それ以外にも、Java 界隈では Java9 以降現在にいたるまで様々なことがありました。短期間にたくさんのことがありすぎて、情報がオーバーフローしてしまった方もいるのではないでしょうか（少なくとも私はそうでした）。また、その情報も、テック系ブログをはじめ、さまざまなところに分散していて、まとめるのも大変でした。
この章では、その Java 界隈の状況の変化が見通しよくまとめられています。
内容としては、Java 界隈の変化を押さえ、Java 開発体制から、Java9 〜 14 までのリリース内容概要、新しい言語仕様の紹介、これからの機能などがわかりやすくまとめられています。
過去と比較して、何ができるようになったかが把握できるのもさることながら、紹介されている機能・仕様が「何故そのようになっているか」にも言及されていて、現在の Java の機能がいかに使いやすくなっているかがよく理解できました。
第2章 JDKに関する疑問と不安解消！ JDKディストリビューション徹底解説
Java リリースモデルの変更があり、その後、雨後の筍の様にたくさんのJDKディストリビューションが現れました。これらのディストリビューションのうち、どれを業務で利用するか迷った経験をお持ちの方は多いのではないでしょうか。
この章では、JDKディストリビューションの歴史から、現在どのようなJDKディストリビューションがあり、どのような特徴をもっているのかが網羅的に解説されています。さらに、どのように選ぶべきかという方針についても言及されています。
これを読んでおけば、JDKディストリビューション選択時のステークホルダーに説明する材料に困ることはないでしょう。
個人的には、BellSoft Liberica JDK が初耳だったので、ちょっと試してみたいと思っています。
第3章 JavaEEからJakartaEEへ 新しいEnterprise Java
20年ぐらい前にJ2EEを使っていましたが、そのときは設定が多く、柔軟性が少ない堅い印象。Java EE7 のときはてらだよしおさんが JJUG ナイトセミナーですごく推してた記憶。その後は進化が滞っていて、今後は余り使うことはないだろう。個人的にはそんな印象の Java EE ですが、 近年開発が再び動き出しています。そんな Enterprise Java の過去から現在についてまとめられています。
この章では、Enterprise Java にフォーカスして、その歴史やアーキテクチャの変遷、最新の Jakarta EE 8 の機能について、網羅的に解説されています。
序盤の歴史の部分は、J2EE を触ったことのある私からすると歴史書的な印象もありましたが、Jakarta EE8 の新機能の部分では、モダンな Java フレームワークの機能を積極的に標準化していこうとする姿勢がよくわかり、変わろうとしているんだ、ということが感じられました。
Enterprise Java の標準としてまとまることで、より開発しやすくなることに期待します。
第4章 MicroProfile が拓く Java のマイクロサービス
前章をうけて、Java EE から派生したマイクロサービスのためのAPI、MicroProfile について書かれています。マイクロサービスは流行っていますが、実装パターンは様々で、開発に時間がかかってしまう印象です。そんなマイクロサービスの実装でみんなが苦労している部分を標準化しようというのが MicroProfile です。
この章では、MicroProfile が産まれた経緯と、その実装方法、機能、そして今後の発展について説明されています。
マイクロサービスとして開発するかどうかは要件によってかわるかとは思いますが、いざマイクロサービスを利用する、となったときにこうした標準があることは助かると思いました。個人的には、今後の発展に含まれていた、「Reactive対応」「LRA対応」が興味深かったです。とくに、LRA（Long Running Actions）についてはマイクロサービスを作る上でいつも悩まされていたことなので、今後の動向に注視していきたいです。
第5章 ネイティブイメージ生成で注目! Java も他言語も高パフォーマンスGraalVM
昨年行われた JJUG CCC などのイベントでも、GraalVM と名のつくセッションは人気でした。その事実からもわかるように、GraalVM は、おそらくいまJava開発者の間でもっとも興味が惹かれている技術ではないでしょうか。
しかし、昨今のFaaS勃興の背景から、GraalVM はどうしてもネイティブコンパイラにフォーカスしがちです（私もその一面しか見ていなかった感じです）。しかし、GraalVMはそれだけでなく、多言語実行環境としての一面もあります。
この章では、GraalVM と HosSpot VM の内部構造を比較し、Graal VM がどのように動作しているのか、如何にして多言語実行環境を実現しているのか、ネイティブコンパイラがどのように動作しているのか、などが記載されていて、いままで曖昧だったGraalVMの全体像が明確に見える思いでした。
また、GraalVM の具体的な適用事例も幾つか紹介されており、この中でも興味深かったのは、リアクティブストリームを使ったアプリケーションにおいて、JITコンパイラをGraalVMのものに置き換えることで、最適化が図られる可能性があるという内容でした。
このことが必要になる大規模なプロジェクトはそう無さそうですが、今後の引き出しとするためにも、手元で試してみたいと思います。
第6章 マイクロサービス、クラウド、コンテナ対応
最後は、最近のJavaというより、Java界隈のフレームワークについての内容です。
Javaのフレームワークは、現在では Spring Boot が隆盛を極めているように思えますが、システムのクラウド化にともなうフレームワークに対する要求の変化から、新しい軽量なフレームワークが数多く誕生しています。その中から、Micronaut / Quarkus / Helidon を実際の実装・コード例を通して紹介しています。
実際に記載されている内容通りに手を動かすことで、ハンズオン的に各フレームワークの機能を知ることができますが、個人的に重要と感じたのは、最近のフレームワークに求められているものについての記事でした。
昨今のクラウドやマイクロサービスが求められているなかで、新しい軽量フレームワークには可搬性（Portability）や観測性（Observability）、非同期処理などが求められているとのこと。とくに「観測性」については、強く言及されている印象で、私も業務中、実装しているときに忘れがちな側面ではあるので、紹介されている軽量フレームワークを試しながら、どのように実現されているのかを確認したいと思います。
まとめ
Java開発をやってきた人の中には、長く進化が止まっていた時代のイメージから、「枯れた技術で長く続ける」という発想を持っている人もいるかと思います。しかし、時代は移り、Java は半年ごとに機能追加が行われ、常に新しいパラダイムを取り込むようになりました。
そうした状況の中、この本は、Java 開発者が今まさに読んでおくべきものだと感じました。一年後では遅いです。なぜなら、今の Java は進化を続けていて、数年後には、この本に書かれていることに加えて、さらに新しいパラダイムがやってきているかも知れません。
Java を使う開発者である我々も、常に新しい技術を学んで、この先生きのこれるようにしなければなりません。また、世の中のシステムが陳腐化することも避けたいです。
この本の序文において、著者の一人であるきしだなおきさんは以下のように書かれています。
Java はみんなで作るものになりました。
この言葉は、言語開発者にだけ向けられた言葉ではないと思っています。 我々開発者も、新しい技術を学び、学んだ知識を共有して、よりよいシステムをつくれるようにしていきたい。
この本を読んでその思いを新たにしました。
すえなみさんが主催している「すえなみチャンス」が面白そうだなと思って、アットウェアで逆すえなみチャンス的なことが開催できたらいいなという所から、トントン拍子で話が進み実現しました！
「すえなみチャンス」についてご説明をすると、参加者はすえなみさんの知りたい話をトークする代わりに、すえなみさんに焼肉をご馳走してもらえるというイベントです。それの逆バージョンをしてみたいというのが、今回の趣旨です。
開催レポを書いたのでご紹介します。
TL;DR
- 二部に分けて開催したことで参加者が楽しめ、エッジの効いた雰囲気を作ることができた
- 楽しめるように企画して楽しんだ！
- 逆すえなみチャンスはプチカンファレンスかと思うくらい最高の時間だった
- またやりたい
- アーキテクチャを体現するということは強いメッセージ性があるので、感受性を養ってコミュニケーションしたり表現する事が大事。
第一部
第一部は、スライドを使ったオーソドックスな発表形式で、お話を聞かせていただきました。
発表者はすえなみさんと、すえなみさんをご紹介頂いたかとじゅんさんをお招きし、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 で木村さんがストリーム処理について発表されていたことを教えてくれました。
そこで「社内勉強会をお願いしよう！」と発案があり、共通の知人を経て木村さんにオファーをして快諾いただけたことで、今回の勉強会が開催されることとなりました。
「入門」という名の「全部のせ」
勉強会のタイトルは「ストリームデータ処理入門」でしたが、タイトルに書いてある「入門」以上の充実した内容でした。
「ストリーム処理とは何か？」という基本的なところから、その基盤や構造、利用方法まで、開発者がおさえるべきポイントを幅広く解説され、そのカバー範囲の広さはまさに「全部のせ」。
アジェンダを資料から引用してみましたが、その内容の充実ぶりがおわかりいただけるでしょうか。
- What is Stream Processing?
- Data processing patterns
- History of Stream Processing System Architecture
- Trouble of Stream Processing
- Stream Processing system structure
- Technical consideration points
- Real Stream Processing performance problems
- Stream Processing system misconceptions
当日はこちらの資料を使ってお話してくださいました。
それぞれの項目の内容もとても充実した内容で、木村さんも知識を共有しようと熱く語ってくださいました。 その情報量はあたかもバックプレッシャーのないストリーム処理のよう。 私も、情報を取り逃すまいと集中して聞いていました。
特に印象に残っているのは、「バッチ処理はストリーム処理のサブセットである」という概念。 「バッチ処理は、無限であるデータストリームを、一定時間ごとに区切って処理する、ストリーム処理の限定的なモデルである」という考え方ですが、今までバッチ処理とストリーム処理の関連性を意識していなかった私にとっては、目から鱗が落ちるような思いがしました。
勉強会を終えて
今回の勉強会は内容が盛りだくさんで、私もいまだ全て消化し切れていません。
しかし、これまで大まかな理解だった大規模ストリームデータ処理について、どのように構築して、どのようなところに注意するべきか、イメージが明確になったと感じています。 また、弊社で進めているストリームデータを扱うプロジェクトにおいては、勉強会で紹介された処理基盤プロダクトではない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へのコントリビューションの貢献のモチベーション・仕方・程度などは多様で、まずは「気軽に始めてみましょう」というお話でした。
普段お世話になっているOSSに恩返しの気持ちも込めて、簡単なところから始めてみようと考える機会になりました。
後半：Akkaについて
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作成のユースケース
今回取り組んだのはウォレットの作成というユースケースでした。
アドバイスをもらいながら、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 基礎知識
- Cacoo の Kubernetes 環境
- Cacoo の Microservices 事例
- Kubernetes のつらみ
- Kubernetes Tips 、便利ツールなど
ついつい全部関心があると言ってしまいそうになるところですが、参加者をアットウェアエンジニア全員として案内をする予定なので、基礎や浅いところにも触れていただき、なぜKubernetesにしようと思ったか、調査や導入前段の思考をお話を聞けると、幅広い層にもリアル感が伝わっていいかなと考えています。
というようなご相談をさせていただきました。
また、Kubernetsに特に関心があったりKubernetes Meetup Tokyoに参加したメンバーの中で以下のような話も聞いてみたいというニーズがありました。
- Kubernetes meetupで発表された内容をさらに深掘りした話
- 導入後の苦労や運用周りの話
- マイクロサービスの周りのアプローチを、どういう風にKubernetesのオブジェクト単位にまで落とし込んでいったかという話
これらのお話は「ぜひ懇親会でも更にお聞きできたら」ということを木村さんにお伝えし、当日の勉強会のテーマが決まっていったのでした。
開催された勉強会では、木村さん自身が関わっているCacooの開発を続ける中で、積み上げられた歴史を知る木村さんだからこそ伝えられる、オンリーワンなすごくいい発表を聞かせていただきました。
当日の勉強会で印象に残っていること
- マイクロサービスと国際的なロケーションを組織にあわせた形でうまく融合できるようになってきたという話。
- 最初うまくいかなかったところや工夫も聞けてよかったです。
- 明確なオーナーシップを持つことでうまくいったそうです。
- 使っているフレームワークや言語は多彩であった
- その中でも独自のルールをなくして、標準的なルールに従うようにするアプローチをとった。
- 新しいメンバーが入ってきても伝わりやすいというメリットを享受。
- 本番環境とステージング（ベータバージョン）の使い方とアプローチ方法
- コストの考え方
- インフラコスト（メモリ使用量なども含め）は上がることが多い
- AWSが儲かるアーキテクチャなんじゃないかな（笑）。だからみんなプッシュしているんですよ。（笑）と談話
- ↑は半分冗談まじりな言い方ですが、メリットがあるからやっている
- システムのスケールに加えて、複数拠点などの働き方・開発チーム自体もスケールできた。
- 仕様を変えて進めていく時のやりやすさ
- こういう話を弊社（アットウェア）のエンジニアが聞いたことを会話し、トレードオフや共通理解を深めていけると感じた。
- インフラコスト（メモリ使用量なども含め）は上がることが多い
- 懇親会でも刺激を受けた
- 木村さん自身が関わったKubernetes周り以外のナレッジもチームメンバーから得て、勉強会で展開したり、自身の学び・仕事に活かしているとのこと
- チーム内で各々が素晴らしい関係が築けていることがわかるというエピソード。
- 実は私と数名が横浜で行なっている個人活動のコミュニティの勉強会が、木村さんにとって勉強会デビューだったという出会いのミラクルな事実が発覚。
- 木村さん自身が関わったKubernetes周り以外のナレッジもチームメンバーから得て、勉強会で展開したり、自身の学び・仕事に活かしているとのこと
最後に
書きたいことは他にもいっぱいありますが、控えめに言って最高すぎたということで、この辺りで筆をおきたいと思います。 今回の内容とは全く同じではありませんが、木村さんがKubernetes Meetup Tokyoで発表されていた動画が公開されています。ご興味ある方は、ぜひ一度見てみてはどうでしょうか。
素晴らしい発表どうもありがとうございました！
今日は、とある日に実施したレトロスペクティブ（ふりかえり）についてご紹介します。
紹介内容は、場の目的にあっていると思うアクティビティ（ふりかえりの場で用いる手法）を選択したというお話で、実施して感じたことについて触れたいと思います。
TL;DR 3行まとめ
- フェーズやメンバーの思いに合わせてレトロスペクティブのやり方を変えて試してみたらいい感触を得られた。
- レトロスペクティブをどんな場にしたいかという認識を合わせてから本題に入ると、どのような場にするのかという指標になり、場がイイ感じで流れるように進んだ。
- 目的に合わせてアクティビティを選択することで、効果的にレトロスペクティブを進めることを実感できた。
レトロスペクティブ（ふりかえり）といえば
弊社でもよく使われるレトロスペクティブの手法で「KPT」がありますが、レトロスペクティブのやり方は一つではなく、レトロスペクティブの場をどういう風に過ごしたいかで、アクティビティを使い分けられるといいなと、以前から思っていました。
場に集まる人の発言は、感情・関係性・過ごした日々の行い・日々の長さといったものを抜きには語れません。
その場に各自がどう挑むか、意義を感じられるか、状況をどう理解しているかは今後の振る舞い方や日々を過ごすアクションに大きく左右するのではないでしょうか。
そこで、今回は、アジャイルレトロスペクティブという書籍で紹介されていた、目的毎に向いている手法を組み合わせてやってみました。
私たちはどんな集まりか？
その日は、社内インフラやセキュリティに関わっているメンバー4人が集まりました。 専任の前任者から4人が引き継ぎ、チームとして活動しており、ざっくりいうと職場環境の維持や改善の対応に取り組んでいます。引き継いでから1年半程度が経っており、日々のタスクやチームはうまく回っているが、少し安定しすぎているチームです。前回のふりかえりから長い日々を過ごしたので、自分たちの今後のことも考えていきたいねと事前に話していました。
私たち、チームとしては「目標」「データ取集」よりも、個々の考えを元に「今後の活動方針」を合わせていきたいという各自が関わる意義を再認識したいフェーズと捉えています。
そこで今回やったレトロスペクティブの紹介
前提事項をお伝えするのが長くなってしまいましたが、今回やったKPT以外の手法（アクティビティ）をご紹介したいと思います。
選んだアクティビティ
1つ目: 場を設定するアクティビティ 「ESVP」
まずは集まってレトロスペクティブを開始する時の準備のアクティビティです。 この種のアクティビティを実施することによって、自分たちがどう思っているのか、温度感などを知ることができます。
有名なものだと「チェックイン」あたりですね。
私たちが今回選んだのは「ESVP」です。これは長いイテレーションを過ごした時に適しており、「レトロスペクティブの作業にフォーカスできるように、みんなのレトロスペクティブに対する考えを理解する」目的として最適とのことです。 面白いのが、4つの立場に分類して自分がどう思っているのかを伝えるが、他の人には自分がどの立場かは知られないということです。
よく言われる心理的安全性を確保して、発言を促せるという工夫があることに気づきました。
4つの分類
各自のレトロスペクティブの場にいる温度感そのものです。
- 探検家：新しいアイデアを見つけたいと熱心な人。
- 買物客：情報を見渡してて、アイデアを知りたいという人。
- 行楽客：レトロスペクティブの作業には関心はないが、他のことをしているより良いと思っている人。
- 囚人：参加を強制されていると思っている人。
書いて捨てた
一人が全員から集めた付箋をみて、集計し書き出しました。 付箋は破ってゴミ箱に捨てることにより、誰がどの立場かはわからないけど、どういう人がどれくらいいる事実だけはわかっています。
結果を見てみると、想像していた通りではなく、ズレすぎず、面白かったです。 この場をどうしていくかの指標になりました。
2つ目: 何をすべきか決定するアクティビティ 「質問の輪」
次のアクティビはこの場で「何をすべきか決定する」です。 今回の場では洗い出しを行うつもりはもともとなかったので、感情・想いをベースに話を進めたり、均等に考えを引き出すことに重きをおきました。
このアクティビは、「次のイテレーションにおける試みやアクションステップをチームが選びやすいようにする。特にチームメンバーがお互いの意見を聞く時に使用するとよい」そうです。
私たちにぴったりです！！
ファシリテーターをおかず、均等に発言したり声の大小にかかわらず、しゃべる・聞くということがテンポよく、うまくできるという仕組みです。
やり方は簡単 質問に答えて質問をするだけ
円になって座り、最初の回答者を決めて「次のイテレーションで取り組みたいことはなんですか？」の質問に自身の考えを述べてもらいます。 これまでのやりとりを踏まえたうえで、自身の考えを述べて、さらに次の人に質問をするという流れです。これを2周くらいすれば、質問がブラッシュアップ・深掘りされて、気づけばいい感じにアクションが具体化と合意に近づいていきます。
どうだった？
ESVPの流れから、私たちがこういう状況にあることをどう思うか？から始まり、実はお互いが状況に応じて補完しあえる関係にあって、バランスよく活動できていることを知ることができました。 話題が自然と落ち着いていき、他人の考えやスタンスを知れることによる、心のゆとりや今後も続けていくことの障害がないことがわかったのです。
長いことやっていると人の参画・移動に関する話もあがって、そこのあたりの考えも知れて良かったです。 毎回だと窮屈になってしまうかもしれないと思いましたが、たまにこういう形でやるといいですね。 非常に生産的に話が進んでいった気がしました。
3つ目: レトロスペクティブを終了するアクティビティ 「感謝」
「ポジティブにイテーレションやレトロスペクティブを終える」目的に利用できるそうです。 長い期間やっていると日々あったこと、心に思っていたことをあらためて感謝の意を込めて感謝を伝えられるのははうれしいものです。
感謝することは任意で、誰も話さない時間がきたら終わるという、実施方法となります。
自然とでる言葉たち
この業務に関わっている人全員が、主たる業務というわけではなく、時間を確保をして協力しながら活動を進めています。 時には個々人が主たる業務のピークがきて、動きが鈍くなってしまう時もあります。 そういう時に誰かが主体的にやってくれたことはよく覚えていて、感謝の言葉が出ることが多かったです。
不思議なものですよね。自分がやった時のことは覚えていないのに、やってもらった行為はよく覚えているというのは・・・
このレトロスペクティブをとおして
終わってみると、普段よくやっている
- ブレスト
- タイムライン
- KPT
などでおこなう「データの収集」「アイディア出し」「何をすべきか決定する」とは違うアクティビティで、終わった時の気持ちの感覚も独特のものがありました。求められていること・貢献したいこと・状況が変わることによって、立場を表明して立ち去ったり新陳代謝するは必要だと考えています。そういう時に、「いい意味でうまくできそうだな」という手応えが掴めました。自分たちが、なぜこの場にいるのか、考え続けたりやり方を工夫することの大事さをあらためて感じられました！
1時間30分があっという間で、いい時間を過ごせたと思うので、応用して他の場でも色々なアクティビティを選んで使ってみたいなと思いました。
株式会社アットウェアは、WeWorkが日本において東京都区外にはじめてオープンしたWeWork Ocean Gate Minatomiraiに本社オフィスを移転、WeWorkコミュニティのメンバーになりました。
WeWorkとは、米国ニューヨーク市に本社を置く、スモールビジネスや起業家向けのシェアオフィスを提供するスタートアップで、2010年に創業の後、すでに世界100都市／500ヶ所以上のロケーションに広がるグローバルネットワーク、コミュニティです。
What Is WeWork? より引用:
WeWork は、企業や個人が成長していくためのワークスペースを提供するグローバルネットワークです。あなたがクリエイティビティを発揮し、仕事に集中しながら、人的ネットワークを拡げられるオフィス環境を提供することで、仕事を豊かな人生に変えるお手伝いをします。ここで仕事をする本当の意義を見つけることができれば、メンバー間のコラボレーションが生まれ、オフィスが自宅のようにくつろげるスペースとなるはず。あなたもきっと月曜日にこのオフィスへ来ることが待ち遠しくなることでしょう。
本社オフィスの移転は、業務拡大による空間的な制約からの開放や経済的な理由もさることながら、WeWorkというコミュニティにジョインすることが非常に大きな動機になっています。
一つ目のねらいは多様な人が集う場で私たちエンジニアが日常的にテクノロジーに閉じない刺激を受けること。
アットウェアのビジネスは顧客との恊働によるSI（System Integration、システム構築／ソフトウェア開発）であり、私たちのミッション「システムで人々をしあわせにする」を実現するための活動だと考えています。「恊働」という言葉は「複数の主体が、何らかの目標を共有し、共に心を合わせて働く」という意味があり、私たちはエンジニアとしてエンジニアリングとテクノロジーに拘りと誇りを持って、顧客のビジネスの価値に共鳴をし、その目的を達成していきたいと思っています。一方的に私たちの技術やサービスを利用者に提供するのではなく、また言われるがままに顧客からの要求に応えていけばよいわけでもない。
古のシステム構築／ソフトウェア開発においては解决したい課題が比較的明確（例えば人手でやっていたこの業務を電子化して効率向上したい等）で、いわゆるウォーターフォール開発、すなわち顧客や上流工程に長けた人が要件を定義し設計し、エンジニア（あるいはプログラマ）はそれを実装していく開発プロセスがうまく機能していました。
一方、システムやソフトウェアがこれまでにないあらたな価値を生み出す起点となって、ビジネスそのものを駆動する現在、ビジネスとエンジニアリングあるいはテクノロジーが明確な界面を失いつつあると感じています。また多様化と変化が激しく近い将来ですら予測できず正解も明確でないなか、小さな失敗を許容し改善と進化を繰り返すリーンやアジャイル開発が広まってきました。
エンジニアであってもテクノロジーに閉じず、幅広くビジネスや社会に関心を持って共通言語を増やす、テクノロジーとビジネスが交わるところを探れる力を持つ。 もちろん私たちも日常的にWebなどで様々なビジネスやサービスには触れていますし、実際にも利用もしています。ですがテクノロジー系の勉強会やコミュニティにエンジニアが集まるように、リアルな場で人と関わることで得られること、感じることとはだいぶ違う。じゃぁ、ビジネス系のイベントや異業種交流会のようなところにわざわざ足を運ぶべきというのも違和感を感じます。エンジニアは総じてシャイでそういう場は苦手ですし、そもそも異業種交流会は営業先を見つける場でしかないことも多い。
WeWorkにはスタートアップから大企業のブランチまで、本当に様々な組織・人がジョインされています。冒頭のコンセプトの通り、メンバー間のコラボレーションを促す場作りがなされた環境で、わざわざ足を運ぶまでもなく、コーヒーを注ぎに行ったパントリーエリアで隣に立った人との何気ない会話、帰り際にオフィスの目の前でやってるイベントをちょっと覗いてみれる。
ソフトウェア開発や普通の社会活動では触れることのない話題。世の中にはどんな問題があってどんなビジネスが生まれようとしているか、どんな技術的な課題を抱えているのか。あるいは、どんなビジネスがどんなテクノロジーで実現されているのか。 こういったものの積み重ねが個々の関心の幅を自然と広げていくのではないかと期待しています。
もう一つは、恊働の機会の創出です。
上でも述べた通り、アットウェアのビジネスは顧客との恊働によるSIであり、これまでにも非常に多くの顧客のシステム／ソフトウェアを開発してきました。その一方で、創るだけでなく新たな事業／サービスを生み出す、運営することにもチャレンジしてきました。その一つである公立はこだて未来大学と設立した株式会社未来シェアの公共交通の最適化事業は、まだまだ道半ばではあるものの大きな期待をいただくまでになりました。ただ、うまくいかなかったチャレンジもたくさんあります。
アットウェアはわずか40人にも満たないエンジニアが中心の組織です。どれだけビジネスへの関心を身につけたとしても、私たちだけで新たな事業をゼロから生み出すことは非常に難しい。むしろ私たちは高い技術力を持つエンジニア・チームとしてエンジニアリングを提供し、事業に長けた人や特定の技術／研究分野を究める人と恊働していくこと、コラボレーションしていくことが社会的な成果に繋がるのではないかと考えています。
また、近年、多くの企業がソフトウェアの内製化へと向かっています。一方で思うようにエンジニアの採用が進まない、採用してもチームとして機能し成果を挙げていくには時間がかかるように思います。個のエンジニアを集めてチームを作るのではなく、エンジニアのチームとしてエンジニアリングの提供を受け短期的に成果を挙げる、その間に徐々に独自のチームを育てていくモデルが現実解になりうるのではないか。
WeWorkに集うコラボレーションを模索する先進的な企業とWeWorkのプラットフォームを通じて関わりを持ち、近しい距離で恊働による事業／サービスを創出していきたいと思っています。
今回のWeWorkへの本社移転は非常に悩んだ末の大きな決断であり、大きな転機になるものと考えています。ですが、これまで同様、私たちはSIerとして、エンジニア・チームとして、創ることに誇りをもって、私たちのミッション「システムで人々をしあわせにする」の実現に向け、チャレンジしてまいります。