_ tDiary 5.0.8 にアップデートした。

恒例の29日になったので、確認したらリリースされてた。

• tDiary.org - tDiary-5.0.8 リリース

今回のリリースで、大きな変更は無いが、最新を追っていくためにササッと上げておいた。

_ カイゼン・ジャーニーを読んだ。

思ったより読むのに時間がかかってしまった。目新しい技術が載っているわけでも、複雑な理論が載っているわけでもないので、読むだけならきっともっと早く読み終えられたと思う。単なる物語であればきっともっと早く読み終えられたはずだが、この本はそういう類のものじゃなかった。

この本に書かれているのは、凝縮した著者の情熱と経験にもとづいて書かれている。主人公の江島が直面する問題には、何かしらの基づく事実がある。その場面場面で、「次に江島は（もしくは袖ヶ浦はなどなど）はいったいどう出るのだろうか」と先を想像しながら読んでしまった。この想像が楽しかったので、読むのに時間がかかってしまった。自分は同じ本を何回か読みたいと思うことは稀なのだけれど、この本は様々な立場の登場人物が描かれているので、想像する対象の人物を置き換えながら何度か読み直したいと思った。物語として書かれているからそう思ったのだと思う。よくできてるなー。
読んでて辛いところもあった。自分を主人公江島に置き換えてしまうと、かつて自分が諦めてしまったことなど辛いことを思い出してしまった。

この本は、これからエンジニアとして仕事をする人、というよりも少し自分で何かカイゼン活動を始めた人が良さそう。1人で始めても2人目が現れるまでに時間がかかることもあるだろうし、その間に1人で解決できない問題に色々直面するかもしれない。江島は運が良いとさえ見えてしまうことがあるかもしれない。
でも、一度でもカイゼン活動に挑戦したことがある人ならある程度の辛さを知っている。その辛さがわかっていれば、この本に書かれていない辛さの部分も汲み取りながら、江島という会うことはできない遠くにいる同志の活動を支えに頑張れそうだと思った。

デブサミ終わってから色々な人が絶賛してたので、若干冷ややかな目で読んでたのだけれど、やはりこの著者2人が書いただけあって、物語の一つ一つが問題に直面している人達の背中を後押しするものだと思いました。
この本を書くまでのジャーニーが新たなジャーニーを生むんだろうな。

さて、僕は何をする人だろう。
この4月から社会人として10年目ディケイド。
これまでの世界を破壊して、ファイナル仮面ライドフォームはどうなるのか*1。

_ 実況パワフルモブプログラミング 感想戦 #devsumi

先日お伝えしていた通り、Developers Summit 2018にて仕事をしてきました。
目黒雅叙園の一室を1時間弱お借りして、仕事をしてきました。事前予約通り満席となり、さらには立ち見まで出て、講演者の我々は大変驚きました。朝一のセッションにもかかわらず、来て下さった皆様、ありがとうございました。
デブサミのテーマが「変わるもの、変わらないもの」でしたが、ただの変わり者の私たちはいかがだったでしょうか。

参加者の皆様の感想については、実行委員の方がToggetterにまとめてくださいました。そちらをご覧いただくと雰囲気が伝わると思いますので、ぜひご覧ください。

• 【デブサミ2018】16-C-1「実況パワフルモブプログラミング - Rakuten Super Englishにおけるモブプログラミングという働き方 -」 #devsumiC #devsumi - Togetter

一夜明け、昨日のことを振り返ってみて、モブの中の人として伝えたかったことを書いてみます。

変わり者達

セッションでプロダクティブなデベロップメントを魅せたクレイジーな開発チームを紹介します。

• Gota Miyazaki: 普段からモブしてるモブの人。PHPの使い手。
• Tatsuya Sato（私）: 普段からモブしてるモブの人。昨年からPHPに真面目に向き合ってる。ボッチじゃない。
• Hiroaki Ono: 今回のキーパーソン。普段は別の部署で別のプロダクトを開発してる人。PHPは使ってない、

この最後の小野さんが今回一番重要なポジションでした。「プログラミング、チーム開発は普通に出来る人、けれど今回触るプロダクトについての知識はゼロ」という状況です。ですので、参加者の皆さんは、
「これまで違うプログラミング言語で開発してきた、中途入社の社員」
として見ていただけたのではないでしょうか。

