かとじゅんさんを招いて「Big Picture Workshop」を開催しました

かとじゅんさんをお招きし、2回にわたってEventStormingの一種である Big Picture Workshop を開催しました。

EventStormingは、近年注目されている、情報システムの概観を掴むための手法の一つです。ThoughtWorks社のTechnology Rader Vol.19では、当社の考える産業で採用していくべきテクニックの一つとして取り上げられました。

EventStormingでは、関係者が集まりシステムを取り巻く環境を大きな壁と付箋を使って互いに発表しあいながら、システム化の対象とシステムへの期待を共有していきます。

EventStormingの特徴は、システムを利用するにあたって発生するイベント（ドメインイベント）に着目している点です。イベントから始まり、それを時系列順に並べ、関連する利用者や外部システム、金銭の発生を洗い出していくことで、システムの全体像を掴むことができます。

今回は「かつてない図書館」を企画するというテーマで、10人程度の参加者が集まって、アイデアを出し合いました。

進めながら気づいたのは、議論を促進するような仕組みが随所に取り入れられていることです。 最初は発散させ後で収束させるようにしたり、全員が立った状態で全員と情報を共有しながら認識合わせをして、座って議論しないようにしたりと意見を言いやすい環境を整え議論の価値を高める効果を感じました。

タイムライン強化 〜 ウォークスルー

最初は参加者が各自の思い思いのイベントを付箋に書いて、タイムライン（時系列順）に並べていきます。 イベントは、動詞の過去形で書くように決められていて、動詞の過去形で書くことで、イベントでないものを出さないように誘導したり、後の工程で「□□した」のが誰なのかに視点を誘導する効果があります。

イベントが出揃ってきたら、タイムライン強化を行います。タイムライン強化では、システムを利用する上で必要不可欠で価値の高い、重要なイベントにフォーカスしてその前後のイベントや関係のあるアクター、外部システムなどを充実させていきます。

次のウォークスルーでは、イベントの流れを言語化しながら、考慮不足や抜け漏れを発見していきます。まずこのイベントが起こって、次はこのイベントが起こる、というように、流れに沿って説明することで、あのイベントが抜けているのではないかということに気づきやすくなるそうです。

実際にやってみると、タイムライン強化の最中は気にしていなかったイベント同士の前後関係の違和感や足りていないアクターが明確になり、タイムラインを充実させることができました。

こうした考慮不足に早い段階で気づけるのは、EventStormingの大きな利点だと感じました。

逆方向ナラティブ 〜 クロージング

ウォークスルーで拡充したタイムラインについて今度は逆方向からそのイベントを起こし得るのに、その前のイベントは適切かという視点を持ちながら言語化しました。

逆方向から読んでいくとそのイベントを起こすためにはその前のイベントは重要だがそれだけでは足りないといった、依存の不足が見つかりました。

また、エンジニアはお金の話が抜けがちということであえてお金について考えるフェーズが用意されていて、実際この辺りの話はいくら素晴らしいビジネスモデルやアイデアがあったとしても無い袖は振れないので、ステークホルダーが一同に介して認識合わせができるタイミングで一緒にお金について考えるフェーズを設けるのは合理的に感じました。

一通り終わったところで今回のワークショップの中でリスクになりそうな問題やその解決策を洗い出し共有しました。

終わりに

ステークホルダーが一堂に会して曖昧な部分を明らかにし合意を形成するため、お客さんやチーム内での認識合わせなど、実際のプロジェクトで有用なテクニックだと感じました。

関係者と顔を合わせながら合意を得るという点で、同様に情報システムに対する期待を取りまとめる技法である、リレーションシップ駆動要件分析（RDRA）と似ている点がありそうです。それぞれの違いを見定めて、各プロジェクトに適した手法を取り入れられるよう理解を深め活用していきたいです。

今回のワークショップで体験した Big Picture EventStorming は、プロジェクトを立ち上げる際に使うものでしたが、他にもプロジェクトの別の場面で使える手法があるそうです。 中でも、設計者や実装者の観点に寄った Design Level EventStorming という技法があるそうで興味を惹かれました。

最後になりましたが、かとじゅんさんに感謝の意を申し上げます。

この度は貴重な体験の機会を作ってくださり、ありがとうございました。

VimConf2019のプラチナスポンサーを終えて

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ワークショップが開催されますのでご興味のある方は、是非参加してみてはいかがでしょうか。

2年連続でVimConf2019のプラチナスポンサーになりました

昨年のVimConfに引き続き、2年連続でプラチナスポンサーになりました。

その想いをご紹介いたします。

VimConf2018でBramさんが登壇され、直接コミュニケーションがあった空間、リアルタイムでのTwitterをつかった感想やフィードバック、あの場が特別であったことは言うまでもありません。

それはコミュニティの情熱、OSSへの貢献、日々の活動の積み重ねの上に実現した場であり、そしてカンファレンスのスタッフがコンセプトを掲げ1年かけてたくさんの議論を経て準備をし開催されていることを深く体感できるものでした。

ニッチかもしれないけど、受ける影響や内容は素晴らしく、自身で体験したいこと・ありたい未来そのものです。

今年はBramさんはいないけど、そんな去年の場を経験した参加者からの発表、新しい息吹を感じさせる基調講演があります。

今一度、「筆者個人・所属会社として今できる最大限の貢献は何か」と考え、最高のイメージを描いたとき、やっぱり今年も継続してプラチナスポンサーをしようという結論に至りました。社内の他メンバーからの後推しをもらって、スポンサー締め切り最終日にプラチナスポンサーをさせてくださいと申し込みました。

