satoryuの日記

忘れっぽいから覚えてるうちに書いておかないと。

「デザイン思考の先を行くもの」を読んだ。

デザイン思考 読書

デザイン思考の先を行くもの

デザイン思考の先を行くもの

最近身近に「デザイン思考」という言葉をよく聞くようになった。 言葉自体は以前から知っているが、一冊本を読んだくらいで、仕事でやったことは無い。

ということで、どんなものなのか知るためにとりあえず一冊読んでみた。 208ページある本だが、見開き2ページの片側のみに文章が書いてあり、文量もそれほど多くないのでサラッと読めた。

この本では、デザイン思考はPDCAと類似するものとして扱っている。 計画（Plan）の部分が、デザイン思考では課題からアイデアを出すまでのプロセスに相当するものとしている。 そのため、デザイン思考だけでまったく新しい何かが生まれることはないと注意している。 後半では、アイデアの作り方について書かれていて、参考になりそうだった。

軽く読める本だったが、知りたかったデザイン思考について、デザイン思考の実例については詳しく触れられていなかった。 単にプロセスだけを見て、PDCAと対応づけられるから同じものとして扱ってしまうのは少しやりすぎなのではないだろうか。 自分がデザイン思考について知っているわけではないが、何かしらプラクティスがあるのではないだろうかと思っている。 まだ1冊目なので、こういう見方もあるのだろうなというくらいでとどめておくことにした。

次に読みたい

なるべく原典に近いものを読みたいので、 デザイン思考ブーム（？）の発端になった「デザイン思考が世界を変える」を次は読んでみようかな。

デザイン思考が世界を変える (ハヤカワ・ノンフィクション文庫)

デザイン思考が世界を変える (ハヤカワ・ノンフィクション文庫)

Butterfly Effect #1 に行ってきた。 #バタエフ

Butterfly Effect イベントレポート

Butterfly Effect というイベントが始まる、ということで、初回ゲストがチームメンバーの @TAKAKING22だったので行ってきた。

butterfly-effect.connpass.com

Butterfly Effectって何？

butterfly-effect.connpass.com

イベントページより抜粋すると、

「すごい人が話を聞きたい人の話はすごいはず」という発想で 毎回違ったゲストを呼んでパネルディスカッションをするというイベント。

ということで、懐かしのテレフォンショッキング形式でゲストを回していくイベント。 確かに、紹介してもらった方がいい話をしてくれる人が来るのはかなり保証できそうだし、運営が楽できる。

運営として面白いのは、ゲストへの謝礼が当日Kyashで集められたお金（通称、投げ銭）が支払われるということ。 この集まった額って、どこかで公開されてしまったりするのかな？

当日の様子

会場に入るとウェルカムドリンクをいただき、また今回は石井食品さん提供のミートボールとハンバーグが振る舞われた。

はじめはネットワーキングから始まり、参加者同士で軽くドリンクを頂きながら雑談。 あとでの会場アンケートでわかったのだけど、エンジニアだけでなく、テスト関係の方々やマネージャーをしている人たちもけっこう居た。 参加者層は、ゲストによるのかな。

予めファシリテーターの蜂須賀さんが質問を用意もしているが、当日会場に来ている参加者からもsli.doを使って、質問が集められていた。 昨日集まった質問も下記から見れる。 app.sli.do

どんな雰囲気だったのかは、トギャッターにまとまってる。 togetter.com

感想

まぁ、いつも通りの@TAKAKING22を見てきた感ある。 ゲストのようで、途中から少しずつモデレートしていく感じで、入場から会場の場づくりまでが設計されているようだった*1。

チーム転職の話は皆さん興味あったみたい。 特に辞めた理由は、みなさんネガティブなものを想像していたようなので、世間一般の退職理由ってそういうものなのかというのを察した。

途中自分も少しだけ引っ張り出されて、チームメンバーからはどう見えるのか聞かれた。

昨日言ったように、みなさんがイベントで見てるように何も普段と変わらない。 最後に次回ゲストから言われたように「意外とチャラくない」のである。 マネージメントの話とか聞くとわかるように、チームの成果のために動く人なので、一緒に仕事しやすいし、楽しい。

次回ゲストは？

昨年に少しだけ一緒に仕事をした繋がりのきょんさん！ 日程はこれから調整らしいが、名古屋から来てくれるそうなので参加しよー

おまけ

石井食品さんのミートボールとハンバーグ、マンゴープリンはどれも美味しかった！

*1:というか台本作りを前日に見てた。

7月からデンソーにジョインしましたのお知らせ

転職 デンソー

タイトルにありますように、デンソーの人として7月より働いております。

今は聖地横浜アリーナ近くの新横浜オフィスでソフトウェアエンジニアとして勤務しています。

経緯

今年1月末にチームでFA宣言を公表し、それに反応していただいたのがきっかけでした。

