サービスの開発をしていてPMから施策案が出てきた時、ソフトウェアエンジニアとして施策案が本当にユーザーのためになりサービスの成長につながるか納得できないことがある。 このような時にただ文句や愚痴を言っても何も始まらない。エンジニアからも何らかのアクションを起こし施策を前に進める必要がある。 そこでエンジニアができるアクションについて、自分が思っていることを書いてみる。 納得できないケースは大まかにどのようなものがあるか 納得できないケースでは大まかに2つのケースがあるのかなと思っている。 (1) 施策をしたい目的や仮説自体に納得できていない (2) 施策の目的や仮説は良いが、それを達成する手段に納得できていない 1つ目は、たとえば「ターゲットとしているようなユーザーって本当にいるか？」「ユーザーにこういう課題があると言っているが本当にそういう課題があるか？」「この指標に繋がると言っているが

最近は読書のやり方を変えてみたら知識の吸収速度・引き出し速度が上がった話 - $shibayu36->blog;に書いているやり方で読書をしている。こういう流れだ。 (1)学びたいと思った知識が書いてありそうな本を2~5冊選ぶ (2)1冊ずつざっくり読みながら、面白かった部分・気になった部分はKindleで黄色にハイライトしておく (3)全冊読み終わったら、ハイライトした部分だけ眺めて、やっぱりおもしろいと思ったところは赤のハイライトを付け直す (4)赤のハイライトを眺めて、読書ノートに転記する (5)とくにおもしろい部分については、自分の知見まとめノートにカテゴリごとに整理する しばらくこれを続けて感じたのは、結局のところ(4)〜(5)に至るまで書籍の内容が全然頭に入っていないということだ。(4)(5)の時に、はじめて「書いている内容が言いたかったのはこういうことだったのか」と頭が急に理

以前Pull Requestから社内全チームの開発パフォーマンス指標を可視化し、開発チーム改善に活かそう - Hatena Developer Blogの記事で、開発パフォーマンスを可視化する話を書いた。その後、バリューストリームマップを作り開発フローの課題を洗い出して、チームの改善を行い、そして開発パフォーマンス指標で効果を検証する取り組みを行ったので、その経験についてブログに書いておく。 前回の記事のサマリー バリューストリームマップを作り、開発フローの課題を発見する バリューストリームマップとは何か チームのバリューストリームマップを作る バリューストリームマップから課題を見つける 見つかった課題を解決する 開発パフォーマンスの指標で改善結果を振り返る まとめ：データを根拠にチーム改善するという進歩 参考 前回の記事のサマリー 前回の記事を前提として書くため、簡単にサマリーすると 開

自分のプロジェクトマネジメントのスキルをもう一つ伸ばしたくて、タスクの依存関係とリソースの両方を考慮してプロジェクトマネジメントをするCCPM（クリティカルチェーンプロジェクトマネジメント）理論を学んだ。この理論を学んだおかげで、よりプロジェクトの計画作りや、プロジェクトの現在の危険度の把握をやりやすくなったと感じる。アジャイルの手法であるベロシティでの管理ともうまく組み合わせられそうだったので、今度試してみたい。 参考にした書籍 クリティカルチェーン 作者:エリヤフ ゴールドラットダイヤモンド社Amazon 進む！助け合える！ＷＡ（和）のプロジェクトマネジメント――プロマネとメンバーのためのＣＣＰＭ理論 作者:宮田 一雄ダイヤモンド社Amazon アジャイルCCPM: プロジェクトのマネジメントを少し変えて組織全体のパフォーマンスを大きくのばす 作者:宇治川浩一株式会社ビーイングAmaz

マネジャーをやっていると、1on1でいろいろな困りごとを相談されたり、雰囲気を感じ取ったりで、部下が困っていることがよく見える。その時「頑張ってマネジャーの自分が解決しないと！」と思い、全部自分で解決してしまうことがある。しかしこのようなやり方は正直デメリットが多く、やめたほうが良いと考えている。 これを続けていると、例えば 部下が問題はマネジャーが解決してくれるものと思いすぎてしまう可能性がある。するとこの仕事はマネジャー、この仕事はエンジニアと過度にカテゴリー分けがなされることがある 部下の問題解決能力、相談能力などの向上機会を奪ってしまう 細かい問題を解決しているだけで時間がなくなってしまう 結果的にスケールもせず、解決に取り組めない問題が増えていく 本当に解決すべき重大なチーム課題に取り組む時間がなくなる などといったことが起こりうる。こうなると実際には自分が色々問題を解決できてい

最近メンタリング制度のことや、技術組織のことについて興味がある。最近「エンジニアリング組織論への招待」という本が出版されて話題になっていたので読んでみた。 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング 作者:広木 大地技術評論社Amazon この本は、エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるのか」ということと述べている。その考え方に従って、思考方法、メンタリング、チーム運営、組織運営といったプログラミング以外でのやるべきことについて、様々な背景も含めて教えてくれる。 全部読んでみたところ本当に良い本であった。メンタリングや組織運営といった、なかなか汎用化や言語化がしにくい分野を、納得のできる形で言語化されていて本当にすごい。僕は最近はメンタリング制度について考えているので、特にChapter2のメンタリングの技術の章が一番

