MANABIYA 2日目に参加して来た
参加して来ました
teratailを運営するレバレジーズが主催するMANABIYAの2日目に参加して来ました。 自分なりにレポートをまとめたので公開します。
エンジニアのための自分経営戦略
講演者
サイボウズ・ラボ、ビープラウドの機械学習周り(PyQとか)の技術顧問
西尾 泰和
著書
- コーディングを支える技術
- word2dev
- 世界一わかりやすいプログラミングのしくみ(新発売!)
転機
違う領域を学ぶために、2011年に社会人大学院生として東工大に経営学を学びに
この講演の目的
最初の一歩を歩ませること
5~10年経った時に役立つようなタネを撒きにきた
Facebookにエンジニアのための自分経営戦略というグループを作っているのでそこで質問やら情報を追加するので是非参加してほしいとのこと
きこりのたとえ
- 木を切るのは大変な仕事だ
- 少し休んでのこぎりの刃を研いだらもっとはかどるよ
- 切るのに忙しくて研ぐ時間なんてないんだよ
これは自分への投資と同じ
損失額の限定
新しいことのへの不安
やることによって何が得られるか、分からない
そんなときは 基本戦略:損失額の限定
結果はわからないのでそれをしたことによる損失を小さく限定する
例えば本を読む時に15分と決めることで、これを実行した時に15分使ったという時間を失われるだけという損失で済む
経営戦略とは 限られたリソースを何に配分するかの意思決定
自分個人の経営に注力 法人ではなく個人 プログラミングでも同じでめっちゃ書いてから試すのではなく小さく小さく試していく
経営を勉強するタイミングで一般社団法人の理事の提案が来てタイミングがよかった
個人のリソースとは
法人だとヒト・モノ・カネ・情報と言われている
列挙したものがすべてかということを疑っていこう
個人のリソースは 時間
配分をして何を得たいのか
何を得たいかは経営者が決める
法人によってはあえて赤字になっても投資をしていったりしている
単純に給料を下げれば利益があがるがそれによって従業員がハッピーになることはなく満足度が下がるときどうなるか、それぞれのリソース配分を考える
個人では自分自身が何を求めたいかを自問していく
今、確実に言えるのはこの場にいる人は知識を求めている、時間を使ってこの場で聞いて知識を得るぞという投資戦略をとっていると言える
このように自分自身がしている経営判断を自覚していこう
自覚するとそれを改善していこうというサイクルが生まれてくるはず、これでより良いものになっていく
お金は使うとなくなるが、知識は使ってもなくならない
使ってもなくなるものではなく使ってもなくならないものを得ていこうという経営学の一派がある
それはエンジニアにもマッチするものであるだろう
なのでそれを掘り下げていく
知識獲得の3タイプ
知識獲得
1.教えてもらう学び
教える側に負荷が集中している
会社の教育とか、先輩、後輩
2.自分で行動しての学び
だから次に必要なのは自分で行動して学んでいく
エンジニアであればプログラムを実行して、バグを直して実行してを繰り返し学んでいく
行動の結果から学ぶ
サイクルを回して学んでいく
よくあるサイクル
- PDCAサイクル
- リーンスタートアップ
- プログラマの学び方
3.知識の交換によって学ぶ
お互いに教えられる
知識の総量、分野が違うものから学び合うことができる
自分よりも知識が少ないものからも学ぶことができる
総量が少なくても違う分野を知っていてそれを交換できる
狭き門から入れ
限られた時間を大勢が学んでいるものにかけるのはもったいない
社外に交換相手を作ろう
同じ分野を勉強しているので別の情報を取れる
社外の勉強会に参加
一時的なグループでしかない
なかなか知識の交換になりにくい
知識交換のネットワークづくりをしていく
グループを作っていく
小さい非公式グループを作る
グループと聞くとイメージが大人数 それはただ目にしやすいから
質問に回答する例
人数が多いと質問者のバックグラウンドを把握して回答することが難しい
質問の文字だけ見て答える状況になってしまう
小さいグループだと質問者はあのプロジェクトをやっていたから〜ってことを使って知識の交換が円滑になる
答えられない場合
自分では答えられないけどあの人がわかるんじゃないかと紹介することができる
よく回答している人はわかるけど・・・なので小さいとそれを把握しやすくなり紹介することができる
ゲートを置く
小さいグループを作るには制限を作る
ゲートがない場合有益なら人が集まるが、得ることをするが与えることをしない
そういう人はそのグループがなくなれば次に行く
効率を考えたら仕方ない
そういう形になるとリソースを食いつぶして行ってしまう
OSSコミュニティの二重性
自由にユーザーコミュニティに入れるがコミッターには条件がある
ものを与える人のみが入れるように
グループを自分で作ろう
あなたが入ることができてしかも小さいっていうものを探すのは難しい
最初は非公式で身近な人2、3人で構わない
互恵的コミュニティにするために
まずはあなたが「与える」
Give & Take
複数のグループに所属しよう
複数のコミュニティに所属することでパイプになる
Aで知ったことをBで教えることができる
何が仲介する価値があって何が価値があるかを判断する力も鍛えられる
ググって手に入る情報を共有しても意味がない
知識交換の必須条件
周囲が持っていない知識を提供して、持っていない知識を提供してもらう
その分野の専門家には知識で負けるが多くの分野をまあまあ知っているのでその専門家と対等に情報交換をできる
技術進歩による海面上昇
ググったら手軽に入手できる知識レベルが10年前より上がった
海面が上がっている
ググって手に入らない情報を持っていたら専門性と言える
マニュアルとか見てもわからないことがあったら、それを試したことによってわかったらそれはもう専門性のある知識
それを交換に使って行くべき
それをみんなブログを書いて行くのでまた海面上昇していくので注意
トリガー
時間が経ってから価値がわかることがある
時間が経った頃に思い出せるようなトリガーを用意して置く
1年後とかに通知とかをすると、それを話題に再度コミュニティを活発化したり
与える人を可視化して、その人たちだけでコミュニティを作って濃縮化したり
多くのことは失敗する
定着までは時間がかかるので再度活発化できるようにトリガーを活用する
行動して学ぶは多くの人が経験済み、見落とされがちなのは「知識交換」
これを構築するための方法を学び作っていこう
生存戦略 技術顧問/テクニカルアドバイザーとしての生存戦略
講演者
- 是澤(元Speee)
- 及川
- 井原(ビットジャーニー)
- 岸川(Realm)
社会人1年目
及川
デックという会社で営業サポートから その後Microsoft -> Google -> Increments 今はフリーで色々な会社を手伝っている
井原
1年目はジャストシステムで三四郎というWindowsのソフトウェアを作ってきた
そのあとYahoo Japan -> CookPad -> ビットジャーニー
開発から組織を作る側に移ってきた
技術顧問の提案が来て技術顧問を開始
10数社くらいを見ている
岸川
iOSデベロッパーをしていた
今はピクシブとかを手伝ったり
iOSのアプリ開発の設計周りを手伝ったり
1社あたりの稼働
及川
3つの契約形態を設けている
- 月額ベース
- 時給ベース
- プロジェクト単位
最初は1、2ヶ月のもので契約して状態を見てから半年とかの契約にしている
井原
3ヶ月やってみて、良さそうと思ったら続ける
さっさと自分が辞められるようにしていく、自分に依存しないように
岸川
よくわからないときは3ヶ月くらいで始める
自分のメインの仕事を優先するので緊急対応などはできないということを対応している
多くて3つか4つくらいの掛け持ち
コードの相談が多くて裏を取ったり調べたり書くという試行錯誤の時間が増えるので、それ以上になるなら別の関わり方を考えなくて行けない
顧問は儲かるか
及川
結構たくさん食える
労働集約的な仕事
月額もどのくらい稼働時間か会社と決める
自分の時間を費やせばその分貰える
Googleでストックアワードがあったりするのでそれには全然足りない
肉体を酷使しても割に合わないとは考えている
井原
クックパッドで貰ったときよりも最大で5、6倍貰えた
岸川
時給換算すると高いが、案件増やしたりしてもコンテキストスイッチも大変だし自分の仕事も大変だしで苦労は多い
そういう仕事ができるならそのまま会社員でも稼げるのではと考えている
顧問に向いている人
及川
引き出しを引き出して行く
その引き出しを満たしていくことが重要
井原
何かしらやり遂げた人にその経験がある人
その知見を共有できたり、更に今はそれでいいのかということを考え学び続けられる人
出せるものもなくなっているので気をつけなくては行けない
岸川
最適解を導ける人
偏っていてはいけない
誠実であること、あまり大げさにいったりしなかったり
メンタリングやコーチの力をどうやって鍛えたか
及川
Microsoftのマネジメントトレーニングがめちゃくちゃ優秀
実際にここだけの秘密だよってことで実際の苦労話を吐露したり、実際のロールプレイを行なったり
井原
特別勉強しているわけではなく、直感になっている
なのでその感性を磨いて行く
無理して磨くなら他のことを伸ばした方がいいのではないか
岸川
エンジニアなどは各々力関係がわかるのでそこを理解して行く
開発手法、ロールプレイなどの学習の機会をどうやって作るか
及川
知り合いづてで実際の現場を見せてもらう
知識を切り売りしていない
その知識を全部持っているというわけではなく、現場と一緒に考えて行くというスタンスでやるので学ぶ場にもなる
井原
自分の言ったことが全て正しいというわけではない
同じように一緒に考えようというスタンスでやるので学ぶ機会になる
顧問受け入れる側としての体制
及川
早めに終わるところとかうまくいかないというときは問題が明確ではない
自分から提案していくというよりは状況を聞いてヒアリングしてやったりスタイルなので明確でないと困る
抽象的なように話されても無理、絶対に具体的に詳しく話さないとアドバイスできないのでNDAの契約をするので話してほしい
井原
自分が一番できると思っている社長がいると困る
エンジニアリングを信じてくれる経営陣であってほしい
経営陣の鶴の一声で決められるのはやっていけない
岸川
質問だったら困っていることなど問題設定が明確であるとありがたい
顧問とかアドバイザーをやっていて得られるもの
及川
目指してなっていたものではなく結果的になっていた
主体性を持ちづらい
結局人の会社であり人のプロダクトを作ったりになる
製品にサインするのが好きなのだがそれができない
いくつもの会社を見るのでそれぞれの知見が溜まる
井原
会社員は楽勝、安心
色々な会社を観れるのはやっぱり知見が溜まるのでいい
主体性を持って取り組めるものを心の拠り所があるといい
岸川
上記二人と同じような感じ
やっぱり会社員の方が時間はある
最後に
岸川
あまり顧問はソフトウェアエンジニアとしてのキャリアとしてはおすすめしない
けどやっぱり知らない世界を知れるのでいい
簡単なら前の会社とかを観たりとか
井原
自分からは行かない、誘われたら顧問をする
顧問として誘われるということがあるのは、そういう経験、信頼を残せたということなのでいいこと
及川
兼業でやっていくのはいい
コミュニティでの活動をするでもいい
たまたまそれが技術顧問だったりしただけ
それを目指していくのは違う
CROSS SESSION エンジニアにとっていい制度ってなんだろう？
講演者
背景
VGの背景
新規事業など若手しかいないチームがあった
ただ評価の観点で正しく評価できない背景があった
なので他の部署のエンジニアが評価する制度を作っていった
社外の人を呼んでいるのは客観的な視点をもらえることがいいことだということを浸透させ文化にしようと考えて進めている
クックパッドの背景
今は手厚い研修生度を用意していない
自分として色々やってこれたのは、何かやりたいと思った時に手助けしたり邪魔しない環境がよかったから
そういうことを会社が実現していくのがいい環境になっていくと
一押しするような環境をやってあげるようにしている
メルカリの背景
新卒の一律給与はやめた
新卒の一律給与はおかしい
中途と同じレベルで来る人もいるのでそれはおかしい
フレックス制などの制度
VG
裁量労働制
チームごとにデイリーミーティング、時間はそれぞれチームごと
朝こないことはなんで困るんだということを考え、それをチームとかで考えて振り返りを行いつつより良い方向を探って行く
ビジネス側のゴールはビジネスを成長させることと考えている方が多い
なのでエンジニアの価値の出し方を聞くとそういう働き方もあるねって話になったりする
Face to Faceの方がやっぱり生産性が高い
でも難しい
クックパッド
コアタイムなしのフレックス制度
グローバル展開して行く中でタイムゾーンが合わない
チームごとにいい時間が別なので同じ時間を設定しても意味ない
チームごとに決められるようにゆるくしている
マネジメント側としてはみんな顔を揃えていてほしい
でも開発フェーズとかは縛っていてはよくないと考えている
エンジニアだけフレックスだった時は反発があった
今は全部フレックスなので大丈夫
営業で外出が多い人とか子供がいる人にもとても役立っている
家でもセキュアに仕事できる環境を用意して、合理的に働けるようにする
リモートワーク
運用は難しいと思っている
部長に許可もらったり、家庭の事情で遠くで働かなくちゃ行けない人とかはしている人がいる
会社に来てほしいとは個人として思っている
メルカリ
フレックスタイム制
全職種共通
会議とかはなるべくコアタイムで
会社としてはリモートワークはOKとしていない
やむを得ない理由があればOKなときも
国外で開発拠点もあるので実質リモートワークではある
エンジニアの評価制度
VG
定量化は難しいと考えている
1時間半の時間に複数に関わり、更に事前資料を読み込む時間を確保して評価に取り掛かって行く
定量的なものでやるよりも柔軟性を重視しようという方向でやっている
CTOになったときスピード重視の傾向が強いと思った
テストやCIなど
その結果技術的負債が溜まっていっていた
人事からエンジニアが評価に納得いっていないという相談から始まった
最初は昇格候補者だけに評価を実施していった
そのころはトップがやっていて、結果的にいいねという話が上がって来たので全社で進めた
小さいところから始めて行くのは重要だと実感した
評価者二人が書いたレポートはGithubに上がり閲覧可能
なのでかなり真面目に書かなきゃいけない
評価者がもっといい評価したいということで参考するために公開することにした
評価されるように制度をハックするようにしてほしい
評価レポートは公開される前に全部CTOが見ている
かなり負担にはなっている
クックパッド
技術力や生産性を数値化しようというのは難しすぎて無駄
そういうことよりも他のことを
年2回部長とテックリードが評価していく
今、ヒントをあげるということを試している
評価期間が長いので5ヶ月前って何したんだっけっていうことがあった
なので毎月全員分良かったこととか通信簿みたいなものを書いている
毎月1on1をして評価に加味していく形にしている
部長などが本ににフィードバックしていく
最近は本人にすら見せない方がいいんじゃないかと思っている
馴れ合いになってしまう
仲良くしてるけど仕事できないって思ってるとか知られるのは微妙
それだったら部長だけに知らせるとかの方がいいんじゃないか
- 課題発見
- コミュニケーション
などの軸がある
メルカリ
技術の伸び幅や影響力がどう変わったかを観ている
1on1でフィードバックしていく
目的になってしまうのは嫌
All for oneという指標があり、それも評価に入るので円滑に進める力も評価に入る
社内エンジニアの教育制度
VG
ない
入って来た人にシステムやサービスの説明はする
日々の業務でレビューとかをしていく
レビューや注意をできる文化を作ることが大事
語学は必要に応じて程度の支援
事業責任者がMBAとか受けにいったり
クックパッド
ない
当たり前のものはある
最近は海外カンファレンスなど
教育で一番大事なのは機会を与えること
会社がどうやって与えるか
CTOの耳に入るようにしている
若い人は感度も高く会社から押し付けるものではない
なので自分で見つけてあとは会社が後押ししてあげる
やってるんなら支援してあげるよくらいの距離感が大事
英語などのサポートはメルカリほど手厚くはない
いちなり勉強しなければいけない環境をどうやって作るかを考えている
英語勉強したいとかいってないでいきなりブリエステルに送り込むとか
メルカリ
ない
メンターをつけてサポートしたり社内で有識者がいたりして勉強会を行ったり
知的好奇心が多い人を採用していく
新卒研修、何かのアプリを作ってリリースするとかを考えていたが、OJTで現場で働くことを検討中
英語しか話せない人も増えて来ているので語学サポートをしてきている
DMM英会話や通訳サポートの部署とか
中途入社のエンジニアに研修しているか
VG
このチームはこういうサービスでこういうシステムでやっているか
エンジニアの給料を下げたことあるか
クックパッド
下げるからプレッシャー感じてというよりはもう辞めてに近い
業界が業界なので他の会社でもやっていけるから
VG
下げたことはある
けどそこから成長していったということはなかった
部署異動などを試して見た結果下げたりするので難しい
