コネヒト開発者ブログ

コネヒト開発者ブログ

コネヒトで実践しているチームビルディングのワークショップ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だと思います。

Kotlin IDE Pluginに共通で定義管理できるplugin-common.xmlが出来ていた

f:id:tommy_kw:20181223172957p:plain

はじめに

本記事はコネヒト Advent Calendar 2018の24日目のエントリーです!

qiita.com

メリークリスマス!Androidエンジニアの富田です。今回はKotlin IDE PluginのKontributeに関する小話で、plugin-common.xmlが生まれてちょっとだけめんどくさい作業が減ったよという内容を紹介します。

Kotlin IDE PluginのKontributeって?

以下のようなCode InspectionIntentionなどの機能についてのKontributeを表します。 f:id:tommy_kw:20181223105545g:plain github.com

詳しい内容については割愛させていただきますが、Kotlin IDE PluginやKontributeについて興味を持った方はぜひ、しらじさんの下記資料をご覧ください! photos.google.com

Kontributeする上でここが煩わしかった

github.com

改めて上記のPRを見ていただくと、複数のplugin.xmlが存在することに気づきます。Kotlin IDE Pluginを開発する上でIntelliJ IDEAとAndroid Studioに対応しなければならないため設定情報(今回はInspection情報)を複数のplugin.xmlに記述する必要がありました。

gist.github.com

以前は上記の設定を下記全てのplugin.xmlに追加していました。ファイル数が多いため自動で追加するGradleタスクがないのかなと探してみたものの、結局なさそうだったのでどうしたものかなと悩んでいました。

  • plugin.xml
  • plugin.xml.173
  • plugin.xml.181
  • plugin.xml.183
  • plugin.xml.as31
  • plugin.xml.as32

KotlinConf 2018にて質問してみた

今年10月に開催されたKotlinConf 2018にて、JetBrainsの方に自動で生成するGradleタスクはありますか?と質問したところ、ないですよという回答を頂きました。それから引き続き愚直にコピペを繰り返していると、10/22にplugin.xmlがリファクタリングされて、plugin-common.xmlが生まれていたことに気づきました!

github.com

各plugin.xmlに以下のようにplugin-common.xmlをincludeすることで共通化されます。Gradleタスクを用いて自動で生成することしか考えていなかったので、なるほど!と勉強になりました! gist.github.com

さらにidea/src/META-INF以下で管理されていたplugin.xmlなどのリソース周りはidea/resources/META-INF以下に移動されていました。移行スクリプトってこう書くのねとコードを読むだけでも面白かったので興味のある方はぜひ! github.com

plugin-common.xmlが生まれてどうなったの?

github.com 上記は先月出したPRになりますが、plugin-common.xmlだけ設定していることがわかります。煩わしい作業が減ってちょっと楽になりましたね!

まとめ

簡単にではありますが、最近のKontribute事情を紹介しました。やっぱりわからないことはカジュアルに聞かないとダメだなと反省しつつ、引き続きKontributeを続けてアウトプットしていきます!

qiita.com

明日最終日のコネヒト Advent Calendar 2018はいとしょさんになります!お楽しみに!

プロダクション環境ですぐに活かせそうなAWS re:Invent 2018のSageMakerアップデート5選

f:id:tatsushim:20181223233656p:plain

時間のない方向けにざっくり言うと

  • 11月にSageMakerのお話で登壇したけど、12月のAWS re:Invent 2018でたくさんアップデートがあった
  • 既存機能の強化に留まらず、「データの準備」から「モデルの変換」もサポートされるようになり、SageMakerの守備範囲がグッと広がったアップデートだと感じた
  • この投稿はその中でもママリのプロダクションですぐに活用できそうな5つのアップデートについて内容をまとめた

この記事はコネヒトアドベントカレンダーの23日目の記事です。 qiita.com

こんにちは!

CTOの島田(@tatsushim)です。
先月11/1「AWS dev day」に登壇させていただきました。 そのときの資料はこちらです。

