D-7 <altijd in beweging>

Day to day life of a Perl/Go/C/C++/whatever hacker. May include anything from tech, food, and family.

序章

YAPC::Asia Tokyo 2015の準備で慌ただしくてしてるある日、俺は肉が焼きたかった。誰でも1年に1回くらい肉を焼きたい時があると思う(要検証)。ステーキ肉だ。焼きたい。

別に高級肉が焼きたいわけではない。そこそこおいしければ普通の肉でいいのだ。しかしスーパーで売ってる 牛ステーキとか、あれは肉の厚さが1cmもないことがほとんどだ。1cmの肉なんてステーキ肉ではない。それは紙だ。ステーキ肉は2cm以上からだ。願わくば3~4cmは欲しい。 牛肉は2cmを超えて初めてステーキ肉になるのだ。

そんなおり、俺のタイムラインに以前より懇意にしているThe Meat Guyのポストが流れてきた。

mrb133aheaderjapanese
画像:The Meat Guy


え、なにこれ… いやだ… カッコいい…。焼きたい!俺はこれを焼きたい!他の肉も一緒に焼きたい!

ということで「日本なのになぜかアメリカンな肉を買える」ことで俺の中で有名なMeatguyで巨大肉とステーキ肉を大量に買って、YAPC::Asia Tokyo 2015スタッフやその回りの人を集めてBBQを開催することになった。俺の目的は肉を買うことであり、焼くことだ。みんなには厚みのある肉を堪能してもらう! BBQを敢行したのはYAPC::Asia Tokyo 2015の苛烈なトーク審査プロセスが嫌になったからでは決して無い。

会場

会場はuzullaさんに任せてしまった。忙しいのに大変申し訳ない。ちなみにこれをやっている間、同時銅鑼パーソン総選挙も炎上中でした。余計に申し訳ない。

そしたらいつのまにかBBQパークという椅子やらテーブルやらの準備や、後の掃除、しまいには火おこしまでしてくれるサービスを見つけてきて、用意してくれたのでおじさん達は大変助かることになりました。ちなみにこの手のサービスが存在することは遠い昔にNHKの朝の番組で見たことはあったのだが、今回実際に体験してみてすげぇ!と思いました。

肉肉肉

というわけで会場も決まったので肉を買います。前にも書いたように薄っぺらい肉なんていりません。厚い肉だけが正義です

まずは先ほどのトマホーク。大きさはだいたい2.5kg。骨も含めてだけど、2.5kgの肉の塊。これ、正直自分でもどうやって調理できるのか(果たしてグリルの上に載る大きさなのか?等)不安だったけど、最悪まわりを焼いて、後から小さくしたものを焼いていけば食える!と踏んだ。これはもうやるしかないだろう。ってか、やるぞ!ということで購入。

mrb133collage1
画像:The Meat Guy


もう見た目がやばすぎる。

次にリブロースステーキ。こちらは日本人は噛みごたえのある肉より軟らかい肉のほうが好きそう… と思って購入。個人的にはもう少し脂身の少ない肉のほうが好き(もちろんリブロースもうまいんだけど、ここは好みの問題)。

mrb109header
画像:The Meat Guy


そして個人的にメインイベント、サーロイン。説明にも「超厚切り」って書いてある。いいぞ!そのいきだ!サーロインは基本赤身で、まわりに脂身がついている。これが最高だ。シュラスコのピカーニャもそういう肉だ。これで食べる人が赤身と脂身のバランスを取ることができるのだ。霜降りとかいらん。赤身+脂身が最高だ!

mrb400headerja
画像:The Meat Guy

そんなわけで以上の肉を参加者の数から逆算して5.6kg 分ほど購入した。俺はこれを一人で… 全部焼く!

来た、焼いた、食った

YAPC::Asia Tokyo 2015シャツを着ている大人が半分くらいのおもしろい集団の中、俺はひたすら焼いた。ちなみに自分は焼いてばかりで全く写真が撮れていないのでこちらの写真、全てuzullaさん提供です。ありがとうございます!

