Satoryu's Diary

Rubyが好きな貧乏プログラマーの日記。日々の生活、開発に関するメモとか考えとか。


2018年02月16日 [長年日記]

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

実況パワフルモブプログラミング

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

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

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

変わり者達

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

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

一日の終り

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

おわりに

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

*1 このセッションの場合、だいたい30分程度。

*2 少なくとも自分は。


2018年02月09日 [長年日記]

_ 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'

これを実行することで、.depoymentdeploy.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は実行されなかった。

参考

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

Developer Summit 2018

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

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

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

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


2018年02月05日 [長年日記]

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

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

おまけ: きっかけ


2018年01月26日 [長年日記]

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

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

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

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


2018年01月21日 [長年日記]

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

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

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

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

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

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


2018年01月19日 [長年日記]

_ Azure Serverless Meetup Tokyo に参加してきた。

今回はDurable Function をテーマに、前半はDurable Functionの解説、後半は牛尾さんが今直面してるDurable Functionをみんなでデバッグしたりチューニングしたりした。

Durable functionは、キューで複数のFunctionを連携させる場合の複雑さを軽減するために、オーケストレーションとそれで制御されるアクティビティで構成される。いずれもFunctionで実行され、内部的にはキューやテーブルで連携が実現されているのだけれど、それを開発者が特に気にすることなく実現できるのが良さそうに見えた。

後半で牛尾さんが直面して問題も、Durable Functionのスケールの問題とチューニングを見れたので面白かった。 今日は参加者が5名とこじんまりしてたけど、むしろそれが良くて、みんなで「あー、これはあれを見ればいいんじゃないか」とかみんなの知識でフルボッコにしてた*1

2月に、Azure Functionの開発者が来日するということで、ハックフェストと、ミートアップが開催されるそうです。これも楽しみ。

気になる人は下のMeetupに登録しておきましょう。

とりあえず、まず自分はC#を勉強して、Azure Functions の開発環境を作っておかないと。

*1 でも明確に解決にまでいけなかったので、「今日はこのくらいにしといたるわ」くらいの感じ。


2018年01月09日 [長年日記]

_ 「技術経営の考え方」を読んだ。

昨年から新規事業の開発の部署にいるので、「技術をどうやって事業に繋げるか」ということに興味があった。例えばブロックチェーンや人工知能みたいに、流行りのものを盛り込めば、それが事業として容易に成り立つわけではない。かといって、そういったものを疎かにする訳にもいかず、積極的に取り入れなければ、いざという時に価値に繋げられないだろう。それとは別で、知り合いが技術経営(MOT)の勉強をしていたので、何かの役に立つのではないかと思い、この本を買ってみた。技術経営の本は探すと、教科書のような本が沢山出て来るのだけれど、この本は新書なので手に取りやすかった。

この本は、著者が実際に経験した大企業の中から新規事業の立ち上げをケーススタディとして、シーズを生み出す研究フェーズから量産体制に入る産業フェーズまでの間にある越えなければいけない「魔の川」、「死の谷」そして「ダーウィンの海」のそれぞれを越えるための知見が書かれている。
著者は製造業の人なので、今自分がいるインターネットの産業とはモノや技術はかけ離れているところはある。けれど、魔の川を越える時などで、経営者や管理職が気にしなければいけないことは、共通するものがあるようだ。例えば、研究段階では人が多くいてはいけなかったり、関連する外部の開発企業に対しては相手側の立場になって関係構築を重視しなければいけなかったり、など。

研究で生まれたシーズをものとしてなんとか成り立つ製品を開発し、そこから実際にお客に価値があるものとして認められる商品にする事業に発展させていく段階的な流れは、リーン開発と何か近しいものがあるんじゃないかと思った。まだリーンスタートアップは読んだことは無いのだけれど。

途中のケーススタディは、新素材開発の話なのでわからないところは多々あるのだけれど、それらは流し読みして*1、失敗談やそれらから出てきた知見やアドバイスは、インターネットのビジネスの人たちにも役に立つのではないかと思う。

あと、後半に書いてある、大企業で新規事業をするメリットと大企業病の話は、「本当にこの会社(大企業)で(新規事業を)やる意味があるかどうか」を判断するのに役に立ちそう。メリットが感じられなくなったら辞めるという判断になりそうだ。

*1 わかる人はちゃんと読んだ方が良いと思う。


最近の投稿

翻訳しました(ちょっとだけ)

follow us in feedly