我ながら2年連続でプラチナスポンサー（と3年連続スポンサー）になるってすごいことだなと思っています...

当日はスポンサーとして話す時間を頂けるので、思いの丈をお話しさせていただきます！

• VimConf 2019 website

ドメインモデリングワークショップ第2弾

前回に引き続きかとじゅんさんによる勉強会の第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回のドメインモデリングワークショップに参加して、「ずいぶん実装のイメージが掴めた」という言葉を貰え、非常に有意義な勉強会となりました。

今後は実装に対する理解を深めていきつつも、よりドメインを深く理解するという考え方や手法についてもフォーカスして知見を深めていきたいと考えています。

『Effective Java 第3版』研修を開催しています

アットウェアでは、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月で終了予定ですが、この研修を通して、エンジニアとしてより大きく成長したいと思っています

かとじゅんさんを招いて「Akkaハンズオン」を開催しました

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勉強会を開催しました

ヌーラボ木村さんを招いて発表形式の勉強会を開催しました。

Kubernetes Meetup Tokyo #14 に弊社メンバーが参加した時に「イイ話だった。もっとお話を聞きたい」という声が出て、オファーをださせて頂き、快諾頂いて実現するに至りました。今回の為だけに業務を調整して、福岡から飛行機で駆けつけくださり感謝です。

最近、このような頻繁にゲストを招いて勉強会の開催が実現している様子をみると、普段の社内の声って大事だなとつくづく感じます。一歩踏み出し、アクションをすることができれば、色んなわくわくすることができたり、向かいたい方向へ前進できてイイ感じです。

そして、今回のKubernetes勉強会の内容の話題に移っていこうと思います。

開催にあたり、参加者の層やどんな話が聞きたがっているのかを事前に会話させてもらい、以下のようなテーマを候補を出していただきました。

1. Kubernetes 基礎知識
2. Cacoo の Kubernetes 環境
3. Cacoo の Microservices 事例
4. Kubernetes のつらみ
5. Kubernetes Tips 、便利ツールなど

ついつい全部関心があると言ってしまいそうになるところですが、参加者をアットウェアエンジニア全員として案内をする予定なので、基礎や浅いところにも触れていただき、なぜKubernetesにしようと思ったか、調査や導入前段の思考をお話を聞けると、幅広い層にもリアル感が伝わっていいかなと考えています。

というようなご相談をさせていただきました。

また、Kubernetsに特に関心があったりKubernetes Meetup Tokyoに参加したメンバーの中で以下のような話も聞いてみたいというニーズがありました。

• Kubernetes meetupで発表された内容をさらに深掘りした話
• 導入後の苦労や運用周りの話
• マイクロサービスの周りのアプローチを、どういう風にKubernetesのオブジェクト単位にまで落とし込んでいったかという話

これらのお話は「ぜひ懇親会でも更にお聞きできたら」ということを木村さんにお伝えし、当日の勉強会のテーマが決まっていったのでした。

開催された勉強会では、木村さん自身が関わっているCacooの開発を続ける中で、積み上げられた歴史を知る木村さんだからこそ伝えられる、オンリーワンなすごくいい発表を聞かせていただきました。

当日の勉強会で印象に残っていること

• マイクロサービスと国際的なロケーションを組織にあわせた形でうまく融合できるようになってきたという話。
  • 最初うまくいかなかったところや工夫も聞けてよかったです。
  • 明確なオーナーシップを持つことでうまくいったそうです。
• 使っているフレームワークや言語は多彩であった
  • その中でも独自のルールをなくして、標準的なルールに従うようにするアプローチをとった。
  • 新しいメンバーが入ってきても伝わりやすいというメリットを享受。
• 本番環境とステージング（ベータバージョン）の使い方とアプローチ方法
• コストの考え方
  • インフラコスト（メモリ使用量なども含め）は上がることが多い
    • AWSが儲かるアーキテクチャなんじゃないかな（笑）。だからみんなプッシュしているんですよ。（笑）と談話
  • ↑は半分冗談まじりな言い方ですが、メリットがあるからやっている
    • システムのスケールに加えて、複数拠点などの働き方・開発チーム自体もスケールできた。
    • 仕様を変えて進めていく時のやりやすさ
  • こういう話を弊社（アットウェア）のエンジニアが聞いたことを会話し、トレードオフや共通理解を深めていけると感じた。
• 懇親会でも刺激を受けた
  • 木村さん自身が関わったKubernetes周り以外のナレッジもチームメンバーから得て、勉強会で展開したり、自身の学び・仕事に活かしているとのこと
    • チーム内で各々が素晴らしい関係が築けていることがわかるというエピソード。
  • 実は私と数名が横浜で行なっている個人活動のコミュニティの勉強会が、木村さんにとって勉強会デビューだったという出会いのミラクルな事実が発覚。

最後に

書きたいことは他にもいっぱいありますが、控えめに言って最高すぎたということで、この辺りで筆をおきたいと思います。 今回の内容とは全く同じではありませんが、木村さんがKubernetes Meetup Tokyoで発表されていた動画が公開されています。ご興味ある方は、ぜひ一度見てみてはどうでしょうか。

素晴らしい発表どうもありがとうございました！

とある日のふりかえりをKPTではない手法でやりました

今日は、とある日に実施したレトロスペクティブ（ふりかえり）についてご紹介します。

紹介内容は、場の目的にあっていると思うアクティビティ（ふりかえりの場で用いる手法）を選択したというお話で、実施して感じたことについて触れたいと思います。