で、着いたらもう会場が設営されてるわけですよ。BBQパークの方が全部一人でてきぱきやっててくれてる。包丁やまな板のようなアイテムから椅子、テーブル、コンロ等全て用意してくれてるのです。すげぇな、このサービス… というわけで僕の仕事は焼くことだけです!



でかい。このトマホークも含め全ての肉が冷凍で配送されてくるので前持って解凍しておかないといけない。かなり慎重に解凍処理を行ったつもりだったんだけどそれでも結構ドリップが出たので大丈夫かなーと思っていたけど、結果的には特に問題なかった。元がすごく良い肉だったのか、自分の解凍処理がうまくいったのかよくわからない。



案の定載らない。結局ぐるぐる回しながらゆっくり焼くことにした。



サーロイン。超うまかった。噛みごたえ、旨味、全てに置いて最高だった。本当にうまかった。次に自分用にもしこの手の肉を買うことがあったら間違いなくこのサーロインを買う。(Meatguyさん、アフィリエイト手数料的なものをそろそろもらってもいいんですよ?w)

あ、ちなみに全て当然のごとく味付けは塩のみです。一応なぜか手元にあったボリビア産の塩を持って行きました(親からのお土産)。赤身の肉は塩で食うのが一番うまい!



あっちでジクジク焼いている間にこっちでちゃっちゃと焼く。この間も結構こまめに炭の移動してました


ねぎはねぎぱねるらさんの提供。いやー、俺楽しそうな顔してるなー。肉焼くのって超楽しいよ!


うおおお、肉だ肉だー! この後、本当に最後の肉になるまでは肉を出すそばから全て売り切れてました。みんな食べてくれてすげぇ嬉しい!


さて、そろそろトマホークがいい色になってきたので、ばらします。これ以上やっても焦がしちゃうだけなので小さくして良いところまで焼いてから提供。まずは骨からばらす。


で、小さく食べやすい感じに切っていくよ!


あとはおいしくなるまで焼くよ!


このトマホーク、結果から言うと大変おいしいんだけど脂身が結構多くて30代後半のおっさんが中心の今回の面子で食べるのはそれなりに苦労した気がする(全部売れたけど)。脂身自体は全然くどさがなくて食べやすかったけど、単純に圧倒的な脂の量だった… 参加者の奥さんが持ってきてくれた大葉とかで包みながら食べたらすごくうまかった!


というわけで5.6kgの肉がなくなるまでずっと焼いていました。あー、楽しかったしうまかった。またやりたい。




このあと子供の昼寝スケジュールとかもあったので早々に我が家は引き上げたのですが、それもBBQパークさんのおかげで後腐れなく引き上げることができました。他の人に片付けさせると心苦しい事この上ないのですが、この日はBBQパークさんが後片付けを全てやってくれるという安心感があったのでさくっと引き上げることができました。大人はお金で解決だね!次回BBQすることあったらまた絶対このサービス使うわ。


というわけで梅雨シーズンの中、奇跡的に晴れた一日で超美味しい肉を堪能してきました。この調子でYAPC::Asia Tokyo 2015も成功してほしい!こちらからは以上です。

最後にもう一枚トマホークの焼けてる写真を置いておきますね! みなさんもHappy BBQ!





    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

ちょうど本業のほうでDBへのアクセスが遅い?んだかなんだかでREST APIがタイムアウトしている事象に出会っていたのでよっしゃとgo-sql-proxyを使おうと思ったのだけど、まずこのままだと実行時間とかが計測できない… ということに気づいて色々考えた結果PRを送る事にした。送ったら光速でマージされた。

今度から NewTraceProxyでプロキシを作れば Open/Exec/Queryに関しては所要時間が出力されるようになります。mysqlなら以下のような感じ:

driverName := "mysql"
if traceEnabled {
    driverName = "mysql-trace"
    sql.Register(driverName, proxy.NewTraceProxy(&mysql.MySQLDriver{}, logger))
}
db, err := sql.Open(driverName, dsn)
...

出力はこんな感じ:

tracer_test.go:27: Open (54.116µs)
tracer_test.go:27: Exec: CREATE TABLE t1 (id INTEGER PRIMARY KEY); args = [] (44.535µs)
tracer_test.go:41: Query: SELECT id FROM t1 WHERE id = ?; args = [1] (1.828µs)

わーい、これでボトルネック探すの捗るぞー!… と思っていたら、元々のNewTraceProxyのシグネチャが

func NewTraceProxy(d driver.Driver, o Outputter) *Proxy

で、これだと自前のloggerを受け付けてくれない!
type MyLogger struct { *log.Logger }
とかでも駄目だ!ということでインターフェースを定義してOutputメソッドを実装してればなんでもいいようにしておいたPRを送って取り込んでもらった。これで使えるようになった。YATTA!(けど、デプロイはこれからなのでまだなにか後で追加するかも…)

どちらのPRも光速でマージしてもらって大分たすかった。ありがとうございます。
    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

最近カンファレンス運営についてのノウハウをちょっとずつアウトプットしていたりします

今回は Web+DB Press #85 でもその一部が掲載されていたものなのですが、YAPC::Asia Tokyo, RubyKaigi, PyCon JP, JANOGという技術カンファレンスの運営陣を集めた座談会の完全版をKindleで出しました。(表紙画像についてはすみません、素人なもんで… もうちょっとがんばって直してみます)

カンファレンスに参加してるだけでは見えてこない運営側の心配、希望、楽しさなどについて読めるかなり貴重な資料だと思います。是非お手にとっていただければと思います!


こちらの売り上げのほうはJPAの運営費やYAPC::Asia Tokyo 2015に使われたりします。よろしくお願いいたします。また雑誌掲載時も今回も編集を手伝っていただいた工藤春奈さんには心からお礼を申し上げたいと思います。日本語が(一部)不自由な筆者では手の届かないかゆい部分の校正をガツガツやってもらえました!


    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

もうかれこれ1ヶ月ほど Packer 0.7.5 で Docker 1.4+ を使ってる状態からdocker builderを使っても永遠に処理が終わらず、終わったと思ったらなんかdockerのエラーで止まるということが続いていた。

tl;dr;としては「多分次のバージョンのPackerで直る」「今はパッチを当ててソースからコンパイルしろ」なんだけど、まずデバッグも含め経緯を。

packerには-verboseみたいなのがなくて、まず状況が把握できなかった。これはPACKER_LOG=1 環境変数を指定することで詳細ログを表示できる。これで以下のようなエラーが出てたら多分このバグ→ #1752

2014/12/25 12:21:32 packer-provisioner-shell: 2014/12/25 12:21:32 Retryable error: Error uploading script: Upload failed with non-zero exit status: 1

で、いろいろ見てるとどうもこの変更で直るくさい。2014年12月(0.7.5の出た9日後)にPRが出てるんだけど、その後修正版PRがやっと出たのが2015年3月… そして2015年4月22日時点でまだマージされてない。

というわけでまだ修正版は存在しないんだけど、docker execを使ったバージョンの野良ビルドを作った人がいる。一応このバイナリは信用できると思うんだけど、野良ビルドだからこれを使う場合はみなさま自己責任でお願いします。

と、ここまでわかったが、PackerがOS X上のboot2dockerとではうまく動かないのはこの修正でも変わらないのでこちらの「Packerを使ってChef/Puppet/AnsibleでDockerのイメージをつくる」のVagrantによる手法でさらにyak shavingを続ける。上記の記事に書いてあるVagrantfileのpackerをダウンロードする部分を以下のように変更…