takaking22.com

都内ではどうやら認知度がまだまだ低いようですが、もともと名古屋で生活していた時期があったので、デンソーという名前は知っていました。 ウェブサービスと連携したMaaS開発を本気で取り組んでいて、新横浜をその拠点として一昨年あたりから取り組んでいるところ、お声がけいただきました。 個人的にも、ウェブだけでなくモノと繋がったサービスに携わって、社会に貢献できればいいな、と思っていたのでとても良い機会をいただけました。

ということで、引き続きよろしくお願いいたします。

また、前職の退職祝い並びに入社祝いを受け付けておりますのでお気軽に送りつけてください。 お祝いの品のラインナップは以下のリストをご活用ください。

www.amazon.jp

Tokyu Ruby会議13 でLTしてきた。 #tqrk13

講演 LT イベントレポート Ruby OSS

TokyuRuby会議13のLTに採択されたので、これまで自分が一番長く関わってきたとあるOSSについてLTをしてきました。 自虐ネタとか言わないで、地道な活動の話だと思って見てください。

自分語り

思えば入社して初めて外の勉強会に行ったのも、そこで初めて体外発表という形でLTをしたのもTokyuRuby会議01でした。 たまたま誘ってくれた人が居て、開催場所が大田区の区民施設で徒歩圏内だったからという理由でほいほいと行ってしまったのです。 あの時に誰が何を話していたのかは覚えていませんが、色んな所から面白い人達がRubyという共通点だけで集まって、賑やかで楽かったのが印象的でした。

それからTokyuRuby会議のLT募集にはおそらく全て応募し、ときには都合がつかずにキャンセルしてしまうこともありましたが、可能な限りで参加し、楽しい空気を作るのをお手伝いしてきました。 楽しいと思っていただければ本望です。 退職を目前として、最後のLTがTokyuRuby会議で良い区切りとなりました。 途中で気持ちよく雑魚寝をしてしまいましたが、それもまたTokyu.rbらしさなんだと思います。

たぶん次回も行く。

おまけ

今年もプレモルセミナーを受講しました。神泡は神の泡でした。

Speeeさんは、雑魚寝をするのにとても気持ちの良い会場でした。

月刊ギルドワークス2019年6月号に行ってきた。 #guildworks #nulab

アジャイル アジャイルコーチ ギルドワークス ヌーラボ

アジャイルコーチについてちょうど興味があったので行ってきた。

guildworks.doorkeeper.jp

余談: なんでアジャイルコーチに興味あるのか

次の会社は複業が可能なので、どのような仕事が複業でできそうなのか考えている。 まったく畑違いのことをしても、バリューは出せそうにないので、今までの開発の経験を活かした何かをやりたい。 充てられる時間についても、そこまで多くないことを考えると、ガッツリとした開発をやらせてもらうのは難しいような気がしている。 ということで、週1とかで開発の悩みや抱えている課題の相談にのったり、その解決のための調査や、実際に現場へ入った支援とかが出来たりしないだろうか、と考えている。 アジャイルコーチの中で、常時現場にいる方もいらっしゃるが、定期的に訪問して活動している方がいるので、興味があった。 自分がアジャイル開発の支援をするかどうかはわからないけど。

アイスブレイクとして、自分の現場での立場と今日のイベントで聞きたいことを付箋に書いて、隣の席の人と軽くお話した。

@ikikko さんと @yohhatu さんによる社内、社外コーチという立場についての講演から始まった。

@ikikko さんは、もともとエンジニア出身であり、2016年からアジャイルコーチとして活動を始めている。 本人は、アジャイルと冠をつける必要は感じていなく、チームの外側から支援するもの、という立場らしい。 Backlogの開発マネージャーでもあるので、常に支援先チームに常駐しているわけではない。 マネージャー業務をなるべく午前中に片付け、午後には横断的にチームの状況をチャットの会話やスクラムイベントを見学に言ったりしながら、状況を観察しているそうだ。 コーチとしてのインプット（勉強）については、週1ほどの外部の勉強会参加をこころがけている。 半年前にお子さんが産まれたこと*1から、頻繁には行けない状況ではあるらしい。 質疑のディスカッション中に、「マネージャーとコーチがどう違うのか」というロールの使い分けについての話があった。@ikikkoさんの考え方は、「マネージャーは決定権を持つ、けどコーチは決めることはせずに、決定権を持つチームを支援する」というものらしい。

