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

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

前回に引き続きかとじゅんさんによる勉強会の第4弾で、ドメインモデリングワークショップの2回目を開催していただきました。

前回のワークショップでは、かとじゅんさんのドメインモデリングワークショップを参考にWalletアプリケーションで登場する概念のモデリングを行いました。

今回のワークショップではそのモデルを利用する側や保存する側などにもフォーカスして、アプリケーションの1つの機能として通して動作するよう実装していきました。

クリーンアーキテクチャ

始めに前回のワークショップのおさらいと、1つの機能を通して実装するに当たりクリーンアーキテクチャの解説をしていただきました。

その後JavaチームとScalaチームに分かれ、各チームはモブプログラミングの形式で実装を行っていきました。

IMG_2748.JPG

前回のワークショップで作成したアプリケーションを、まずはクリーンアーキテクチャの構成に変更していきました。

かとじゅんさんのクリーンアーキテクチャの記事で紹介されている構成を参考にinterface-adaptorcontract-interface-adaptoruse-casedomaininfrastructureというプロジェクトを作成し、依存関係を定義しました。

以下はその記述の一部です。(JavaチームではGradleを使用しています)

IMG_2753.JPG

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'){
    }

各プロジェクトが上位のプロジェクトに依存しないことを実装者に強制するために、パッケージではなくプロジェクトで分けるという方法が印象的でした。

clean.png

Wallet作成のユースケース

今回取り組んだのはウォレットの作成というユースケースでした。

アドバイスをもらいながら、Walletの識別子をULIDを用いたものに変更したり、金額をint型からMoney型という値オブジェクトに変更するというリファクタリングを進めつつ、今回新たに作成したuse-caseinterface-adaptorについても実装していきました。

interface-adaptorに作成したWallet用のRepositoryはメモリ上に保存する実装をしたのですが、これはcontract-interface-adaptorにあるWalletRepositoryというinterfaceを実装しています。

後に保存先がDBになった場合でも、contract-interface-adaptorに定義したinterfaceを守った上で新しいRepositoryを実装することでuse-casedomainが隔離されinterface-adaptorの変更に左右されなくなるので、クリーンアーキテクチャのメリットを体験できる良い機会になりました。

最後に

今回のかとじゅんさんによるワークショップではDDDとクリーンアーキテクチャを用いて実際にアプリケーションの1つ機能を通して実装しました。

ドメインモデリングのワークショップを始めるにあたって、参加者から「Evans本やIDDD本を読んだが実際のプロジェクトにどう適用していけばいいかわからない」という意見をもらっていたのですが、この2回のドメインモデリングワークショップに参加して、「ずいぶん実装のイメージが掴めた」という言葉を貰え、非常に有意義な勉強会となりました。

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

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

『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』の翻訳や、『プログラマー"まだまだ"現役続行』の執筆など、多方面で活躍されています。そんな柴田さんのお話を伺おうと、研修には、入社1・2年目の新人から、開発経験10年以上のベテランまで、10名の社員が参加しています。

研修は、基本的には輪読・記載されている内容の解説・質疑応答という形で進められていきますが、解説される内容は書籍に記載されている内容だけにとどまらず、さらに掘り下げる形でJavaの言語仕様やJVMの仕組み、コンピューターサイエンスにまで踏み込む講義をされることがあります。とくに言語仕様やJVMの解説では、なぜJavaの文法がこのようになっているかという側面から話がすすめられるので、説得力をもったないようで語られます。また、折に触れ柴田さんの業務での実体験が話としてされることがあり、エンジニアとして業務を推進する姿勢や開発に対する意識など学ぶことが多くあります。経験に裏付けられた柴田さんの講義は、新人だけでなくベテランにまで良い刺激になっているのではないかと思います

研修も既に6回を数えており、和やかな雰囲気で進められています。研修の中で書籍のミスを発見する出来事もあれば、休憩時間には『Java PAZZLERS』の問題を解いたり、柴田さんから90年代のJava開発の話を聞くなど、講師と参加者の距離も縮まっており、楽しい時間を過ごしています。