現場で用いたSageMakerについて発表させていただいたのですが、私の発表の翌月にre:Inventがあり、SageMakerも大きくアップデートがありました。
今回は、プロダクション環境ですぐに活かせそうなAWS re:Invent 2018のSageMakerアップデートを5つご紹介します。

5つのアップデート

1. データ準備サポートツールの追加( Amazon SageMaker Ground Truth )

  • 「この画像は犬の画像であるか、そうでないか」を分類するタスクがあるとします。これを機械学習によって分類するためには、まずはじめに「この画像は犬ある」というラベルが付いた画像と「この画像は犬ではない」とラベルが付いた画像が必要です。
  • こうした状況で、データ(この例では画像)に対してラベル付けを支援するのがAmazon SageMaker Ground Truthで、利用するメリットは下記の2つです。
    • ①: ラベリングツールがAmazon SageMaker Ground Truthで提供されるため、ラベルをつけるツールの購入・自作・管理が不要
    • ②: S3にラベル付けしたいデータをアップロードして、Amazon SageMaker Ground Truthでラベルをつけると結果がS3にあがるため、データの管理が明確
  • また、一部のデータを人の手でラベル付けした上で、その元データから自動で付与するような機能も存在しています。

2. Gitのインテグレーション

  • SageMaker上でGitリポジトリを登録しておけば、ノートブックインスタンス起動時にリポジトリがgit cloneされるようになりました。
  • 今まではコンソールからGitを利用するか、Jupyter Notebookで書いたコードを手動でGit管理する必要がありましたが、JupyterLabのGit extension設定がデフォルトでされる形になるので、視覚的な管理が可能になりました。

3. 学習・推論用コンテナのアップデート

  • TensorflowコンテナがPython3に対応しました。
    • (日本語処理をしてる側からすると嬉しいアップデート!)
  • scikit-learnのコンテナが追加されました。
    • ただしほとんどのアルゴリズムで分散学習に対応してないため、学習は単一インスタンスで行うことになると思います。

4. 学習ジョブモニタリングのサポート

  • 学習時のモデルの精度をグラフ化できるようになりました。
    • 正規表現でルールを書いて、標準出力から精度を抽出する必要があります。
  • ビルトインアルゴリズムの場合は最初から設定されているので正規表現は不要です。
  • 注意点としては、1分おきのメトリクスになっている点です。現状の仕様ではこれは1分未満はできないそうです。

5. 推論時にGPUの部分的な利用をサポート( Amazon Elastic Inference )

  • GPUリソースをEC2やSageMakerのインスタンスに一部割り当てることができるサービスのようです。
    • (最初何言ってるかわからなかった)
  • イメージとしては、PythonでボトルネックになってるところをCythonで書くみたいな感じで、コードとしてGPUを使用する箇所を明記することで、そこだけGPUを利用してくれるようです。
  • こちらにサンプルコードがありますので、イメージとしてはこちらをご覧になっていただくのが良いかと思います。
  • 画像分類の推論をリアルタイムで処理したいニーズには便利です。

終わりに

他にも強化学習、DeepRacer、AWS Marketplace for Machine Learningなど触れたい部分はたくさんあるのですが、今回は比較的すぐに実応用可能なアップデートに絞って内容を共有させていただきました。
機械学習の分野でますます活用が増えていくであろうSageMakerには今後も注目ですね。
以上、島田(@tatsushim)がお送りしました!
今年も、ここまで1日も切らさずにコネヒトアドベントカレンダーは続いております。ここまで継続してくれているメンバーに感謝です。
明日は富田(@tommykw)さんのターンです!

DockerとJavaScriptの付き合いかた

f:id:dachi023:20181220161955p:plain

こんにちは。エンジニアの安達 (@dachi_023) です。会社用アカウントとして @ry0_adachi を用意していましたが全然呟かなくなっちゃったので辞めました。複数アカウントの運用って面倒ですね...。はい、コネヒト Advent Calendar 2018 の20日目はDockerとJSです。

まえがき

DockerfileにJS (とかCSSとかHTMLとか) のビルド処理を書いてコンテナ立ち上げてブラウザで見えるところまでの話です。