続いて、@yohhatu さんの社外コーチの話。 ギルドワークスの現場コーチとしてお客さんへの支援の入り方は、現在は主に週1、2から隔週で現場に訪問し、スクラムイベントなどの支援をしている。 月1くらいになってしまうと、お客さんの状況がわからず、「たまにきて良いこというおじさん」という扱いを受けてしまうそうだ。 支援する頻度のポイントは、悩んでいるところに同席して方向性を決め、次の訪問のときにその結果が新鮮なうちに教えてもらえるかどうか、のようだった。 改善施策を伴走していくようなものなのだろうか。 支援先のチームや組織が成熟していったところから、徐々に訪問頻度を下げていき、離れていく。 これまでの支援期間は、だいたい1社あたり1、2年だそうだ。 また、社外コーチとして支援する内容は多岐に渡っていた。開発プロセスはもちろんのこと、営業やマーケティング、バックオフィス、カスタマーサポート、採用など開発の現場に影響を与えるものに関してなら殆どやっているようだった。

感想

アジャイルコーチという仕事は、かなり気苦労の多いものだろうな、と思っていたので、それの実際の話を聞けた。

社内コーチは、おなじ組織なのでいろいろな情報を得やすいが、兼務などが付くとどの立場で発言しているかによって受け取られる印象はかなり異なるだろう。また、社内に明確にアジャイルコーチを置くと決定したのだとすると、組織内にアジャイルに関する理解が多少なりともあるのではないだろうか。

社外コーチは、細かい社内の情報を知らない（知れない）ので、それらの情報を集めるための観察や傾聴のスキルが問われそう。 予め外部から来てることはわかっているので、その立場を利用して、ある程度自分のことを棚に上げて発言することはできそうだ。 ただ、その発言を受け入れてもらうためには、「○○の人」と言われるような外部から見てもわかる実績を持っておく方が良さそう。

そして、いずれも成果はチームのもの、という中でコーチ自身の成長をどう維持していくのかも大変そう。 自分はやっぱりエンジニアとしてメインでやっていきたいので、コーチとしての違う目線をどう養うか、というのもあるのかな。実際やるかはわからんけど。

おまけ

会場提供はnulabさん。

神保町に移転してから始めて来たけど、玄関かわいい。

ウェルカムドリンクに、よなよなエール、インドの青鬼、水曜日のネコが入ってて、いい業界だなって思いました。

提供してくださったnulabさん、ありがとうございました！

【お中元ギフト】よなよなエール ビールギフト 4種 飲み比べ [ 350ml×6本 ] [ギフト包装済] エールビール クラフトビール 人気4種詰め合わせ

【お中元ギフト】よなよなエール ビールギフト 4種 飲み比べ [ 350ml×6本 ] [ギフト包装済] エールビール クラフトビール 人気4種詰め合わせ

*1:おめでとう御座います！

nikotama.rb #2 に行ってきた。 #nikotamarb

Ruby イベントレポート

nikotamarb.connpass.com

第2回目は、残念なことにキャンセルが出てしまい、何の申し合わせもなく弊社*1社員のみで開催となった。 どうやら裏で開催しているk8s tokyo meetupに持っていかれたらしい。

ラクマのサーキットブレーカー導入の話

最初に、今絶賛実施しているというラクマでのサーキットブレーカーの導入のLT。

社内APIを利用するアプリの開発で、そのAPIが死んだ場合の影響を減らすためにYammerが開発しているCircuitboxを導入しようとしているそうだ。

github.com

Faradayのミドルウェアとしても使えるらしいので、お手軽に導入できて良さそう。

  • AcctiveSupport::Notification でcircuit_openなどをsubscribeできてログとか便利そう
  • circuit_gauge をsubscribeするとメトリクス情報が取れる
  • それを外のアグリゲーションに送って集めて、Graphiteとかで可視化すると楽しそう

という話でもりあがった。

誕生日のお祝い

今日の参加者のラクマの方で、お誕生日の方が2名いたのでお祝いした 🎉

ざっくばらんに雑談

といったことでワイワイして今日は終えた。

次回は、7/18（水）開催

ということで、予定を空けておきましょう。

*1:まだ辞めていないので弊社と言える。

Visual Studio Code Remote Development のRuby環境を作ってみた。

Docker Ruby Visual Studio Code

https://code.visualstudio.com/assets/docs/remote/containers/architecture-containers.png

VS Code の次期目玉機能であるRemote Developmentを試してみました。

TL;DR

Visual Studio Code Remote Development って？

先日発表されたVisual Studio Codeの一押し拡張機能で、リモートにあるソースコードや実行環境を利用した開発をVS Code上から実行できるというもの。 接続先には、

  • SSH
  • Container（Docker）
  • WSL

があります。

CPUやメモリ、ビデオカードなど特殊な環境を利用した開発環境をVMで作成し、そこにSSHで接続したり、共通した開発環境をコンテナで揃えるなどができるので便利そうです。 チーム開発時の開発環境を共通化するのが楽になりそうで期待しています。

Remote Development拡張はまだ正式にはリリースされておらず、開発版のVS Code Insidersでのみ利用できます。

普段Macで開発しているので、Mac上でDockerコンテナ上のRuby開発環境を利用するための設定を書いてみました*1。