「どこまでやるか」と「どうやるか」

モブプロ開始した時に、朝礼をまずやりました。
これは、スクラムのスタンドアップミーティングとかそういうものや、全く堅苦しいことではなく、

• 今日どこまでやるか
• どうやるか

を決めるだけです。
このセッションの時は、事前に「どこまでやるか」は決めていたので、それの再確認から始まりました。普段においても、せいぜい数分程度で済ませます。メンバーそれぞれが別々のタスクをアサインされる場合、朝礼ではそれぞれが何をやったのかを共有し、それぞれが抱えている問題を相談したりします。ですが、モブだとチームでできることは1つであり、一緒に活動しているので、それは既に共有されています。ですので、朝礼ではやることの再確認程度です。
なので、このセッションでは「どうやるか」にすぐ自然と移りました。
「どこまでやるか」と「どうやるか」を決めるフェーズは明確には別れていません。それは、「今日」*1の中で終えられるかどうかを考えなければならないので、「どこまで」いけるかは「どうやる」によって変わる可能性があります。

今回のやることは、管理画面に出ているデータが数字だけではわかりづらいので、「棒グラフでデータを表示する」というものでした。これに対して、次のようなタスクに分けて、進めることにしました。

1. とりあえず何でもいいからグラフを出す。
2. PHPからダミーのデータを渡す。
3. データベースからデータを抜き出し、ダミーデータを置き換える。

ここでは、会場に来ている参加者の人達が少しでも進捗が見えるようになればと思い、まずは画面のアウトプットを出し、それが徐々に精緻化されていくことで、「本当にゴールに向かって開発が進んでる」という感覚を持ってもらおうという意図があります。
ですが、これは普段でもわりとやります。目に見えてない段階では想像でしか出来栄えについて議論できないので、その議論は無駄になりがちです。ですので、ダミーデータでもいいので何かしらアウトプットを出すところから始めるようにしています。もちろん、すぐにアウトプットまで作れそうな場合は、SQLを組むところから始めることもあります。

見積もり

今回は意識してそれぞれにかける時間を見積もりました。この日は30分しかないということで、分単位の見積もりをしましたが、これは初めての試みでした。
いつもは1日単位で、その日のやることを決めてます。
ランチタイムや休憩時間といったタイミングが入ったりするので、その時点であとどれくらいいけそうなのかどうか確認をします。

設計

朝礼の時にやっていたように、その場でプロダクトの画面を見ながら完成のイメージについて絵を書いています。ホワイトボードだったり、そこら辺に置いてあるコピー用紙とかで絵を書いたりしてます。書いたものは残したりはしてません。セッション後に「ドキュメントはどうしてるんですか？」と聞かれたけれど、必要な時にその時の相手向けに書いています、としか回答できなかった。伝えたい相手に伝えるための手段なので、その時々に書くしかないのだと思う。プロダクトについて網羅的に書くのは、今のプロダクトはシンプルだから出来るかもしれない。けれど、作ったところで誰が見るのかがわからないものは無駄になりそうなので、多分やらないと思います。

ちなみに、この時に使っていたホワイトボードはnu boardです。

ドライバー選択

やることが決まり、それをどう進めるかも決まったら、最初のドライバーの選択です。普段なら誰が誰がどの順でやっても良いのですが、今回は、プロダクトについて知らないメンバーが1人います。彼にはプロダクトの知識が必要なものを敢えてやってもらう必要があるので、最後の3つめのタスクをやってもらうことにしました。その他2つはPHPやJavaScriptといった技術に関する知識で解決できてしまうため、ナビゲーターが持つプロダクトに関する知識を引き出す機会はほぼ無いでしょう。新しく入ったドライバーが進めなくなった時、その時がナビゲーターの持つ知識がドライバーの背中を押すタイミングだと思います。

YATTA!

この盛り上がりはリアルなやつなのかなw上手く行ったらマジで喜ぶのか、今の場がこうさせてるのか #devsumiC

— ryoichi (@saitoryc) 2018年2月16日

