コネヒト開発者ブログ

コネヒト開発者ブログ

Slack Block Kitを使って既存ツールをカッコよくしてみた

こんにちは、 BLUE GIANT SUPREME (7) (ビッグコミックススペシャル)を読みました。金城(@o0h_)です。
読後、へーしゃで称賛が発生していました。

f:id:o0h:20190303130444p:plain
こちら、社長と私です

そんな感じで色々にSlackを利用している身のものですが、先月「新しい機能をリリースしたよ!」という発表がありました。
「Block Kit」です。

Block Kitは、「Slack投稿の表現力を上げる」「ユーザーと、より気の利いたインタラクションをつなぐことを支援する」ための新UI(のためのAPI)です。
これを利用すると、いつものSlackの投稿がとても高機能になります。

実際に触ってみたので、使い方やハマったポイントなどを共有していきます。

https://cdn-mamari.imgix.net/authorized/5c7ccc81-7170-439c-8949-0034ac110003.jpg

続きを読む

React HooksとContextAPIでFluxをやってみる

f:id:dachi023:20190226162905p:plain

CTO室エンジニアの安達 (@dachi_023) です。React v16.8で待ちに待ったHooksが (20日前に) リリースされました。そんなHooksを使ってFluxやる時ってどうするんだろう?と思ったので調べて写経してみました。

reactjs.org

書いたコード

create-react-app して出てきたものをいじって作りました。Flux化するまでに書いたコードだけを見たい場合は コミットログ が分かりやすいかもしれません。

github.com

余談: 実際書いてみて「Hooksちゃんと理解してなかったなぁ、9割くらい写経だとしても覚えるために書くというのは良いことだ」と感じられました。

やってみる

  • お題: +1 / -1 ができるカウンターの実装
  • useReducer() とContextでStoreをつくる
  • Actionの発行 → dispatch → Stateの更新 → 再描画 をやる

Context

ContextがStateを管理するための入れ物 & 伝搬役になります。とりあえず createContext() して返します。今回はdispatchも同じContext内で管理します。

import { createContext } from 'react'

export default createContext({
  count: 0,
  dispatch: null
})

Reducer

Actionを受け取って新しいStateを返します。Actionの中身は redux-utilities/flux-standard-action と同様です。Reducerの定義は Reactのドキュメント にも書いてありますが (state, action) => newState です。

export default function CounterReducer(state, action) {
  switch (action.type) {
    case 'increment':
      return { count: state.count + 1 }
    case 'decrement':
      return { count: state.count - 1 }
    default:
      return state
  }
}

ActionCreator

外部通信やビジネスロジックがないのでほぼ無意味な感じになってますが前述したflux-standard-actionに倣ってActionを生成して dispatch() します。

export function increment(dispatch) {
  dispatch({
    type: 'increment',
    payload: {}
  })
}

export function decrement(dispatch) {
  dispatch({
    type: 'decrement',
    payload: {}
  })
}

Component

作ったものをつなげていきます。

App.js

useReducer() にCounterReducerとStateの初期値を渡してstateとdispatchを取り出しProviderに突っ込めばStateの生成と値の伝搬作業が完了します。

import React, { useReducer } from 'react'
import Counter from './Counter'
import CounterContext from './contexts/CounterContext'
import CounterReducer from './reducers/CounterReducer'
import './App.css'

export default function App() {
  const [state, dispatch] = useReducer(CounterReducer, { count: 0 })
  return (
    <div className="App">
      <header className="App-header">
        <CounterContext.Provider value={{ ...state, dispatch }}>
          <Counter />
        </CounterContext.Provider>
      </header>
    </div>
  )
}

Counter.js

の処理でProviderにセットしたStateを useContext() で取り出し表示します。Stateと一緒に入れてあるdispatchを取り出してクリックイベントに仕込めばStateの更新処理までが完了です。

import React, { useContext } from 'react'
import CounterContext from './contexts/CounterContext'
import { increment, decrement } from './actions/CounterActions'

export default function Counter() {
  const { count, dispatch } = useContext(CounterContext)
  return (
    <>
      <h2>{count}</h2>
      <button onClick={() => increment(dispatch)}>Increment</button>
      <button onClick={() => decrement(dispatch)}>Decrement</button>
    </>
  )
}

できあがったのがこれ

ちゃんと増えたり減ったりするようになりました!

f:id:dachi023:20190226160647g:plain

まとめ

  • 今までのClassベースのComponentとは書きっぷりがだいぶ異なるので最初とっつきづらいのかもなと思いました、1回でも真面目にやると「なんだ全然できるじゃん!」という感じですが。
  • 複雑なことしないのであればFluxライブラリなど使わずにHooksで実装しちゃってもいいかもしれないですね。結構使えそうじゃないかな?と思ってます。

