読者です 読者をやめる 読者になる 読者になる

エンタープライズエンジニア

雑記

エンタープライズエンジニア」って聞くと「社畜エンジニア?」とか「Excel方眼紙が得意そう?」って思ったりするのかな?これは、去年僕のチームにOJT(On the Job Training)に来てたカナダ出身の海外新卒のメンバーが言った言葉で、すごく印象に残ってる。

彼のコメントは「OJTの前は『エンジニアになりたい』と思ってたけど今は『エンタープライズエンジニアになりたい』と思ってる」ってことだった。つまり、エンジニアとして技術力を発揮するだけじゃなくて、それが会社に、ビジネスに、そして社会に貢献していけることにつながっているエンジニアになりたいってコメント。ちょっとスマートすぎて「あぁ僕はこういう世代と競い合っていかなきゃいけないんだなぁ」って思い知らされたのであった。

で、ぼんやり考えてた↓こういうことも、彼の言う「エンタープライズエンジニア」だなって思ったのでメモ。


自走するチームづくりをサポートするときのパターンぽいもの

Team

プロジェクトデザインパターンを読んだ。内容は企画に携わる人向けなんだけど、ちょっと言葉を変えると、エンジニアとしても「わかる!」って感じで読んでてワクワクした。良かった。

ということで「そういえば、チームづくりのサポートをするときに、ある程度パターン化してるものが僕の中にもあるなー」と思ったので、それっぽく書いてみる。

立ち止まる時間

やることが多すぎてチームが疲れている。

その状況において

少しでもタスクを早く終わらせてチームに余裕を作りたい!と、手が空いたメンバーに対して五月雨式にタスクをアサインしていると、メンバーは終わりが見えなくて疲弊してしまう。そして、効率良く作業をするほうが損をしているように感じてしまう。

そこで

5または10営業日の短い期間で区切り、その期間で終わらせるタスクを前もって共有しておく。その期間の終わりにはチームで時間を取って、何を終わらせることができたかを振り返る。

その結果

それまでは、終わりのないずっと続く作業に思えていたものが、この振り返りの単位で「終わり」が認識できるようになる。それによって、メンバーは自分たちが期間内に終わらせたタスクを確認することができ、チームとして一歩ずつ前進していることを実感できるため、達成感と自信を得ることができる。また、期間内でのアウトプットが見えるようになるため、効率良く作業を進めることを受け入れることができるようになる。

称え合い

メンバーにスキルアップして欲しいと思っている。

その状況において

リーダーは、メンバーの足りていない部分を見つけると、その場で伝えてあげないとまた繰り返すと考え、指摘する。その一方で、良いと感じた部分に関しては伝えるタイミングがなく、またそれを伝えないことによるプロジェクトへの実害もないため、伝えずに済ましてしまう。そして、リーダーから指摘を受けてばかりいるメンバーは自信ややる気をなくしてしまう。

そこで

《立ち止まる時間》にチームのメンバー同士で良かった点を伝え合うようにする。そこで、特にリーダーはメンバーの良かった部分について伝えるようにする。また、指摘に関しても、開発中にどうしても伝えなければならないこと以外は《立ち止まる時間》に共有する。その際には個人に対する指摘ではなくチームの課題として取り上げ、チームの仕組みとして改善していくようにする。

その結果

メンバーは、自分の良い部分を認識し自信を持つことができる。そして、相手がどのように思ってくれているかを知ることができるため、お互いを助け合いやすくなる。それぞれが自分の強みを活かしてお互いにサポートし合うことで、チームとして弱みを補って成長していくことができるようになる。

誰の幸せ

メンバーに自主的に仕事を進めて欲しいと思っている。

その状況において

メンバーはアサインされたタスクを指示通りにこなすだけで、自分から意見を出してくれない。だから、リーダーは自分が指示を出さざるを得ないと感じている。

そこで

