satoryuの日記

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

DENSO Meetup Yokohama #1 に行ってきた。

イベントレポート Ruby TDD デンソー

自動車業界の中でも有名なデンソーさんが、新横浜に独立した内製の開発組織を作っていて、その部署とクリエーションラインさんの共催イベントの第一回目に行ってきました。 Attractor社の吉羽さんがコーチに入っているという話を以前に伺っていて、昨年のデブサミでも講演していたり、大企業の中でアジャイル開発の導入を取り組んでいることは知っていました。 このイベントでは、1年半前のオフィス立ち上げから携わっているエンジニアの方々の話を聞くことができました。

connpass.com

オフィスの一室のでっかいテーブルとでっかいディスプレイをわいわい囲んで、ひさびさに「勉強会」っぽさあるミートアップでした*1。

RoR未経験なのに、3か月でプロトタイプ開発した話 @hiroky_814

最初はGoで書いていたサービスを酔った勢いで本人も使ったことが無かったRailsにしようという提案が採用されて、そこからどういった開発や学びの話でした。 チームで意思決定できる環境で、新しいことにチャレンジしやすい反面、過去に作ったものが負債になってしまうということや、機能ごとに実装した人しかわからなくなってしまうような属人化があるなど、スピード重視で作ったときのあるある感がありました。 しかし、開発の途中から「品質を優先」として、rubocopを入れたり、OSSを読んだり、外部からRubyistを呼んでRails Wayを学ぶといった取り組みをしたそうです。 新しくチームが立ち上がった時に、レビューには他のチームの人たちを招待するという取り組みはとても面白いと思いました。

AWSの機能が増えすぎて、Ruby実装をやり直した話 @じゅんじゅん

パブリッククラウドのアップデートと開発との追いかけっこしてしまった話でした。 作ったり、作ってる最中にほしかったものがリリースされるのありますねーｗ

テスト駆動開発(TDD)の紹介 @安井 力(やっとむ)

昨日は、TDDBCの資料をベースに、TDDの説明とFizzBuzzを例に実演をしてくれました。

TDDBCの資料はこちら。 speakerdeck.com

  • 動かない汚いコードから、きれいで動くコードへ向かう道は二通り。きれいにしてから動くようにする、もしくは動くようにしてからきれいにする。
    • 前者はきれいにすることにいくらでも時間を注いでしまいがちで、きれいにしてから動くようにする時にうまくいかないことがわかったりする。
    • 後者はTDDのとる道。動くようにし、動くとは何かをテストで書いて、それを維持したままきれいにしていく。
  • まずはToDoリストを作るところから始める。
  • テストの方が負債化しやすい。だから意味のあるテストを残し、それがわかりやすいようにする。
    • RSpecではdescribeのネストができるので、それを使って、ToDoとの関連を記述していたのは学びだった！例えば、 describe "3の倍数"みたいに。
  • テストを取り除けるのは書いたあとすぐ。時間が経つと除去していいのか不安になる。そして他人が書いたコードとなるとさらに不安。

TDDってコードだけではわかりづらくて、どう書いているか流れを見たかったので、こっそり動画に撮ってたんですが、アプリが固まって保存できてなかった… 一昨年に出た新訳のテスト駆動開発は、サンプルコードに差分が載っていて、どう変更していったのかが追いやすくなっていると教えてもらいました。

テスト駆動開発

テスト駆動開発

懇親会とふりかえり

クリエーションラインさんからヤッホーブルーイングのクラフトビールの差し入れをいただき、懇親会。 自己紹介したり、今やってることの話しをしたり、TDDの話をしたり、ワイワイしてた。

第1回目のふりかえりは、@yattom さんがいたので、もちろんここはFun-Done-Learn。

やっとむさんとFDLの話ができて楽しかった。

次回は秋葉原のクリエーションラインさんで開催するみたいな話が出てました。

おまけ

爪痕を残した(๑•̀ㅂ•́)و✧

*1:勉強会っぽさって何だよ、というツッコミはお控えください。

「新訳 科学的管理法」を読んだ。

読書 マネージメント