参考記事

AmazonAurora カスタムエンドポイントのフェールオーバー時の挙動についての検証

こんにちは。インフラエンジニアの永井(shnagai)です。

昨年11月にリリースされたAmazon Auroraのカスタムエンドポイントを運用していて、先日ある検証環境でフェールオーバーが起きた際に考慮していなかった事態が起きたので、仕様を確認するがてらカスタムエンドポイントのタイプ別にフェールオーバー時の挙動をまとめてみました。

カスタムエンドポイントについては下記をご参照ください。 自由にAuroraインスタンスを組み合わせて、用途別にAuroraのエンドポイントを管理出来る機能で、これまで泣く泣く続けていたmysqlのbinlogレプリ運用から解放されるようなうれしさがあります。 docs.aws.amazon.com

起きた事象

Auroraクラスタにフェールオーバーが発生した際に、当然リードレプリカがマスター昇格します。その際に、カスタムエンドポイントのノードが0になりカスタムエンドポイントへのDB接続が不可となりました。

これは、下記環境の説明にあるようにREADER TYPEでカスタムエンドポイントを作成していたので、登録していたリーダーインスタンスがREADER TYPEの条件不一致になりメンバから外れたのが原因でした。 リーダーエンドポイントだと、よくあるLBのSorry設定のように、ノードが0になればマスターが一時的にメンバに入りノード0を防ぐような挙動をしてくれますがカスタムエンドポイントではそのような挙動はありません。 今回の検証では、リードレプリカに降格したインスタンス(旧ライターインスタンス)が、自動的にカスタムエンドポイントに登録するような設定を見つけるのがゴールとなります。

問題が起きたカスタムエンドポイントの環境

  • Auroraクラスタで、ライターインスタンス1台、リーダーインスタンス1台構成で運用
  • カスタムエンドポイントは下記条件で作成し運用
    • READER TYPE
    • メンバシップルール内の[今後追加されたインスタンスをこのクラスターにアタッチ]はDisable ※この設定はAuroraレプリカを追加する際に意図せずエンドポイントに追加されるのを防ぐ意図で入れたのですがこれが仇になりました。。
    • 静的リストで、リーダーインスタンス1台を登録

Auroraのカスタムエンドポイントの主な設定値

はじめに前提知識としてAuroraのカスタムエンドポイントに主な設定値の内容を確認しておきます。 主な設定値は2つです

タイプ指定

Any or READERでカスタムエンドポイントのルールを指定する

type 説明
READER 読み取り専用の Aurora レプリカである DB インスタンスのみが、READER カスタムエンドポイントの一部となることができる
ANY 読み取り専用の Aurora レプリカと読み取り/書き込みのプライマリインスタンスの両方が ANY カスタムエンドポイントの一部となることができる

メンバーシップルール

  • 静的リストか除外リストを用いて、カスタムエンドポイントに所属するインスタンスを指定する
  • [今後追加されたインスタンスをこのクラスターにアタッチ]するか否かを選択する ※今回の検証ではここが肝だった

検証

6つのパターンからフェイルオーバー時に降格したマスターノードがカスタムエンドポイントのメンバに自動的に追加される設定を探りました。

検証

  • テスト用のAuroraクラスターを作成
  • クラスタには、1台のライターノード(test-custom-endpoint)と1台のリーダーインスタンス(test-custom-endpoint-ap-northeast-1c)を用意
  • 6パターンのカスタムエンドポイントを作成し、フェイルオーバー時の挙動を確認

結果

②の構成でカスタムエンドポイントを作ることで、フェイルオーバー時に降格したインスタンスがカスタムエンドポイントに追加されることが確認出来ました。

また、⑤⑥の構成であれば静的リストの中からレプリカのみがカスタムエンドポイントのメンバーとして管理されることがわかりました。

※はてブでコメントいただき「ライターインスタンスは静的リストに入れておいてもライターのうちはREADER TYPEのメンバにはならないからそれをうまく使うという」気づきを得ました。

No TYPE 追加インスタンスのアタッチ 静的リストに登録するメンバ 予想 結果
READER Disable レプリカのみ メンバいなくなる メンバいなくなる
READER Enable レプリカのみ メンバいなくなる or 降格したインスタンスがメンバイン 降格したインスタンスがメンバイン
ANY Disable レプリカのみ そのまま(昇格したライターのみ) そのまま
ANY Enable レプリカのみ そのまま or 降格したインスタンスがメンバイン そのまま
READER Disable レプリカとライター 降格したインスタンスのみ 降格したインスタンスのみ
READER Enable レプリカとライター 降格したインスタンスのみ 降格したインスタンスのみ