アサインするタスクだけではなく、プロジェクトで何を作るかだけでもなく、それを開発することによって誰に対してどのような幸せを届けたいのか、を伝える。

その結果

一連のタスクがどのようにビジネスや社会に貢献できるのかを知ることができる。そのため、次に何をするべきか、少しでもその幸せを大きくするにはどうすれば良いか、を考えることができるようになり自主的に動けるようになる。

昨日の天気

タスクを無理なく期間内に終わらせて欲しい。

その状況において

メンバーは《誰の幸せ》かを考えているため、できるだけ早く進めたいと考えている。そのため、実現可能なスケジュールではなく「こうありたい」というスケジュールを立ててしまい、予定した期間内で終わらずに無理をしてしまっている。

そこで

実際にその前の期間で終わらせることができたタスクを数える。期間の開始時に100時間で見積もっていたものが、期間の終了時に40時間分残っていたら、チームには見積もりの時点で60時間分のタスクを終わらせることができる力があるということになる。実績を元にしているので、そこには、差し込みタスクや病欠、プロジェクト外の仕事に取られる時間なども含まれていることになる。

その結果

チームは、自分たちの感覚や希望・逆引きではなく、実績を元にスケジュールを立てることができるようになる。それによって、差し込みタスクや、レビュー後の差し戻しなども含めて、無理のないスケジュールで開発を進めることができるようになる。

ケーキの切りわけ

できるだけ管理することなく、進捗状況をより正確に把握したい。

その状況において

毎回、開発の中盤までは進捗状況が悪くなく見えているが、終盤になってレビューによる差し戻しが発生したり、仕様の認識違いが発覚したりしてしまい、予定通りに進まないことが多い。

そこで

開発の各工程(設計・実装・テスト)で切り分けるのではなく、スコープを小さく切り分ける。それによって、短い期間でリリースまで持っていけるようにする。

その結果

工程がxx%終わっている、という内容ではなく、動くものがxx個中yy個開発完了している、という内容の進捗把握をすることができる。完了しているものはエンジニアの感覚ではなく実際に動くものなので曖昧さがなく手戻りもない(手戻りを含めて、既に終わっている)。開発が全て完了しない場合も、そこまでの部分でリリースをすることができるのでリリースできないというリスクを軽減することにもなる。

生き残る方法

プランニングを行っている。

その状況において

《昨日の天気》で現実的なスケジュールを出したが、それではリリースに間に合わないことが分かった。

そこで

「一致団結してがんばりましょう!」というような精神論でその場を乗り切るのではなく、現実を見て計画を立てる。そのために、プロダクトオーナーに状況を説明し、調整可能なスコープがないかを一緒に考える。《ケーキの切りわけ》で、なんとか生き残れる方法がないかを話し合う。

その結果

ビジネス視点、開発視点の両方の視点からの議論をすることができ、段階リリースなどでなんとか安全に生き残ることができるパスを探すことができる。チームは、そのおかげで現実的なスケジュールでクオリティを落とすことなく、予想外の事態にも対応できる体力を持ったまま開発を進めることができる。

そんな感じ

で、上から順番にやっていくと「指示を受けて動くチーム」から「ビジネス視点を持って自走できるチーム」になっていく感じあるかなー。知らんけど!

昔書いたやつ

似たようなこと書いてるんだろうと思う。

bufferings.hatenablog.com

参考

books.rakuten.co.jp

プレパタも好き。

books.rakuten.co.jp

DC/OSのドキュメント読んでるところメモ

雑記

メモ