100年以上前の、しかも工場での生産を対象としたマネジメントの本なのだけど、いろいろマネジメントについて考えることができた。

|新訳|科学的管理法

|新訳|科学的管理法

昨年くらいからエンジニアリングマネージャーというのが流行っていて、そもそもマネジメントとは何なんだろうか、という疑問からこの本を見つけた。 マネジメントと聞くと、ドラッカーのマネジメント なんかを思い浮かべたのだけれど、その本の序文にも科学的管理法について言及されている。なので、この本の副題にあるように、「マネジメントの原点」という本だ。 この本では、それまで良しとされてきたマネジメント手法の問題、労働者の怠惰を挙げ、それに対して科学的管理法を提唱し、それを導入した3つの事例研究を紹介している。

科学的管理法

科学的管理法以前は、「自主性とインセンティブを柱としたマネジメント」が良しとされていた。自主性とは、労働者が自ら仕事について良くしていくという自主性を指していて、そしてインセンティブとは、その自主性の結果による成果に応じて賃金を与えるなどの報酬を与えることを指している。 読んでいてこれで良さそうに思ったのだけれど、ところどころに「労働者は十分な教育を受けていない」といったような記述があったたので、自主的に進めることに限界があったという前提があるのだと思う。 しかし、その管理法の下で労働者の怠惰が蔓延していたことが指摘されている。「効率が良くなり一人当たりの生産量が多くなると職を失うという迷信、時間給であったが労働時間は正確に計測されていなかったことがあったため、ある程度働くことが最善となっていた。 なおかつ、そのような状況にもかかわらず、この管理法が管理者のさじ加減で実施されて、口伝で広められていた。

それに対してテイラーは、科学的管理法における管理者の責務として、

  1. 労働者1人当たり生産量や作業時間など測れるものを様々に計測し、その因果関係を導き出し、
  2. その上で、生産量を最大化するような作業手順の作成、教育、さらには適切な人材の採用を行い、
  3. 労働者と協力しながら最適な手法を現場に浸透させ、
  4. なおかつ責任についても、労働者に負わせるのではなく、適切に管理者も負うこと

を挙げている。その上で、インセンティブについても適切に賃上げやボーナスを与えていくことを推奨している。

感想

第一章が上に書いたように科学的管理法についてと、それが生まれた背景について書かれていて、第二章が事例研究の紹介だった。 自分がいるようなソフトウェア開発への直接の適用は難しい。けれど、マネジメントの原点でもあり、いろいろと考えるための出発点としては非常に面白かった。

適用が難しいと感じたことについて書いてみる。

  • 事例研究にある労働者の作業は生産量や作業に関する数字が計測可能であり、それが成果にほぼ直接結びついている。例えば、検品したベアリングの数や、スコップのサイズとそれですくう量とか、レンガの数や積んでおく資材の距離とか。一方でソフトウェア開発では、これが難しい。行数、カバレッジ率、リードタイムにかかる時間など測れるものはあるが、それらが直接ビジネス価値につながるかというとそうではない*1。
  • 作業者1人1人について個別にマネジメントを行うことで、全体の生産性も上がっていくということに基いているが、これらは個別の生産量の総和がチーム*2の生産量になるためだと考えられる。ソフトウェア開発ではやはりこれも難しいので、個別ではなく、チーム単位でマネジメントを実施しないといけないのではないだろうか。
  • 科学的管理法においては、管理者が労働者の作業内容について計測可能な項目と生産量の関係を研究を行う。これは、先に説明したように労働者の自主性では限界があるためだと思う。しかし、現在においては、労働者が自身の作業について計測・研究できないことも無いと思う。
  • また、作業内容についてプランを作るのも管理者の仕事とされている。これはマイクロマネジメントっぽい記述にも見えるが、前と同じ条件の元で考案されたのではないだろうか。もし現在において作業内容を管理者が作成するのであれば、現在のソフトウェア開発に関連する技術について理解している必要がある。
  • そして、上に挙げたように、現在においては個人に対してではなく、チームに対してのマネジメントが必要なので、技術だけでなく人や集団の性質についても理解している必要がありそう。