最終的にどんな構成にすればいいのか

カスタムエンドポイントを使いたいよくあるケースは下記のようなパターンかと思います。

  • マスターにはサービスからの書き込みトラフィックが流れる
  • 複数台あるレプリカを束ねるカスタムエンドポイントにサービスの読み取りトラフィックが流れる
    • フェイルオーバー時は、このサービス用のカスタムエンドポイントのいずれかがマスタ昇格
  • 分析用にAuroraのレプリカを作ってそこは分析のSQLだけが流れるような構成

下記のような構成を取ることで、カスタムエンドポイントの本来の良さを生かしてAuroraレプリカへのトラフィック分散が出来るのではないかと思います。(さらばbinlogレプリ)

  • レプリカのスケールアウトはあまり行われず、別用途のレプリカが追加される可能性の高い環境で運用したい場合は⑤の構成
  • レプリカのスケールアウトを行う可能性があり、その際にシームレスにカスタムエンドポイントに追加されてほしい場合は⑥の構成

※カスタムエンドポイントはGUIから作るとAny typeになるので、READER typeのエンドポイントを作るにはAWS CLI等からの作成が必要

サービス用のカスタムエンドポイント

READER type + 新規インスタンスのアタッチ有or無 + 静的リストにライターとサービス用のレプリカを登録 + 所属するリードレプリカのFailOver優先度を0(最優先)にしこの中からフェイルオーバー時のマスター昇格が行われるようにする

分析用のカスタムエンドポイント

READER type + 新規インスタンスのアタッチ無し + 静的リストには分析用のレプリカを登録 + 所属するリードレプリカのFailOver優先度を15(優先度最も低い)にしてフェイルオーバー時のマスタ昇格は行われないようにする

f:id:nagais:20190222174722j:plain

参考までに画面キャプチャ

f:id:nagais:20190218163647p:plain f:id:nagais:20190218163659p:plain

f:id:nagais:20190218163715p:plain f:id:nagais:20190218163723p:plain

f:id:nagais:20190218163740p:plain f:id:nagais:20190218163749p:plain

f:id:nagais:20190218163801p:plain f:id:nagais:20190218163812p:plain

f:id:nagais:20190222174642p:plain f:id:nagais:20190222174656p:plain

コネヒトでは変化を恐れずに良いものを取り入れながらサービスの信頼性向上をミッションに一緒に働く仲間を探しています。 少しでも興味もたれた方は、是非気軽にオフィスに遊びにきていただけるとうれしいです。

www.wantedly.com

入門監視を読んで、「監視の民主化」に本気で向き合おうと思った話

こんにちは!待ちに待った2月です。
何を待っていたか? フットボールネーション(13) (ビッグコミックス)ブルーピリオド(4) (アフタヌーンコミックス)BLUE GIANT SUPREME(7) (ビッグコミックススペシャル)が発売される月ということになります。
嬉しい〜!の金城(@o0h_)です。

https://cdn-mamari.imgix.net/item/500x0_5c6a9464-96b0-4fc9-8ee2-0034ac110002.jpg.jpg

さて。
(ほぼ)ちょうど1ヵ月前に出た「入門 監視」は、いろいろな方面で話題になりました。
既に色々な書評やまとめが出回っていて、反響の大きさが感じられますね!

www.oreilly.co.jp

弊社でも、会社の書籍購入補助を利用して即予約 & 入手をしました。
この本からは非常に多くの学びや示唆を得られたと感じています。

先日、その内容・感じたことを、社内LT会で共有しました。
発表内容を踏まえつつ、読後に自分なりに考えさせられたことをまとめてみたいと思います。
ただしスライドに含まれる全ての内容を扱うと広範になりすぎるため、今回は「組織」側面のトピックに絞って取り上げます。

また、本稿では「入門 監視」に関する「まとめ」はあえて避けていきます。
その代り、その内容を踏まえて痛感した、我々のチームにおける「これまでの失敗」と「何を反省したか」を記します。
(そのため、既に一読されている方が対象になるかもしれません。)

TL; DR

  • この本を読んで、「監視の民主化」をしたい!と非常に強く感じた。
    うちのチームは、少なくとも形式的にはアラートへの対応を全員でやっているが、見えない壁があった。
  • 「監視をできるようにする」ために必要なのは、「知っている人」「慣れている人」からの歩み寄りが大事だと思う。
  • 「監視はスキル」。誰でも出来るように、インプットとトレーニングを用意する。