本記事では最低限これができていればそんなに遅くならないよねってものをいくつか書いています。コードは GitHub に上がってますのでそちらを見ていただいてもOKです。このコードは create-react-app で生成したものをビルドしてコンテナ上のNginxで公開するという簡単なものですが、実際にママリのProduction環境に投入したものもJSに限って見てみればやってることはほとんど一緒になったので、この手の問題はあんまり難しく考えないほうがいいんだろうな、というのが現状の結論です。

今回はやってませんがSSRする場合は他にも考慮すべき点がありそうなのでもうちょい複雑かもなと思ってます。

Dockerfileを書くときに気にしてること

めちゃくちゃ普通なんですけど一応書いておきます。

  • キャッシュをなるべく使えるようにする
  • イメージのサイズを小さくする

JS起因でDockerのビルドが遅いのはだいたいインストールとビルドのせいなのでキャッシュが効くべき時に効くのが大事そうです。あとはイメージサイズを小さくするためにどのイメージを使うかとか、ビルドの過程で使ったツールなどをイメージに含まないかとか、そういうのを意識してます。

たとえば

上記は GitHub に上げたDockerファイルですがこの12行だけでも気にしてることを満たせているはずです。

  • yarn [install] でキャッシュを効かせたいので実行前にCOPYしてくるのは package.jsonyarn.lock だけにして、ビルド時に使うものはその後にCOPYしてくる
  • multi-stage build を使うことでnode_modulesやビルド前のファイルなどを最終イメージに残さない

実際にdocker buildした結果はこんな感じです。

キャッシュ無

$ time docker build -t dachi023/docker-create-react-app:test .
real    1m5.287s
user    0m0.375s
sys 0m0.249s

フルキャッシュ

real   0m2.172s
user    0m0.165s
sys 0m0.116s

一部キャッシュ (JSのコードを編集)

real   0m18.399s
user    0m0.229s
sys 0m0.147s

あとは $ docker run -itd --name docker-create-react-app -p 8080:80 dachi023/docker-create-react-app:test などとやると起動までちゃんとするのでサクッと何かを作りたい時などにご活用ください。

まとめ

キャッシュが効いててイメージが軽ければ開発時のストレス減りそうだね、というお話でした。アプリケーションが複雑になっても基本この2つがブレないようにしていればいいのではないかと思ってます。Dockerチューニングでやれることはまだあるかと思いますが、まずは効き目のある部分からやっていきましょう!

明日は nkuroda さんの引っ越し話です!技術が絡んでくるかもしれないし絡まないかもしれません、ご期待ください! 👋

How to Write Testable Code in Golang

f:id:itosho525:20180823212423p:plain

はじめに

本記事は コネヒト Advent Calendar 2018 の19日目のエントリーになります。

こんにちは!先日PHPカンファレンス(通称: ペチコン)でLT登壇させていただいた @itosho です。

ペチコンのことも書きたいのですが、ペチコンでもGoの話をしたので、今日はGoのテストを話をしたいと思います。具体的には、今年公開した gdp というCLIツールのテストを書く時に工夫したことを紹介します。

ちなみに、gdpがどういうツールなのかは以前 Go製のCLIツールを公開しましたという記事で説明しているので、もし興味がある方はこちらも読んでいただけると嬉しいです。

開発初期のコード

gdpにはリモートリポジトリに指定したtagが存在確認を行う処理があるのですが、当初はこんな感じのメソッドを用意していました。*1

呼び出される側

func IsExistTagInRemote(tag string) bool {
    out, err := exec.Command("git", "ls-remote", "--tags", "origin", tag).CombinedOutput()
    if err != nil {
        return false
    }

    if string(out) == "" {
        return false
    }

    return true
}

呼び出す側

func main() {
    err := Validate(tag) // tagは事前にコマンドライン引数から取得
}

func Validate(tag string) error {
    if !IsExistTagInRemote(tag) {
        return errors.New("tag is not exist in remote")
    }

    return nil
}

問題点と解決方法