研修は6月で終了予定ですが、この研修を通して、エンジニアとしてより大きく成長したいと思っています

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

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

4月18日に三回目となる、かとじゅん(@j5ik2o)さんを講師に招いた勉強会を開催しました。

今回は、分散処理フレームワークのAkkaを実際に触りながら学べるハンズオン形式で行いました。 かとじゅんさんは、Chatworkにおいて分散処理の設計に携わったり、技術カンファレンスでAkkaに関する発表をされたりと、Akkaに関する知識の広さを力に活動をされてきました。 近年、アットウェアでは一部の社員の間でScalaへの関心が高まっています。Scalaを社内に広め、実業務で役立てるための技術推進活動の一環として、今回の勉強会を開催することになりました。社員からは10名程度が参加しましたが、Scala経験者だけでなく、これまでにScalaを触ったことのない社員も参加し、Scalaや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勉強会を開催しました

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

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ではない手法でやりました

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

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

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

TL;DR 3行まとめ

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

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

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

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

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

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

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

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

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

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

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

選んだアクティビティ

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

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

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

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

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

4つの分類

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

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

書いて捨てた

IMG_2377.JPG

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

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

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

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

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

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

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

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

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

どうだった?

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

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

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

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

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

自然とでる言葉たち

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

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

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

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

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

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

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

Join WeWork

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
TEL: 045-650-9505

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

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

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

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

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

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

ドメインモデルの分析

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

IMG_20190122_185533.jpg
スクリーンショット 2019-01-23 19.06.40.png

ドメインモデルの実装

分析したモデルをモブプロ形式で実際のコードに落とし込んでいく演習も行いました。 言語の指定はなかったのですが、チームの共通言語が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); 
}
%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88+2019-01-23+19.05.49.jpg

最後に

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

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

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

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

開催のきっかけ

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

内容

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

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

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

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

最後に

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

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

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

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

勉強会のきっかけ

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

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

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

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

IMG_1800+2.jpg
オンラインコミュニケーションの一例

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

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

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

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

最後に

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

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

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

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

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

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

sponsor_session.png

想いはすべて発表に込めて話したとおりとなりますが、参加者みなさんのブログや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! のメッセージで締めさせていただきます。

bram_message.png

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

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エントリー蓄積されるまでにおきたこと

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

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

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

遡ること4年前

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

like.png

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

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

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

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

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

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

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

今日一番書きたかったこと(今)

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

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

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

そしてこれから

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

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

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

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

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

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

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

をテーマにしました。

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

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

security.jpg

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

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

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

ob.jpg

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

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

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

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


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

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

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

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さんに逢える日が今から楽しみでしかたありませんね!

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

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/

Androidアプリ「はこだてバスガイド」提供終了のお知らせ

アットウェアが開発、公開しておりましたAndroidアプリケーション「はこだてバスガイド」のサービスの提供を2018年3月9日を持って終了させていただきます。

長らく函館の皆さんにご利用いただいておりましたが、この度、函館バスのバスロケーションシステムの変更およびスマートフォン向け画面の提供(函館バス株式会社様からのアナウンス)に伴い、「はこだてバスガイド」の役目を終えることとなりました。 2012年9月の公開から5年以上もの間、非常に多くの方にご利用いただき、ありがとうございました。

なお、今後の函館バスのロケーションシステムについてのお問い合わせは、函館バス株式会社様へお願いいたします。

インターンシップ体験記・2017(公立はこだて未来大学 石戸さん)

インターンシップ体験記・2017(公立はこだて未来大学 石戸さん)

アットウェアインターンシップ 活動報告

はじめに

公立はこだて未来大学 学部3年の石戸です。8月21日から9月8日までの3週間、アットウェア横浜本社で開催されたインターンシップに参加させていただいたので、その内容などについて簡単にまとめたいと思います。
「Webサービス・アジャイル開発 実践」という募集要項に対し、参加した人は全国各地から集まった大学生と高専生合わせて11名。
全員の力を合わせて「プロジェクト内のタスクを管理するWebサービス」を作成しました。