はい、大げさにやりましたｗ
普段のオフィスではここまでやりません。「よし！」とか言ったりします。
このYATTA！の本質は、「成果の喜びを共有」し、「そこに行き着くまでの過程を称える」ことだと思っています。単に出来て良かったということだけでなく、それのどこが良いのかを話したりします。例えば、「あそこのエラー、わかりづらかったけど、無闇にはまらずに別の方法に変えてよかったね」とか、「事前にあの辺りのことを調べておいてもらって助かりました。」とか。こういう良いことを言われると、自然とそれを再現させたくなります*2。
もちろん、嬉しいことをいつものメンバーと嬉しいと言えるのはとても楽しいので、喩えモブプロをしていないとしても、是非みなさんもやってみましょう。周りの騒音にならない程度に。

一日の終り

事前の打ち合わせでは、時間内にゴールまでたどり着かなくても、それはそれで問題にモブで立ち向かうことで見てもらえるものはあると思っていたのだけれど、予想外なことに最後に時間が余ってしまった。
なので、途中で後回しにした見た目の修正などをまとめる作業に入りました。これも普段の一日の終りにやることです。開発中は、機能として中核となる部分から作り、少しずつ精緻化していくやり方でした。このやり方だと、本質的でない部分は飛ばしてしまいます。このセッションでは、グラフの縦幅が大きすぎるので小さくしないといけなかったり、棒グラフの色を統一させないといけなかったりや、クエリにorder byを付けないと順番が保証されない、など細かい修正タスクを事後のやることとして出しました。

おわりに

やってる方も、見てる方もとても楽しんでいただけたようなので、とても満足しています。参加してくださった皆さんの普段のお仕事が少しでも楽しいものになれば、幸いです。

_ Azure Web Apps にLaravelをデプロイするカスタムデプロイの作成方法

今のプロジェクトで、Laravelでアプリケーションを開発していて、それをAzure Web Apps 上で動かしている。公式のドキュメントでは、Composer Extensionを使って、デプロイした後にcomposer install が自動的に実行するようにしている。けれども、これは下記の観点からオススメしない。

1. デプロイ時に実行される処理を変更できない。
2. インストールされるcomposerのバージョンが、Composer Extensionをインストールした時点での最新。

1については、Composer Extensionがデプロイ時に実行されるスクリプトを上書きしてしまうため、カスタムデプロイを実装できないことを言っている。2は、composerやphpのバージョンの組み合わせで発生する問題がある場合、デプロイ時に混乱する恐れがある。

また、Laravelのアプリをプロダクションとしてデプロイする場合、パフォーマンスを最適化するためのコマンドが用意されているので、それをデプロイ時に実行したい。

ということで、Azure Web Appへのデプロイ時にそういったお好みのコマンドを実行できるようにカスタムデプロイを準備する方法を書きます。

Composer をアプリのリポジトリにインストール

Composer はpharファイル（圧縮されたphp）で配布されているので、それをリポジトリ内にインストールする。上で書いたように、Composer Extensionを利用するとそもそもカスタムデプロイが実行できないため、自前で持つ必要がある。

cd /path/to/your/laravelapp/
mkdir bin
php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"
php composer-setup.php --install-dir=bin --filename=composer
git add -A
git commit -m 'Install composer'

Azure Portalからデプロイ先のWeb AppにKuduで入り、コンソールでインストールしても構わない。Slotを利用したデプロイをする場合、Slot作成時に毎度インストール作業が発生するので注意が必要だ。

カスタムデプロイのスクリプトを作成

ゼロから書く必要は無く、npmでKuduScriptコマンドをインストールし、それを使ってPHP用のデプロイスクリプトの雛形を用意する。

cd /path/to/your/laravelapp/
npm install kuduscript -g
kuduscript -y --php
git add -A
git commit -m 'Generate deployment script'

これを実行することで、.depoyment とdeploy.sh が生成される。
.deploymentはどのファイルをデプロイ時に実行するかを指定し、実際に実行される一連の手続きをdeploy.shに書く。

#!/bin/bash

# ----------------------
# KUDU Deployment Script
# Version: 1.0.15
# ----------------------

# Helpers
# -------

exitWithMessageOnError () {
  if [ ! $? -eq 0 ]; then
    echo "An error has occurred during web site deployment."
    echo $1
    exit 1
  fi
}

# Prerequisites
# -------------

# Verify node.js installed
hash node 2>/dev/null
exitWithMessageOnError "Missing node.js executable, please install node.js, if already installed make sure it can be reached from current environment."