TL;DR 3行まとめ

• フェーズやメンバーの思いに合わせてレトロスペクティブのやり方を変えて試してみたらいい感触を得られた。
• レトロスペクティブをどんな場にしたいかという認識を合わせてから本題に入ると、どのような場にするのかという指標になり、場がイイ感じで流れるように進んだ。
• 目的に合わせてアクティビティを選択することで、効果的にレトロスペクティブを進めることを実感できた。

レトロスペクティブ（ふりかえり）といえば

弊社でもよく使われるレトロスペクティブの手法で「KPT」がありますが、レトロスペクティブのやり方は一つではなく、レトロスペクティブの場をどういう風に過ごしたいかで、アクティビティを使い分けられるといいなと、以前から思っていました。

場に集まる人の発言は、感情・関係性・過ごした日々の行い・日々の長さといったものを抜きには語れません。

その場に各自がどう挑むか、意義を感じられるか、状況をどう理解しているかは今後の振る舞い方や日々を過ごすアクションに大きく左右するのではないでしょうか。

そこで、今回は、アジャイルレトロスペクティブという書籍で紹介されていた、目的毎に向いている手法を組み合わせてやってみました。

私たちはどんな集まりか？

その日は、社内インフラやセキュリティに関わっているメンバー4人が集まりました。 専任の前任者から4人が引き継ぎ、チームとして活動しており、ざっくりいうと職場環境の維持や改善の対応に取り組んでいます。引き継いでから1年半程度が経っており、日々のタスクやチームはうまく回っているが、少し安定しすぎているチームです。前回のふりかえりから長い日々を過ごしたので、自分たちの今後のことも考えていきたいねと事前に話していました。

私たち、チームとしては「目標」「データ取集」よりも、個々の考えを元に「今後の活動方針」を合わせていきたいという各自が関わる意義を再認識したいフェーズと捉えています。

そこで今回やったレトロスペクティブの紹介

前提事項をお伝えするのが長くなってしまいましたが、今回やったKPT以外の手法（アクティビティ）をご紹介したいと思います。

選んだアクティビティ

1つ目: 場を設定するアクティビティ 「ESVP」

まずは集まってレトロスペクティブを開始する時の準備のアクティビティです。 この種のアクティビティを実施することによって、自分たちがどう思っているのか、温度感などを知ることができます。

有名なものだと「チェックイン」あたりですね。

私たちが今回選んだのは「ESVP」です。これは長いイテレーションを過ごした時に適しており、「レトロスペクティブの作業にフォーカスできるように、みんなのレトロスペクティブに対する考えを理解する」目的として最適とのことです。 面白いのが、4つの立場に分類して自分がどう思っているのかを伝えるが、他の人には自分がどの立場かは知られないということです。

よく言われる心理的安全性を確保して、発言を促せるという工夫があることに気づきました。

4つの分類

各自のレトロスペクティブの場にいる温度感そのものです。

• 探検家：新しいアイデアを見つけたいと熱心な人。
• 買物客：情報を見渡してて、アイデアを知りたいという人。
• 行楽客：レトロスペクティブの作業には関心はないが、他のことをしているより良いと思っている人。
• 囚人：参加を強制されていると思っている人。

書いて捨てた

一人が全員から集めた付箋をみて、集計し書き出しました。 付箋は破ってゴミ箱に捨てることにより、誰がどの立場かはわからないけど、どういう人がどれくらいいる事実だけはわかっています。

結果を見てみると、想像していた通りではなく、ズレすぎず、面白かったです。 この場をどうしていくかの指標になりました。

2つ目: 何をすべきか決定するアクティビティ 「質問の輪」

次のアクティビはこの場で「何をすべきか決定する」です。 今回の場では洗い出しを行うつもりはもともとなかったので、感情・想いをベースに話を進めたり、均等に考えを引き出すことに重きをおきました。

このアクティビは、「次のイテレーションにおける試みやアクションステップをチームが選びやすいようにする。特にチームメンバーがお互いの意見を聞く時に使用するとよい」そうです。

私たちにぴったりです！！

ファシリテーターをおかず、均等に発言したり声の大小にかかわらず、しゃべる・聞くということがテンポよく、うまくできるという仕組みです。

やり方は簡単 質問に答えて質問をするだけ

円になって座り、最初の回答者を決めて「次のイテレーションで取り組みたいことはなんですか？」の質問に自身の考えを述べてもらいます。 これまでのやりとりを踏まえたうえで、自身の考えを述べて、さらに次の人に質問をするという流れです。これを2周くらいすれば、質問がブラッシュアップ・深掘りされて、気づけばいい感じにアクションが具体化と合意に近づいていきます。

どうだった？

ESVPの流れから、私たちがこういう状況にあることをどう思うか？から始まり、実はお互いが状況に応じて補完しあえる関係にあって、バランスよく活動できていることを知ることができました。 話題が自然と落ち着いていき、他人の考えやスタンスを知れることによる、心のゆとりや今後も続けていくことの障害がないことがわかったのです。

長いことやっていると人の参画・移動に関する話もあがって、そこのあたりの考えも知れて良かったです。 毎回だと窮屈になってしまうかもしれないと思いましたが、たまにこういう形でやるといいですね。 非常に生産的に話が進んでいった気がしました。

3つ目: レトロスペクティブを終了するアクティビティ 「感謝」

