リリースについてのブログも書いていないのに、
ちょっと全然違う事を書きます。
昨日、
Quipper社のTokyo Office代表横井さんと技術チーフ藤村くん(実は大学時代からの友達)と
食事をしていて『プロダクティビティエンジニア』についての話が出てきました。
弊社の開発における考え方として「方向>開発フロー>スキル」という順番があります。
方向がずれているとすぐに数ヶ月吹っ飛ぶので向かう先をどこにするかは最も大事。
次に開発フローで、変なコミュニケーションロスがあるといかにスキルの高いエンジニアがそろっていてもスピードがあがりません。
そして最後にスキル。
そんな話を藤村くんたちに熱弁していたら、
「ゆうじ、それはプロダクティビティエンジニアって言って、職種として今後大事になってくる考え方だよ」
と教えてもらいました。
このプロダクティビティエンジニアについては、
まだ日本語での良いドキュメントが見つからず自分の言葉で説明するしかないのですが、
要はスループットを上げる事にフォーカスするエンジニアの事です。
上記に書いたようなコミュニケーションロスなどを無くしたり、
最適なツールを決定したり、issueの切り方を整理したり、
テストフロー、デプロイフローなどを整備したりする職種になります。
例えば、日本だとKAIZEN platformさんが職種としてプロダクティビティエンジニア採用を進めていました。
探しても日本だとここに特化した採用をされている会社はあまり無いようですね。
[KAIZEN社]Dev Productivity Engineer募集！
これを見ると技術顧問であるito naoyaさんが率先してそこをやっていらっしゃるのかなぁと思います。
※このスライド、非常に勉強になるので必見です。
中にはこんなコメントも。
結局、この辺りが大事ですよね。
背景にはgithubの登場によってバージョン管理が容易になった事などがあるのではないでしょうか。
またはリモートワークを正常に稼働させようとすると、オフラインでのやり取りは難しいわけでより高度な開発フローを創る必要が出てきているのだと思います。
アジャイル、リーンなど色々な言い方ありますが、
結局あれって「走りながら改善していこうぜ」って事だと思うので、
そういった開発をして行きつつ、人数が増えてくると開発フローを整備しないと歪が生まれてくるのだと思います。
これはとても自分でも納得で、開発フローがうまく回っていないと、
本当にスキルがあっても中々スループットが上がっていかない。
しかも、人数だけでなく開発する内容、働き方などによっても最適な開発フローが違うため、常にチューニングする必要がある。
そして何度も書きますが、スキル以上に開発フローの整備が重要だと感じています。
さて、そうなってくるとExcelでスケジュール管理しているようないわゆるWEBディレクター職の未来が少し心配になってきます。
最低でもissueとスループットの管理が出来ないと、難しくなってくるのではないかなと思ったりします。
弊社の場合だとどのようなチューニングを過去に行ったかと言うと下記のような形になります。
・3月:Bitbucket利用開始。Hipchat利用開始。Trello利用開始。
・4月:言語、サーバー決定。Bitbucketでのissue切り方ルールの整備。Trello利用中止。QiitaTeam利用開始。
・5月:ホワイトボードでのタスク管理開始。Basecamp利用開始。
・6月:DegitalOcean利用開始、masterブランチで常にテスト出来るように。Basecamp利用中止。スプレッドシートで中里１人だけ細かいタスクを管理し、他メンバーは常にホワイトボードに1,2,3と付いた優先順位だけを見て作業するように。KPT導入。月1の合宿、週1の優先順位決め、毎朝の朝会を明確に行うように。
・7月:Bitbucket利用中止、githubへ移行。(おそらくHipchat利用中止、slackへ)
細かい事を書き始めるともっとあるのですが、たくさんのチューニングをしています。
この中でスループットを上げたのに効果があったのは、
・Bitbucketでのissue切り方ルールの整備→issueの粒度を細かくした
・QiitaTeam利用開始→簡易な開発ドキュメントから引越し時のタスクまでとにかく可視化
・DegitalOcean利用開始、masterブランチで常にテスト出来るように
・常にホワイトボードに1,2,3と付いた優先順位だけを見て作業するように→上中下などではなく何が1番上で2番目は何かを明確化
・KPT導入→振り返りの時間をしっかり創る事により全員の課題をすり合わせる
・月1の合宿、週1の優先順位決め、毎朝の朝会を明確に行うように→方向性の認識合わせ、全員の作業状況を可視化
あたりになります。
ただ、これも少人数における開発フローなので、人数が増えたりリモートワークが増えたり、プロジェクトが複数出来た場合などにはこの形ではありえないかと。
そういった時に柔軟に開発フローを整えるのが重要なのだと思います。
--------------
最後に告知になりますが、
弊社の場合は専門的なプロダクティビティエンジニア採用は行っておりませんが、
開発フローのチューニングに対する意識は高い会社です。
もしご興味ある方は軽いお茶などでも良いので、下記からもしくはnakazatoあっとthewoody.jpまでご連絡下さいませ。
サイバーエージェント出身CEO/CTOが立ちあげた会社を一緒に創りあげてくれる創業エンジニア募集中！
先日会社で行った引っ越しピザパーティーにてサイバーエージェントのエンジニアが
Bigqueryをお披露目してくれている現場。
ちょっと全然違う事を書きます。
昨日、
Quipper社のTokyo Office代表横井さんと技術チーフ藤村くん(実は大学時代からの友達)と
食事をしていて『プロダクティビティエンジニア』についての話が出てきました。
方向>開発フロー>スキル
弊社の開発における考え方として「方向>開発フロー>スキル」という順番があります。
方向がずれているとすぐに数ヶ月吹っ飛ぶので向かう先をどこにするかは最も大事。
次に開発フローで、変なコミュニケーションロスがあるといかにスキルの高いエンジニアがそろっていてもスピードがあがりません。
そして最後にスキル。
プロダクティビティエンジニア(Productivity Engineer)
そんな話を藤村くんたちに熱弁していたら、
「ゆうじ、それはプロダクティビティエンジニアって言って、職種として今後大事になってくる考え方だよ」
と教えてもらいました。
このプロダクティビティエンジニアについては、
まだ日本語での良いドキュメントが見つからず自分の言葉で説明するしかないのですが、
要はスループットを上げる事にフォーカスするエンジニアの事です。
上記に書いたようなコミュニケーションロスなどを無くしたり、
最適なツールを決定したり、issueの切り方を整理したり、
テストフロー、デプロイフローなどを整備したりする職種になります。
例えば、日本だとKAIZEN platformさんが職種としてプロダクティビティエンジニア採用を進めていました。
探しても日本だとここに特化した採用をされている会社はあまり無いようですね。
[KAIZEN社]Dev Productivity Engineer募集！
これを見ると技術顧問であるito naoyaさんが率先してそこをやっていらっしゃるのかなぁと思います。
※このスライド、非常に勉強になるので必見です。
中にはこんなコメントも。
十数年エンジニアやってるけど技術的に困難で解決できない問題があってみたいな時は実は少なく、解決すべきはちゃんとみんなに伝えてね、めんどくさがらずに話してね、仕上がりを確認しようね、みたいな話ばかりである。小学校か
— Naoya Ito (@naoya_ito) 2014, 6月 13結局、この辺りが大事ですよね。
背景
背景にはgithubの登場によってバージョン管理が容易になった事などがあるのではないでしょうか。
またはリモートワークを正常に稼働させようとすると、オフラインでのやり取りは難しいわけでより高度な開発フローを創る必要が出てきているのだと思います。
アジャイル、リーンなど色々な言い方ありますが、
結局あれって「走りながら改善していこうぜ」って事だと思うので、
そういった開発をして行きつつ、人数が増えてくると開発フローを整備しないと歪が生まれてくるのだと思います。
これはとても自分でも納得で、開発フローがうまく回っていないと、
本当にスキルがあっても中々スループットが上がっていかない。
しかも、人数だけでなく開発する内容、働き方などによっても最適な開発フローが違うため、常にチューニングする必要がある。
そして何度も書きますが、スキル以上に開発フローの整備が重要だと感じています。
単純なディレクター職はいらなくなる？
さて、そうなってくるとExcelでスケジュール管理しているようないわゆるWEBディレクター職の未来が少し心配になってきます。
最低でもissueとスループットの管理が出来ないと、難しくなってくるのではないかなと思ったりします。
WOODYにおける開発フローの変遷
弊社の場合だとどのようなチューニングを過去に行ったかと言うと下記のような形になります。
・3月:Bitbucket利用開始。Hipchat利用開始。Trello利用開始。
・4月:言語、サーバー決定。Bitbucketでのissue切り方ルールの整備。Trello利用中止。QiitaTeam利用開始。
・5月:ホワイトボードでのタスク管理開始。Basecamp利用開始。
・6月:DegitalOcean利用開始、masterブランチで常にテスト出来るように。Basecamp利用中止。スプレッドシートで中里１人だけ細かいタスクを管理し、他メンバーは常にホワイトボードに1,2,3と付いた優先順位だけを見て作業するように。KPT導入。月1の合宿、週1の優先順位決め、毎朝の朝会を明確に行うように。
・7月:Bitbucket利用中止、githubへ移行。(おそらくHipchat利用中止、slackへ)
細かい事を書き始めるともっとあるのですが、たくさんのチューニングをしています。
この中でスループットを上げたのに効果があったのは、
・Bitbucketでのissue切り方ルールの整備→issueの粒度を細かくした
・QiitaTeam利用開始→簡易な開発ドキュメントから引越し時のタスクまでとにかく可視化
・DegitalOcean利用開始、masterブランチで常にテスト出来るように
・常にホワイトボードに1,2,3と付いた優先順位だけを見て作業するように→上中下などではなく何が1番上で2番目は何かを明確化
・KPT導入→振り返りの時間をしっかり創る事により全員の課題をすり合わせる
・月1の合宿、週1の優先順位決め、毎朝の朝会を明確に行うように→方向性の認識合わせ、全員の作業状況を可視化
あたりになります。
ただ、これも少人数における開発フローなので、人数が増えたりリモートワークが増えたり、プロジェクトが複数出来た場合などにはこの形ではありえないかと。
そういった時に柔軟に開発フローを整えるのが重要なのだと思います。
--------------
最後に告知になりますが、
弊社の場合は専門的なプロダクティビティエンジニア採用は行っておりませんが、
開発フローのチューニングに対する意識は高い会社です。
もしご興味ある方は軽いお茶などでも良いので、下記からもしくはnakazatoあっとthewoody.jpまでご連絡下さいませ。
サイバーエージェント出身CEO/CTOが立ちあげた会社を一緒に創りあげてくれる創業エンジニア募集中！
先日会社で行った引っ越しピザパーティーにてサイバーエージェントのエンジニアが
Bigqueryをお披露目してくれている現場。
コメント