発表資料

こちらが、発表した内容です。
公開に当たり、実際に利用した資料を一部編集しています。

続きを読む

DroidKaigi 2019に行ってきました!

f:id:tommy_kw:20190211202916p:plain

はじめに

こんにちは!Androidエンジニアの富田です。先日開催されたAndroidカンファレンスのDroidKaigi 2019に参加しましたので、簡単に参加した感想を共有したいと思います。

カンファレンス全般について

カンファレンスへの支援

f:id:tommy_kw:20190209075031j:plain
オープニングでコネヒトを紹介していただく

DroidKaigiは5回も開催されている大規模なAndroidカンファレンスですが、今年初めてコネヒトはサポーター枠として支援させていただきました。僕がコネヒトにジョインして2年半で初めてAndroidカンファレンスに支援することができたので、とても感慨深かったです。

f:id:tommy_kw:20190209085232j:plain
カンファレンスアプリに記念コントリビュート
最早毎年恒例となっているカンファレンスアプリですが、昨年に引き続き、今年もtakahiromさんが開発リーダーとしてカンファレンスアプリの開発からリリースまで担当されていました。そんなカンファレンスアプリですが、約140名の方がカンファレンスアプリにコントリビュートされており、僕も簡単なIssueにコントリビュートさせていただきました!たくさんのPRがあったにも拘わらず、圧倒的なスピードでのレビューありがとうございました。

セッションの同時通訳

昨年くらいのDroidKaigiから海外の登壇者も増えてグローバルな大規模Androidカンファレンスになった印象です。海外のスピーカーのセッションだと英語になるので、どうしても聴講者数が日本語セッションと比べて少なくなりやすいです。ですが、今回からいくつかの英語セッションで同時通訳が採用されて、聴講者数が増えたと思いますし、逆に海外からの参加者の方も同時通訳を利用して日本語セッションを気兼ねなく聴講することができたと思いますので、素敵な取り組みだったと思います。

簡単にフィードバックしやすいアンケート

各セッションに対するフィードバックはとても重要なものだと考えます。なぜならフィードバックをもらって刺激を受けたり、さらに改善に繋げることができるからです。ただ、アンケートするの忘れてしまったり、ちょっとめんどくさくなってアンケートをやらないなどのご経験は誰にでもあるのではないでしょうか?今回のDroidKaigiのアプリUIはその課題をうまく解決できていたと思います。

セッションが終わるとアンケートリンクが表示される 簡単にアンケートに答えやすいUI
f:id:tommy_kw:20190209080406j:plain f:id:tommy_kw:20190209080452j:plain

またアプリだけでなく、セッションとセッションの間の休憩時間が20分と長くなっていて、その隙間時間に余裕を持ってアンケートに回答することができました。各セッションの司会者の方がアンケートについてのリマインドをして下さったおかげて全てのアンケートに回答することができました。全体を通してもとてもアンケートの回答率が高かったのでないでしょうか。

心地よい疲労感

正直にお伝えすると、昨年までのDroidKaigiでは疲れて寝そうになってしまうことが少しだけありました。体力にあまり自信のない僕にとって、1日8セッションくらいを聴講することはちょっとハードなことです。ですが、今年のDroidKaigiでは眠気に襲われることもなく、心地よい疲労感に包まれながら楽しむことができました。振り返ってみると、以下のジャンルのセッションを聴講しました。

  • Flutter
  • Gradle
  • Server-side Kotlin
  • アーキテクチャー
  • TensorFlow
  • Jetpack
  • マルチモジュール
  • Androidプラットフォーム
  • Dex R8
  • Android Studio設定
  • Codelabs

Androidのカンファレンスではありますが、本当にジャンルが豊富であることがわかります。この豊富なジャンルのおかげで全く飽きなかったことや、Codelabsで実際に手を動かし、コードを書いていたことも大きな要因かなと思います。Codelabsは今まで一度もトライしたことなかったので、新鮮で本当に面白かったです。以下がCodelabsのリファクタリングに関する内容になっていますので、ご興味のある方はご覧ください。

github.com

セッションやカンファレンスアプリについて

DroidKaigiのスタッフの皆さんのおかげで、すでにDroidKaigiのセッション動画が公開されています。また、まとめ記事もありますので気になる方はご覧ください。今回は特に気になったセッションやカンファレンスアプリについて紹介させていただきます。

www.youtube.com qiita.com qiita.com

Server-side Kotlin for Frontend: 複雑なAndroidアプリ開発に対するアプローチ @qsonaさん