「ポジティブにイテーレションやレトロスペクティブを終える」目的に利用できるそうです。 長い期間やっていると日々あったこと、心に思っていたことをあらためて感謝の意を込めて感謝を伝えられるのははうれしいものです。

感謝することは任意で、誰も話さない時間がきたら終わるという、実施方法となります。

自然とでる言葉たち

この業務に関わっている人全員が、主たる業務というわけではなく、時間を確保をして協力しながら活動を進めています。 時には個々人が主たる業務のピークがきて、動きが鈍くなってしまう時もあります。 そういう時に誰かが主体的にやってくれたことはよく覚えていて、感謝の言葉が出ることが多かったです。

不思議なものですよね。自分がやった時のことは覚えていないのに、やってもらった行為はよく覚えているというのは・・・

このレトロスペクティブをとおして

終わってみると、普段よくやっている

• ブレスト
• タイムライン
• KPT

などでおこなう「データの収集」「アイディア出し」「何をすべきか決定する」とは違うアクティビティで、終わった時の気持ちの感覚も独特のものがありました。求められていること・貢献したいこと・状況が変わることによって、立場を表明して立ち去ったり新陳代謝するは必要だと考えています。そういう時に、「いい意味でうまくできそうだな」という手応えが掴めました。自分たちが、なぜこの場にいるのか、考え続けたりやり方を工夫することの大事さをあらためて感じられました！

1時間30分があっという間で、いい時間を過ごせたと思うので、応用して他の場でも色々なアクティビティを選んで使ってみたいなと思いました。

Join WeWork

株式会社アットウェアは、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として、エンジニア・チームとして、創ることに誇りをもって、私たちのミッション「システムで人々をしあわせにする」の実現に向け、チャレンジしてまいります。

本社移転のお知らせ

株式会社アットウェアは本社オフィスを下記に移転することとになりましたので謹んでご案内申し上げます。
これを機にさらに業務の充実を図り、皆様のご期待に添えますよう、一層の努力を重ねてまいる所存です。
今後とも倍旧のご支援、ご愛顧を賜りますようよろしくお願い申し上げます。

平成31年2月25日より営業開始

新住所：
〒220－0012
神奈川県横浜市西区みなとみらい3-7-1 オーシャンゲートみなとみらい8F

かとじゅんさんを招いて「ドメインモデリングワークショップ」を開催していただきました

前回に引き続きかとじゅんさんによる勉強会の第2弾です。

ドメインモデリングワークショップ

今回はドメインモデリングについてのワークショップを開催していただきました。 前回の勉強会の際に社内で、「Evans本やIDDD本を読んだが実際のプロジェクトにどう適用していけばいいかわからない」という声が上がっていました。 今回のワークショップではその辺りの疑問に応える形で、実際のユースケースからどうドメインモデルに落とし込んでいくか、という部分に焦点を当てたワークショップを開催していただきました。

お題はかとじゅんさんがScala福岡 2019でご講演なさったウォレットサービスのドメインについてでした。 想定するユースケースも講演内容のユースケースと同様のものが予め展開され、そこからどのようにモデルを見つけていくかという内容でした。

ドメインモデルの分析

以下がドメインモデルの分析で行ったモデリングの一例です。 付箋の色で表すものが違っていて、緑がドメインモデル、青が振る舞い、赤が属性、黄色が気になることとなっています。 支払いについてはウォレット集約の配下でまとまりましたが、請求をウォレット集約に含めるか否かで活発な議論がなされていて、モデルについてより深掘りして考える良い機会となりました。

ドメインモデルの実装

分析したモデルをモブプロ形式で実際のコードに落とし込んでいく演習も行いました。 言語の指定はなかったのですが、チームの共通言語がJavaだったので今回の演習ではJavaで記述しました。 頂いたレビューの中で、集約の与り知らないところでコレクションの操作をされるのを防ぐために、コンストラクタや値の返却時にはコレクションのコピーを渡すべきというのが印象的でした。

インスタンス生成時

// List<WalletEvent>は本来ファーストクラスコレクションにするのが望ましい
public Wallet(long id, List<WalletEvent> eventHistory) {
    this.id = id;
    // 外から渡された参照は外部で任意の操作をされることがあるので中身のコピーを渡す
    this.eventHistory = new ArrayList<>(eventHistory); 
}

値の返却時

public List<WalletEvent> getHistory() {
    // 渡した参照に外部で変更を加えられる恐れがあるのでコピーを返却する
    return new ArrayList<>(eventHistory); 
}

最後に

かとじゅんさんにワークショップを開催していただき、実践的なドメインモデリングの手法を体験することができ非常に有意義で楽しい時間でした。 とても良い題材を頂いたので今後もウォレットサービスをベースにDDDについて取り組み、知見を深めていきたいと考えています。

増田さんを招いて「ドメイン駆動設計 考え方と技法」をテーマとして社内勉強会を開催しました

あけましておめでとうございます。 昨年末に『現場で役立つシステム設計の原則』の著者としてもよく知られている増田さんをお招きして、ドメイン駆動の考え方や技法についての勉強会を開催しました。

開催のきっかけ

よこはまクラウド勉強会に参加しているメンバーがDDD Alianceの高崎さんと弊社で『現場で役立つシステム設計の原則』が話題になっているというお話をした際に、お繋ぎしましょうかというお話を頂き今回の勉強会が実現しました。 著者の方から直接お話を聞けるとは思いもしなかったので、今回の機会を実現していただいた高崎さんには心より感謝致します。

内容

