エンジニアリングマネージャー勉強会に参加しました
2016年12月13日に「エンジニアリングマネージャー勉強会」に参加してきました。
(結構前のメモになるのでうろ覚えでの記述になります。すみません。)
「エンジニアのマネージャ(リーダ)による、メンタリング、指導、立ち居振舞いについて現状を共有します」というテーマだったのですが、全体的にキーワードとして「心理的安全性」というのが出ていました。
@muddydixon さんの「ボトムアップとトップダウンの技術組織への変革をしている話」というお話では、動機づけ要因とか衛星要因というキーワードが出てました。「組織としての目標やゴールに対して、責任を持つ(モチベーションを保つ)ということ」と「心理的安全性を作るということ」とを両立するというお話だったと思います。
面白かったのが、メンタリングを考える際にその人の「指向・姿勢・その人が持つアセット」を「キャリアアンカー改」という方法で分析されていることです。詳細についてはスライドでわかると思います。
あんちぽさんの「『いるだけで成長できる環境』を作るメンタリング」というお話では、基本的に「いいじゃん いい感じに ばーんと」という3つの言葉しか言っていないという話をされていました。
「いいじゃん」が、まだ最初の段階であまり信頼関係がないときに「肯定」をすること
「いい感じに」が、だんだん信頼できるようになってきてその「信頼」を示すこと
「ばーんと」は、もう完全に信頼しているので完全に任せきる「期待」を示すこと
という感じでやってるそうです。
あんちぽさんがCTOをしているGMOペパボではメンターを受けたひと(メンティー)が次の世代のメンターになるような親方と弟子みたいな関係や、同僚だったり同じような役割の人たちからの横からのメンタリングも入れて「上から下から横から」「公式にも非公式にも」というメンタリングモデルを目指しているそうです。
あと、質問の時に話されていたのですが定例会議を完全にリセットする取り組みをやって実際にうまくいったとのこと。。すごい。
@kenchan さんの「メンタリングはじめの一歩」というお話でも、心理的安全性を高めることと達成感を高めるということの両立の話をされていました。
1 on 1で心理的安全性アップをおこない、目標の面談で責任と期待のマネジメントを行うようにしてるとのこと。
目標の設定は、達成できないと評価されないので達成できるレベルよりも若干楽にしてしまうような「防御的」な目標にしてほしくないということを考えているそうです。
@takesako さんの「エンジニアリングマネージャの職務要件」という話では、他のロールとの比較のお話が出ていました。
プロデューサーは思いがつよく、「あれもやりたいこれもやりたい」
プロダクトマネージャーは逆にやらないことを決めることで映画の監督のような立ち回りをする
そしてエンジニアリングマネージャーは最初からチームに関わる
エンジニアリングマネージャーはエンジニアの「得意なことを伸ばす」ということが重要。
まず「快適」ということめざし、それだけでは堕落してしまうので「チャレンジ」というステータスを目指す。
エンジニアはとがった人が多かったりもするのだけども、「チームの隙間を埋めていく人材」にならなければならない。
それを実現するのがリクルートグループで共通で用いられている用語のATIを持つ人。
ATIとは圧倒的当事者意識のことで、その人は完全に枠にとらわれない。
ずっと前に、DevLove甲子園でリクルートの黒田さんという方が話されていたお話を聞きましたが、問題を解決するために上限を設定しないという態度は確かにという感じでした。
具体的にはスクラムを導入するコーチの選定の仕方や、スクラムで働きやすくなったということは利益の成長につながっていないことをちゃんと評価してそこから先に進むためにリーンの手法を導入したこと。
というのを思い出しました。
@yuku_t さんの話と@tatsushim さんの話はビアバッシュ中のLTだったのでちょっとメモもなくて申し訳ないのですが、@yuku_tさんの話は「スタートアップ的な組織」だと組織の規模が小さい黎明期はメンバーが本当に知っている人しかいないのでコミュニケーションなどに問題は起きないんだけど、組織が成長すると知らない人が増えて難易度が上がるというお話だったと思います。
特に意思決定の適切なプロセスや、メンバーの良好な関係をつくることが難しくてそれがマネジメントに影響を及ぼすという感じだったと思います。
@tatsushim さんの話もそれと似た感じの文脈はあるのですが、そのようなマネジメントの問題に対してスクラムを導入したお話をされていました。
案件管理のスプレッドシートの「優先度」カラムが最重要が複数あったり、「must」や「スター」などの別のカラムが追加されたりしてカオスになるという話はすごくよくわかる感じです。
スクラムを導入するのでも、拒否反応っていう結構難しい問題をはらんでいるのでその辺の心理的安全性をどう保つか、というお話だったと思います。
どの話もすごく面白く、今後自分がどのように仕事に向き合うかということにもかかわってくるものだったと思いました。
2回目のエンジニアリングマネージャー勉強会があるならまた参加したいです。
additional
@kenchan さんのお話でも少し出ていましたが、RebuildFMというポッドキャストで過去にポッドキャストのオーナーの@miyagawaさんと@naoyaさんが心理的安全性や「チームが機能するとはどういうことか」ということについて話されていた回があったと思います。
また、直近の171でもお話されていて、そちらも聞くといろいろと考えさせられて非常に良いと思います。
プロダクトファーストな考え方と、エンジニアとして主体的に働くこと
エンジニアとして主体的(アカウンタブル)であることを放棄している状態というのがいくつかあります。
- 上から言われた仕様や要件を実現させるだけのための技術的な解決方法やスケジュールにだけこだわってリリースすること
- 別のエンジニアや組織に発注する側である場合、自分たちの要件についての交渉可能性を放棄し、「私たちはあなたたちのこれができていないせいで困っている。とにかく何とかしろ」という態度で望むこと
- これはそもそも、7つの習慣などで言及されているWin-Loseなコミュニケーションをしている状態であると思います。こんな人とは一緒に仕事はしたくなくなります。
- アジャイルやウォーターフォールといったプロセス論にだけこだわり、プロジェクトの危機的な状況にたいして本当に見える化や継続的改善することに対してフォーカスされていないこと
こういった状況は仕事をする上では犠牲的つまり主体的でない状態の仕事であると思います。
こうしたことが起こる原因は、もっとマネジメントに関して、プロダクトファーストな考え方にシフトしていないせいではないでしょうか?
プロダクトのオーナーと「要求」には合意している状態で、「要件」については「交渉可能」である状態であるというのが望ましいのではないでしょうか。
つまり、「これをやりたいんだ」ということに関しては合意していて、それをどう実現するかについては交渉可能な状態であることです。
よく例として挙げられるのがオレゴン大学の実験の話です。
こうした状況で出来上がるプロダクトとして、「こんなはずではなかった」とか「かかったリソースの割合にできたものの売り上げが見合わない」といった状況も起こりうるだけでなく、継続的にそのプロダクトをメンテナンスすることに関しても弊害が出るはずです。 「言われたとおりに作ったんだから、なんで改修しなければならないんだ」とかいう気持ちになることはよくあります。
プロダクトオーナーと要件について交渉が可能であれば、少なくともこうした事態は避けられるのではないかというのが個人的な実感です。
前職であるeコマースの会社では元エンジニアであったデータマーケティングの担当者がこうした要求をこちらに伝えたうえで、要件に関してはこちらとの交渉可能性を残してくれている状態でした。
結果としてそのプロジェクトに関して、自分は(プロフェッショナルであるべきアーキテクトに関して)アカウンタブルな状況でのぞむことができ、ある一定の成果を出せたのですが、それは要件の合意について交渉かのうであったことが一番の大きな理由だと思います。
アカウンタブルであったため、シチュエーショニング(その要件や要求を整えるための状況の作成や他のエンジニアとしての交渉)についても気を使うことができ、他のエンジニアに発注する側であったとしても要求の「Why」の部分を伝えることに注力したつもりです。(ただしこれはまだまだ未熟な部分も多かったのですが)
個人個人の働く環境によってこんな交渉が可能な状態でいつも仕事ができるわけではないかと思いますが、エンジニアの成長可能性を一番高めるのはこうしたことが実現されていることが重要な差をつけるものになってくるなのではないかと思います。
そういう意味では、DDDなどの考え方を自然に開発に取り入れられているKRAYさんの取り組みなどには本当に感心させられます。 かかわる人間すべてが同じ言葉で会話できるだけでなく、設計や要件についても善しあしを交渉する足がかかりになっているのではないかと思います。この辺は推測でしかないのですが。
プロダクトファーストな考え方で仕事をするのが望ましいとは思うのですが、「そうは言うが大佐、このプロジェクトは納期だけが決まっているんだ」「オーナーとは交渉する余地がない」みたいなときはどうしたらいいかというと、メンタルだけには気を付けて「仕事は金のため」と割り切りましょう。
その上で「メンタルがやばい」とか「ソウルジェムが濁って魔女化しそうだ」みたいなときは「手を手遅れになる前に」転職先を探したり、よいカウンセリングのサービスでも探すしかないかと思っています。こんな解決方法しか思いつかなくて申し訳ないです。
理想を言えば、以下のスライドにあるようなチームに所属したいですね。 このスライドは本当に素晴らしいです。
とにかく自分の仕事が犠牲的な考え方(他の人のせいで私は仕事ができない)になっているかどうかについては気を付けつつ、基本的には「プロダクト」をよりよくするためにはどうしたらよいか、なんかあったら自分がそのプロダクトに対して責任を持つ(アカウンタブルである)ということを考えながら仕事をするべきです。 自分もそれがまだまだできてるとはいい難い状況なので恐縮なのですが。。。
あと最後に日曜朝にやっていた戦隊ものの特撮番組「トッキュウジャー」の中で怪人が「世の中金だー!」と叫んでいましたが、「お金は大事」です。 これについては自戒も含めて。
プロダクトファーストな考え方と、エンジニアとして主体的に働くこと
エンジニアとして主体的(アカウンタブル)であることを放棄している状態というのがいくつかあります。
- 上から言われた仕様や要件を実現させるだけのための技術的な解決方法やスケジュールにだけこだわってリリースすること
- 別のエンジニアや組織に発注する側である場合、自分たちの要件についての交渉可能性を放棄し、「私たちはあなたたちのこれができていないせいで困っている。とにかく何とかしろ」という態度で望むこと
結論としてはプロダクトのオーナーと「要求」には合意している状態で、「要件」については「交渉可能」である状態であるというのが望ましいのではないでしょうか。
つまり、「これをやりたいんだ」ということに関しては合意していて、それをどう実現するかについては交渉可能な状態であることです。
よく例として挙げられるのがオレゴン大学の実験の話です。
顧客が本当に必要だったものとは (コキャクガホントウニヒツヨウダッタモノとは) [単語記事] - ニコニコ大百科
プロダクトオーナーと要件について交渉が可能であれば、少なくともこうした事態は避けられるのではないかというのが個人的な実感です。
前職であるeコマースの会社では元エンジニアであったデータマーケティングの担当者がこうした要求をこちらに伝えたうえで、要件に関してはこちらとの交渉可能性を残してくれている状態でした。
結果としてそのプロジェクトに関して、自分は(プロフェッショナルであるべきアーキテクトに関して)アカウンタブルな状況でのぞむことができ、ある一定の成果を出せたのですが、それは要件の合意について交渉かのうであったことが一番の大きな理由だと思います。
アカウンタブルであったため、シチュエーショニング(その要件や要求を整えるための状況の作成)についても気を使うことができ、他のエンジニアに発注する側であったとしても要求の「Why」の部分を伝えることに注力したつもりです。(ただしこれはまだまだ未熟な部分も多かったのですが)
もちろん、個人個人の働く環境によってこんな交渉が可能な状態でいつも仕事ができるわけではないかと思いますが、エンジニアの成長可能性を一番高めるのはこうしたことが実現されていることなのではないかと思います。
ルビィのぼうけん 読書感想
ルビィのぼうけん
DevLove関西のイベント「それぞれの現場におけるチームづくりの試行錯誤」に参加したのですが、その中で翔泳社の岩切さんが1冊だけプレゼントしていただけることになりました。
1冊しかないので参加者でじゃんけん大会となり、じゃんけんとても苦手なのですが自分が勝ちとりました。
岩切さん、ありがとうございました!
内容の紹介と感想
帯の紹介によるとプログラマー的思考法を育む知育絵本、とのこと。
読んでみた感想ですが、非常に示唆に富んだ物語で面白いなーと思います。
子供が気に入って何回も読めばいろんなことに気付きそう。
そのために結構読み聞かせる親御さんなどのアシストも重要な気がします^^;
ルビィのほかにペンギンたち・ジャンゴ・雪ひょう・ロボットたち・きつねたちといったキャラクターが登場するのですが、たとえばペンギンたちはLinuxというよりもUnixの基本的な考え方「小さいまとまりに分けられた問題を好む」という性格で描かれていて、おもしろいです。
プログラミングが好きな人が読んでも、このキャラクターの性格は、こういう理由かなと想像しながら楽しめたり。
ルビィはある目的のために、そういうキャラクターたちとかかわりながら冒険を繰り広げる感じです。
周りのキャラたちとコミュニケーションをしつつ、出てくる難題を解決するのにはどうしたらいいか工夫をして解決していくのですが、どう伝えたらペンギンたちなど他のキャラクターに伝わるか、道具をどうつなげたら取りたいアイテムにたどり着けるか、みたいなところが見どころだと思います。
絵柄もカラフルで非常にかわいいので子供が見たら単純に楽しいんじゃないかなぁと思います。
後ろのほうに子供と一緒にパズルをとくみたいなワークがついていて、課題解決するためのアルゴリズムとか考え方を身に着けるのにとても役立ちそう。
そしてそれはプログラミングにつながっていくものだと思います。
ワークは子供とやる前にちょっと大人同士で練習してみてもいいかもしれないと思いました。
これからの時代、プログラミング的な思考のあるなしの違いは大きくなってくると思います。
それだけがすべてじゃないけれど世界を変えていく力の土台部分ですし。
子供たちのこれからを変えていくインパクトのある本だと思います。
「Whyの依存関係を明確にすることにフォーカスした質問」をどう活用するか?
暗黙知になっていること、とくにタスクや課題の依存関係などを明快にするには質問を「いい感じに考えるべきポイントにフォーカスして」繰り返すといいなと最近思っています。
というのもそういう質問の仕方がうまい人が同僚に入ったからなのですが。
『考えるときには考えるべきポイントを間違えないことが大事だ』
俺ガイル2期で平塚先生が何回もおっしゃっています。いや、何回も言ってるんじゃなくて何回も見てるんだった。
会社なら会社としてのビジョン、ミッションというのがまずあるはず。
ビジョン、ミッションにより近い質問からブレイクダウンしていく。
「プロジェクトのこの作業はこのミッションに貢献しているからやっているのですか?」
ということに答えるために、なぜなぜ分析っぽく
「会社の目標は何か?」
「会社のミッションは何か?」
「IT部門として成し遂げたいミッションは何か?」
「利益向上、コスト削減、リードタイム短縮のために作りたいインフラ基盤・アプリケーション開発基盤は何か?」
「なぜこのプロジェクトをやるのか?」
という依存関係のわかる化につなげていきます。
ハイコンテキストからローコンテキストへ置き換える作業でもあると思います。
で、その場で質問とその答えを聞いた人はわかるんだけど、それだけじゃなくて見える化したい。
そうすることで「ぶれないマニフェストをサジェスチョン」(※俺ガイル2期の意識高い系会議より)することが可能になると思うのです。
『「Whyの依存関係を明確にすることにフォーカスした質問」をどう構造化するか?』
前回参加したDevLove関西のイベントの情報設計の話ともつながると思います。
やり方自体はツリー構造でいいんじゃ、ってことなのですが。
メンバーだけで通じる暗黙知、ハイコンテキストを少なくし、周囲の人(ステークホルダー)に、常に見える状態にして『透明性』を出したいです。
その上で「本当に透明になっているか?正しいか?」ということを『検証』できる状態にしたいです。
さらには検証した結果を常に改善、『適応』できるようにしたいです。
それも楽に。
『ぶれないマニフェストをサジェスチョン』
Whyを共有できてないことに起因する本当に無駄な会議をしたくない。
やるべきことにフォーカスして仕事していきたいものです。
難しそうな「情報設計」に実際にふれてみる #DevKan
2016年3月18日に開催された表題の勉強会に参加してきました。
株式会社インパス 山下 一樹さん
UXをインクリメントするのに、UIだけをカバーしてるのはダメで、カテゴライズなどの情報設計も重要。
建築のプロセスに当てはめてみると、建築資材からコンセプトを決め、導線を決め、間取りを考え、使いやすさを実現するといった整理・設計が非常に重要になる。
情報設計は地味で出来て当たり前と捉えられがちだが、ディテールに拘る意味では計測をしっかり行うこととあわせてガチで重要だと思う。
デザインやUIだけ決めて工数見積もるとかやめて、コンセプトで情報設計に徹底的こだわるべきなのではないかと思う。
山下さん、会場の楽天さん、DevLove関西スタッフの皆さま、ありがとうございました。
『FRONTEND CONFERENCE 2016』に行ってきました
2016年3月5日にあった表題のイベントに参加しました。
特に良かったと感じているのは、以下の内容です。
大型フロントエンド開発におけるTypeScriptとDDD
奥野賢太郎さん Chatwork株式会社
累計メッセージ数 10億
以前のWeb版Chatwork
- moduleなし
- jQuery
TypeScript導入の経緯
『型がないとしんどい. 』
チームが拡大
1人 -> 8人 拡大することによる特有の問題が発生
- コメント、コーディング規約
- デザイナーとの連携
- テスト
- ビルド、タスクランナー
コメントは意図を残す
「なぜそう書かざるを得なかったのか?」
ドキュメント、コーディング規約
外注さんは背景をご存知でない。だが、JSやHTML5は得意。 暗黙知であったものを共有することが必要。 主要な処理は「エントリポイント」を用意し、新しい人でもコードをたどれるように。
ex. onclickから発火して、どのようにデータを取っていくのか
『入り口、玄関をきれいににしておく』
エントリポイントを用意する考えは参考にしたいです。
dockerfileなどのように。
デザイナーさんとの連携
- SCSSを採用 変数やmixin
エンジニアがTypescriptでHTMLのテンプレートを管理
テンプレートでUIをロジカルに設計してHTMLを構成する
そこから先がデザイナーの仕事
これをちゃんと分離していることがUIの改善を行う上で重要なんだと思います。
デザイン仕様書の取り扱い
その結果として「リポジトリ内で検索しやすい!」とのこと
単体テスト
mocha + power-assert
モックを扱ったり型違反を意図的に扱ったりする ここだけTypescriptではなくES2015で記述する部分も
不安なロジックはしっかりテスト
カバレッジ100%は目指さない。 もし実装を変更するたびにテストが赤になっていたらそもそも何か問題がある。
設計変更で壊れるテストをなくせるテスト自体も負債化する
E2Eテスト
PageObjectパターンを導入する
PageObjectは自分もGebで使っていますが、非常にわかりやすくシナリオと実現方法を分離できます。
Karmaテスト
- 開発初期のテストはmochaとE2Eだけだった
- イベントハンドリング周りの検証
ちょっと試してみたい。。。
タスクランナー
- gulpを使用
- 属人性に気をつける あっという間に秘伝のタレ化
gulpファイルの差分を見やすくするように管理
検証環境の構築
検証環境へのデプロイもgulpで構築 @kyo_agoさん
- 実際のAPIレスポンスを用いて開発
build
- build時間はモチベーションに直結 browserifyをwebpackに替えたら5分の1 tslintはバックグラウンドで回すように scssだけのタスク
TypescriptとDDD
約400のソース
- Component, Service, Utility, API
- チームメンバー全員で共有するのが大変
Typescriptの型はチームメンバープロダクト全体の把握を助け、揺るぎない情報となる
大きなシステムほど「膨大な知識」が要求される -> Domain Driven
型の恩恵
一ヶ月後の自分は他人
コンパイラはJSDocと違って嘘をつかない むしろ@paramに型情報を書かない
短いコメントを付けるくらいなら型名をIDEを使うと、ショートカットやクリックでファイルを辿れる
テストの捉え方が本質にせまる -> 振る舞いそのもの
『実行時Assert』自信を持ってリファクタリング 1、2行の変更であれば型が壊れていなければ安心
DDD
- 完璧なDDDの実践は難しい 言語的な面もチーム共有の側面も
ユビキタス言語 エンジニア、デザイナー、ビジネスでの共通言語
コンテキスト
coreドメイン
- User, Message, Taskなどのドメインモデル コレクションごとのClass
Applicationドメイン BindableUser class
『3人』という文字列 {length}人ではなく{UserCounts}
TypeScriptとDDD
Viewフレームワークとの付き合い方
オワコンなんてない フレームワークの「変動に強いアーキテクチャ」の検討
フレームワークロックインへの考え方
いつでも捨てても大丈夫なように抽象化された実装にする
Applicationドメインに表示描画用のロジックを集約
Angular2化を始めている
二槽式アーキテクチャ フロントエンドフロントエンド CSSとかDom
フロントエンド・バックエンド Coreドメイン、Applicationドメイン
ScalaJSに置き換えたい
感想
『型がないとしんどい. 』とはどういうことなんだろう、と思いました。
型がある複雑な言語だと抽象化する必要があるときに複雑なステップになったりする傾向がある、と知り合いに聞いています。
ChatworkのサーバサイドはScalaと聞いているので、その影響が多いんだろうかと思いました。
型で管理するのはいいけど、特定のデザインパターンに縛られることだけは避けたい気がします。
TypeScriptを使ってIDEでの操作しやすくしたり、テストを書きやすくするってのは良さそうだけどAngularはちょっと見たいな気持ち。。。
そうしたViewフレームワークなどのJSのメインストリームの変化に対しては、抽象化している「変動に強いアーキテクチャ」で対応するというのは素晴らしいと思います。
サーバーインフラの文脈でも『Docker、Vagrant、Serverlessアーキテクチャとかに依存しすぎない』、と同じように言われています。
変動に強いエンジニアになりたいです。
不勉強なところはとにかく何とかしたい。。。
奥野さん、FRONTEND CONFERENCE 2016のスタッフの皆さま、ありがとうございました。