FiNCさんのKotlinを用いたBFFの紹介で、BFFとは、ClientとBackend Serverの間にServerを配置するパターンです。コネヒトで運営しているママリでも画面によっては、APIを10個くらい叩いている画面が存在します。そのような画面においてBFFは有効で、AWSサーバ間との通信であれば10msくらい*1でレスポンスが返ってきて、クライアント側では1つAPIを叩くだけで必要なレスポンスを取得することができます。ただ、BFFのサーバを挟むことによって管理対象が増えるため適切な設計が必要となります。こちらのセッションでは、FiNCさんの貴重な導入事例が紹介されていますので、ご興味のある方はぜひご覧ください。

All About Test of Flutter @kikuchyさん

docs.google.com

実はFlutterを全く触ったことがなかったのですが、ユニットテスト、Widgetテスト、結合テストとわかりやすく説明していただきセッションが終わった頃には、「なんかテストが書けるような気がする!」という思いになっていました。とはいえ、FlutterもDartも全く触ったことがなかったので、DroidKaigi後にGoogle Codelabsで簡単なアプリを触ってみました。

codelabs.developers.google.com codelabs.developers.google.com

Dartの文法に関しては、こちらもkikuchyさんの資料で勉強させていただきました。 qiita.com

改めて、kikuchyさんの登壇資料のユニットテスト、Widgetテスト、結合テストまで一通り試してみるとめちゃくちゃ理解しやすかったです。なんだか、FlutterやDartを好きになりました。テストの書き方はわかったのですが、実際のアプリではどんな風にテストを書いているんだろうとふと考え、メルカリさんのカンファレンスアプリで勉強させていただきました!ご興味のある方はこちらも覗いてみると良いかもしれません。

github.com

Android Studio設定見直してみませんか? @shirajiさん

shiraji.hatenablog.com

僕が見た中で一番盛り上がっていたセッションで、スピーカーと聴講者が一体になって楽しむことができた聴講者参加型のセッションでした。Android Studio設定の便利機能をたくさん紹介していただき、早速利用させてもらっています。さらにどうやって機能実装しているんだろうと気になることばかりだったので、IDEやPlugin周りのコードを漁ってみようと思いました。

カンファレンスアプリ

github.com

カンファレンスアプリは知見の塊です。実際のコードやPRやIssueを覗いてみると参考になる情報がたくさん詰まっています。今回はその中で気になったPRを紹介します。

メモリーリークの対応ってどうやっているか気になりませんか?こちらのPRではRecyclerViewの利用に関するメモリーリーク対応でした。 github.com

gzip対応することによってトラフィック量を減らすことができたというまさにawesomeな内容でした。 github.com

Android Studioで、変数名に「favorited」、「okhttp」、「ktor」を利用するとIDEのスペルチェッカーに引っ掛かりTypoしてますよと警告される経験はありますよね。.idea/dictionaries以下に辞書ファイルを定義することによって警告を制御することができるという内容でした。 github.com

build.gradleでリソース変数のresValueをうまく利用されていてとても参考になりました。 github.com

PR自体はSafeArgsに関する内容ですが、初期化のタイミングについてコメントされており、改めて初期化のタイミングを意識しないといけないなと考えさせられる内容でした。 github.com

他にもたくさん参考になるPRがありますが、 awesomeラベルが貼ってあるPRもあるのでそれらを見るだけでも面白いと思います。ご興味のある方はご覧ください。

最後に

運営の皆さん、登壇された皆さん、参加者の皆さんのおかげで今年も楽しい時間を過ごすことができました!Flutterを全く触ってこなかったのですが、DroidKaigiのおかげでFlutter、Dartが好きになりました!DroidKaigiに参加させてもらってたくさんの知見を得ることができたので、今度はそれをプロダクトに反映してユーザに還元していきたいなと思っています。それではありがとうございました!

*1:サーバーの処理にかかる時間に依存しますが、ネットワーク間でかかる時間は長くみても10ms以内

忘年会コンテンツをFirebaseとHerokuを使って3日で実装しました

こんにちは、CTO室エンジニアの安達 (@dachi_023) です。少し時間が経ってしまいましたが、弊社の2018年忘年会で実施した催し物についての話をします。

やったこと

社員同士で写真をたくさん撮った人の勝ち というサービスを作りました。

サービス名は写真を撮る擬音「パシャリ」と競技的な意味で「オリンピック」をくっつけて パシャりんピック となりました。もともと、社内で「〜ピック」みたいなオリンピックをもじった名前をつける文化があり、そこに乗っかりました。

コンセプト

ご歓談タイムをバージョンアップする