つらつらと書いてみたのだけれど、マネジメントはそれだけで大変な仕事であるし、相当勉強しなければいけないと思った。 もしこれをエンジニアチームを対象とした場合にどうなるか、ということがきっと昨今のエンジニアリングマネージャーというブームなのかな、と思う。ただでさえ技術の移り変わりやビジネスの環境も変化が激しいので、それらをキャッチアップするのも非常に骨が折れそうなのは目に見えている。

この本の事例研究で書かれていた内容はいずれも、単なる生産量を上げることのためではな、健全な労働環境のもとでの生産量の最大化である。 要するに、労働者のことを、その人の傍で徹底的に観察しているし、それを実施できるための信頼性の構築も含まれている。 どうあれ、せめてこの本で書かれているようなマネージャーの目的が達成され、不本意な人間関係が生まれてしまうことが無ければ良いのかな。

「雇用主に限りない繁栄をもたらし、かつ働き手にも最大限の豊かさを届けるのがマネジメントの主な目的であるべきだ」などという主張は、あまりに当然すぎて、あらためて述べるには及ばないと思うかもしれない。しかし、産業界を広く見渡してみると、雇用主も働き手も、相手と協調するよりむしろ敵対しようとする空気が強い。どちらの側でも大多数の人々が「共通の利害で結ばれた関係を築くのは不可能だ」と考えていることは、火を見るよりも明らかである。

要するに、エンジニアリングマネージャーは難しい*3。

*1:受託だと納品までどれだけコストを下げられるか、を考えればいいのだから容易なのだろうかとも考えた。しかし、顧客が納品物でビジネスがまわらなかったらリテンションはありえないので、そこで破綻するのだろうから、やはり難しいのではないだろうか。

*2:この本ではチームについては全く触れていないが、同じ作業を複数人で集まって行っているような記述は書かれている。

*3:雑な締め方w

Multi-Stage Build を使ってLaravelアプリのイメージを作ってみた。

Laravel Docker

LaravelとVue.jsの勉強がてらにちまちまとアプリを作っていて、そのLaravelアプリケーションを実行する環境をDocker で構築しているのだけど、以下の2つほど問題があった。

  1. composer やnpm はアプリを起動させるまでに必要なパッケージのインストールやアセットのコンパイルに必要なのであって、アプリ実行時には必要ない。特にnode_modules。
  2. Dockerファイル内でcomposer やnpm のインストールするとなると、その記述やそれぞれのバージョン管理が面倒。

ということで、Docker 17.05以降で使えるようになったマルチステージビルドで解決してみた。 検索してみると、Laravel Newsに丁度いい記事を発見した。

実際に書いてみたのがこちら。

マルチステージビルド

これは、異なるイメージで特定のコマンドを実行し、1つのイメージを作る方法。 例えば、以下のようなDockerfileがあったとする。

FROM composer:1.8.0 as vendor    # （1）

COPY composer.json composer.json
COPY composer.lock composer.lock

RUN composer install

FROM php-cli:7.2.14

RUN mkdir /app
WORKDIR /app

COPY . /app
COPY --from=vendor /app/vendor/ /app/vendor/  # （2）

CMD ["php", "artisan", "server"]

（1） でPHPのパッケージをインストールするために、composer:1.8.0 イメージを使ってインストールしている。 そこでできた成果物、つまりvendor以下のPHPパッケージをLaravelアプリのイメージを作る際にそのまま利用する（2）。 このように、特定のコマンド（composer）の実行時に必要なイメージ（composer:1.8.0）を使い、そこでできたものを実際に欲しいイメージ作成時に利用することができる。

ということで、各ステージ毎に何をしているのかがわかりやすくなったし、最終的に作りたいイメージに必要ないものを含めずにコンパクトにできたので、だいぶスッキリした。

Azure Functions がTypeScriptでかけるようになったからVS Codeで試してみた。

Azure

先日、 Azure Functions の公式ツイッターアカウントで、TypeScriptで書きたい人向けのパッケージのリリースアナウンスがあった。

これは面白そうなので試してみようと思って探してみたら、さすがMSの人がQiitaに早速書いていた。

