SOFT SKILLSで色々反省した
こんなツイートを見かけたので早速ポチって積読しといてやっと重い腰をあげて読んだ。 すぐに忘れてしまうので思いのままに自分なりにまとめてく
ブログ書いた。ここ5年でいちばんのおすすめ本。入社時給与交渉から引退までについて書かれてる"
— higepon (@HigeponJa) September 21, 2015
プログラマ向けに書かれた「Soft Skills」という本がすごいという話 - サンフランシスコではたらくソフトウェアエンジニアhttp://t.co/ByKMJs6FIU "
翻訳されたほんはこちら
- 作者: ジョン・ソンメズ,まつもとゆきひろ(解説),長尾高弘
- 出版社/メーカー: 日経BP社
- 発売日: 2016/05/20
- メディア: 単行本
- この商品を含むブログ (3件) を見る
英文はこちら
Soft Skills: The Software Developer's Life Manual
- 作者: John Z. Sonmez,Scott Hanselman,Robert C. Martin
- 出版社/メーカー: Manning Pubns Co
- 発売日: 2014/12/29
- メディア: ペーパーバック
- この商品を含むブログを見る
全体的な感想
これもネットの書評を見たとおり、プログラマー向けのビジネス書だと思う。あとは年齢なんか結局は関係ないが、20代のうちに読んでおきたかったなーと感じた
特に刺さった部分をpick up
第4章 社交術:考えているもの以上のものが必要だ
人間は非常に感情的な生き物
正しい理論を訴えてもその人との関係値があまりイイものではなければ無駄に批判されたり、思いもよらない方向へ進んでしまうので日頃の些細な関係値づくりは必要という話。ただ世の中にはどんなにこちらが頑張っても批判ばかり口にする人がいる。もしそんな人に出会ってしまったらその人に気づかせてあげよう・うまく付き合っていこうなんて思わない事だと言っている。人の人間性を変える事はそんなに簡単な事ではない。自分の為にできるだけ逃げる事も重要だと。もし直属の上司だったら移動願い、無理だったら迷わず転職を勧めていた
第10章 プロであること
正しい事をする
ソフトウェア開発者で著作家のボブ・マーティンの説明で医者を例にして説明している
患者が医者の仕事の仕方に指示をする事がバカげているのはだれでも納得できるだろうと
患者が腕がひどく痛むので切り落としてしまってくれと医者に指示しても医者は絶対「No」というしそれが正しい判断だと
でもソフトウェア開発に話を戻すと、患者と同じ立場であるクライアントや上司に断片的な情報を元にまぁいいからこの仕様で作ってくれと言われてそのまま従ってしまう技術者が多いと。怒りをかってしまうのではないか、失注してしまうのでは無いかという恐怖がある。でもプロには超えてはいけない一線があってそこは守るべきだと。当然その場では何かしらの代償を払う可能性はあるが、長いプログラマー人生を考えたときはそちらのが良いと
第18章 テクノロジーに対して頑なな態度をとるな
選択肢を制限しない
自分が選択したテクノロジーが最高だと強調して、他のすべてのテクノロジーを過小評価してはならぬ。それは最終的に自分を傷つける事になる
自分があまり良いと思っていないテクノロジーを選んで、そのテクノロジーが良いと思ってる人を探して理由なり聴いて理解に努めよう
第26章 バカにされるのを恐れるな
小さなステップを踏もう(でなければ飛び込め)
批判される事はある程度覚悟しながらも恐れずにアウトプットし続ける。恐れて何もしていない事こそ自分にとっては最も恐ろしい事だと。小さな事でもいい最初は。でもそれすらできなければ...一気に飛び込んで必死にもがいたらイイ
このくらい刺激的な言葉だと覚えやすい!!
第28章 私の10のステッププロセス
「学習 - 実践 - 学習 - 教え」(LDLT, learn-do-learn-teach)
より理解が深まり、且つチームのレベルも押し上げる
第35章 知識の中の隙間を見つける
ただ何となくでしか理解していない事やあやふやな理解のままで事が進んでいくと弱点が長期的に増えてくる
そういった隙間が多くなると効率を最大限に引き上げて仕事をすることができなくなる
メモパットを身近において、隙間を定量的に貯めていく事から始める
第45章 習慣を作る:コードを磨こう
悪い習慣に気づいて変える
新しい習慣を生み出す
自分にxxをしなければ自分にとって重要なxxができない状況・決めを作って最初はしんどいけど頑張るしかない
第48章 どんなことでも、しないよりした方がまし
動かないでいる最大の理由は恐怖
行動を取らないでいるのは駐車している車のハンドルを切るのと同じで簡単にはきれない
逆に動いている車のハンドルは切りやすい
誰でも無駄な事は避けたいし、目的に向かって一直線で進みたいと思っているけど、実は動きながら考えて色々とハンドルを切って方向転換しながら進むことは走行距離は増えるけど最短の時間で到達できるという話
第65章 心は身体にどのようにして影響を与えるか
すべては心から始まる
信念が変われば、思考も変わる
思考が変われば、言葉も変わる
言葉が変われば、行動も変わる
行動が変われば、習慣が変わる
習慣が変われば、人格も変わる
人格が変われば、運命も変わる
宗教臭い感じもするけど納得している
第70章 失敗に正面からぶつかれ
失敗と敗北は同じではなく、失敗は一時的で敗北はずっと続く。敗北は自らの意思で選んだ結果
でもなるべく失敗してもダメージが少ない場面を選ぶとより良いと思ってる
最後に
- 多少できてる部分もあればまだまだと感じた部分もあった
- 元々エンジニアだった人が書いたビジネス書のようなものなので言っている内容がスッと入ってくる
- 元々エンジニアの人が言ってるから妙な説得力がある
- アメリカのソフトウェア開発を元に書いているので日本でもそのままとはいかないと思うけど本質的な部分はまぁそうですよねという感じ
- 老害にならないように低姿勢に真摯に自分を見つめ直す時間を持てて良かった
- 色々と突っ込みたい事はあったりするんだが、この本で出てくる第4章の内容を胸に読み込んだ
chefのCHEF-3694課題をちょっと追いかけたのでメモる
インフラ関連はChefで管理していて色々とレシピを書いていてCHEF-3694というwarningが出たのでその時に調べたことをまとめておこうと思う
CHEF-3694
下記がエラーの内容
[#CHEF-3694] Resource cloning should be removed - Opscode Open Source Ticket Tracking
今はgithubに移行していて下記あたりのissueで語られている
Chef側の対応
v12.1.0からは一応スキップできるように対応されたようです
ちなみにChef 13からは根本から対応するようす
対策
- まぁwarningなので無視する運用はあり
- 色々と工夫されてる方がいらっしゃる qiita.com
- とりあえずv12.1.0以降を使っていれば、気持ち悪いけどそのまま使えるので使ってv13が出た時にversionを上げてしまう
社内勉強会で「SRECon16の紹介」をした
基本的に毎週金曜日に30分で社内のエンジニアで勉強している。 今回は自分が発表しようと思って色々とネタを探していたが、最近参加した外部の勉強会でSREConなるものを知り、色々と追いかけてみたのでその情報を共有する内容にした。
Microservices Meetup vol.2 - Tsuyoshin blog
発表資料
SRECon
所感
- 英語がもっと得意な人は自分の数倍早く、深く理解できるだろうな....
- やっぱり各社それぞれ定義が異なっていたがそれぞれ面白かった
- failure-resilient, not failure-resistantという言葉が印象的で納得感あった
- 今回の資料には出てこないけどOn-Callという言葉も自分の中では印象的であった
- 少しでも理解が進めばよいなと
- 下記はSRE関連の情報がまとまっていてとても勉強になった
- 今後もっとSREという言葉が言われるようになると思うけど、ある程度のサービスを運営するチームであれば必然と誰かがやってる状態になって、その業務領域を皆にわかるように(ちゃんと評価されるように)
SRE
というtagがつけられた感がしてる - 下記の本を読んで見ても良いかも(スイマセン自分は読んでません)
Site Reliability Engineering: How Google Runs Production Systems
- 作者: Betsy Beyer,Chris Jones,Jennifer Petoff,Niall Richard Murphy
- 出版社/メーカー: O'Reilly Media
- 発売日: 2016/03/23
- メディア: Kindle版
- この商品を含むブログを見る
Microservices Meetup vol.2
勉強会に参加させてもらったのでメモ
勉強会概要
microservices-meetup.connpass.com
発表
「マイクロサービスとSREの役割」by 鈴木@kenjiszk (株式会社FiNC)
- コンウェイの法則
- 理想形?各microsericeのチームにSREをいれるのがよい?
- SREのリソースがネックになりつつある
- SRE業務ができる人材を育てる。権限の委譲を進めながら
- 開発/SREの壁をどんどんとり払っていく
- SREももちろんコードを書く
- SREが責任を持って守るライン
- セキュリティ
- コスト管理
- スケール
- 新技術の取り組み
マイクロサービスの本やInfrastructure as Codeの話等々を踏まえて自分は、セキュリティは独立したチームを組むべきで、逆にそれ以外は各microservicesのチームに託していくべきだと思っている。
SRE(の役割)とは各microservicesのチームに含まれている部分もあれば、独立して担う役割の部分があると思ってる。当然各チームや会社によって範囲は変わってくる。
なのでマイクロサービスとSREというのはそれぞれの解釈?定義が違うので一概に語ることは難しく、FiNCさんの場合はという感じで聞いていた。
参考
マクロサービスアーキテクチャを数回読んだ - tsyoshin blog
Recruit Technologies Open Lab #03 テーマ:Infrastructure as Code に参加してきた - tsyoshin blog
「SRECon 2016 Wrap Up」by 坂本さん@takus (スマートニュース株式会社)
- Freedam & Responsibility
- どの開発者もNetflixのシステムを買わせるほどのアクセス権がある
- そこでSREの作るツールが重要になる
プロダクトを作っている感覚でSREはツールを作っていく
SRE should be a Enabler , SRE should not be a Servant
SREcon16の内容とか追っていなかったのでそこでの話などとても為になった
「マイクロにしすぎた結果がこれだよ!」by 榎本さん@mosa_siru (株式会社Gunosy)
www.slideshare.net
- AWSのsecurityグループとIAMを活用して経路自体に制限をかけてまとめた
- 全体構成が複雑が複雑になり人数いないと機能しない話
- 少人数のために各APIを管理する統合管理画面なるものを作成してその為だけのAPIを作った話
- ここまでくるとちょっと辛いし、microsericeは自立したチームでもあるので、組織構成が大切だなと
「Microservicesの実際と対策」by 大谷さん@shot6 (株式会社 ファーストリテイリング)
- swagger使ってる
- appはnodeで書くパターンが多い
- kong使ってる
- 体制が重要で。専任のスモールチームが必要
- そもそもマイクロサービスとは、すごく優秀な数名で最大限に活用するモデルがmicroservice
- 課題
- 運用面。既存の仕組みとの連携方法が難しい
- 共通的に解決しなくてはいけない課題をどう乗り越えるか?
- 答えがないのでどうやって横のつながりを増やすか
- サービス間の通信の可視化
- 依存関係の把握
- microserviceのテストの課題。dockerにすりゃ済む話ではない。10個以上docker立ち上げられないよローカルで
ウェルネスタイム (大好評、FiNCトレーナーによるストレッチタイム)
- タバタトレーニング
- しんどかった。勉強会で筋肉痛になったの初めて
「より良いAPIを作るために」by 相川さん@awakia (ウォンテッドリー株式会社)
- 最初からHerokuを使っていてその後、Dockerへ移行
- 2002年にamazonの社長だした司令の話
Kong使ってる事例を初めてみたけど、使ってる感じどうなのかなぁ?って思ってる。ざっくり聞きたいな
最後まとめ的な
Coveを試してみた
Coveって?
要は会社のOKR、チームのOKR、個人のOKRを便利に管理するツールです。
ざっくり特徴とか
日報的に毎日進捗等を記したり、進捗N%と更新することで定量的なレポートが見えるので管理がしやすくなる。
- そのレポートをメールで飛ばされる。チームのObjectiveはチーム全員へメールされると思われる
Key Resultの部分でTO-DOSを登録できたりする
OKRのマップ(視覚化)
感想やら雑感
- 目標に対する進捗なるものの管理はすでにあったりして、もし導入するならそれを置き換えるイメージになると思う。
- 追加でこのツールも導入とか考えると、ダブル管理の部分が出てくるし、手間でしかなくなる気がする
- ちゃんと使いこなす文化ができれば、あまり関わりの無い部署のOKRの進捗が簡単にみれたりする(OKR Map)でのその点は良いと思う
- エンジニアでは無い人は使いこなせるかは、んー
- 結局ある特定の人、チームだけが使いこなしていても他の人達が分からなかったり、伝わらなければ仕事の透明性を欠き色々と問題が噴出してくるのは変わらないと思う
- 少し前にプロジェクトの見取り図なるものを教えてもらって作って運用してるけど、他部署の人への伝わってる感はそれなりに感じている
PMについて思った事
元ネタは下記の動画をみて、自分的に思った点やメモを残す
まずはPMとは
- ここで言っているのはプロジェクトマネージャでは無く、プロダクトマネージャ である
- この辺りは色々な所で違いを定義したり、言われたりするけど個人的には下記の文がしっくりきている
プロダクトマネージャ
プロダクトの課題の解決に向けて技術的なアプローチも含めどうやって実現していくかに責任をもつ
プロジェクトマネージャ
品質であったり、開発コスト、スケジュールに責任をもつ。
補足等々
- パッケージソフトが主流だった頃を考えるとプロジェクトマネージャの立ち位置はわかりやすいと思う。
- webやアプリでサービスを継続的にスピード感持って提供していく上ではプロダクトマネージャがより重要になってきると思う
- プロダクトマネージャには技術的な理解や手法の習得がとても重要でほとんどエンジニアのような存在だったりする
- プロダクトマネージャの部下はエンジニアではなく、お互いに対等なレイヤーなので、指示等は基本存在しない
- なんでお互いの信頼関係がとても重要
- でも実際はプロダクトマネージャがリードしていくパターンが多く、エンジニアをリードするにはエンジニアリングもスーパーな人でないと厳しい気がする
Product Manager vs Project Managerでもひと記事いけそう...
さて本題. PM(プロジェクトマネージャ)の役割に関して
結局は全社でCross Functional TeamになるんだけどPM(プロジェクトマネージャ)とEngineerは両輪になるし、密に連携しながら進めなければいけない。なので重要なPMとEngineerの役割をピックアップする
PM(プロジェクトマネージャ)
- 「What」「When」「Why」をしっかり定義して押し進める。
- PRD:Product Requirements Documenを主に活用していく
- プロダクトの課題の解決に向けて技術的なアプローチも含めどうやって実現していくか (2回目記載)
- OKR
Engineer
- 「What」「When」「Why」で決まった方針に関して「How」どのように実装していくかを担当していく
- Design Doc
memoやら
- 「How」の実装方法はEngineerのリスペクトにつながるのでPMは基本的に関与しない
- ただ、Engineerのただ試してみたいという意向だけでselectされたオーバーアーキテクチャには注意が必要だなとおもった
- そこまでやる必要ある?ってスタートアップではよくある話で....
- 「How」の実装方法はEngineerに託すが、PMは内容に関してはしっかりコードレベルで理解していかないとキツいと思う。
- PRD:Product Requirements Documenは重要で工期の終盤、リリースを優先する場合は機能を削減しなければいけない場合がある
- その時に方針をブレずに判断する為に必要
参考
- Servant leadership - Wikipedia, the free encyclopedia
- job-descriptions/product_manager.ja.md at master · increments/job-descriptions · GitHub
- OKR (目標と主な結果) – 前田ヒロ
- OKR:組織内のコミュニケーション効率化と重要なゴールへの集中を促すシステム - yaotti's diary
- Design Docの例:WebKit WebSocket design doc - Google ドキュメント
最後
主にKPIの所からPRDに落とし込んでOKRを設定して開発を進めるが、当然それだけだと全く楽しくないし、それだけでは不十分。思ってもみなかった不具合やユーザの反応を見ての改善=ボトムアップで出てくる改善の開発も入れながらバランスを取ってやっていく事が重要だなと思う。
ひとえにPMといってもプロダクトマネージャなのかプロジェクトマネージャを指してるのか曖昧になってる事がよくあると思う。スタートアップでは両方の役割を一人がこなす事が多いから問題にならないけど、違う事を理解しておかないとスケールした時に色々と問題が生じる
作るプロダクトによる(B2B向け?B2C向け?)けどプロダクトマネージャはほぼengineerと同程度のテックは必要だと思ってる。 日本でよくいる技術的な事が分からないディレクターやプロデューサーとは全然別ものなんだけど、彼らにプロダクトマネージャの役割を担わせようとしてる事が多い気がする。当然無理が生じる。結局はengineerの誰かが補ってるパターンが多い。
別にテックが無いディレクターやプロデューサーを批判しているわけではない。仕事を通してスキルを身につけていく事は普通だけど、例えば経済を学ぶ学生アルバイトに弁護士試験をパスしていてと言っているぐらい、別物で難易度が高いもを担わせようとしているような感じ?かな。もっとイイ例えがありそうだけど。
プロダクトマネージャと言うものをちゃんと理解してテックのバックボーンがある人間が担っていく事が理想だけど、なかなかそういう人っていないよなーって思うし、社内から生み出していかないといけないだろうなーと思う。
とにかくそれぞれの役割の違いをみんなで理解するところかな。ちなみに動画でも言っていたけどそれぞれの役割とラップする部分は多くあるのでオーバーラップは当然ある。重要なのはどこに軸足を置いてるかと
Habitat Meetup #1 に参加してきた
勉強会に参加させてもらったのでその時のメモやら
勉強会概要
発表
Habitatとは? Chef Software, Inc. Alex Vinyar
- Habitatを含むChef Automationのお話
- Chef Automate – Embrace DevOps | Chef
- Chef Automationのポイントは下記3つ
- Visibility
- Workflow
- Compliance
- Chef Automationの概要図は下記の図がわかりやすい(本家から)
感想
今、Chef,Rubocop, Foodcriticを使ってレシピかいてServerSpecで担保してってやってるけどこれらをChef内で完結できるとより良いエコシステムになるしビジュアライズはステキだなと感じた。 githubのPRのような人によるレビューをするワークフローが存在していた。
関連情報
Foodcritic - A lint tool for your Chef cookbooks
Habitat考察(仮) 高石諒(@r_takaishi)
- Chefがデータセンターの自動化なら、Habitatはアプリの自動化というお話
- HabitatはRustで書かれているらしい
- HatbitatはInfrastructure as Codeの分類で言う所のinfractures serviceに属するお話
- Infrastructure as Code の分類の話は関連情報で
- Habitatの特徴としては
package
とsupervior
がある - どういったアーキテクチャで動いているかや他のプラットフォームでも動く点など
- docker上でもいける
- 実際のデモ
関連情報
Infrastructure as Code のこれまでとこれから/Infrastructure as Code // Speaker Deck
ChefConf2016参加レポート クリエーションライン株式会社 鈴木逸平
VP of EngineerのSeth FalconのKeynote
@r_takaishiさんがデモしてくれた内容やChef Automationに関しての話が中心
CEOのBarry CristのKeynote
Chef Automationの話はあるが、注目すべきポイントは下記
slowness kills
ビジネスアイディアとshipingはという要素は重要で良いアイディアはあるけど実際にshippingできたのは2年後といったものではもはや遅すぎる。 たとえどんな素晴らしいアイディアであっても遅いと全てが無くなってしまうという話。Amazonなどのサービスがなぜ良いか、当たり前のサービスを迅速にユーザにshippingし続けているからだ!!と
ここではShippingまでのスピードといってるけど、サーバのレスポンスだったり、カスタマーサポートのレスポンスだったりのスピードも同じだと思っている
ideas = easy
アイディアを出すのは簡単。shippingをどれだけ迅速にできるかが重要。shippingまで至るまでにはどうやって実現するかや乗り越えるべき障壁は色々とあるだろうが、結局はshippingできてからの話
まとめ的なもの
- Chefの製品は自分が3年前に見た時よりかなり変わってて、Chef内で完結するような製品群になってきているなと
- 日本だとServerSpecとかがあってそれなりに定着してる感あるのでInspecとかはどうかなと思ってる
- Inspecの書き方や動作はServerSpecそのままのように見えた
- Habitatも各デプロイツール+Dockerとかという部分とかぶる気がするけど、Supervisorやクラスタ機能は手軽感あったので今よりは良いのかな
- visualizeの機能は可視化は重要なので今までに無い機能でよいなと思った
- ChefConf2016のKeynoteを聞いた。英語全然得意じゃ無いけど雰囲気わかった
slowness kills
の話は本当にそうだし、実現するには色々な壁があるけど、重要性をずっと説いていくことは意味あることだと認識した- 同じことを事ある後に言い続けるのはツライけどそれだけ価値があることだと思った
- 自分は不得意です
- 今回の勉強回に参加させてもらって改めて思ったのは、その先にあるProductivityやDevOpsの話に必然的に繋がって、どう事業を成長させるかという感じになって深くなっていく。
- そして本当のObjectiveにぶつかる
お疲れさまでした