まずはソフトウェアの諸問題は変更容易性に依存していているというお話からはじまり、モジュール構造の評価指標、設計スタイルの話からドメインロジックに焦点を当てる開発手法の話へとわかりやすく順序立てて話を進められていました。 ドメインロジックに焦点を当てる開発において要求を分析するための技法のお話では、Fact-Rule-Goalアプローチ、VETRO分析などのキーワードでお話しいただき、実際の業務においてどうビジネスポリシーをどう噛み砕いていくかというを説明していただきました。 コードに近づいたところの話としてはドメインオブジェクトの設計パターンも説明していただきました。 クラスの単位や計算の種類、区分オブジェクト、コレクションの操作や契約による設計などのキーワードで説明していただき、よりドメインロジックに焦点を当てたモデリング手法を理解できました。

強く印象に残っているのが区分オブジェクトのお話のところで、区分、種別を見つけたらEnumに寄せてみようというものでした。 例としてレンタルビデオの料金種別を考えたときにEnumに{ 新作, 一般, 子供 }に列挙すると新作の子ども向けの場合はどうなるのか等の違和感が出てくる。 その違和感を見つけることでより本質的なドメインに焦点を当てることができるというお話をしていただき非常に参考になりました。

もう1つ強く印象に残っているのが契約による設計で、事前条件/事後条件の担保をassertでするのではなく引数や戻り値の型を用いて行うという手法です。 値オブジェクトとして定義した型を利用することで、その型のインスタンスが生成されているということは、存在すべき値の範囲で生成されているということができていると見なすことができるというお話でした。 増田さんのこちらの資料にもある事前条件/事後条件の担保についてのお話です。 利用する側としても渡すべき関心事が明示的でわかりやすいです。

私の普段の業務でドメイン駆動設計のことで疑問に思っている事柄について増田さんに質問をしたところ、増田さんご自身の中での答えとともに、日々実験的に色々なアプローチでより良い答えを探し続けているというお話をいただきました。 私も日々の業務の中で色々なアプローチを試しより良い答えを探し続けていく姿勢を学びました。深く感謝致します。

最後に

atWareでは技術スタックの1つとしてDDDをあげられるよう日々学習しています。 その1つの活動として今回の増田さんや前回の記事のかとじゅんさんのようなDDDの先駆者の方々をお招きして社内ナレッジを蓄積しております。 その過程で私どもとしても提供できるアウトプットがあればぜひして展開していきたいと考えております。 今後とも宜しくお願いします。

かとじゅんさんを招いてDDD基礎講座およびChatworkの事例発表会を開催しました

かとじゅんさんを招き、DDD基礎講座とChatwork社の事例発表の勉強会を開催しました。

勉強会のきっかけ

2015年9月にScalaのひよっこという立場でScala先駆者インタビューという連載を企画し、8人の先駆者の方にお話を伺ったのが始まりです。

始めた頃には最後どうなるかも想像できていませんでしたが、インタビューさせていただいた先駆者には、バトンを繋ぎたい方を紹介して頂き、さらに次回のインタビューに同席してもらうという形をとりました。最終的にかとじゅんさん（Scala先駆者インタビュー記事）に辿り着き、最終回を迎えることができました。

そこから1年弱経ち、社員が関わっているコミュニティの野毛倶楽部「Scala, DDD, Akka の夜」というイベントでふたたびお会いした時に、ざっくばらんに弊社が取り組んでいる技術的なスタックと状況をお話ししたところ、リモートによるScala,Akka,DDDなど実践・基礎力を高めるために技術アドバイザーとして支援していだけることになり、こういった学びの活動の場ができました。

ScalaMatsuriやAWSSummitなどでお聞きすることもあった、Chatwork社の貴重な経験や成果から学べる機会をいただけたのは、うれしい限りです。

オンラインコミュニケーションの一例

社内に招いて発表セッション＆懇親会を実施しました

かとじゅんさんが取り組んで感じた話を聞いたり、過去の発表セッションの再演をしていただきました。前半は勉強会スタイルで、後半は懇親会内のフリーダムな時間で行うという試みにしました。

私たちのリアル感がある身の上話も聞いていただき、話題を交えながらゆったりとした時間で相談でき、すごく盛り上がりました。身近な存在として会話ができる良さだなと実感できた瞬間でもありました。

最後に

今後も、継続的にオンラインで相談にのって頂いたり、不定期で弊社にお越し頂いてワークショップや勉強会などの開催のご協力をいただける見込みです。かとじゅんさんがChatwork社で培ってきた知見を惜しみなく、親身になって弊社の立場も考えて、相談にのってくださったり、相談しやすい雰囲気も作ってアドバイスをしてくださって、とても感謝しております。

アットウェアとしてもScalaなどを始めとする新たな技術に対して一歩ずつ踏み出して、社内での導入と案件を通じて経験をさらに培っていき、こういった社内の取り組みをこれからアウトプットしていきます！

プラチナスポンサーとして関わったVimConf2018を終えて

7月にこちらのエントリーでVimConf2018のスポンサーをさせていただくことをお知らせし、VimConfが素晴らしい一日となれるようにサポートしました。

当日には、Bramさん発表前にスポンサーセッションをするという貴重な機会までいただき、以下のタイトルで発表しました。

想いはすべて発表に込めて話したとおりとなりますが、参加者みなさんのブログやTwitterによる当日の様子や感想を見ると、プラチナスポンサーになって改めてよかったと感じることができました。

スライドの中で触れた「軌跡に残るこの日」という視点について少しだけ言及させてください。

