エンジニアの 
id:sukechannnn です。
最近 e-Navigator という取り組みをはじめました。
おかげ様でたくさんの人に受けてもらって大忙しですが、エンジニアの卵が成長していくのを見るのはとても楽しいです。エンジニアを目指している方は是非やってみてください！
Regional Scrum Gathering Tokyo 2018 行ってきた
もう２週間前になりますが、RSGT2018 に行ってきました！
私は現在、新卒/ポテンシャル採用に関わっており、かつエンジニアの組織づくりに興味があるのもあって楽しみにしていたのですが、とても良い刺激を受けてくることができました。
今回はその中でも特に印象に残ったセッションについて、感じたことや思ったことを書きました。(セッションの内容は貼ってあるスライドを読むか、登壇者の著書があればそれを読んでみてください。)
若干エモい内容も含まれますが、ご容赦ください(笑)
キーノート - Richard Sheridan - Build a Workplace People Love – Just add Joy
「Joy, Inc.」の著者の方です。彼がCEOを務める Menlo Innovations での取り組みを話してくれました。
印象に残ったのが「トップが意図的にカルチャーを形成する、カルチャーは自然にできるものではない」と言い切っていた部分でした。また、そのためにはカルチャーに合う人を採用するというのも重要だと言っていました。
スクラムをやっているとボトムアップでの改善に頼りがちですが、会社全体のカルチャーは誰かが意図的に作り出す必要がある、というのはその通りだと思います。そうやって醸成したカルチャーがなければ、採用をしようと思った時に会社に合うかどうかも判断することができません。働いている人がが自社のカルチャーはこんな感じ、というのを自覚できるのは大切なことだと思います。
Takeshi Arai - 心が折れてもソシキ・カイゼンを続けられるたった一滴の魔法
Richard のセッションではカルチャーはトップが作ると言っていましたが、ヴァルさんのカルチャーはこの人が作っているんだなーと思える内容でした。人の幸せのためにここまで頑張れるのはすごいと思いましたし、何よりそれを楽しんでいるのがもうなんか「神か！」という感じでした。心が折れても自分の信念に従って行動できる人ってそんなにいないと思うのですが、逆に言うとそういう人のいるところに良い組織はできていくんだろうなとも思い、自分も頑張らねばという気持ちになりました。
Ryutaro YOSHIBA (Ryuzee) - Scrum プロジェクト開始のベストプラクティス / Best Practice for Initiating Scrum Project
発表を聞いているあいだ、ずっと「そうだよな〜」って頷いていました。
- 作るものが決まらないとどんな開発手法が合うのかは分からない -> スクラム一択ではない
- 本当にアジャイルでいいの？を考える
- ステークホルダーに合意を取る(ステークホルダーは思っているより多い...)
- スクラムは十分な条件を揃えないと機能しない
- 揃わない条件を補うためのフレームワークではない
- 初期十分条件で始める
当たり前のことなのですが、現実としてなかなか難しいことでもあります。でもやらないと失敗する。強い意志が必要です。
このセッションは１日目の最後だったのですが、なんだか１日かけて「意志の強さ」みたいなものの大切さを痛感させられたような気がしました。
Michimune Kohno - 敢えて属人化せよ！エキスパートの集団こそが最強のチーム(Embrace Collaboration and Fun of Coding)
めちゃくちゃ良い発表でした。スライドがまだ上がっていないようなので、書いたメモを上げておきます。
Azureを作ってる
- めちゃくちゃ楽しいらしい
- 不安定な状態が楽しい
仕事の環境
- 元々個室だった（エンジニア一人に１つ個室ってすごい...）
- それをオープンスペースにした
- 昇降式デスク...！
- コラボレーションしやすくなった
- コミュニケーションのレイテンシーはゼロ
- また個室に戻った
- やっぱり集中はしやすい
- どちらにも良さがある
設計・実装・デプロイ・運用すべてに責任を持っている
- Azureでもそうなんや...
- 規模がでかいのにすごい
楽しく作るには環境大事！
- リモートは当たり前にやることだが、それでやりきれないこともある、対面での議論は非常に重要
楽しく作れる条件
- 大きな裁量、権限
- 自社の優秀なエンジニアが作り上げた素晴らしいソフトウェアのソースコードにコミットできる権限をもらえるのは最高
- コードは知識の履歴
- あがる給料
- やっぱりお金は欲しい
- 正当な評価
楽しくなくなる条件
- 孤独、タスク押し付け、無責任な上司
- あがらない給料
- ネトゲしながらコード書いてても、アウトプットが出てればOK
- 別に何してても良い、アウトプットが全て
個人が Water Fall から Agile に移った経験談
- Water Fallな部署からAgileな部署へ異動
- アメリカに行って１年半くらいは英語が怖かった
- 同僚の言ってることがわからない
- ドキュメント書いても意味がない
- ソフトウェアはドキュメント大事だし、計画的に作る
- Azureはクラウドなので、詳細なドキュメントを書いても賞味期限が１〜２ヶ月しかない
Dev + Support
- サポートも含めてのサービスの価値
評価システム
- 昔は１〜５段階(1が最も良い)
- ５段階評価を全部やめた
- 無駄に競争が生まれてしまう
- 後ろから追いかけられてるような恐怖感
- 安心して仕事ができなかったが、できるようになった
- インパクトが大きい人が評価される
- 同僚をレビューする(良いと思った人をプロモーションする)
- どれだけ仲間を助けたか、を評価
- 上司を評価するシステム
- アメリカだと学校にもある
- 自分がパフォーマンスを発揮できないマネージャーは悪く評価され、その評価はマネージャーの上司に行く
- 雇用が流動しているので、ダメなマネージャーの部下は辞めてく
- マネージャとエンジニアは明確に必要なスキルが違う、チームのパフォーマンスを最大化するのが上司の仕事
社内のセキュリティチームが抜き打ちで攻撃してくる(笑)
- セキュリティ専門チームが何の前触れもなく突然自社サービスに攻撃を始める
- 「中に入っていろいろできちゃったぜイェーイ」と発表される、とても悔しい
ハッカソンの力
- 業務と関係ないけどなんか作りたい！ってのを発散する場がある
- 上手く行けばそれをAzureのプロダクトにできる
- それをやってる間メインの業務はやらなくて良い
- エンジニアの持っているポテンシャルを生かす場があると爆発的な何かができる
- それを実現するためにはマネージメントが非常に重要
マネージメントの力
- エンジニアがフォーカスすべきことを示してくれる人がいないとチームが発散する
- 毎日言ってもよい
- なかなか理解してもらえない人に分かってもらうためにはメッセージを発信し続けることが大切
- One Microsoft
- 色々なチームが一緒にやれば面白いことができるじゃん！というのをトップが示した
- やっぱりこれはボトムアップだと難しい
変わらなかったのは「変化すること」だけ
- 必要なのは変化に強い体制と心構え
「スイッチ」を切り替えるべし！
- 上司は良い仕事をするための良きパートナーであり、命令をしてくる人ではない
- 属人化した Expert 集団こそ最強
- ゴールは勝つこと
- 各分野のスペシャリストにその分野をとことん追求してもらう
- そういう人たちをうまくポートフォリオを揃えて、どこかに行かないように気を使って、頑張ってもらう
「楽しく価値を Deliver しましょう！ Happy Haching!!」
- お客さんが喜んでくれるのが嬉しい
楽しく働ける環境を作ってくの大事
- 日本語って難しい、変な意味に取られがち
- 「バグを憎んで人を憎まず」みたいなメッセージを上が出し続けることが大事
このセッションが聞けて本当に良かったです。
個人的な感想ですが、エンジニアが仕事に情熱を持って取り組める環境をどう作っていくか、はやはりエンジニアにしか考えることができないんじゃないかと思いました。「ネトゲしながらコード書いてても、アウトプットが出てればOK」なんて、エンジニアでも全員がすんなり理解できるとは思えません。でも、それを許容してでも成し遂げたいもの・作りたい環境がある、と考えると、本当にすごいなーと思いました。
もちろんマイクロソフトだからできるということはあると思いますが、そうじゃなくても性善説で仕組みを考えることが大切なんじゃないかと思います。(同時に採用がめちゃくちゃ重要になる)
Daisuke Kasuya - リモートワークは難しい - それでもぼくらは歯をくいしばってやっていく
弊社でもリモートワークの議論があり関心も高いので楽しみにしていたのですが、とても勉強になるセッションでした。全てをリモートでやるのは難しいというのを改めて聞いた上で、それでも実現に向けて努力する意義があるなと思いました。リモートをする、という選択ができる状態であることの重要性を感じることができたのでとても良かったです。
また、先日の大雪でおためしリモートワークが発生したのですが、その体験もとても良かったので、具体的な導入に向けての議論ができればいいなーと思っています。
Takao Oyobe - Teamwork Revolution - チームとものづくりに真正面から向き合うモブプログラミング -
弊社でも一部のチームでモブプロを試していたりするので、楽しみにしていました。とても勢いのある楽しいセッションだったのですが、ここでもやはりそもそものメンバーが合うことと、心理的安全性があることが大前提で、それがないとモブプロはできないとおっしゃっていました。もちろんモププロで解決する問題や効率的になる部分はたくさんあると思うのですが、その大前提を揃えるのが非常に重要かつ困難だなと感じてしまいました。(このセッションが２日目の最後だったのですが、２日間通してずっとこんな感じですね。)
とはいえ僕自身はモブプロ面白いなーと思っていて、例えばいきなり全てをモブにするのではなくレビューだけモブでやるとか、そういった形で小さく取り入れてみるのも面白そうだなと思っています。勝手に周囲の人を巻き込んで試したりしてるのですが、なかなか良い感じなので広めていきたいです。
まとめ
何をするにも、大前提となる良い組織、文化、制度を作りましょう。これに尽きますね。
個人的には、新卒/ポテンシャル採用をやっているので、自分が関わって入社してくれた人が「この会社最高や！」と思って働いてくれたら嬉しいです。そのために自分にできることを探して、少しずつでもチームを良くしていけたらいいなと思っています。