カイゼンするときに気をつけてることをちょこっと ( #devsumi 関西に行ってきた

Team

今日はデブサミ関西に行ってきた

Developers Summit 2016 KANSAI #devsumi

僕はといえば

いつも通り、こんな感じ


とはいいつつも

いい空気に触れることができて、楽しかったなー!

スピーカーのみなさん、スタッフのみなさん、ありがとうございました!お疲れ様でした!

みんな試行錯誤してるんだなー

って思った。

  • 次から次に新しい技術やアーキテクチャが開発手法が出て来る中で、その変化にどのように対応していけばいいんだろう?
  • 僕らはいったい何を作ればいいんだろう?どうやって?
  • 海外と比べたときに、日本の難しさってどこから来るんだろう?
  • エンジニアにとって魅力的な職場ってどんなんなんだろう?
  • 現役エンジニアなマネージャとしてどんなチームづくりをしよう?
  • カイゼンってどんなことに気をつけてどこから何に手をつけていけばいいかな?

わかる。わかるよぅ。

なので僕は

カイゼングループってグループを社内で立ち上げて、色んなグループに対して、エンジニアとして技術的なサポートとか、チームづくりのサポートとかをしてます。そのおかげで自分も色んなシステムやチームを見ることができて、スキルアップできるし、楽しい!

サポートするときに気をつけてるのは、例えば、

  • 僕自身が手を動かして何かをするんじゃなくて、そのチームのメンバーの理解をサポートしたり質問に答えたりして、チーム自身がそれをすることができるようになること。Jenkinsで自動デプロイの仕組みを作ってあげるんじゃなくて、そのチームが作るのをサポートする感じ。じゃないと、その後運用できなくて使われなくなっちゃうしね。
  • 目の前の数字には現れないけど大切なこと、をサポートする。チームのメンバーのスキルアップの手伝いだったり。コミュニケーションのフローを作るのをサポートしたり。だって、目の前の数字に現れることなら、普通にできるもんね。

とかそういう感じ。チームのポテンシャルをあげることのサポートなのかなー?

実際のサポート活動自体は2,3ヶ月で終わるんだけど、その結果は1年後くらいに出るかなーって思うので、ワクワクしながら見守ってますん。「そういう活動をしたい」って言って「好きにやっていいよ」って言って理解してくれて、自由にさせてくれてるので幸せ。

今は、マネージャ1人と、プロデューサー1人と、エンジニアの僕1人の3人でそれぞれの立場からカイゼン活動中ー。


宣伝

今年は、ゆっくりできるスペースを設けようと思ってるので、そこで、チームづくりのお話とかしましょうー!来てくだしー!

Azure Container Service with DC/OSでアプリを動かしてみることにした

Azure

Azureを触ってみることにした

Azure上でSpring Cloud使ってMicroservicesを動かしてみたいかな。Spring CloudやるならPivotal Cloud Foundryがいいんじゃ?って気もするけど、そっち方面はいい感じになるんだろうなと思ってるので、自分の中の別の選択肢を持っておこうかなってところ。

インフラ周りは、全然分かんない

んだけど。ぼちぼち触ってみる。

何から始めよう?

んー。VM立ち上げて、そこでアプリ動かしてー、って考えるの面倒だから、Dockerのイメージをpullしてきて動かしたいな。でも、Dockerをインストールしたマシンをいっこずつ管理したりするの嫌だなー、と思ってぶらぶらしてたら。Azure Container Service with DC/OSってのを見つけたので、それ触ってみることにした。

DC/OSはMesosってものを使ってるみたい。

Mesos

Mesosは、複数のVMをまとめて1個のおっきなマシンみたいに見せてくれるっぽい。それで「その中のこんだけCPUとメモリ使わせてー!」って言って使えるぽい。環境の分離にはDockerが選べるみたいで、Dockerで作っといたアプリをそこで動かせるみたい。よさげ。

Marathon

Mesosの上で動くMarathonってフレームワークがあって、そいつを使うとWebアプリをいい感じでコントロールできるみたい。インスタンス数のコントロールとか、Service Discoveryとか。WebのUIがあるから簡単に始められそう。よさげ。

DC/OS

ということで、DC/OSは、そんなMesosを使ってるんだけど。Mesosを自分でインストールしたり設定したり、好きなMesos Frameworkを入れてみたりしてもいいんだけど、DC/OSは、色々最初からいい具合にしてくれてるってことなのかな?

Reference implementation: The Azure Container Service

こんな感じ?

SpringBoot on Docker on Marathon on Mesos on DC/OS on Azure

ふむ。面白そうだ。

触ってみる

この辺よみながら、まずはSpring Bootのアプリ起動するところまでやってみようかな。

qiita.com

全力で効率の良くないチームをつくる

雑記 Team

というのが、最近の僕の好み。

効率の良いチーム

効率の良いチームは、みんなすごく効率良く仕事を頑張ってて。システムも効率良く既存のリソースを使ったりしてて、開発もすごいスピードで進んでいる。

なんだけど、最短の道を選び続けていて、どんどん選択肢がなくなっていって、動きが鈍くなってく。

そうすると、どうするか?「このままじゃダメだ!もっと効率良くやらなきゃ!」ってなって、最後には、頑張り続けて疲れた人が離れていく。そんな感じがする。

効率の良くないチーム

きょろきょろしたり、うろうろしてみたりして、選択肢を広げておく。ペアワークとか。暗黙知の共有とか。形式知化とか。新しい技術へのトライとか。そういう、一見、遠回りに見える道の方が、実は近い。という感じがする。リファクタリングとかもそうかな。

遠回りに見える道を選ぶのには、勇気が要るのだけどね。だって、最短に見える道を選んだのにうまくいかなかったら「最短の道を選んだんだ。他の道を選んでたらもっとひどかったと思う。」って言えるもんね。

システムも、難しいのは「共有しない」という判断を、一歩さがってできるかどうか、かなぁって感じがする。共有する方がいい部分と、共有しない方がいい部分がある。と思う。何でもかんでも共通化してしまうと、結局あとになって、からまりあって手が出せなくなって、「動いているものには触らない!」とか言い出して、コピペと分岐なコードになる感じがする。

全力

さて。効率の良くないチームで勇気を持って寄り道しながら進んでいくとして。外向きに大切なのは「それって効率が良くないんじゃないの?」と思われないようにすることかな。そう思われてしまうと、色々注文が飛んで来たりする。だから、全力でやっている、というように見せる。

ということで「全力で効率の良くないチームをつくる」というのが今の僕の中の流行り。

そんな感じ。

全然関係ないけど宣伝

今年も楽天テクノロジーカンファレンスの大阪サテライトやりますー。

10/22(SAT)。是非きてください!無料です。

tech.rakuten.co.jp

登録はこちらから↓

Rakuten Technology Conference 2016 Tickets, Sat, Oct 22, 2016 at 11:00 AM | Eventbrite

ちゃんとしたお知らせは別途!

明日は娘達とクッキーでもつくろうかなー(∩´∀`)∩

Memo: Reactive Streams and Project Reactor

Reactive Streams

http://www.reactive-streams.org/

a standard for asynchronous stream processing with non-blocking back pressure

  • asynchronous
  • stream processing
  • non-blocking
  • back pressure

Java API

http://www.reactive-streams.org/reactive-streams-1.0.0-javadoc/

Mainly only 3 interfaces:

  • Publisher<T> : Data provider following the demand from Subscriber
  • Subscriber<T> : Subscribe data from Publisher
  • Subscription : used to both signal desire for data and cancel demand between a Publisher and a Subscriber

And there's one more:

  • Processor<T,R> : Subscriber and Publisher

Specification

https://github.com/reactive-streams/reactive-streams-jvm/blob/v1.0.0/README.md#specification

Flux & Mono ( Project Reactor )

In my understandings, the interfaces of Reactive Streams are low level contracts for standardization. Therefore we need more convenient implementations on top of them. One of them is Project Reactor.

https://projectreactor.io/

Both Mono and Flux implements Publisher.

Now it seems a bit clear for me. I'm feeling like Reactor provides definition of flow. I will continue to check Mono & Flux.