当日会場にいた人は肌感覚で感じ、翌日にBram氏にいただいた以下の言葉で、さらに実感としてこの日がコミュニティやVimにとって未来へのターニングポイントであったというの実感できたのではないでしょうか。

I am amazed to experience the professional level of this conference about one piece of open source software that I happened to start 27 years ago. Thanks to all the organisers and speakers for this exciting conference!

アットウェアが掲げている以下の「システムで人々をしあわせに」のMission Statementの補足文で触れられている

システムでしあわせにするのは決してお客様だけだとは思っていません。 我々技術者自身も意義のある・やりがいのある仕事を楽しみ、常に時代の先端技術に触れる喜び、共に暮す家族に誇れる企業であり健康で安心して生活できるしあわせ。 そして、IT業界全体が躍進・繁栄し、技術者の地位が向上することに少しでも寄与できるよう、IT技術コミュニティや地域コミュニティへの積極的な参加を推進しています。

このMissonに真摯に向き合い、一つの形として実現できました。

また、スポンサーチケットを学生に譲り招待することにより、場の共有とユーザを含むコミュニティの未来に少し繋がった気がしました。VimConfで体験したことを持ち帰り学校でLTをするそうです。

8年前に学生だった方々が、このVimConfで発表されている姿も見ました。同じように私も一緒に年を重ねたけどスタッフになることで1歩前を向けました。こういう一つの体験やきっかけが、明日に繋がっているように思えて仕方ありません。

最後になりましたが、アットウェアでも一緒に働いてくださる仲間を募集しています！

Bram氏にVimConf2018で配布したチラシに書いていただいた Happy Vimming! のメッセージで締めさせていただきます。

Scala関西Summit2018に行ってきました

11月10日、大阪の天満研修センターにて開催された Scala関西Summit 2018 に参加してきました。
セッションはScalaの言語的な話題からAkka、FP、DDDまで幅広く、例えば「明日から使える実践エラーハンドリング」では Scala でのエラーハンドリングにどの方法を使うといいのかということを、Javaからの歴史をなぞって分かりやすく解説されていたり、「Scalaでのドメインモデリングのやり方」ではドメインモデリングする際のかなり実践的な方法を紹介されていたりと、技術者として刺激を受けた非常に楽しい一日となりました。

そんな中、弊社からも1人CFPに応募してScala関西Summitにて登壇しました。
題名は「もしExcel方眼紙を愛するSIerがScala案件に投げ込まれたら」。

発表では、今までほとんど使ったことのないScalaに苦戦しつつも、まずは今までやってきた仕事の経験を活かすことを目標とし、業務理解や要件整理といった自分の得意分野を着実にこなすことで徐々に自信を取り戻していったと語っていました。
Scala のような慣れない技術に初めて触れるとき、どのようにバリューを出していくのかということは、誰にとっても難しい課題の1つだと思います。
もし自分がそういった状況になったとして、まずは自分の持っている知識と能力を活用し、今自分にできることを確実にやっていくという考え方は、今後同じような状況になった場合の1つのロールモデルとして参考にできそうだと感じながら見ていました。

また、最後には Scala を怖がらずに難しい概念に遭遇したら楽しんでしまおうというメッセージを発信されていました。
全体を通して、何はともあれ「とりあえず楽しんでやってみようよ」というような気概を感じるセッションでした。
初心者の状態から Scala 案件に飛び込むのは、Scala は難しいというイメージもあり、少し勇気がいる事かもしれません。ですが、Scala に興味はあるけど仕事で使うのはちょっと...と二の足を踏んでいるような人の背中を押すようなセッションになっていたんじゃないかなと思います。

---

今回Scala関西Summit2018に参加してみて、様々なセッションがあって1つ1つのセッションを飽きずに楽しくみることができ、Scalaをより好きになれるような素晴らしいカンファレンスでした。スピーカーの皆さん、運営の皆さんお疲れ様でした。
また来年も今回のようなカンファレンスが関西の地で開催されることを今から楽しみにしています。

（ちなみに、今回の Scala関西Summit2018 ですが弊社アットウェアもシルバースポンサーとして協賛させていただきました）

4年間で社内ナレッジツールに800エントリー蓄積されるまでにおきたこと

社内ナレッジを横展開したい・自分の書き留めたメモをアウトプットして役立てたいという想いから、Webベースの社内ナレッジツールを開発し、足掛け4年間で800エントリーに到達しました。

数を目標に始めたわけではありませんが、800エントリーと4年という歳月はふりかえるのには十分ではないかと思いましたので、記憶を思い起こしてエピソードや感じたことを伝えれればと思います。

遡ること4年前

アットウェアでは複数の案件とプロジェクトが存在します。そうするとナレッジはプロジェクトと個人に溜まっていき、「実は他のプロジェクトでどんな技術が使われているのかよく知らない」。また、あまり知る機会がなく、技術資産がうまく活用されていないのでは？と目に見えないある種の閉塞感といった課題がありました。

社内の事業部・プロジェクトを跨いで、社員間で技術やノウハウの共有をもっともっと盛んにしたい、この想いを実現するべく、普段の業務の合間を縫って有志が活動しはじめたのが始まりでした。

以下が当時に掲げられた、社内ナレッジ共有ツールの領域を視覚化した図です。

最初は積み上げられるコンテンツになるところから（リリース当初）

ナレッジツールの立ち上げ当初は数名が自身のブログやメモで書くような事、ワンライナーまでアウトプットし始めました。継続性と書く人のモチベーションを強く意識したMVPがしっかりしていたので、エントリーの削除機能はなかったけど、Googleアカウントによるシングルサインオン、ストック機能やタグづけ機能やコメント機能やmarkdownでの記述はリリース当最初から存在していました。