参加の経緯

インターンシップに参加した理由はいくつかあります。

  • 大人数での大規模開発がやってみたい
  • Webサービスを作ってみたい
  • アジャイル開発の技法について学び、実践したい
  • 実際の現場での雰囲気が知りたい

大きな理由は以上4つです。アットウェアのインターンシップは、自分のやってみたいこと・経験したいことが盛りだくさんだと直感し、応募・参加しました。

活動内容

1週目:アイスブレイク・勉強会

初日はアイスブレイクを行いました。その日に初めて会った人たち数人+社員の方1名でとチームを組んで話し合いながら、ゲームを進めていきます。その中で開発に活かせる手法について学びました。例えばタスクの可視化ができる「かんばん」です。タスクの状態を「ToDo」「Doing」「Done」の3つに分け、そのタスクが現在どのような扱いかをすぐさま把握することができます。2人1ペア(1チーム3人1ペア)を作成し、ペアごとに機能を作成するタスクを割り振っていきます。ちなみにこのペアは1週間に1回変わります。
2日目はインターン期間中に作成するプロダクトの内容決めをし、作成に必要な機能の洗い出しをして、必要な時間を計算しました。はじめに述べたとおり、「プロジェクト内のタスクを管理するWebサービス」を作成することになりました。
3日目は集団開発で必須なgitについて勉強し、開発に必要な技術についてペアプログラミング方式で勉強・開発をしました。ペアプログラミングは1人がキーボードを叩き(ドライバー)、一人が指示を出す(ナビゲーター)開発手法です。1週目では私はドライバーとなり、ペアの指示に従って実装していきました。
4日目以降は各ペアごとに2日目に割り振ったタスクをこなし、機能を作成していきました。

2週目:開発・プログラミングコンテスト

週の初めには先週の内容についてKPTで振り返りを行いました。KPTは「Keep(保っていきたい=良かった点)」「Problem(改善したい点)」「Try(試したいこと)」の3つを考える振り返り手法です。先週の良かった点、改善点を元に試したいことを考えました。
2週目のペアが「自分の開発技術を磨きたい!」とのことだったので、自分はペアへの実装方法の提案や、実装方法の調査などをメインに行いました。
金曜日はインターン生全員でプログラミングコンテストに挑戦しました。出された問題に対し、適切なプログラムを作成する競技プログラミングです。ペアで5つの問題に挑戦します。私のチームは5問全問正解することができました。最後の問題はとても解き甲斐があり、楽しかったです!

3週目:開発・成果発表会

3週目もKPTで開発に取り組みました。この週が最終週なので、全員完成に向かって頑張って開発を行いました。
私は全体のデザインの統一や、全員の作業ブランチのマージ作業を担当しました。コンフリクトの解消や、マージして気づく不足点などの補完を行いました。地味ながらも重要な作業で、大変だったと感じています。
最終日は成果発表会です。参加者全員がこのインターンで感じたこと、成長したことなどを思い思い語りました。

作成したもの

作成したものはプロジェクト内タスク管理Webサービス「ぷろまね。」です。

image-1.png

色々機能はあるのですが、一番わかりやすいのはこの画面です(開始日でこの記事を書いた日がバレバレ・・・)。プロジェクトマネージャー(以下PM)がプロジェクトおよびタスクを作成し、そのタスクをこなすプロジェクトメンバー(以下メンバー)を指定します。メンバーはタスクに対しPMに参加申請をすることができ、PMはその申請をお知らせ画面で受け取り、参加の可否を審査します。タスクに参加しているメンバーはタスクに対し進捗度の更新やコメントを残すことができ、別のメンバーとサービス上で交流することができます。
実はこの画面、最終日から少しだけ個人的に開発を進めたものになります。最終日時点では終了日の未設定機能が未実装だったり、PMでなくてもタスクを削除できるといった実装の荒い部分が残っており、自分でちょっとだけ改修しちゃいました。インターンが終わっても開発のモチベーションが続き、作ったものを改善したい!と思って改修を進めました。この記事を読んでいる一緒に「ぷろまね。」を開発したみんなが、少し驚いてくれたら嬉しいです。