サンプルアプリ

Sinatraで簡単なウェブアプリを作りました。 http://localhost:4567 にアクセスすると、"Hello, World!"が表示されるだけです。 なので、

  • プロジェクトの依存するgemとしてsinatraがあり、
  • コンテナにポート4567で接続できる

ような環境が必要になります。

構成

Remote Developmentで接続するコンテナについて、下記のファイルがポイントになります。

  • devcontainer.json
  • Dockerfile

Remote Develop拡張のドキュメントの通りにやれば、VS CodeからRubyで開発するためのこれらのファイルを生成してくれます。

ですが、

  • リポジトリ内のファイルを利用したコンテナを作れない
  • bundlerを使うことを想定してない

ようなものだったので、書き換えてみました。

.devcontainer.json

このファイルは、接続するコンテナやリモートにインストールする拡張、そしてその設定などを記述するためのファイルです。 .devcontainer/devcontainer.json にも配置することができるのですが、リポジトリのルートに.devcontainer.jsonに置くことにしました。どうやら、.devcontainerディレクトリ内にDockerfileなどまとめておくのも良いのですが、リポジトリ内のファイルなどをDockerfileでCOPYすることが出来ないようです。

今回は下記のような設定ファイルを書きました。

// See https://aka.ms/vscode-remote/devcontainer.json for format details.
{
    "name": "Ruby 2",
    "dockerFile": "Dockerfile",

    // Uncomment the next line if you want to publish any ports.
    "appPort": [
        4567
    ],

    // Uncomment the next line if you want to add in default container specific settings.json values
    "settings":  {
        "solargraph.useBundler": true,
 },

    // Uncomment the next line to run commands after the container is created.
    // "postCreateCommand": "",

    "extensions": [
        "rebornix.Ruby",
        "noku.rails-run-spec-vscode",
        "castwide.solargraph"
    ]
}
  • appPort: サンプルで書いたSinatraで公開するポート
  • settings: リモートにインストールするVS Codeの拡張の設定。今回はSolargraphを起動する時にbundle execを利用するための設定を追加しています。
  • extensions: リモートにインストールする拡張。

リモートでインストールできる拡張には制限があるようで、UIやThemeなどに関する拡張はインストールできません。

Dockerfile

Remote Development拡張が生成するDockerfileには、bundlerやGemfileに関する扱いが記述されていません。 ここでは、bundlerで依存管理をする開発環境を想定して、Dockerfileに

  • GemfileおよびGemfile.lockをCOPY
  • bundle install を実行して、依存しているgemをインストール

させ、依存するgemをコンテナのレイヤーとして入れています。

先程の.devcontainer.json のpostCreateCommandにbundle installを指定することで、コンテナ生成後にbundle installを実行することができます。 ですが、この方法だと依存関係が変わっていなくても、コンテナを再構築やプロジェクトをVS Codeで開くたびにgemのインストールが実行されてしまいます。

FROM ruby:2.6.3

# Install ruby-debug-ide and debase
RUN gem install ruby-debug-ide
RUN gem install debase

# To install the latest version of bundler
RUN gem install bundler:2.0.1

COPY Gemfile /root/
COPY Gemfile.lock /root/
RUN cd /root/ && bundle install

# Install git, process tools
RUN apt-get update && apt-get -y install git procps

# Clean up
RUN apt-get autoremove -y \
    && apt-get clean -y \
    && rm -rf /var/lib/apt/lists/*

# Set the default shell to bash instead of sh
ENV SHELL /bin/bash

gemのコマンドを実行するには

例えば、Ruby Solargraphのように、gemが提供するコマンドを実行する拡張を使う場合、以下の2通りある。

  1. 環境変数PATHに、/usr/local/bundle/binを追加
  2. Gemfile にgemの依存を記述し、bundle execでコマンドを実行する

今回は1ではなく2の方式で作成してみた。 開発の用途も含めて、プロジェクトで利用するgemはGemfileに記述しておくことで明示的になるし、セットアップの手順もbundle installにまとめられるので、個人的にはこの方式が望ましいと思っています。

おわりに

VS Code Remote DevelopmentのRubyコンテナを使った簡単な開発環境を作ってみました。 これまでもDockerを使って環境を揃えるなどはやったことはありますが、docker execを使ってコマンドを実行するといった煩わしさがありました。 Remote DevelopmentでTerminalを開くとコンテナ内に入った状態から始まるので、スムーズに作業ができるのが嬉しいですね。 そういった環境をコンテナで整備できるので、Remote Development拡張をインストールしたVS Codeがあればすぐに開発が始められそうなので、重宝しそうです。

はやく正式リリースされないかなー

参考

*1:SSH接続も試してみたかったのですがVMを作ったりするのが面倒でお金も掛かりそうで断念しました。