# Setup
# -----

SCRIPT_DIR="${BASH_SOURCE[0]%\\*}"
SCRIPT_DIR="${SCRIPT_DIR%/*}"
ARTIFACTS=$SCRIPT_DIR/../artifacts
KUDU_SYNC_CMD=${KUDU_SYNC_CMD//\"}

if [[ ! -n "$DEPLOYMENT_SOURCE" ]]; then
  DEPLOYMENT_SOURCE=$SCRIPT_DIR
fi

if [[ ! -n "$NEXT_MANIFEST_PATH" ]]; then
  NEXT_MANIFEST_PATH=$ARTIFACTS/manifest

  if [[ ! -n "$PREVIOUS_MANIFEST_PATH" ]]; then
    PREVIOUS_MANIFEST_PATH=$NEXT_MANIFEST_PATH
  fi
fi

if [[ ! -n "$DEPLOYMENT_TARGET" ]]; then
  DEPLOYMENT_TARGET=$ARTIFACTS/wwwroot
else
  KUDU_SERVICE=true
fi

if [[ ! -n "$KUDU_SYNC_CMD" ]]; then
  # Install kudu sync
  echo Installing Kudu Sync
  npm install kudusync -g --silent
  exitWithMessageOnError "npm failed"

  if [[ ! -n "$KUDU_SERVICE" ]]; then
    # In case we are running locally this is the correct location of kuduSync
    KUDU_SYNC_CMD=kuduSync
  else
    # In case we are running on kudu service this is the correct location of kuduSync
    KUDU_SYNC_CMD=$APPDATA/npm/node_modules/kuduSync/bin/kuduSync
  fi
fi

# PHP Helpers
# -----------

initializeDeploymentConfig() {
    if [ ! -e "$COMPOSER_ARGS" ]; then
    COMPOSER_ARGS="--no-interaction --prefer-dist --optimize-autoloader --no-progress --no-dev --verbose"
    echo "No COMPOSER_ARGS variable declared in App Settings, using the default settings"
  else
    echo "Using COMPOSER_ARGS variable declared in App Setting"
  fi
  echo "Composer settings: $COMPOSER_ARGS"
}

##################################################################################################################################
# Deployment
# ----------

echo PHP deployment


# 1. Initialize Composer Config
initializeDeploymentConfig

# 2. Use composer
echo "$DEPLOYMENT_SOURCE"
if [ -e "$DEPLOYMENT_SOURCE/composer.json" ]; then
  echo "Found composer.json"
  pushd "$DEPLOYMENT_SOURCE"
  ./bin/composer install $COMPOSER_ARGS
  exitWithMessageOnError "Composer install failed"

  php artisan package:discover
  exitWithMessageOnError "Package discover failed"

  php artisan config:cache
  exitWithMessageOnError "Caching config failed"

  php artisan migrate --force -v --database=sqlsrv
  exitWithMessageOnError "Migration failed"
  popd
fi

# 3. KuduSync
if [[ "$IN_PLACE_DEPLOYMENT" -ne "1" ]]; then
  "$KUDU_SYNC_CMD" -v 50 -f "$DEPLOYMENT_SOURCE" -t "$DEPLOYMENT_TARGET" -n "$NEXT_MANIFEST_PATH" -p "$PREVIOUS_MANIFEST_PATH" -i ".git;.hg;.deployment;deploy.sh"
  exitWithMessageOnError "Kudu Sync failed"
fi

##################################################################################################################################

echo "Finished successfully."

デプロイ！

デプロイすると、deploy.shが実行されるようになります。
ドキュメントは見つけられていないけれど、どうやらローカルgitやGitHubなどgitリポジトリを介したデプロイのみにサポートしているようだ。Zipデプロイを試してみたところ、deploy.shは実行されなかった。

参考

• Azure App Service Web Apps での PHP の構成 | Microsoft Docs
• Deployment hooks · projectkudu/kudu Wiki
• Deployment - Laravel - The PHP Framework For Web Artisans

_ Developer Summit 2018 で普通に仕事してきます。

Developer Summit 2018で普通に仕事してきます。

• 実況パワフルモブプログラミング - Rakuten Super Englishにおけるモブプログラミングという働き方 - デブサミ2018

モブプログラミングで仕事してるって言ってるけど、いったいどんなスタイルなんだろう？

という方々をお迎えして、現場見学会というのは兼ねてより実施していましたが、毎度入館申請とか社内の場所取りとか面倒くさいので、ここいらで一気に片付けてしまいたいと思います。

ごめんなさい、お暇なら是非見に来てね！

_ エンジニアのためのデザイン思考入門を読んだ。

デザイン思考というものは、成果物を中心に進めていくものづくりの方法だと思っていたのだけれど、それだけではなく、ユーザーの体験をデザインするものだと知った。この本では、実際に東工大で実施されたエンジニアリングデザインプロジェクト（EDP）を元に、問題を発見していくためのユーザーインタビューからアイデアの発見、そしてプロダクトにまでの方法と、それを行うチームのあり方について書かれていた。
チームについて書かれている3章や、EDPに参加した学生のコラムを読むと、チームで意見をぶつけあいながら試行錯誤していく、そしてそれが楽しそうなのが描かれていた。とにかく3章だけでも読む価値あると思う。丁度昨年、EDPに参加する社会人を募集しているという話を聞いたのだけれど、なんでもっと話を聞かずにスルーしてしまったのだろうと後悔してる。
今新規事業の開発をしているので、読みながら時々、今のプロダクトを良くするにはどうしたらいいのか、というのをあーだこーだと考えてた。

おまけ: きっかけ

周りでちらほら読んでる人がいる。これも読みたい本のリストに積んどこう。

エンジニアのためのデザイン思考入門 https://t.co/LPMCfCAlt5

— さとりゅう 🌸 たつや学院 (@sato_ryu) 2018年1月21日

_ 旅猫リポートを読んだ。

通勤の電車の中で主に読んでいたのだけれど、物語の終盤は家で読んで正解だった。
愛猫を手放さなければいけない飼い主が、その貰い手を探す旅の物語。
物語はネコの目線とその飼主の目線の両方で書かれていて、時にはコミカルで笑えるし、ときにはそれぞれが互いへの想いが出ていて、そのギャップに引き込まれた。

もう10年ほど前にネコを飼っていたのだけれど、子供が生まれるのを機に実家に引き取ってもらった。生まれたばかりで捨てられていたのを妻が拾ってきた。2年ほど一緒に過ごしたのだけれど、あいつは何を考えていたのだろうか。この本を読んだ後、そういう空想が楽しかった。あと、主人公のサトルの生き方というか考え方は憧れるものがある。あぁいう風に生きれたらいいな。

今年、映画化されるそうなので楽しみだ。

• 映画『旅猫リポート』公式サイト

_ 中小企業診断士FOCUSテキスト「運営管理」を（途中まで）読んだ。

「運用自動化、不都合な真実」の資料を公開しました。https://t.co/1olL6j2mWL

撮影禁止にしたところは、結局ほぼそのまま載せちゃいました。(「ここからは鬱憤炸裂、視聴注意」以降)

会場右後方エリアからの拍手が激しかったなぁ、闇が深いなぁ。 #ssmjp

— HATANO Hirokazu (@tcsh) 2017年12月13日

昨年末、波多野さんがシェアしてくださったこの資料でビビッと来たので、社内勉強会の講演に来ていただいた。その時に

中小企業診断士の運営管理のテキストを読むと良いですよ。

とお勧めされたので途中まで読んでみた。

運営管理は、製造業で生産効率を挙げるための工場の生産工程を効率良くするための考え方と手法について書かれていた。工場は同じものをある一定量だけ作るだけでなく、需要を見ながら生産量と資源の仕入れを考えなければいけないし、多数の部品と工場が関連するものはその繋がりを考慮しないといけないので、色々な方法が存在していることはわかった。そういう業態だと、標準化が効いてきそうなのはわかった。けれどやはり、ソフトウェア開発だと、毎度同じものを作るわけでは無いので、標準化で生産性向上を目指すのは難しそう。でも、プロセスを見えるようにする方法とかは参考になりそうなので、真面目に勉強しても面白そうな分野だと思った。

資格試験のテキストは淡々としてて読み進めるのが辛かった…
ので、もうちょっと内容とか実例がある本を次は探してみようっと。