使用技術

Webサービスを作るにあたって、Javaプラットフォーム向けフレームワーク「Spring Framework」を使用しました。Spring Frameworkはユーザのログイン認証やMVC、データベースアクセスなどを簡単に実装できるものです。Webサービスの開発が比較的簡単に行えるもので、開発前はJavaの初心者でもインターン終了後にはそれなりにサービスが作れるんじゃないかといった上達が見えるすごいやつです。
その他使用した技術要素としては、HTML, CSS, JPA, JDBCです。HTML上のデザインはBootstrapを用いています。

感想

最終日には「短かったなぁ」と感じるほど濃密な3週間でした。開発では社員の方にわからない場所を丁寧に教えていただいたり、コードレビューをしていただいたりと、とても親切に指導していただきました。他にも集団開発でしか経験できないことを多く学ぶことができました。会社の雰囲気もとても良くて、社員の方とも一緒にお昼ご飯を食べ、会話が盛り上がる一面もありました。歓迎会や交流会も開催していただき、開発以外でもとても楽しい3週間でした。この度はインターンに参加させていただき、本当にありがとうございました!

インターンシップ体験記・2017(徳島大学 森さん)

インターンシップ体験記・2017(徳島大学 森さん)

atWareインターンシップ参加レポート

徳島大学3年の森と申します。 この度、8/21~9/8の3週間に体験させて頂きましたインターンシップについて簡単にまとめました。

はじめに

私はこのインターンに以下の3つの目的を持って参加しました。

  • IT業界の方や他校の学生との交流
  • チーム開発
  • Webサービスの開発

結果として、3つの目的は達成でき意義のある3週間を過ごすことができました。今回は、上記3つの参加動機(体験できたこと)に関して、主観的に感じたことを交えてまとめました。拙い文章ではありますが、これからインターンシップへの参加を検討している方にとって、少しでも参考になれば幸いです。

概要

今回参加したインターンシップの簡単な概要としては、9人のチームで、3週間3回のイテレーションでのアジャイル開発によって、Springを使いWebサービスをつくる、というものでした。インターン生の9人は、4人が高専4年、4人が大学3年、1人が大学2年でした。作成するWebサービスは事前にメールで提案したものから適したものを選んでもらっており、初日にインターン生同士で詳細な仕様を決めました。

交流

チームメンバーの9人ですが、全員が初対面で出身地もばらばらだったので、地元の話や通っている高専・大学の話などの普段聞けない話が聞け、面白かったです。特に普段他校の方と話す機会が少なかったので、カリキュラムや学校行事のことや実習・研究でどんなことをしたかなどの話ができたのは良かったと感じています。3週間の時間があるので休憩時間やご飯のときにじっくり話ができる機会が多くあることも3週間のインターンならではのものだったと思います。
またインターン生だけでなく、社員の方とも話ができたり、開発のアドバイスをもらえたりできたことも、このインターンならではの良かったことだったと思います。今回開発を進めるにあたり、常に新卒の社員の方が付いていてくださりサポートして頂きました。アジャイル開発の進め方を教えてくれたり、Webアプリ開発の技術的な質問に答えてくれたりと、私たちインターン生にとって頼もしい存在でした。

アジャイル開発

開発の進め方はカンバンという手法を使い、タスクの切り分け・コスト見積もり、タスクの可視化、1イテレーション後に反省・改善、という流れでした。まず週の初めにミーティングを行い必要なタスクの切り分けとそれにかかる時間の相談を行います。開発経験に個人差があるのでこのミーティングの際にお互いのタスクへの認識や技術に関する知識を共有できました。開発を進める際には、タスク内容と達成に必要だと推定した時間を書いた付箋をTodo、Doing、Doneのタスクの状態に応じて壁に貼っておくことで、残タスクの量や全体の進捗具合を目で確認しながら進めることができました。1イテレーション毎に行う振り返りでは、それぞれ個人が1週間で感じた良かった点や悪い点を共有するミーティングを行いました。
今まで個人開発が多く9人ほどの人数で開発をする機会がなかったので、9人で1つのものをつくるのは難しいと感じましたが、今後チーム開発する機会は絶対あるので、その時に活かせられる良い経験ができたと思います。