僕は自分がやったこと・勉強したこと・気づいたことなどはどんなにちょっとしたことでも、公開の場のブログに書くようにしている。その内容はある程度雑でも良いので、とにかく公開の場に書くようにしている。それによって、結構良いことが起こっているというのを社内の日記に書いていたのだけど、これも公開の場に書いておいても良いかと思ったので書く。 これまでの経験だと、次のような良いことが起こっている。 最低限未来の自分に理解できる程度まで記事にまとめることで、知識が頭の中で言語化され、定着する 時々他の人からフィードバックを受けて、さらに学習が進むことがある 「あれ昔なんか勉強したけど覚えてないな」という時に自分のブログ見たらすぐ思い出す 分からないことを調べようとググったら自分のブログが出てきてすぐ思い出す 初めからブログに書くつもりでインプットすると、自然と体系化・汎化しながらインプットできるようになる

これまで少し大きめな機能であれば、コードを書く前にまず仕様や実装の方針をissueのdescriptionにまとめ、それを先にレビューしてもらってから実装にとりかかるということをしていた。最近、その方針をそもそもrepositoryのファイルとして書いて、PullRequestしてレビューしてもらうようにしたら便利だったのでご紹介。 なぜコードを書く前に仕様や実装の方針をレビューするのか 前提としてなぜコードを書く前に仕様や実装の方針をレビューして欲しいのかについて書いておく。これはとにかく手戻りの量を少なくしたいという要求のためである。 実装に取り掛かろうとすると、実装の方針はいくつか思いつくが、どれが一番よいか迷うことはよくある。その場合に誰にも相談せず自分だけで判断し、コードを書いてからPullRequestを送った場合、もしその選択に重大なミスがあった場合全て書きなおさないといけな

先に前提を話しておくと、会社は全く辞めるつもりはないし、むしろどんどん会社を良くしていこうと思っている。今回はそういう基準で自分がコードやドキュメントを書いていますよという話。 コードやドキュメントを書く時に、どのくらいきれいにしておくかとか、どのくらいわかりやすくしておくかとかを考えることがある。こんなとき僕は、いつ突然自分が会社をやめて連絡がつかなくなったとしても他の人がある程度理解できるか、を基準にしている。そのためにはあまりいい方法が思いつかなくて仕方なく書いている部分にはちゃんと経緯のコメントを書く。他にも例えば作ったサービスであるイベントを開催する方法のドキュメントを書くなら、全く何もやったことがない人がそのドキュメントを読んだらとりあえず開催できるよう、ドキュメントを書く。当然コードもかっこよさよりも、説明しなくても分かりやすくなるようなシンプルさを追求する。 また、このよう

僕は学習をする際には書籍を参考にするのが好きだ。なぜネットとかではなくて書籍を参考にするかというと、書籍のほうが学びたい事柄についてネット情報や人から教わるのと比べて、どちらかというと体系的にまとめられていると思っているためだ。 ただし書籍を参考にしている時によく陥りがちなのが、「学習する」という目的を忘れて、「本を読み切る」という事自体が目的化してしまうことだ。こうならないため、僕はこの書籍を読む目的をはっきり決めるようにしている。その目的が大体3つくらいの種類に分類されてきたので、今回はそれについてまとめてみようと思う。 三つの目的のどれかを選ぶ 僕の中で学習目的で書籍を読むときは以下の三つの目的のどれかに絞っている。 これからの課題を解決する方法を見つけるための読書 これまでうまくいったことの言語化を行うための読書 視野を広げるための読書 この三つのどの目的で本を読むか、自分の中で明

最近、シバソンという名のほぼ身内でやっているイベントを開催している。シバソンとはシバハッカソンの略で、なぜか適当にハッカソンしますと会社で呼びかけたら自然とシバソンという名前になっていた。今日は勉強会について簡単に書きたいと思う。 Kyoto.pm 以前自分はKyoto.pmというperl界隈のイベントの主催をしていた。このイベントは最初もっといろいろな人にアウトプットする場を提供したいという気持ちで始めたイベントだった。有名な東京のperl hackerを呼べたり、東京からはるばる来てくれる人が何人かいて、けっこう面白いイベントに出来たと思ってる。 ただ問題点がいくつかあった。 一つ目は主催者が開催のために前準備(スピーカー集めとか)をするコストが非常に高かったこと。発表会形式にすると、特に関西ということもあって、全然スピーカーが集まらないということがよくあった。そのたびにいろんな人に声