qiita.com

これを参考に、Visual Studio Code からローカル環境でAzure Functions を起動し、デバッグするところまで試してみた。 サンプルで作ったリポジトリは、こちら。

前提条件

Function の新規作成

参考のQiitaの記事の通りに、HttpTriggerのFunction を作成しましょう。

デバッグの準備

下記のようにHttpTriggerが存在することを前提に進めます。

./HttpTrigger/
├── function.json
├── index.js
├── index.ts
└── sample.dat

VS Codeの拡張 Azure Functionsを使って、必要なファイルを生成

Ctrl+Shift+P（Macなら⌘+Shift+P）から、「Initialize Project for Use With VS Code」コマンドを実行する。

f:id:satoryu:20190116153521p:plain

ソースマップを生成

tsconfig.json に、"sourceMap": true" を追加し、ビルド時にソースマップを生成させるようにする。ソースマップが無いと、ビルド後に生成されたindex.js`上にしかブレークポイントを置けない。

{
    "compilerOptions": {
        "target": "es2018",
        "module": "commonjs",
        "lib": ["es2018"],
        "sourceMap": true
    },
    "include": [
        "**/*.ts"
    ]
}

TypeScriptをビルドするためのタスクを追加

package.json に、以下のスクリプトを定義する。

"script": {
  "build": "tsc"
},

下記のようにビルドが実行できることを確認。

$ npm run-script build

（オプション）デバッガ起動時にビルド

デバッガ起動時に、func extensionsコマンドが実行されるようにlaunch.jsonが定義されています。 これに、tasks.jsonに以下の設定を追加することで、同じタイミングで上で定義したTypeScriptのビルドを実行するようにしておきましょう。

    {
      "label": "buildTypeScript",
      "command": "npm run-script build",
      "type": "shell"
    }

デバッガを実行

まず、index.ts ファイルを開き、コードの中でデバッグしたいところにブレークポイントを起きます。 その後、Ctrl+Shift+D（Macだと⌘+Shift+D）でデバッガサイドバーを開き、「Attache to JavaScript Functions」で起動します。

http://localhost:7071/api/HttpTrigger をブラウザで開くと、ブレークポイントに達したところで、Visual Studio Codeに移るはずです。

f:id:satoryu:20190116163046p:plain

おー、デバッグできるー！

おわりに

Visual Studio CodeでTypeScriptで書いたAzure Functionsをビルドし、tsファイル上に置いたブレークポイントで止まるようにデバッガを設定、起動する方法を紹介しました。 あとは、デプロイも事前にビルドするようにCIを用意すれば、TypeScriptで開発できそう。

クリスと #NoEstimates について立ち話をして思ったこと

アジャイル

先日のRSGT2019の3日目に開催されたOSTにて、基調講演で来てくれていたクリス・ルーシャンに #NoEstimates について少し話を聞いてみたので、それのザックリとしたメモとして書き残しておく。

自分が途中から参加したテーブルのテーマは「見積もりをすることのメリット」だった。 自分はスタッフ業で聞けなかったのだけど、どうやらクリスは基調講演で、見積もりすることのデメリットについて語り、#NoEstimates をやっているという話をしたようだ*1。そこで、このテーブルでは、見積もりすることのデメリットだけではなく、メリットについても取り上げ、見積もりの可否について議論していた*2。

そこにクリスが覗きに来てくれたので、ちょっと話を聞いてみた。 超意訳になるのだけれど、そこはご容赦いただきたい。

さとう（以下、さ）: マイルストーンとかロードマップみたいな長期間の計画って持ってるの？
クリス（以下、ク）: 昔は持ってたよ。でも、あれはいろいろと問題を起こす。
さ: （わかるー）プロダクトバックログアイテムが大きい時とかって、どうしてるの？
ク: それは小さく分解する。すぐに出せるようなくらいに小さくするんだ。ソフトウェアの80%は使われなくて、20%しか使われないって言われてるでしょ？その20%に近づけるようにするのさ。
さ: お客さんがバカでかいものが欲しいって言ってきたら、どうするの？
ク: プロダクトオーナーがお客さんに説明するんだ。「これだと実現できないし、開発チームが苦しむ。だから、小さく分解して、こういう順で進めたい」って。