mori-kanban.png

Webサービスの開発

 今回、開発にはSpring(Java、HTML、CSS)やGitを使用して進めていきました。チームではJavaやGitの経験が少ない方も多いため、タスクの切り分けではそのことを考慮し勉強時間もタスクとして設けました。私自身もJavaは学校で学んでいましたがSpringの経験が一切なかったので、勉強しながら開発ができ、無理せず足並みを揃えて進めることができました。また、タスクに取りかかる際には2人ずつのペアに分かれてそれぞれで進めていったため、先に勉強を終えたペアに分からないことや進め方を相談できた点でも安心して進められました。

mori-workspace.png

おわりに

 IT企業のインターンシップはバイトのように業務をこなす形式やハッカソン形式のものがありますが、今回はそのどちらとも違い、学ぶ機会の多いインターンだった思います。最初は技術面で不安がありましたが、チームメンバーでお互い勉強しながら開発ができたことや、社員の方がいつでもサポートしてくれたことや、社長の牧野さんからIT業界や企業に関するお話を聞かせてもらえたことなど、たくさんの学ぶ機会がありました。また同時に、交流の機会も多かったと思います。アジャイル開発やペアプログラミングでの交流だけでなく、歓迎会や打ち上げを企画してくださり、本当に楽しい3週間でした。
 最後になりましたが、インターンを無事終えることができたことに、丁寧に教えてくださった社員の方々や一緒に開発に取り組んだチームメンバーに感謝しております。楽しい3週間をありがとうございました。

mori-snapshot.png

立命館コンピュータクラブでRustとVimをテーマに勉強会を開催しました

立命館コンピュータクラブでRustとVimをテーマに勉強会を開催しました

IMG_9721.JPG

「立命館大学の学術系公認サークル「立命館コンピュータクラブ(RCC)」にて、今年の春に開催されたRCCOSSという勉強会が非常に好評をいただいたようでしたので、半年ぶりに勉強会を企画し、事前にいただいた興味あるテーマから2つほどピックアップし、弊社メンバーが2名お伺いしてそれぞれ40分枠で発表してきました。

開催前に

RCCには部室があり、勉強会前に部室に寄らせていただきました。 部室内には参加者20名ほどが10畳ほどの部屋でワイワイやっていて、熱気がすごい。

本棚は古い本から新しい本まで多種多様で、Vim棚もありました。

勉強会の様子

IMG_9771.JPG

Vimの方では Vimで会社や業務を支える技術 というタイトルで、考え方とTips的なものを混ぜて話しました。参加者に発表中にヒアリングしたところ

  • 3割〜5割程度の方はVimを利用したことがある
  • この機会に使い出して3日目という方もちらほら

こんな感じの比率でした。

IMG_9715.JPG

Rustは 使って分かったRustのいいところ というタイトルで、Rustで言語仕様の説明を中心に、実際に作った通知系サービスのコード例を交えて発表しました。発表の中で「一度C++で苦しんでおくと、Rustが神様のようにみえるかもしれない」というフレーズもあり、新しい言語との出会いはいつも面白さがありますね。

懇親会

IMG_9730.JPG

勉強会での感想や関連する話題、普段どんなことに興味があって研究やプロジェクトをしているのか、ハッカソンに参加した時のことなど、いろんな話しをして楽しい時間を過ごしました。

RCCの部員は60名ほどで、こういう活気があって各々が興味があるテーマに打ち込んで、切磋琢磨できる環境に身をおけるのはいいですね。過去に後輩が先輩から受けてきた影響のエピソードを聞いている最中に、別のテーブルでまさにエピソードに近い、そのような光景を目の当たりにしました。

最後に

今回も楽しんでもらえたということが一番の収穫です。

社外に出てこうやって発表する機会を増やしていきたいと思っていますので、私たちの所でもというリクエストがございましたら、お気軽にお問い合わせください!