この頃、アットウェアではプロジェクトの括りとは違う「チーム」という単位で組織が運営・駆動されていいました。ナレッジ共有ツールの開発者が所属していたチーム目標としてアウトプットしまくるということを立てて、着々とアウトプットを積み重ねていったのを覚えています。

アットウェアではこれまでは、既存ツール（TracのWikiでやろうとか、WordPressのXXXプラグインでやろう）を使ってパッとやりはじめはしたものの、運用メンテナンスや使い勝手向上を高望みしてしまい、アウトプットすることに集中できずにいました

そうやって、いつしかそのサイクルが途切れてしまうというのを繰り返していたのが、この社内ナレッジツールリリースをきっかけに、一つのツールと深く向き合うようになったのでした。

逆に、シンプルな機能ということが幸いしたのかもしれません。

全社員が使い出す頃には（1〜2年目）

月日を重ねるうちに、技術メモやTips以外にもイベントレポートや書籍の感想なども、日常的に出てくるようになりました。その頃には、コントリビュートという記事が「ストック」されると、ユーザに数値でコントリビュート数が表示され、コントリビュート数が多い人気のエントリーというのがサイドバーに表示されるようになると・・・

ストックするとどうなるかが視覚化・認知されある現象がおきました。

そう、ご祝儀ストックです。そもそもストックの狙いとしては「この記事役立つ。あとで見返したいたい」という、ピン留めやお気に入り的な意味合いがあったのですが、イイね的に使う人も現れました。

投稿するのがレアな方が出した、コンテンツ内容的に至ってごく普通のエントリーが、2位になってしまったのです。（イイね的なストックが多すぎて）

数値による視覚化の軌道修正

軌道修正を行うべくMVPには入っていなかったLike機能が実装されリリースされました。 その際に、コントリビュート係数も変更され、LikeよりもStockの方がコントリビュートの重み付けが高くなるようにし、人気エントリーにも変動が見られるようになって、Likeとしても、たくさん付くようになりました。

空気のようになってきたころには（2〜3年目）

社内勉強会のアウトプットをひたすらし続ける人、プロジェクトの技術メモをアウトプットを定期的にしている人、ポエムを書き出す人など、このナレッジ共有には人それぞれの使い道がでてきて、毎日ではないけど途切れることなくアウトプットが続くようになってきました。

特別な存在ではないけどあるのが普通の状態。 当初の目的は達成できたかのように感じたステージでした。

2年くらいでこのような状態までになりました。 人の思考がアウトプットされるコンテンツはその人だけが書くことができる価値あるコンテンツなので、「みたよ」と声がけされなくても、投稿されると見てくれていることが多いことに気づきました。

投稿があると社内チャット（Typetalk）へ自動通知されたり、ユーザが区切りのコントリビュート数や掲載記事数に達すると、祝福するメッセージもチャットへ流すようになりました。

そして月日が流れると・・・

今日一番書きたかったこと（今）

数年が経って800エントリーに達したころ、「あれ？社外に見える形でアウトプットする機会減ってない？」ということを感じました。心理的安全性という言葉が定着して久しいですが、社内のナレッジ共有だからチラシの裏的でも構わないという気軽さと、アウトプットすることに慣れれば社外にも・・・ という考えは、コンフォートゾーンを超えず、逆に貴重なコンテンツも埋もれさせる形になってしまっていたのです。

社外秘的な微妙な表現を再校正するという、ちょっとしたことが実は心の障壁となってしまい、コンフォートゾーンから脱せず、この800エントリーの中から、社外にアウトプットされるエントリーは極僅かとなってしまっていました。

社内のナレッジ共有という目的は果たせたかもしれないけど、プライベートとパブリックの使い分け。内と外との活動バランス（アウトプット）のバランスも考えないとなぁと思う、SNSでマイクロブログを書き出してしばらく経った時のアレに近いものを感じています。

そしてこれから

ナレッジ共有ツールをうまく浸透・フィットできたことは喜びつつも、次はツールではなく思考の先にあるコミュニケーションやアウトプットができるようになっていくと、自分が身をおきたいと思える環境に近づくなぁと思えるようになってきました。自身のメモ以外にうまくいかなったことも含め、自分の立場で体験した何かを伝えたり・表現したり、活かしたりできるようになっていればいいなと思います。

淡々と書いていたら、長くなってしまいましたが、長文にお付き合いいただきありがとうございました。

立命館コンピュータクラブでMonoid・セキュリティ・OB談話をテーマに勉強会を開催しました

今年も立命館大学の学術系公認サークル「立命館コンピュータクラブ（RCC）」にて、勉強会を企画させていただき弊社メンバー3名が発表させていただきました。

昨年はテーマのリクエストの中から Rust と Vim を選ばせて頂いたのですが、今年は一転して

• Monoid
• セキュリティ
• OB談話

をテーマにしました。

Monoidは数学が話の中心とあって、プログラミングと数学の隙間を埋めるような切り口で発表されていました。前提知識から話し始めて、Monoidにすると「なにが嬉しくなるのか？」という説明する頃には、発表終盤。

序盤の説明も噛み砕いて、すっきり頭に入ってくる層とわかったようなわからないようなという方もいたのではないでしょうか。実際に役立ちそうなケースにぶち当たるのが実感しやすいとは思いますが、参加者の数人はこのテーマがど真ん中という方もいて、楽しんでもらえたようです。

