エンジニアのキャリアを考える
はじめに
取り留めのない雑記で、個人的な頭のダンプのために書いたものです。 また、私の理解で整理をしているため定義が異なるなどありますが、そちらはご了承ください。
だいたい書こうと思っている事 エンジニアとしてどういう道があるのか、自分がどうしたいと思っているのかを中心に書いてます。
一応自分の立場でいうと、2018年度頭あたりから新規エンジニアチームの中で一番歴が長かった事と、元々SREやDevOpsなど開発チームの文化作りに興味があった事もあり、半分開発半分エンジニアリングマネージャー（EM）的な事を行っていたのが、最近はマネージャーとしてチーム運営（ピープルマネージメント）を中心に行なっています。
CTO とか VPoE とか
上記の通り業務を行なって来た事で、自分がどこを目指したら良いのか、またピープルマネージメントを行う上でどういうキャリアを考える機会が多くなり、個人的に気になってCTOとかVPoEって何だろうかなど私なりに整理しているモノです。
まず、調べてみるとよく出て来たのが次の4つの役割「CTO, CISO, VPoE, VPoP」それぞれの役割としては、
- CTOは組織に置ける最高技術責任者として、高い技術力を持ってテクノロジーの方針を決める人
- CISOは組織に置ける最高セキュリティ責任者として、セキュリティ全般の方向性を決める人
- VPoEはエンジニアチーム育成や採用・組織設計などを担い、人の生産性を最大化をする人
- VPoPはプロダクトの責任をもち、短中期的にプロダクトの方向性を決めていく人 注) 組織の大きさによってこの分割ができないことは十分に理解しております。
ざっくりと言うとエンジニアとしていくのにはこの4つしかなく、技術を極めていくのか、セキュリティをリードしていくのか、そこだけじゃなく組織やプロダクトの方向性を決めたいかが重要なキャリアのポイントだと考えてます。
ただ、この4つがあるからといって、誰もがどれかにならないといけないと言うことではないし、全員がなれるわけではないです。これらに対してどのぐらいずつ割り振るかとか、どのぐらい興味があるかは自分と対話して理解しておくといいと思う。
私の場合だと今はこんな感じだなと思う。 - 技術マネジメント力 : 5 (メンバーに任せてる） - セキュリティマネジメント力 : 20 (チームで持ってるプロダクトに対して） - チームや組織のマネジメント力 : 60 - プロダクトのマネジメント力 : 15
ちなみに、実際にエンジニアリングマネージャーとして、チームマネジメントなどにやってみて思うのはチームの組織力をあげる事や個々人のモチベーションをコントロールする事などは面白い仕事だなと思っているし、この先にあるものをみてみたい。
何かいい発見があれば、どこかでまとめようと思います。
考えてる時に読んだ記事など
思い出したら追加していきます。
マネジメントは「役割」。CTO・VPoE・VPoPが3頭分立する、Gunosyのエンジニア組織 | SELECK [セレック] CTO・VPoEたちが語る、20年後もエンジニアとして生き残るために必要なこと - ログミーTech
SRE読書会をやってました
ちょっと時間があいてしまったが、今年の1月から7月にかけて、SREの読書会を行っていました。
注意）SRE自体がどうだったかというと話は特に書いてません！
なぜ読書会をしたのか
もうこの本が出てからするとだいぶ経ってしまって今更ですが、 SREとはGoogleから生まれてきた「Site Reliability Engineering」の略称で自社サイトの信頼性向上を目的としたエンジニアリングを行うこと。実際にここ数年の変化をみていると、webサイトを作るだけなら誰でもができてしまうし、それをサポートする形で言語もインフラとしてのクラウドも進化していると感じている。
そういう環境変化の中で、
- より早くより安定して、かつよりスケールするシステムをどう作って行ったらいいんだろうか？
- 自分たちが考えてるものが通じるのだろうか？
などの疑問を確認するために、この本を読もうと思いました。
また、正直この本は分厚くて一人で読んでいると理解するのも時間がかかるし、読みきれる自信がなかったので読書会を実施してみたものです。
どんな読書会をしていたのか
読書会を行う時に考えたのは、自分が無理しないことです。コミュニティとか運営するには結構な体力がいると思います。人が来なかったらどうするかなども含めて不安もあるのですが、まあ人がいなくなったら一人で読もうぐらいの気持ちではじめました。
読書会の個人的な分類
今回どんな読書会を実施したかのために、私の読書会を分類を出すと
読んでくるか集まって読む と 講義を聞くか議論するの組み合わせになると思う
読んで来て、講義を聞く これは事前に読む範囲を決めておいて、その範囲を事前に担当を決めた人がまとめて紹介するなど輪読会的な読書会です。
メリットは、事前に読んでくるので短時間かつ短期間で進めることができる。
デメリットは、講義を聞くだけなので実際に読んでなくても良いので、本を読みきったという実感がなくても良い。 あと自分の担当の時に休みにくいという点もある読んで来て、議論する これも事前に読書してくるのは同じだが、議論として自分が感じた疑問や気になった点をお互いに話すことで理解を含めるものです。 メリットは、事前に読んでくるので毎回集まる時間は短時間でも十分に進めることができる。
デメリットは、事前に読んで来ないと話が進まず、少人数で読書会を実施していると誰かが読んで来ないだけで開催が難しくなると思います。集まって読んで、講義を聞く これは事前に本を読むのではなく、集まってから決められた範囲を読み、そのあと講義を聞くものです。
やり方は様々あり、担当決めておいてその人が講義をする場合や、詳しい人が解説する場合などもあると思う。
メリットは集まって読むので、確実に参加すれば読むことができる。 デメリットは、詳しい人や講義できる人がいないとなかなか深い理解につながらない場合があるのと、集まってから読むので時間がかなり必要となる集まって読んで、議論する これも集まってから決められた範囲を読み、そのあとは講義ではなく議論をするものです。
メリットは集まって読むので、どの回でも参加すれば何を話すのか理解する時間が取れる。
デメリットは理解を深めるために議論が必要なのでファシリテーターが重要だったり、最低3人ぐらいいないと話に広がりがなくなると思う。
今回実施した方法
今回実施した方法は、「集まって読んで、議論する」方法でした。
毎回決めた1・2章を読んで、その場で感じた疑問や気になった事から話、実際の自分たちだったらどういうアプローチが出来るかを話しました。
- 集合時間から60分間は自由に読書会を実施
- 読み終わった人は、slackに読み終わった事を記述する
- 全員読み終わったら最低30分間の枠で議論する
という方法をとりました。
やってどうだったのか
何とかSRE本のだいたいを読むことができたと思います。だいたいというのは、1部・2部・4部は読んだのですが、Googleが実践した3部については一部読んでないところがあります。読んでないのも自分たちが知っていても現状経験がなく議論が難しいスケールの話が出て来たので、その辺を除いた感じです。
SRE自体を理解したいのであれば、特に2部を読めばいいと思いますし、4部を合わせて読むとどうやってそれを広げるかがわかると思います。
運営自体で苦労したのは場所取りです。今回はYahooのLodgeを予約して使いましたが、こういう読書会をするにはある程度のスペースがあり、ホワイトボードがある場所を定常的に借りれると楽でいいなと思いました。（夜中に予約するの大変ですよね）
ただ実際にこういう読書会を運営してみて思ったのは、確実に一人で読むよりも途中で諦めることはないと思いました。仲間がいることで、取り組み方が変わりますし継続しやすくなるものだと思います。また、こういう重い本だと自分だけの視点だと理解できないものや、現状どうなってるのかわからないものも多くあるので、チームや同じ会社の人と集まって実施すると、良い気づきが得られると思います。
今後も何か同じ課題を持ってる人がいたら、集まって読書会やハンズオンのあるようなものは続けていければと考えてます。
読んだ感想
SRE自体がどうだったかというと、「エラーバジェット」「トイル」「SLO」など真似してみたい考えなどはあるが、これを今の自分が実践するためには足りてないものとしてメトリクスをどう取るかだという理解をしました。
手段はなんでも良いのだけど、自分たちの現状を客観的に理解できる可視化がないと、そもそもこういう活動を取り組むことは難しく、また必要性を話すことは難しいものだと思います。何がボトルネックになるのか、例えば新機能を出す時には企画決定のための不要な議論の時間かもしれないし、セキュリティ対応かもしれないのだけども、そういうことも含めてサービスのパフォーマンスをユーザ視点で計測したり、提供してるサービスのSLOとして計測したりができていないと、不満はあれど改善活動ができないのは変わらないなと感じたものだったので、まずはどうやって自分達のチームの状態やプロダクトの状態を計測するのか試したいと思ったものでした。
最近は社内ではあるが、この辺の読書会を実施しています。
また、個人的にはこの辺読んでます。
どこかで、この辺読んで思ったことまとめたいなと考えてる次第です。
【de:code2016】黒船襲来で夜明けはあるのか？
書こう書こうと思いつつ早９ヶ月！ 今度こそ何かアウトプットをということで書き続けます（月１ぐらい）
MS主催の技術イベントde:codeに参加してきました。 de:code (decode) 2016 ｜ 日本マイクロソフトの開発者/アーキテクト/IT Pro 向けイベント - Microsoft Events & Seminars
MS主催というだけのことはあって、当然MS製品が中心ですがそれだけではない部分も多かった。 特に「DevOpsの黒船がやってきた！」というセッションを中心にDevOps周りのセッションは本当に良いセッションでした。
詳細を知りたい方は、MSエバンジェリストのメソッド屋のブログや#decode16あたりを見ると良いと思う simplearchitect.hatenablog.com （一次ソースを見るのは大切）
セッションとは別に、印象を受けたのは昨今テクノロジーのTop企業の注力点が 技術の囲い込みから、Open化に寄っているという部分。（ここには色々な考えがあると思う） 結局はクローズドな技術だけでは世の中とのギャップが生まれるので、 要となるところは公開しコラボレーションが重要となるし、 １人ですべてやるのではなく得意な人が集まり、よりよいものを作り出すという流れになっているということ。
特にワンクリックで世界中に自動的に公開されるクラウドができたりと、 劇的な変化が起きてる今だからこそこの流れは強いのだと思う。（これはappleもgoogleも同じなのだろう）
さて、話はかわりDevOpsについて見てきた事と感じたことを書いておく
まずはじめに伝えないといけないのは、 「日本のソフトウェア開発は鎖国状態である」
ちょんまげという、ウォータフォールで揃え エクセル方眼紙という刀を振るい 着物の代わりにスーツを着る
これは本当に感じる。 何気ない作業の中でも時代の変化を受け入れられず、 丁寧なつもりで全く内容のないことをしていることをよく見かける。 たぶん人に感じてるなら、私もそんなことをしているのだと思う。
その原因が何かはちゃんと考えたことがないが、 １つはサービスを作るのに、関係者が多すぎるためだろう。 それは、Amazonの2pizzaチームでもないし、MSのアジャイル導入で示した8-10名ぐらいのチームでもないということ。
このスモールチームで行動し、企画からリリースまでのサイクルを回せないデメリットはなにか。 人が増えれば、決めごとに調整が必要になったりと時間がかかりサイクルのボトルネックが出てくる。 複数の部署やチームをまたいで１つのプロダクトを作成するとなると、チーム間のコミュニケーションや調整にボトルネックが発生する。 などなど、少し考えても色々出てくる。
結局最適なサイズでサービスを提供し、継続的に良くしていくのに適した人数が８人（互いの状態が把握できる）なのだろう
サービスを届けることを考えるとどうだろうか。 サービスは世の中に与える変化であり、その変化は事前に仮設を立て創りだしたプロダクトの結果である。
つまり、仮説と結果があるなら検証しないといけない！ この検証なしにはサービスは作れないのは今までと何ら変わってない。
そこに加えて今起きてる流れは何か？ クラウド化によりインフラというコントロールが難しくスケールなどに時間がかかるものが抽象化された。 自動化環境が増えたことで、開発サイクルが早くなっている。
つまり、仮説と検証のサイクルを早く回すことが可能となり、それが求められる世界。 それがDevOpsなのだろう。
言うなれば、「正しく計測し、試行錯誤と変化を繰り返す世界」
何となく思いつきの施策を立てて、リリースするなんて企画は不要となるし 技術変化を受け入れ対応できないエンジニアも不要となるだろう
そんなことを感じ取った。
これらを実現するツールとして黒船が襲来してきた！ というのが黒船というセッションだった
何が黒船か？
HashiCorp, Jenkins, Chef, Mesosphereというそれぞれの特性が開発サイクルの高速化に繋がると言いたいのだろう。
個人として言えば、どのツールがベストなのかは別にして インフラのコード化であったり、自動化は必須条件（十分条件ではない）になっていると感じてるので ここができてない所にいたら１年ぐらいで置いてきぼりとなり、使えなくなるのだと思う。。。
この黒船襲来にどう対応するのか、今後のエンジニアとしての活動に影響するものとなるのか反芻しておきたい。。。
その他気になったキーワード
- 「Software driven as Future」
- 「Our industry does not respect tradition - it only respect innovation」
- 「Conversations as a platform」
最後に何となく書いておく。
「What is DevOps for you ?」 こんな質問があったらなんと答えるだろうか。 きっと私は「効率的に試行錯誤を回せる環境と文化」と答える
「can you make DevOps culture？」 たぶん、１人では難しい。でもやるために変化を取り入れていく自信はあるし、 変化を楽しんでいく。 そう答えると思う
忘れていた！ これからDevOpsを日本で取り組む方へ！ テンション上げていかないと辛いですよｗ
【DevOps】DevOpsハッカソンはハンズオンだった
DevOpsハッカソン
MS主催のDevOpsハッカソンへ参加した。
DevOps Hackathon (English - 通訳あり)
まずはじめに感じたのは、この空間で濃密な２日間はなかなか味わえない環境だと思う
開催していただいた、牛尾さん、Davidさんに感謝します
だいたいのまとめ
ファシリテーターなど
参加人数：30名
急いでる人は、ここと #devopsjp あたりを見ると良いと思います。
- DevOpsプリンスの登場
- DevOpsの文脈を再確認（資料良かった!）
- ノリノリの英語発表
- Azureを使ったデプロイチェーンのデモ（infrastructure as code的なの）
- アイディア発表（わりと英語）
- AzureとVSOのハンズオン（ここ本質的なのではない）
- 日本人率80%ぐらいだが、全体発表の公用語は英語（同時翻訳わかりやすい！）
- Azureを初めて触ってるがために、ほとんどハンズオン状態で終わってしまった
- AzureとVSOを繋げることで、だいたい今やりたいであろう開発フローは実現できそう
サンプルコード
VSO
新Azure Manager
旧Azure Maneger
このまとめ書くのに調べていて気がついたけど
大元の募集要項があった。： blogs.msdn.com
なぜ参加したのか
きっかけはこんなところ
- 最近文脈として、DevOpsに興味があること
- ここ1年ぐらいの業務などではUTだったりTFDに近いことができてきている（TDDではない）
- 社内のシステムは知ってるけど、世の中はあまり知らない（井の中の蛙）
- 面白いイベントあるよと唆された
参加して得たいもの
- 世の中の文脈としてDevOpsがどんな認知なのだろうか
- 自分が思うDevOpsと何が違うのか
- そもそも、DevOpsハッカソンとか、よくわからないモノをどうやるのか
- 知識のインプットだけではなくアウトプットしきたい
だいたい、この辺が参加したきっかけと興味関心
能力的にはWebのバックエンドAPI作っているゆるふわエンジニアだったりします
全体のながれ
day1
- DevOpsの説明
- VSO & Azureでのデプロイチェーン全般の紹介
- アイディア出し&チームビルディング
- ハッカソン開始（ほぼAzure & VSOと戯れる）
day2
- アイスブレイク
- タスクボード作ってみる（状況共有ツールの紹介 この辺がDevOps的なところ）
- ハッカソン後半戦
- 発表
ハッカソン自体は、12時〜18時 + 9時〜15時なので、だいたい12時間ぐらいのもの
DevOpsとは何か
個人の理解として、DevOpsはツールと文化のコラボレーションだ
カンバンや、CIツールや、Deployチェーンがあることは大切なことだが
それがあるだけでは意味がない
これらを活用するチームメンバーである企画・開発・運用などが、
ユーザーにより良いものを届けたいという共通のVisionを持ち、
互いを尊重しながら推し進める事も重要な要素となる
互いを理解せずに進めていては、遠回りをしてしまいうまくいかないのだ
（セクショナリズムをなくし、コラボレーションを大切にする）
今回参加してみて感じた事は何か
とにかく２日間AzureとVSOと戯れ続けて終わってしまった。。。
チームの皆さんには何も力になれてない気がして申し訳なかったです
成果物自体も、ハッカソン自体のものとしてはなく
初めて触ったwindowsサーバーとAzureとVSOについて、理解が深まったのと
このハッカソンが記念すべき第一回目だからこそ経験できる
産みの苦しみを感じられました
また、コミュニケーションの難しさを改めて感じた
特に分野の違う人々が集まり、DevOpsという同じ土俵で話をしても
その堅牢さなどは変わってくると感じた
ここの認識を揃えることに注力できなかったかもなと思う
そのほか振り返ってみると
よかった事
- Azure / VSOと普段触れない世界に触れられた事
これは一つ触ってみたいと思っていたので良かった - 様々な人のDevOpsの考えを聞けた事
- それらの人の中で広めようと思っている方は、みんな同様に産みの苦しみを感じてる事を体感できた
- 座学ではなく手を動かし実践できたこと
個人的には癖はあるのだろうと思うが、AzureとVSOがコラボすることで
タスク管理や実装コードの管理、またCI/CDという流れ全般が活用できるのはすごい良かった
これもっと事前に慣れていれば、色々できたのかもしれない
（とはいえ、ゆるふわエンジニアなので出来ないと思う）
それと、最近知識ばかりでちゃんと手を動かしてないなと思っている自分にはとても良い機会でした
実際知識としてDevOpsを知っていても体験してみないと
初期構築の難しさやCIするための苦労などって分からないと思う
できる人には当たり前でも、やっていない人には遥か彼方の地平線のようなものは沢山あるってこと
悪かった事
特に失敗したなと思ったのは、
最初の時点でチームの能力の把握とミニマムなトライを定義しなかったこと
これって難しいんだけど、おそらく初めて会う人同士でチームビルディングなら
絶対に必須の事なのだと思う。
そうすることで、皆の得意分野がみえて、アウトプットが出しやすくなる
エンジニアって不幸なことに、結構一度やったことをやらないし（そうでもないのか？）
人は初めてのものに触れるとき、悩んでしまって動かないもの
そうすると、チームとして誰も触ったことがなくても
その中に知識がありそうな人にすがり動かなくなるのだと思う
なんとなく、誰かがやってくれそうという思いのデットロックがかかるのだろうか
次回参加するならどうする
１つ目 良かったことはさらに伸ばしたい
普段とは違うツールに触れ考え動かしてみるという機会を作るのは中々難しい
例えば、jenkinsを普段使っていてVSO使ったらどうなるのかなんてのは、
やってみないとわからないしどちらが良いかの比較もできない
こういう機会は今後も作っていきたいし
また、DevOpsというプラクティスは範囲が広く全てを短い期間で感じることができる
環境は本当に少ないと思っている（もしこれが普段から体験できてるなら、すごい恵まれた環境だ）
そういうのと戯れられるというのも良いinputになると思う
2つ目 悪かったことは直したい
ツールにこだわってしまったり、壮大な夢を見てしまったり
あまりDevOps的な展開を行うことができなかったなと思う
例えば、誰か環境整備が得意な人がセットアップツールを作り展開するとか
早めにデプロイチェーンを動かして、失敗を早い段階で検知する環境を作っておくとか
ミニマムに動く状態を整備するとか
デプロイ自体をテスト駆動的に作る（始めは動かないデプロイチェーンを作るが、徐々に動いていくみたいな）
なんか、こうもっと開発初期からデプロイまでの流れ全体を最適化するような方法を考えられればよかったなと
特に、機械系や医療系やフリーやwebなど様々な分野の人が集まれば考え方も違うわけだし
その辺のバランスを取れれば良かったのだろう
また、運営の皆さまへ
ある程度事前にサンプルコードや流れを告知しておいていただけると助かりました
（してあったけど、くみ取れてなかったです）
せっかくAzureあるので、とりあえずVM作ればOKみたいな環境あると
とっつきやすいのかもと思っています
どうぞよろしくお願いします
最後に
セミナーなんかも一種のプロダクトなので、昨日今日のデプロイ結果を計測して
次回サービスに反映されることを期待してます
また、DevOps、CI/CD、ユニットテストこの辺の文脈に興味がある人
触れてみたい人は是非参加してみるといいと思います!
２日間で質の良いInputが得られると思います