最近Hubotの導入をしている。今回はHubotを導入したらikachanというツールの代替も出来たのでそのメモ。 ikachanとは http://blog.yappo.jp/yappo/archives/000760.html https://github.com/yappo/p5-App-Ikachan ikachanとは、HTTPのAPI経由でIRCに対してメッセージを送るように出来るようになるPerl製ツール。ikachanはdaemonとして動き、特定portでLISTENされるので、そこにcurlなどを使ってPOSTすると簡単にIRCにメッセージを送れる。これまで様々な人がIRC botを作って、投稿する部分を実装していたのだけど、ikachanがproxyとしてHTTP APIを提供してくれるので、それを起動しておいてHTTP APIを叩くだけでひとまずメッセージを送る部分

最近nginxでリバースプロキシの設定を書いているんだけど、設定のたびに本番に緊張しながら反映していた。さらにその副作用として、nginxのファイルはリファクタリングされないという問題があった。 そこで反映する前にバグ等が見つかるようにnginx設定のテストを書きたいと考えた。今回はperlでテストを書いた。 どういうテストをしたいか やり方によってnginxの設定ファイルの分割の方法は違うのだけど、例えば以下の様なnginxの設定があり、それが別のファイルのhttpコンテキストの中にincludeされているという分割で考える。この時、この設定ファイルに書かれた内容が正しく動いているかテストを書きたい。 upstream app1 { server app1.host; } upstream app2 { server app2.host; } server { listen 8080;

EmacsからiTermに対してコマンドが送りたい時がある。例えば 現在Emacsで開いているファイルのディレクトリにiTermで移動したい 現在Emacsで編集中のテストをiTermで実行したい など。 そういう時には以下の様なユーティリティを定義しておくと便利。AppleScriptを利用して、iTermにコマンドを送る。 (defun execute-on-iterm (command) (interactive "MCommand: ") (do-applescript (format "tell application \"iTerm\" activate tell current session of current terminal write text \"%s\" end tell end tell" command))) これを利用して「現在Emacsで開いているファイ

最近PrePANのcarton 1.0化を進めるため、vagrant、chef、knife、AWSなどにはまりまくっております。今回はその中でvagrantにchefを適用しようとしたら全く終わらなくて、それについて調べたことについて話します。 PrePANの開発環境でvagrantを使っていたりするのですが、そのVMに対してchefを適用してみたところ、固まってしまって動かない(厳密に言うとすこしずつしか動かない)という状態になりました。そこでいろいろ調べてみると、IPv6とDNSの関係でネットワークの疎通が遅くなっていたという事がわかりました。 詳しくは Slow networking (due to IPv6?) on CentOS 6.x · Issue #1172 · hashicorp/vagrant · GitHub を見てもらうと分かると思いますが、IPv6で名前解決に行く

MySQLのswap insanity問題という言葉を聞いて、なんのことかさっぱり分からなかったので、調べてみました。CPUとかLinuxとかMySQLとかちゃんと理解しているわけではないので、間違っていることを書くかもしれません。 NUMAアーキテクチャ http://www.nces.is.nagoya-u.ac.jp/NEXCESS/blog/index.php?itemid=211あたりが分かりやすい。 UMAアーキテクチャがメモリを全てのCPUの共有資源とみなしてグローバルにアクセスするのに対して、NUMAアーキテクチャは以下のようにメモリを管理する。 ノードという単位でメモリを分割し、各CPUが割り当てられたメモリをローカルメモリとして管理するようになる numactlとかlibnumaとかで構成は変えれる? 他のCPUが管理しているメモリにはそのCPU経由でアクセス可能 de

最近Dockerとか、serfとかその辺りのツールが流行ってる。その中でとりあえずDockerはテスト環境やCIでは使えるかもしれないけど、実際にwebサービスが動いているものに使えるかどうかはまだわかんないねーという流れになっていた。 まあでもとりあえず動いているwebサービスをDockerでやったらどうなるかというのを知りたいというのがあって、いろいろ機会があったので4人で3日くらいやってプロトタイプ実装というのをしてみて試した。 結局出来たこと 結局以下の様なものが実際に動くところまで行った。 AWSのような環境がなくてもDockerさえ動けばブルーグリーンデプロイ出来る VPSだろうが自宅サーバだろうがなんでも ボタンだけで「本番用環境構築」「本番前の確認」「本番切替」が出来る web n台くらいを一セットとみなした環境をボタンひとつで簡単に作れる Docker imageのビルド

最近Serfというツールも気になっていたので、とりあえずクラスタを組んでイベントハンドラの設定をしてみるところまでやってみました。 Serfとは http://www.serfdom.io/ https://github.com/hashicorp/serf Serf is a decentralized solution for service discovery and orchestration that is lightweight, highly available, and fault tolerant. Orchestrationという層を支援する軽いツールみたいですね。これをうまく使うことで、クラスタにjoinしたweb serverを自動的に配下に加えるHAProxyとかを実装したり出来ます。参考: Serf+HAProxyで作るAutomatic Load Balanc