続いて、セキュリティについては「仕事で実際にあったセキュリティ対応」という人間味あるエピソードを交え、企業で仕事をするということ、責任・心理なども含め、資料に載せられないこともお話ししました。

特に自分にしかできない話しを意識して内容を考えました。「実体験」や「こう考えるに至った」という切り口が聞く方にとっても、発表する側にとってもよさそうと思い、差し障りがないところを赤裸々に伝えました。

発表している最中にTwitterですぐに反応をもらえるというのは、刺さるフィードバックという観点で素晴らしいですね。

最後のOB談話は「atWareで働いてみて良かったこと」という、直球的な内容でした。 RCC出身の学生が1年半経ってどういう風に感じているのか？という視点や、RCC文化から新しい環境に移ってギャップや共通点はどうだったのかなど、身近な存在として、とても気になるところだったのではないでしょうか。

学生時代の自身のことを知っている世代がいる最後の機会ということもあったようで、日々感じていることを等身大の表現で話してくださいました。「1on1」や「入社後ヒアリング」や「社内に学生の方を招いて発表」という形では、きっとこのような表現で聞けなかったと思います。

本人はダイレクトマーケティングと揶揄していましたが、誇張なしにいい発表だと感じました。

自社ブログでこんなことを書くのはアレすぎるんですけど、良いと思ったことは感じたままに残しておこう思います。

---

継続的にこういった勉強会の場を続けていると、見慣れた顔もでてきます。一緒に働けたらそれはそれでうれしいのですが、それ以上に企業として自分たちの経験やフィードバックやアウトプットをすることで、私たちとノリが似ているなと思う、RCC所属の学生さんたちにとって、何かのきっかけや、楽しい場・意義ある場になっていれば幸いです。

また、来年会いましょう！

Bramさんが来日するVimConf2018のプラチナムスポンサーになりました

昨年、VimConf2017をこのような想いでスポンサードさせていただき（開催後のレポートはこちら）、今年もこの時期がやってきました。

2013年から開催されているVimConfは前身イベントから数えると5年以上になりますね。

今年は特別なものになることが告知されています。遡ること30年前（1988年）にVimの作者であるBram Moolenaarさんが1.0を公開しました。そして30年継続的にコミュニティと一緒になって開発が続けられ、現在に至ってはほぼ全てのLinux OSにデフォルトでVimが搭載されており、開発者に向けたエディタとしても利用され続けています。

流行やパラダイムシフトや周辺環境事情の変化が起き続けるなかで、一つのことをやり続けるということは数年、十年でもすごいことなのに、30年という時を積み重ね、今尚第一線であり続られるマインドはどのようなものなのでしょうか？

VimConf2016のk-takataさんの発表でありましたように、現在もリリース作業や機能取り込みの意思決定はBramさんがおこなっているものの、多くの日本人を含む世界中のVimコミュニティの方々も一緒になって開発やメンテナンスが続けられています。

これから10年・20年先もVimが使い続けられていることも想像でき、コミュニティも周辺環境の変化に対応していくのではないかと思います。

世界を見据えて活動されていたVimConf。リリースから30年という節目の年にBramさんが来日するというこのイベントに影響されて、普段業務で接しているOSSに関して考える方も何かの小さな活動を開始をする方も多くでてくるのではないでしょうか。

そんな、過去と未来を繋げるこのカンファレンスに、筆者個人・所属会社として今できる最大限の貢献は何か？と真っさらな状態から考え、プラチナスポンサーとして申し込みさせていただきました。（この辺りのことはまた当日話せる機会があればお話ししたいです）また、筆者個人としても開催に向けて協力できることがあればしていきたいと考えております。

当日は、日本をはじめとする世界のVim本体開発者やこのエディタを使ってOSS開発する方々にとって明るい未来のきっかけになるような、楽しく・素晴らしい日になることを願っています。

Bramさんに逢える日が今から楽しみでしかたありませんね！

• VimConf official site
• VimConf2018開催告知

ScalaMatsuri 2018にスポンサードします

日本最大級の Scala のカンファレンス ScalaMatsuri 2018 が 2018年3月16〜18日 に開催されます。

アットウェアはプログラミング言語としては Java をメインとしていますが、近年、問題解決のアプローチを模索する中で、Scala が持つ可能性を見いだし、　Scala先駆者インタビュー を企画したり、社内ツールの実装言語として採用したり、継続的に取り組んできました。
その継続的取り組みと、昨年の ScalaMatsuri 2017 スポンサードの甲斐もあり、昨年はいくつもの具体的なお仕事の話をいただき、そのうちのいくつかは現在も鋭意進行中です。幸運なことに Scala 界隈の有識者の方々と一緒にプロジェクトに関われているということもあり、「いい時にいい場所に関われている」という好循環が生まれつつあります。

そこで、今回の ScalaMatsuri 2018 では、侍スポンサーからアップグレードして、 大名スポンサー としてご協力することとしました。
引き続き、実績とノウハウの蓄積をコツコツを積み重ねて、「受託 SIer としての Scala との向き合い方」を真剣に考え、弊社なりのポジションを確立すべく邁進していく所存です。

---

アットウェアでは、一緒に働いてくださる仲間を募集しています。Scala 未経験でもかまいません。
顧客との直接取引で、技術的決定権があり、プロジェクト推進に裁量をもって、企画から開発・運用まで携わることができます。
ぜひ、お気軽にお問い合わせください！ https://www.atware.co.jp/recruit/