たくさんの人と写真を撮る、という行為を選んだ理由ですが、ただゲーム性があって内輪で盛り上がれるだけなのではなくて、 一緒に働く人たちと美味しいお酒を飲み、美味しいものを食べながらのご歓談タイム をもっと良い形にできるのでは?と思ったからです。

  • 社内のメンバー全員が一斉に集まるタイミングは貴重
  • 同じメンツで話し込んじゃったりして、いろんな人と話せなかったなぁとなりがち
  • そこで、自然といろんな人と話せる機会を作れるような企画がいいのではないか?

上記のような考えから忘年会と相性が良さそう!となり、採用されました。

f:id:dachi023:20190123223620j:plain

開発について

パシャりんピックを実現するために必要なものは2つです。

  • 写真を撮ったり見たりするもの
  • 最後に集計して結果発表するもの

開発体制など

  • メンバー:エンジニア2名
  • 与えられた期間:約3日

インフラ

メンバーは私ともう1名でしたが、得意なことがそれぞれ異なったので (私はJSだし、もう1名はPHPなので) システムを完全に分けて、それぞれ得意技かつ並行で進めることにしました。ので、インフラもそれぞれがやりやすいように分割しました。

Firebase

  • コネヒトの社員のみがログイン・閲覧できる
  • なにかで使えるかもなので写真をクラウドストレージにアップロードできる
  • 最後に順位をつけて表彰したいので誰が誰と撮ったかをDBに格納できる
  • 上記を実現するwebサービスを公開する場所がある

これらの要件を1サービスでサクッと実現できるためFirebaseを選びました。本当は無料枠でどうにかなる予定でしたが、忘年会前日の夜に実装をミスって無料枠を食いつぶしてしまったので結局課金しました...。

f:id:dachi023:20190123161736p:plain
Firebaseの開発メニュー。AuthもDBもStorageもHostingもあるので全部Firebaseでできる

Heroku

  • Dockerコンテナが使える
  • Firebaseからデータを吸い上げて集計処理ができる
  • 慣れていて、とにかくやりたいことをサクッと実現できる

HerokuはPaaSサービスでもかなり使い勝手がよい素敵なサービスです。対応している言語も多く、弊社でもチャットボットなどのツールでの実績があったりなどして「使いやすい・慣れてる」というのが大きな理由になりました。ちなみに、Firebaseからデータを取り出してくるのはFirebase SDKがあるのでどこからやってもサクッとできちゃいます。

f:id:dachi023:20190123183221p:plain
Herokuなら無料!

コード管理

GitLab

コネヒトではGitHubを使っていますが今回はGitLabを使いました。GitLabちゃんと使ったことないから試しに使ってみるか!という思いと、本当はGitHubのorgにリポジトリを置きたかったけど置くと忘年会のサプライズコンテンツなのにバレちゃうよね、という理由からでした。

結局git pushくらいしかしてないのでGitLabの良さを発見できなかったのですがその後に個人開発で使ってみたりなどしているので、とっかかりとしては良かったかな〜と今は思っています。

構成図

全体で見てみるとこんな感じになりました。

f:id:dachi023:20190123185827p:plain

フロントエンドの実装

技術選定

  • material-ui
  • firebase
  • react
  • styled-components

今回は3日間という長くはない期間の中でいかにちゃんと動くものが作れるか、という状況だったのでとにかく乗っかれるものには乗っかって体験づくりにフォーカスできるようにしました。なので、なるべく手に馴染んでいる技術を選ぼうということで私の場合は上記のような構成になりました。

f:id:dachi023:20190123195040p:plain
こんな感じで自分の撮った写真で画面が埋まっていく

やってみてどうだったか

f:id:dachi023:20190123223025j:plain
パシャパシャしている様子
f:id:dachi023:20190124132747j:plain
写真を撮るとスクリーンに映した画面に流れてくる

想像以上に盛り上がりました!

  • 参加者:約50名
  • 歓談タイム:約40分
  • 撮影総枚数:約550枚

ご歓談コンテンツとして受け入れられたようで、がんばって作ってよかったなぁエンジニア日和だなぁ、と感動しつつ忘年会を終えることができました。積極的に写真を撮って盛り上げてくれたみなさんにとても感謝しています。

後日談

一緒に制作してくれたエンジニアの @o0h_ が振り返りページを作ってくれました!このページで自分以外の撮影した写真を眺めたりできるようになりました。

f:id:dachi023:20190124144712p:plain
優勝はCEOでした (笑)

さいごに

はじめて忘年会をハックしてみましたが楽しかったです。作るのはもちろんですが、目の前で自分がつくったもので楽しんでいるのを見れたのが最高でした!

コネヒトで実践しているチームビルディングのワークショップ4選