このコードでも、やりたいことは実現出来ます。しかし、テストのことを考えるとこのコードには問題があります。何故なら、 Validate() メソッドが IsExistTagInRemote() メソッドに依存しているからです。IsExistTagInRemote() メソッドは外部(リモートリポジトリ)との連携があるため、Validate() メソッドのテストコードを書く際に IsExistTagInRemote() メソッドの結果を変更するのが難しく、結果としてテストしづらくなります。これがまだローカルのテストであればよいのですが、例えば、CIのテストとなると、場合によってはgitのセットアップから始める必要があり、非常に手間がかかります。

このような問題を解決する手段として、Goでは Interface を利用します。Validate() メソッドを IsExistTagInRemote() メソッドに依存させるのではなく、Interfaceに依存させます。そうすることで、モックが使えるようになるため、テスタビリティを向上させることが出来ます。

Interfaceを利用したコード

概念だけだと分かりづらいと思うので、実際のコードをご覧ください。

呼び出される側

type Git interface {
    IsExistTagInRemote(tag string) bool
}

type Cmd struct {
}

func (c *Cmd) IsExistTagInRemote(tag string) bool {
    out, err := exec.Command("git", "ls-remote", "--tags", "origin", tag).CombinedOutput()
    if err != nil {
        return false
    }

    if string(out) == "" {
        return false
    }

    return true
}

Git というInterfaceにIsExistTagInRemote() というメソッドを持たせるようにしました。GoではメソッドリストがInterface内のメソッドと一致する型はそのInterfaceを満たしていることになるため、 Cmd 型は Git Interfaceを実装していることになります。

呼び出す側

func main() {
    cli := &CLI{
        git: &Cmd{},
    }

    err := cli.Validate(tag) // tagは事前にコマンドライン引数から取得
}

type CLI struct {
    git Git
}

func (cli *CLI) Validate(tag string) error {
    if !cli.git.IsExistTagInRemote(tag) {
        return errors.New("tag is not exist in remote")
    }

    return nil
}

CLI 型にGit Interfaceを持たせて、Validate() メソッドはこのInterfaceを利用します。初期化時に Cmd型を与えているので、実際にはCmd型の IsExistTagInRemote() メソッドが実行されますが、Validate()メソッドはそれを知らない(あくまでIntefaceを利用している)ので、冒頭のコードにあった依存をなくすことが出来ました。

Interfaceを利用した際のテスト

では、これで本当にテスタブルになったのか確認していきましょう。Validate() メソッドのテストは以下のように書けます。

type MockCmd struct {
    Git
}

func (m *MockCmd) IsExistTagInRemote() bool {
    return false
}

func TestValidate_NotExistInRemote(t *testing.T) {
    cli := &CLI{
        git: &MockCmd{},
    }

    err := cli.Validate()

    expected := "tag is not exist in remote"
    if !strings.Contains(err.Error(), expected) {
        t.Errorf("Output=%q, Expected=%q", err.Error(), expected)
    }
}

ポイントは Git interfaceを満たすモックを準備していることです。Validate() メソッドのテストでは、このモックを利用することで、Gitのセットアップなしにテストを行うことが出来るようになります。冒頭のコードでは依存があったため、このようなモックを準備することが困難でした。しかし、Interfaceを利用することで、モックが使えるようになり、結果としてテストコードを書くことが出来るようになりました!

まとめ

ここまでInterfaceを利用したテストについて説明してきました。Interfaceを利用することで、依存性を分離することができ、コードをシンプルにすることが出来ました。コードをシンプルにすることのメリットはテストのしやすさだけではありません。例えば、Gitの操作をコマンドベースではなく、APIベースに変更した際、呼び出す側(今回の場合だと CLI 型)は具体的な実装に依存していないので、コードの変更を最小限にすることが出来ます。「Interfaceを制するものがGoを制す」とも言われているように、Interfaceは非常に便利な機能です。

とは言え、常にInterfaceを利用するべきかと言うとそうではないと思います。Interfaceを利用したコードはどうしてもコード量が多くなってしまいます。ですので、例えば、一回きりしか使わない使い捨てコードの場合は冒頭のように愚直に書いたがほうがよいと思います。gdpは社内で頻繁に利用されているツールであり、OSSとして公開しているので、可能な限り*2よいコードを目指しました。