Vagrant.configure("2") do |config|
    config.vm.box = "ubuntu/trusty64"
    config.vm.provision :docker do |d|
        d.pull_images "ubuntu"
    end

    config.vm.provision :shell, :inline => <<-PREPARE
apt-get -y update
apt-get install -y wget unzip curl

mkdir /home/vagrant/packer
cd /home/vagrant/packer
wget https://github.com/stefancocora/packer-issue1752-fix/archive/master.zip
unzip master.zip
mv packer-issue1752-fix-master/packer/* .
rm -rf master.zip packer-issue1752-fix-master
echo "export PATH=$PATH:/home/vagrant/packer" > /home/vagrant/.bashrc
PREPARE

end

で、これを使ってvagrant up, vagrant ssh, packer build ... すると、やっと!やっと!Packerを使いつつDockerイメージを作れる。

なんかここまでしてPackerからDockerを使う必要があるのかという噂もあるけど、AMIなりGCPイメージなりを作るとAWSないしGCPないしと通信しなくちゃいけないし、いろいろ試してる間は自分の環境だけで終わらせたかった。PackerにはVirtualBoxとかのイメージを作る機能もあるけどその場合はベースとなるイメージを用意しなくてはいけない。でもそれをgitレポジトリにコミットしたくないのでどうしてもDockerを使いたかった、というのがここまでがんばってみた理由です。
    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

ここ1ヶ月くらいうちの長男がはまっているのが「ぼくのトイレ」「ぼくのおふろ」という絵本。





「でもいつもまいにちまいにちおんなじトイレ」「たまにはちがうのでしてみたい」というところから奇想天外なトイレが何個もでてくる。最後のほうは「ウォーリーを探せ」っぽくなる。最初に一回読んだ時はそれらのトイレに目が行くが、何回も読み聞かせをしていると今度はページ上あちこちにでてくる小さなキャラを探しながら読むようになれる。お風呂やトイレというテーマが身近なせいか、長男はこれを何回も何回も何回も何回も(以下略)読んでくれとせがんできて、どこに何があるか全部覚えていた。

まぁとは言え同じ本なのでそろそろ飽きてきたかなー、というくらいに偶然クレヨンハウスに行ったら今度は同著者から新作が出てたのに気づいた。 「ぶららんこ」と「すーべりだい」。




ウォーリーを探せ的な部分はないものの、ノリはわりと一緒。最初は普通のブランコだったのになぜか座る部分がふたつになり「ぶららんこ」に、次はみっつになり「ぶらららんこ」に… そして… みたいな。

今回もかなり気に入っているみたい。一気に買うと一気に消費してしまうので「すーべりだい」のほうは今回は購入を見送った。本屋で一回立ち読みしてみて、このタイプの絵と話がいけそうならおすすめの作品です。
    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

grpcをさらっと触ってみた。僕の個人的な結論から言うと、小規模なシステムにはいれるメリットあんまりないけど、複数チームでわりとバラバラに開発をしてるけど同じRPCを叩く必要があり、なおかつそれなりのトラフィックがあるなら有効そう。

他の言語の事は知らん。とりあえずGoでさわる。github.com/grpc/grpc-commonをチェックアウトして、サーバーとクライアントを起動する。ドキュメント読んでるとProtocol Buffersの話とかでてくるけど、動かしたいだけなら全部忘れてよし。

$ cd go/greeter_server
$ go run main.go
$ cd go/greeter_client
$ go run main.go

これだけだと一回RPCが走るだけでつまらないので、client側を変えて100 goroutineでぼちぼちたっぷりのコールをするようにする変更した部分はこんな感じ。ローカルホストにサーバーもクライアントもある状態なので正直正しい計測ではない事はまず言っておく。その前提で ざっくり10000 jobs/sec。HTTP2のオーバーヘッドを含めてだいたいそんなものなのでまぁ悪くないな、って感じ。

と、ツイートしたら"net/rpcと比べてどう?"って聞かれたのでほぼ同じプログラムをnet/rpcで作ったところ、約25K jobs/secいけた。 というわけで生スピードでは負けてしまったが、プロトコルの複雑さの差分と、goのhttp2がついこの間作られたばかりであまり最適化されていない、というのがほとんどの原因だと正直思ってる。

この辺りの厳密な値はちゃんとサーバー立てて検証すべきだし、他の言語でも試すべきなので本当に雑談程度の認識にしておいてください。

それより、やはり方法論としてProtocol Buffersでプロトコルを定義してそれを複数言語用に自動生成できるのが強みかなーと思ってる。JSON Schema的な。あっちの大陸とこっちの大陸で作業してるチームがサーバー・クライアントのコードのひな形を簡単に生成して作業を始められるのは強いのではないだろうか。このコード生成をgoから試すにはgithub.com/google/protobufを入れた上でgithub.com/golang/protobuf/protoc-gen-go を入れる必要があるので注意。

以上、さわってみたエントリでした。
    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

Software Design 2015年3月号

ソフトウェア デザイン 2015年 03 月号 の表紙はYAPC::Asia Tokyo 2013, YAPC::Asia Tokyo 2014でもお世話になり、今年もお世話になる予定CONBUの面々による「カンファレンスネットワークの作り方」です。普段正直ほとんど技術系の雑誌ってわざわざ買わないんだけどこの号は購入した。

DSC_0812


本文の記事ももちろんおもしろいんだけど、個人的にはやはり「YAPC」という文字列が専門誌とは言え一般的にあちこちで流通している雑誌の表紙に載っているのが胸熱…! 今までも雑誌にYAPC::Asia Tokyo関連の記事を載せてもらったり書いたりしたことはあったんだけど、もうYAPC本体とはなんにも関係ないところで自然?な形でこういう形でYAPCの名前が載るのがとにかく感動であった。

Web+DB Press vol 85

最近あんまり文章を書く仕事をしていないのだけど、WEB+DB PRESS Vol.85には自分が企画・進行諸々をやった「カンファレンス運営の本当の舞台裏」という座談会の記事を無理に言ってねじ込んでもらった(企画は賛同してもらって実際おもしろいと思うのだけど、多分俺の知らないこのページ数を都合する戦いがあったのだろう、と思ってこういう言い方をしてます)。

以前にもカンファレンスカンファレンスというイベントがあったりしたけど、運営側もすごくいろんな事を考慮しながら運営してるのでどうしても観客がいるとぽろっと話しちゃまずい話とかもあって好きに喋ることができないので正直言いたいことの10分の1も言えなくてストレスがたまる。それを解消したい! ぶっちゃけ話も聞きたい!ぽろりがあった場合はあとで修正して、おもしろい部分だけ世の中に伝えたい!という自分の欲求を正直に編集の稲尾さんに相談したら乗り気になってもらったのでガツガツと進行させて実現させてしまったのがこの会です。


_MG_6807_edit


というわけでRubyKaigiPyConYAPC::Asia Tokyo、そしてJANOGの皆さんに集まってもらって(もっと時間とお金と色々あれば他のカンファレンスの人達も呼びたかったのだけど、会場と司会進行の都合でこのメンツになりました)、まぁとりあえず酒でも飲んで、辛い事楽しいこと野望やらなにやら話そうぜ!という形で進めたらやっぱり楽しかったのであった。

本当におもしろいのでカンファレンスに登壇、出席している人には読んで欲しいなー。

ちなみにこの座談会のエッセンスはこの記事に出せているので是非読んで欲しいが、将来どこかのタイミングで完全版?を出版したと思っています。もしこの記事を読んでおもしろいと思ってくれたら、ブクマとかでコメントをくれると僕と文章の編集を担当してもらっている工藤さんがとても喜ぶしやる気がでるので、是非ぽちっとして教えてください!
    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

更新: h2oを0.9.1から1.0.0にしたらこのハック無しでもいけたくさいです!





HTTP2使いになりたい!と思いはじめて数ヶ月。でもなかなかうまいことここぞという使い道がなかったので、2週間ほど前にとりあえず仕事でkuradoを立てた時に前段にh2oを入れて様子を見ていた。kuradoならたくさんグラフ表示されるし、HTTP2の恩恵を受けられるはず…!と思って。HTTP1モードでは当然特になんにも問題はなかったのだが、いざChromeでenable-spdy4を有効にした時になーんか… 崩れる…

具体的にはCSS、画像の類いがこない事が多いが、たまにメインのHTML部分が返ってこない。Chromeの開発者ツールやnet-internalsを見ててもただERR::connectionResetみたいなエラーが返ってくるだけで全然意味がわからなかったので、しばらくそれはそれで忘れてた。

だが、ふとローカル環境で同じセットアップを試そうと思って色々とログを出したりして見ていたら、h2o側にアクセスが行っているタイミングと裏のkuradoのアクセスログが出てくるタイミングが全然合わない状況が認識できた。

はっ… persistent connectionとかkeepalive timeoutとかだ…!

と 細かい理屈が脳内でさっと組み立てられなくても経験値からひねり出せる天啓を得たのでごにょごにょデバッグ開始…

色々な組み合わせを調べてみた結果、とりあえずh2o側の設定で以下のようにすると、動く。YATTA! 

    paths:
      /:
        proxy.reverse.url: http://172.17.42.1:5434/
        proxy.timeout.keepalive: 0

そしたら、SUGEEEEEEEEE! kuradoやcloudforecastはご存じの通り1ページに大量のグラフが出てくるんだけど、それらの描画が爆速になった!これぞまさにライフチェンジング!まぁなんかどこかに問題があるとは思うんだけど、とりあえず期待通りの結果を得られた。

もし「本当はこうするべきだよ!」という方法をご存じの方がいたら是非教えてください!

おまけ:

その後ツイッターでこんなやりとりが。この続きはあるのか…?










追記




    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

ソーシャルコーディング時代の非技術者と技術者の関わり方についてちょっと考えをまとめたい。なお、これは「技術によって実現されるなにかをベースに商売をしている団体」という前提のもとで書く。たまたまインフラの一部にGitHubを使っているとかそういうのはここに含めない。また、大きめの企業・団体では数の利をいかしてなんとかこのあたりを解決できてしまったりするので、それもここでは含めない。



昔々、自分がメーカー系の会社に勤めていた頃バグトラッカーやレポジトリ(Perforceだった)などにエンジニア以外の人を入れるのは御法度だった。技術者側からの「わけのわからん注文をされる」「話がかみ合わない」など、納得の理由もある。なにより技術的な素養をもたない人達にとってはこれらのツールを使いこなすことが難しく、閲覧することさえなかなかかなわなかった。こちらもごもっとも。

が、21世紀に入って10年以上過ぎている今日、GitHub等のソーシャルコーディングを可能とするプラットフォームを使っている現場においては非技術者も積極的にコードやドキュメントの状態の閲覧、そして時には自ら介入して意見を言う必要があると思っている。そしてプライベートなプロジェクト等ではそのためにGitHubにアカウントを持つべきだと思う。特に小さいチームにおいては全員がプロジェクトに参加できるようにするべきではないだろうか。自分は100人も200人もいるチームなら別だが、10人、20人のチームであるなら自分達が関わっているプロダクトの開発がどのように行われているのかせめて見える・見るようにするためにGitHub等に積極的に参加するべきだと思っている。





自分がこれを必要と思う理由はいくつかある。

まずは分業文化を避けるためである。ある程度それぞれの部署で自力でどうにでもできる大きさの企業なら分業制は効果があるだろうが、小さいチームでは一蓮托生。全員での密なコミュニケーションを取り、なにが今必要なのかをちゃんと共有する必要がある。非技術者がコードやドキュメントの状況を見られない、というのは「自分はコードには責任を持たない」という気持ちを肯定する意味があると思う。それでは駄目だ。当然実装には関わらないが彼らにも当事者でいてもらわないといけない。営業や顧客対応をしている人達こそがプロダクトの本当の姿を知っているのではないだろうか。彼らこそがエンジニアのケツをひっぱたくべきなのではないだろうか。もちろん、全体の状況を鑑みて取捨選択をしたり、エンジニアを余計な労働から守る人も同時に必要にはなるが、それもまた密なコミュニケーションにより状況を相互理解しあう事が必要だと思ってる。

次にエンジニアの怠慢を避けるためである。これは前の点と根っこは一緒なのだが、自分も含めエンジニアというのはやりたくない機能の実装や修正はとにかく先延ばしにしたい、というのが本音だと思う。たまに意識の高い人もいるが、それは稀であると思う。基本人間怠けたいものだ。プログラムを書いている側というのは自分が書かなければ何も始まらないという圧倒的アドバンテージを持っているため、立ち回り方を間違えなければエンジニア以外の人から見たら信じられないほど怠けることができる。秘密にしてたんだけど、ここではしょうがないのでバラす。僕の元クライアント・元同僚の皆様、僕はあなたたちに気づかれないようにかなり怠けてきました、すみません。ところがソーシャルコーディングプラットフォームを使って可視化することによって、多少鼻の効く非技術者が混ざればこの辺りが圧倒的にやりにくくなる。非技術者が実装して欲しい機能を技術者側から「えー、それはやりたくない…」と言われても、開発の状況をなんとなく見つつもう一歩突っ込めそうなタイミングで突っ込んでみる、ということができるようになるわけだ。

そして最後に自分達の命運がかかっているプロダクトの本当の姿を知ってもらうためだ。営業、運用、みんな自分達のプロダクトがどういう状態なのか知っておくべきだ。問題がある部分やすごくうまくできてる部分。どれも知ってるべきだし、その状況に合わせておのおのの仕事の戦略を変えるべきだ。何もエンジニアはプロダクトをSGUPP(スーパー・グレート・ウルトラ・パーフェクト・プロダクト)レベルに常にしておく必要があるというわけではない。現実とのバランスを取りつつ「ここは手を抜く」「これは駄目駄目だけど、とりあえずの形で実装しておく」などの取捨選択をせざるを得ないだろうし、それが普通だ。でもその状況をチームは共有すべきだ。

PRs


もちろんこのような事を実現するためにわざわざGitHubのアカウントを取るのではなく、ミーティング等で共有する、というのはありだろう。だけど俺が共有のための報告を行う場合、相手が開発の状況を何も知らないのなら俺は絶対に話の内容を盛ります。面倒くさい追求を受けたくないから、実害のでない範囲で嘘もつきます。そしてなによりミーティングはみんなの時間と生産性を奪う。昔ならばこの辺りの情報共有をしたかったらレポートに色々まとめないといけなかったのだろうが、2015年である。GitHub等のツールが使える。パーフェクトなツールではなくとも、issueの報告もできればwikiも書ける。コードの統計情報も見えるし、テストが通っているかという状況も見えるし、実装についてのエンジニア同士の喧々囂々も読める。

要はこの手の情報共有をするためのコストが10年くらい前と比べると圧倒的に低くなっている。もはや少なくともGitHub等に参加することによってコードの状況を見る事がコスト増(=損)にはならない。見ない事はマイナスになりえる。

エンジニア達は非技術者達にもっと自分達のやってることを見せるべきだし、非技術者達は恐れずにもっとプロダクトの中身の光と闇に向かい合うべきだと思う。




おまけ。若干違う論点だけど、似たようなトピック:
    このエントリーをはてなブックマークに追加 mixiチェック Share on Tumblr

このページのトップヘ