はじめに

本記事は コネヒト Advent Calendar 2018 の25日目のエントリーになります。遂に最終回!メリークリスマス!

こんにちは。アルバルク東京🏀を応援している @itosho です。バスケットボールと言えばチームスポーツ!と言うわけで、今日はいつもと趣向を変えてチームビルディングにフォーカスを当てたいと思います。

コネヒトでは開発手法としてスクラムを導入しているのですが、チーム一丸となって「スクラム」を組んで開発を進めていくためにはチームビルディングが不可欠です。

僕は約1年前からスクラムマスターをやらせてもらっているのですが、チームビルディングをしていくにあたって最初はとても苦労しました。*1それは、チームビルディングに「銀の弾丸」はなく組織 / 現場毎に課題や状況の変数が異なるため、教科書通りにやってみても上手くいかないケースが多いからだと考えています。*2

それでも1年間続けてみてある程度形になってきた部分もあるので、本エントリーでは書籍を読んだり勉強会に参加したり他社さんの事例を聞いたりして、実際に僕がコネヒトで実践しているチームビルディングのワークショップを4つ紹介したいと思います。なお、それぞれのワークショップ単体でも一つの記事が書けるほど奥深いワークショップですので、今回は概要のみに留めさせていただきます。

KPT

最初に紹介するのはKPT(読み方: ケプト、ケーピーティー)です。こちらは日本のスクラム開発現場でも多く取り入れられている手法ですので、ご存の方も多いかもしれません。

KPTは振り返りのためのフレームワークで、流れとしてはまず最初に「Keep」としてよかったことや今後も続けたいことを挙げます。次に「Problem」として、よくなかったことを挙げます。そして、最後にKeepをよりよくする、もしくはProblemを改善する「Try」を挙げます。なお、挙がったTryを全て取り組むのは難しいことが多いため、取り組むTryは話し合って決めます。

KPTはフレームワークに沿えば比較的容易にプロセス改善のPDCAを回すことができ、また導入している現場も多いため、振り返りをしたことがない現場へ最初に導入するワークショップとして非常にお勧めです。

コネヒトでの利用シーン

  • コネヒトでは最もよく利用されているワークショップで、主にスプリントの振り返りとして活用されています。
  • また、みらい会議*3という全従業員が参加するような開発以外の会議でも活用されています。

注意点

  • 取り組むTryについて、コネヒトでは多数決で決める*4ことが多いのですが、合議制で必ずしもよいとは限りません。ですので、Tryの優先度をきちんとチームで見極める必要があります。
  • これはKPTに問題があるわけではないのですが、毎回同じ方法で振り返りをしていると飽きたり惰性で行なったりするようになってしまいます。ですので、コネヒトでは気分転換に違うワークショップを取り入れたり、KPT自体をカスタマイズしています。

様子

KeepとProblemとTryが張り出された様子です

学習マトリックス

次に紹介するのは学習マトリックスという方法です。KPTと似ているのですが、名前の通りアウトプットがマトリックスとして表現されるのが特徴的です。

こちらも振り返りのためのフレームワークで、流れとしては最初に「Good」としてよかったことを挙げます。2つ目に「Change」として変えたほうがよいことを挙げます。3つ目に「Idea」として新しいアイディアを挙げます。そして、最後に「Thanks」としてメンバーなどに感謝したいことを挙げます。

プロセス改善のPDCAを回すという意味ではKPTと同様ですが、斬新なアイディアを出しやすいこととメンバーに感謝を伝えられるので、場が暖まりやすいワークショップでもあります。

コネヒトでの利用シーン

  • KPTがマンネリ化している時の振り返りのワークショップとして利用されることが多いです。
  • 具体的には Connehito Marché という社外向けの勉強会の振り返りによく利用されています。勉強会の振り返りは普段のスプリントでの振り返りとは異なり日々継続的に改善していくものではないので、労いや感謝の言葉を伝える「締め」の場にもなっています。

注意点

  • 場が暖まりやすいワークショップなので、ややもすれば「なんとなくやった感」や「なんかいい感じ」で終わることがあります。ですので、やりっ放しにせず、きちんと次のアクションが打てるようにしましょう。
  • KPTに比べると、あまり事例が多くない(少なくとも日本では)ので、振り返りに慣れていないと少し苦労するかもしれません。少なくとも、ファシリテーターは何故学習マトリックスを利用するのかを語れるようにしておくとよいと思います。

様子

学習マトリックスの完成図はこんな感じです

ドラッカー風エクササイズ