ちなみに、このあたりの話は以前勉強会でも発表させていただいたことがあるので、興味がある方はこちらもご覧いただけるととっても嬉しいです。

speakerdeck.com

参考サイト

Goのこの手の話は五億番煎じくらいなので、たくさんお世話になりました。

明日の予告

明日のアドベントカレンダーは @ry0_adachi さんが登場するよ!

*1:なお、コードは必要な箇所のみ掲載しています。

*2:まだまだ改善の余地はあるので、Pull Requestをお待ちしております。

読書会でチームの改善が捗った話

f:id:yanamura:20181213002738p:plain:w320

本記事はコネヒト Advent Calendar 2018の14日目のエントリーです!

こんにちは!エンジニアの柳村です。

わたしの所属するチームではチームメンバー全員がスクラムマスターをできるようになろう!という目標でいろいろなことをやっています。その一環としてアジャイルコーチングという本の読書会を行っています。もともとは、単にスクラムやアジャイルのコーチングの知識をつけることが目的だったのですが、チームの開発プロセスの改善がどんどん進むという効果もあったのでそれについてご紹介します。

読書会の進め方

  • 事前準備
    • 各自が1章ずつ読み、その中で「学び」、「疑問」、「試したい」「うちのチームだとどうか」などといった視点で気になったことを付箋に書いてきます。
  • 読書会
    • 30分間
      • (2回目以降)前回のtryの確認
      • 全員の付箋をシェア
      • 疑問点について議論
      • tryすることを決める

付箋はこのように番号(章のどこの節か)書いておくと整理しやすかったです! f:id:yanamura:20181213002038p:plain:w300

ポイント

ポイントは、「tryすることを決める」ことと「前回のtryの確認」です。

本を読んで学びを得たり、疑問が解消するだけでも効果はあるとは思いますが、それを実行に移さないとせっかくの勉強もあまり意味がありません。読書会では最後に実行可能なtryをいくつか出すようにしています。「実行可能な」というところもポイントで、実行できるものでないと結局やらずに終わってしまい意味がありません。大きなtryが出た場合は小さくスライスするなどして対応しています。

また、tryを出してもやらずに忘れられてしまうということも起こります。それを防ぐために次の読書会の最初に前回のtryをやったかチェックする機会をつくっています。

結果

やってみた結果、例えばこのようなtryがあげられて実際にチームで実行しました。

try
5章:デイリースタンドアップ パーキングロットをつくろう
7章:前もって計画する バックアップボードの運用
8章:見える化する ブロッキングしてるタスクを見える化
13章:ふりかえり カラータイムライン、感情セイスモグラフを使う

やってみてうまくいったものもいかなかったものもありましたが、どちらにせよチームとしては学習することができましたし、これまでと比べて格段にチームボードやデイリースタンドアップ、振り返りなどの改善が進んだなと思っています。この読書会自体も最初からこのような形ではじまったわけではなく、改善を重ねてこうなりました。

もっと効率的だったり効果的なやり方もあると思いますので、おすすめの読書会の進め方があればぜひ教えてください!

Connehito Marché #4 ~サービスデザイン市~ を開催しました!

こんにちは。
サーバーサイドエンジニア兼チョコレート大臣*1の結城(@super_manner)です〜。 この記事はコネヒト Advent Calendar 2018の12日目の記事です。

今日は、先日行われたコネヒトマルシェという勉強会のレポートをしたいと思います!

f:id:supermanner:20181211181248j:plain

今回のマルシェのテーマ

今回は少しプログラミングから離れ「サービスデザイン」をテーマに開催いたしました。
昨今注目されている分野ということもあり、非常にたくさんの方にLTをしていただくことができ、 5分枠と10分枠でなんと合わせて10名という過去最高の盛り上がりをみせました🎉

LT内容

LT内容について簡単にご紹介させていただきますね。

デザインをしていく上で行動心理を学ぶと楽になる話