自分はこのクリスとの立ち話で、NoEstimates は見積もりをしないのではなく、見積もりをしなくても問題の無い、むしろコストに感じる状態に至ったのだな、と思いました。
少なくとも、

  • 小さく分解して、それをすぐにリリースできるような開発環境
  • プロダクトオーナーが開発チームの状況を踏まえた上でお客さんに説明にいける
  • そして、それを理解できるお客さん*3がいる

という環境が必要なのかなー

*1:「見積もりをやらない」をやっている、という表現に何か違和感があるがどうしたらいいのだろう。

*2:という趣旨と記憶している。間違ってたらごめんなさい。

*3:お客さんを選んでいるのか、お客さんを教育しているのか、といった話は聞けなかったのが後悔

Hacktoberfest Tシャツを貰った。

f:id:satoryu:20190112224627j:image

毎年オクトーバフェストの時期になるとDigitalOceanとGitHubが開催するHacktoberfestというイベントがある。これはこの期間中に、OSSのリポジトリにプルリクエストを5つ送ると、上のようなTシャツが貰えるというイベント。

昨年も例年通り開催されたので、エントリーして、そのTシャツがやっと届いた。

一昨年もエントリーしてたんだけど、住所入力がまずかったのか、届かなかったので、やっと手に入れた感じで嬉しい。

Regional Scrum Gathering Tokyo 2019のスタッフをやってきた。 #RSGT2019

イベントレポート

年に1度のスクラム開発の祭典Regional Scrum Gathering Tokyo 2019 に、当日スタッフとして行ってきました。 正月休み明けの三日間、新年の始め方としてはとても有意義な始め方になりました。

来た理由

本当は今年は来るつもりはありませんでした。昨年のRSGT2018が終了した時には、そう思ってました。 2014年からほぼ毎年スタッフやらスピーカーとして参加してきたのですが、昨年の時点ではちょっと飽きを感じていました。「特別面白いセッションが無ければ来ないなぁ」なんて思っていました*1。 今年来た一番の理由は、弊社新卒の勇姿を見るためです。昨年の夏、突如訪れた新卒向けのエンジニア研修で、最＆高な姿を見せつけてくれた彼らがRSGTのオオトリとして発表してくれた。研修最終日のデモで与えてくれた感動を再び魅せつけてくれました。思わず泣きそうになった人も少なくないはずではないでしょうか。 素直で真面目で、それでいて楽しもうという気持ちを忘れない、そんな彼らがいくつもの壁を乗り越えた話はいろいろな方々に知ってほしいです。セッションの詳しい内容については、以下の記事をご参照ください。

やったこと

スタッフとしては、セッションのタイムキーパーやスピーカーの呼び込みや、その他の雑務諸々を落穂拾いのようにやっていました。 それとは別に、（自分が勝手に）担当していたのは、「賑やかし」でした。

  • スタッフとして参加者のみなさんに声を掛けるときに、少しでも楽しい気分になっていただくために、つまらないことを言ってみるとか、
  • Twitterのタイムラインに会場の様子などを書き込んでみたりとか、
  • RSGT名物「ハイタッチ」への呼び込みをしたりとか、
  • クロージングキーノートの前説をやってみたりとか、

をしていました。少しでも楽しんでいただけたのでしたら、嬉しいなぁ。

次回予告

さて、今回のRSGT2019ではプロポーザルを出したのですが、落選でした。なんと、その落選してしまった内容を来月に大阪で開催されるScrum Fest Osakaてお話させていただけることになりました！ ここでは、自分がこの4、5年くらいの間にエンジニアとしてユーザーやお客さんと接してきた中でやってきたことと、それの助けになってくれたある教えについてお話します*2。

confengine.com

www.scrumosaka.org

ということで、ほなサイナラ。

*1:いやーいかにも受け身な感じで嫌なやつだわ。自分で面白いセッションを作ればいいのに、と今更思う。

*2:周りにも話をしたことないので緊張するわー