3つ目に紹介するのはドラッカー風エクササイズです。ちなみに、ドラッカー風のドラッカーはかの有名な ピーター・ドラッカーさん から取られています。ドラッカー風エクササイズは一言で言うと、期待値調整と相互理解のためのワークショップです。

コネヒトでは 原案 を少しアレンジして運用しており、具体的にはワークショップの参加メンバーは以下の質問に答えながらワークショップを進めていきます。

  1. 自分の得意なこと
  2. 自分が期待されていること
  3. ◯◯さんに期待していること(チームメンバー全員)

これらの質問に答えることで、みんなが思っていることと自分が思っていることのギャップを認識することが出来ます。そして、チームとしてそのギャップを埋めていくことがこのワークショップの目的です。

コネヒトでの利用シーン

  • コネヒトではまだお互いのことがあまり分かっていない新チームの結成時や新規プロジェクトの開始時によく利用されています。
  • チームビルディングとの文脈ではないので本エントリーでは触れませんが、インセプションデッキの作成と同じくらいのタイミングで実施するのが個人的には好きです。

注意点

  • 率直な発言を引き出すために、比較的心理的安全性の高さが求められるので、ファシリテーターは楽しくワイワイ出来るような場作りに努める必要があります。
  • また、やりっ放しにならないようにこのワークショップで出た付箋などは普段から見えるところに置いておきましょう。

様子

ワークショップで集まった付箋はみんなのデスク近くに置くようにしました

スタート・ストップ・コンティニュー

最後に紹介するのは、スタート・ストップ・コンティニューです。実はこのワークショップはまだ1回しか試したことがないのですが、けっこう面白かったので最後に取り上げたいと思います。コネヒトでは振り返りのワークショップとして導入しましたが、それ以外のシーンでも活用出来るのではないかと考えています。

元ネタは僕が大好きなNetflixなのですが*5、コネヒトでは個人にフォーカスした振り返りとして実施しました。

具体的には下記の3つの項目をチームメンバー全員にフィードバックします。

  1. 始めて欲しいこと
  2. 止めて欲しいこと
  3. とてもうまくいっているので続けて欲しいこと

一緒に頑張ったチームメンバーから率直なフィードバックを貰うことで、次の仕事に活かすのが狙いです。

コネヒトでの利用シーン

  • 先述の通りまだ1回しか試していないのですが、とある開発チームの最後の振り返りに利用しました。
  • Netflixでは相手に改善して欲しいことがあれば、上長ではなく本人に面と向かって言うという文化が根付いていて素晴らしいなと思うので、コネヒトでも利用頻度を上げていきたいなと思っています。

注意点

  • チームメンバーが充分にラポールを形成していたり信頼関係を築いていたりする必要があるので、プロジェクト初期では避けたほうが無難です。
  • つまり、ドラッカー風エクササイズより高い心理的安全性が必要になります。個人的な工夫としては、チームメンバーに遠慮がないことと思いやりがないことは違うよ、というようなことを事前に伝えています。

様子

最後はみんなのフィードバックをもとに最優先するスタート・ストップ・コンティニューを決めました

まとめ

さて、ここまで主にファシリテーターとして僕がよく実践しているワークショップを4つ紹介してきましたが、コネヒトではこれ以外のワークショップもたくさん実践しています。それは、コネヒトの開発メンバーが日々のプロセス改善をジブンゴト化しているからであり、その時々の状況にあった方法を模索しているからです。

冒頭でも述べたようにチームビルディングに「銀の弾丸」はありませんし、極論ですが、僕はチームビルディングの「How」は何でもいいと思っています。大切なのは、何故その「How」を取り入れるのか?その背後にどういう課題や問題意識があるのか?をきちんと自分で語れることだと思います。ただ有名な会社がやっているから真似してみたとか、教科書に載っていたから採用してみただけでは意味がありません。*6ですので、思考停止せず、自分たちに合った「How」を「Why」から考えることがよりよいチームをつくるための最初の「一歩」だと僕は考えています。

というようなことを、僕はスクラムマスターの経験を通じて、今年学ぶことが出来たので、2019年もコネヒトはよりよい開発組織になれるように引き続き試行錯誤していきたいと思います!

参考サイト / 文献

*1:今も試行錯誤の日々ですが、特に最初は慣れていなかったので大変でした。

*2:僕自身の力不足もあると思いますが…!

*3:コネヒトのちょっと先の未来についてみんなで課題抽出と解決案の検討を行う会議のこと。

*4:カラーコードドットという方法を採用しています。

*5:Netflix社が具体的にどういう方法で実践しているかは不明。ご存知の方がいましたら教えてください…!

*6:もちろん、最初の一歩として参考にするのはGoodだと思います。