1番目の発表は, yusuke_hata_79さん。
ジャムの法則を例に、ユーザーが選択する際のストレスを減らしてあげることが大事ということを説明してくださいました。 選択をするUIにヒエラルキーをつけることで、申込みのコンバージョンがアップされたそうです!すごい!

※資料未公開

プロトタイピングtips!

note.mu

2番目の発表はRisaHiyamaさん。
Graffityの開発を行った際に得たプロトタイピングのtipsを共有してくださいました。女子大生を巻き込んだり、母校の文化祭に出店するなど行動力の化身ですね!確証をもってアプリの開発に臨むために大切なことを教えていただきました。

チームの成長の流れを掴む話

www.slideshare.net

3番目の発表はAyumuNishibeさん。
チームで成果を出すのはサービスデザインにおいて大切なこと。 定量データ・定性データ双方を読み解き、みんなで一丸となってデータと向き合うことの重要性を改めて考えさせられる発表でした!

リサーチあるあるから見る、UXリサーチの使いどころ

www.slideshare.net

4番目の発表はvegemakiさん。
バリバリの関西弁を操りながら、様々なUXリサーチ手法を可愛らしいイラストと共に解説してくださいました。UXリサーチをこれから始める方は、この資料を読むだけでも基本的なところが理解できます!

tock pop(トックポップ)ロゴ&サービス紹介動画のデザイン

www.slideshare.net

5番目の発表は稲毛誠さん。
ロゴ制作時の試行錯誤のプロセスをかみくだいで解説してくださいました。たくさんのアイデアに非デザイナーの私は圧倒されました...。また、動画制作についても制作の際の工夫を伝授してくれました!

ブランディングのためのUXライティング

speakerdeck.com

6番目の発表はRina_Satoさん。
「ことば」のデザインについてのお話。UXライティングというものをお恥ずかしながら存じ上げなかったのですが、日本語の与える印象一つでこんなにも変わってくるのか〜と驚きました。

チームの議論の土台をつくるためにデザイナーのわたしができること

7番目の発表はNatsukiWatanabeさん。
サービスデザインをするためには、チームで価値を作るということが重要。 デザイナーとしてのサービスデザインの関わり方を、ママリの開発事例をもとにお話しくださいました。日々のチーム開発でも活躍してくださっています!

国内最大のハンドメイドマーケットを支える同僚を支える技術。

8番目は鹿さん。
実は、画面の向こうのユーザーだけがユーザーじゃない。一緒に働いている同僚もユーザーなんだよ、ということを何度も繰り返されていた点が非常に印象に残りました! 鹿さんのプロダクト愛がたくさんつたわってくる発表でした!

※資料未公開

遊びこころの大切さ。あると楽しい一手間。

9番目の発表はkiyoeshiさん。
新規サービスのロゴデザインをする際に、「ひとさじの遊び」を加えることでたくさんの楽しいアイディアが生まれるという話でした。 こちらは、近日きよえ氏がnoteに公開するとのことなので、詳しくはそちらをご覧ください!

※資料未公開

幼稚園児はできてる超高速PDCA

www.slideshare.net

10番目の発表はmiteoさん。
マシュマロチャレンジの結果をもとに、以下にPDCAを早く回していくのが重要かということをお話しくださいました。机上の空論で固めがち….耳が大変痛く、気をつけようと思いました。

懇親会

サービスをこよなく愛するデザイナーさんたちが集まって和気あいあいと会話を楽しんでいただきました!
皆さんサービスとデザインが本当に大好きな方たちばかりで、時間ギリギリまでわいわいと盛り上がりを見せておりました😋

参加くださった皆様で写真をパチリ
参加くださった皆様で写真をパチリ

運営もがんばります

さて、コネヒトマルシェも早いもので4回目を無事に開催することができました。
運営一同、毎回振り返りをしてより良い運営を目指していますので、ぜひ興味のあるトピックの市にいらしてくださいね😊
ツイッターもよかったらフォローお願いします! twitter.com

明日は@ry0_adachiさんのエモい記事です!お楽しみに📖

*1:社員のお母様が買ってきてくださったアドベントチョコを渡す係