今のチームで自分が貢献できること、貢献していきたいこと

はじめに

ふと思いついたテーマ。

自分の実力、技術がオープンに評価されることがもっとも望ましいことではあるけど、それが必ずしもオープンで、ワールドワイドな評価でなくてもいいと思う。仕事をしていく上で、自分が今いるチームでどんな価値が発揮できるか、自分の得意なところなどこなのかを自覚しておくことは大切だと思い、書き記しておく。

チーム内で自分が相対的に優れていると思うこと

最新技術動向のキャッチアップとアウトプット

1人化け物みたいなひとがいるのですが、それは置いておいて、定期的にmenthas.comさんを見ていること、Twitterの技術アカウントのタイムラインを見ていること、後述しますが社外勉強会に参加していることから、少なくとも語彙という意味で最新技術情報は知っているほうです。

1人化け物*1みたいなひとがいるので、そのひとに食らいついていきたい。

CI/CDまわりのツール・フレームワークの技術知識

前のチームでそれら専任チームをリードしていたので当たり前といえば当たり前ですが、チーム内では教えることができる立場にいます。

そもそもgit(github flow)の使い方からあやしいひともいるので、gitというツールの使い方からサポートしています。

具体的には以下のような感じ

• git
• gitlab
• gitlab-ci
• jenkins
• ansible
• capistrano
• serverspec

OSSの構築とチーム内導入

自由に使える仮想環境とIPアドレスを持っていることもあり、これまで様々なOSSを持ってきては試してみる、ということをやってきました。

• phpipam
• minio
• mattermost
• jenkins
• knowledge
• etherpad

自分で探して使ってみる、ということもありますが、「これ便利だから使いたいなー」という声を聞いて立ち上げた例もあります。Webアプリケーションの構築、セットアップ、導入をスピード感を持ってできる点は優れていると思います。

仕組み変えるための提案能力

何か仕組みを変えるための説明資料の作成と、説明して変更、受け入れてもらうプロセスを素早くやることができます。

これも前の仕事で開発プロセスのルール変更を外側からやった経験もあることと、様々なツールを導入して展開した経験も相まって、使ってみる、試してみる、誰もが使えるようにする、ということは得意です。

また、必要であれば図示して公開、ひとを集めて説明することで、これは何のために、どうやって使うのかを説明し、すぐに使える体制にすることができます。使ってみてのフォローまで行ってきました。

新しいテクノロジーの導入であったり、課題を仕組みから解決することを任されると、結構楽しくやれますね。

チームのパフォーマンス向上

マインドの問題ですが、誰よりも属人化を嫌っているので、チーム全体としての底上げは常に意識しています。勉強会のリードしたり、自分ができることをあえて別のひとにやってもらってフォローすることで、全員がいろんなことをできるように、じわじわ少しずつ広がっていくような仕掛けを出しています。

チーム内で自分が相対的に劣っていること

もちろん劣っていることはたくさんあります。詳細にはあげませんが、以下。

• Pythonのコーディングスキル
• OpenStackの内部ロジックの知識
• データベースのパフォーマンスチューニング
• オープンソースコミュニティへのコントリビューション

これらはこれから伸ばしていかないといけない部分です。

得意なことと活かしてチームにどう貢献するか

今のチームには僕は途中からJOINしているのと、外側から関わってきたという背景があります。メンバーの大半は長く同じチームに在籍しているひとが多いです。

チームを底上げすること、自動化まわりの技術をリードできること、仕組みの変更を得意としていることから、1つの技術開発をどっぷりやるというよりは、全体最適のための改善をリードしていく立場をやりたいです。

途中からJOINした自分だから見えることがあるので、現在の自分の案件を持ちつつ、広い視点を持って、細かい改善から大きな仕組み変更まで、できるだけ多くやっていきたいです。

ただし、改善というのは、「したらうれしいけどしなくてもしなない」こと。自分の案件も持っていて改善だけやっていればいいわけではないので、コミットが難しいのが難点。

いかに日頃の業務スピードをあげて、改善に時間が割けるかが鍵だと思います。

やりたいと思ってる改善は以下

• MS WORDの撤廃、すべてのドキュメントをgit差分管理可能な状態にする
• 上記のためドキュメントCI環境構築
• configのgit管理と、適用自動化
• ドキュメント開発へMRによるレビュープロセス導入
• 開発環境のモニタリングとインシデント事前予防

まとめ

オープンな技術で、会社を超えて広い世界で評価される技術をつけることも大切ですし、今後発信も行っていきたいですが、今自分が働いてるチーム内という小さな世界でも自分の立ち位置、価値、そしてどう貢献していくかを考え、周囲にコミットしていくことも大切だと思いやってみました。頑張るぞ！

*1:あなたいつその情報仕入れてるの、みたいな物量と深さのあるネタを週一でメーリスに投げてくるひとがいる

「エンジニアのための文章術再入門講座」を読んでドキュメント作成スキルの振り返りをする

はじめに

良いドキュメントを書くことはエンジニアのたしなみ。ということで定期的に自身のドキュメントスキルの見直しを行っています。

エンジニアのための文章術再入門講座

ドキュメントといえば結城先生の数学文章作法もおすすめ。

数学文章作法 基礎編 (ちくま学芸文庫)

数学文章作法 推敲編 (ちくま学芸文庫)

で、この"エンジニアのための文章術再入門講座"なんですが、各章ごとにエッセンスを紹介して、そのあと具体例を用いて悪い文章を良い文章に直す、というスタイルで進んでいきます。ただ、この例がかなり自分にとってはしっくりこず、本当にこんなドキュメントわざわざ書くやつおるんかいな、と思うシーンがほとんどで、僕はエンジニアのはずなのにおかしいなぁと思ってしまいました。

とはいえ、書いてある観点そのものは正しいと思うので、その点にしぼって振り返りをしてみます。

エンジニアにとってのドキュメント

その前に、エンジニアにとってなぜドキュメントスキルが必要か、ということを再認識しておきましょう。

本書でも一章で、ドキュメントはエンジニアのスキルを表すということが言及されていますが、信頼できる文章を書くことで技術的にも期待されるという面は確かにあると思います。

私は本書の例にあるようにお客様にシステムを提案するドキュメントを書くことも、経営層に投資対象を選択してもらうためのドキュメントを書くこともありません。

今の私が仕事でドキュメントを書くシーンは

• ツールやコードのREADME、MergeRequestでの仕様説明
• チームメンバーや後輩への業務指示
• チーム内で遵守すべき共通ルール
• ナレッジ(技術的知見)の共有
• 業務上不明点の相談、報告
• 業務進捗報告
• イベント参加報告

ぐらいでしょうか。どれもたいしたことないように思えますが、なるべく一発で相手に伝わるドキュメントを書くスキルは重要だと以前より考え、ブログでのアウトプットを続けているのもその一環です。(時間に余裕が無い時スピード重視で雑なままつきとばしてしまうことが最近あって、反省。。。）

チーム内でもドキュメントに対するこだわりは強いのですが、実力はまだついていないようで、まだ他者に褒められるまではいたってないので今後も精進。。。

ドキュメントを書く時の心がけ

本書第２章で語られている以下の2点は正しいと思います。

ルール① 目的にフォーカスする ルール② 相手にフォーカスする

結城先生も「読者のことを考える」だけをひたすら言い続けた本を書いたわけですが、その読者がどういう知識レベルで、どういう目的で読むかを考えることが第一に大切なことだと思います。

プレゼンのときに「対象は誰で」「知識レベルはどれぐらいで」「何を持って帰ってもらうことが目的なの」ということを考えますが、それと同じですね。

論点を絞る

本書第３章では、伝えたいことを1つがテーマです。本筋に余計なことが書かれていると気が散りますよね。

余談ですが、余談ですがで本筋を見出しまくったココイチ好きすぎな記事を昨日読んで、なるほどカレーが食べたくなっちゃうなーと思いました。余談ですが。

www.mikinote.com

本書まとめでは「論点を絞る」ことに関するチェックポイントが5つもあってなかなか絞りきれないと感じました。

論理的記述力

4章、主張をしたら根拠を述べる。

まぁ、そうねって感じですね。

ちなみにまとめで5つのチェックポイントがあるわけですが、5つめの受け身表現や稚拙表現を使わない、がカテゴライズされてるのが謎です。この主張自体は正しいのですが、論理性による文章の信頼性担保のついでに、受け身表現も信頼度減るよ、稚拙表現(これはこれでまた曖昧な表現ですが)も信頼度減るよ、だからやめようね、のついで感があります。

構造化力

5章、同じグループをまとめたり、同じ階層ではレベルを揃えるとのこと。これはとても重要ですね。

箇条書きでよくやりがちなのは、粒度が揃っていなかったり、論理展開を並べてしまったりする場合があります。

# 私とカレーについて
* カレーが好き
* キーマカレーが好き
* 週末はよくカレー作りをする

おいおいカレーとキーマカレーは粒度が違うやないかい、カレーの好みと、カレーをどう好きかもまた粒度が違うやないかいってなりますよね。

# 私とカレー
* カレーはおいしい
* カレーを作ってみようと思った
* カレーエンジニアに

まぁそんな流れでカレーエンジニア(ってなんだよ)になったのかなーってのはなんとなくわかるけど、思考の流れや論理展開を箇条書きにするのも好ましくないと思います。伝わるけどね。

平易表現力

本書第6章です。

難しい用語、専門的な用語、自分やチームの人しかわからない言葉は、言い換えて表現する ただし、文章に前修飾すると分かり難いので、脚注やカッコを使う

"一言で言う「結論」"で「ただし」と足されているところがしっくりきませんが、使う用語は読者が理解できるものしようというのは正しいと思います。

これは冒頭で述べた「読者の知識レベルを考える」でカバーできる範囲だと思います。

正確表現力

7章です。

自分が知っていることを省略しない、あくまで相手の知識や理解をベースに書く 主語や主体は明確に書く 曖昧な表現や無意味な表現をしない

3点目の曖昧な表現や無意味な表現がとってもブーメランになってる気がしますが、暗黙的な理解を省略してしまうことはあると思うので、前提が相手にはわかるかな？という視点は大切かと思います。

あとここに関連するか微妙ですが、略語を使わないということも大事ですね。(略語も省略といえばそうなので) 少なくとも１回目は正式名称で述べ、以降略するとか。ついついチーム内への提案ドキュメントにcapistranoをcapiと書いてしまって最近指摘されました。capiって言うもん。ごめんなさい。

A remote server automation and deployment tool written in Ruby.

capiはいいぞ。

短文表現力

8章

無駄な文章をそぎ落とす 図解や記号化を行い、文章を画像として扱う 短くするための言い換えを使う

!? って感じのまとめですが、できるだけ短くしようね、ということは納得します。

論理展開を→を使って省略するということが主張のようですが、まぁ好みの問題かなと思います。

体現止めにしてブロックにしてそれを矢印で遷移させるのはプレゼンの領域でしょう。

感情・心理利用力

相手の感情に訴えるなど、心理面のアプローチをドキュメントに埋め込む 複数案から選ばせることで、こちらの意図した方向に誘導するなどの技術を駆使する

上記の結論を添削するなら、本書はドキュメントに関する指摘をしているので"ドキュメントに"埋め込む　は冗長。

意図した方向に誘導する"など" という曖昧な表現は排除すべきですね。

で、ここにきて感情論かよ、って思いそうになりますが、これは「相手の気持ちを考える」ということなので、とても良いことです。つまり提案を受ける側の選びやすい形にしてあげる、と捉えることができます。

まぁなんか相手を褒めるとかも書いてありますが、うん、まぁ、そうね、普段のコミュニケーションとしては大事です。

この章、言ってることは間違ってはいないのですが、ドキュメントの技術的な校正を考えるなら除外すべき章だと思いました。もう少し大きな枠組みで、チームで働くときに気をつけるべきメンバーへの働きかけ方、という範囲で述べられることかなと思いました。

フレームワーク

相手と目的によってフレームワークを用いましょうという話。そういうものがあるなら使えると思いました。ここはテクニックではないですね。

おわりに

あらためて振り返りましたが、ドキュメントの目的を考える、読者の知識レベルを考えるという2点はやはり欠かせません。

その上で本書を読んであらためて気をつけたいことは

• 論点を絞ること
• 構造化し、箇条書きは粒度を揃えること
• 表記ゆれ、誤字、省略を避けること

を守れば良いドキュメントは書けると思いました。

最後に思い出したようにひとつ。僕がドキュメントへのこだわりが強いのは以下の記事であるように引き継ぎが大嫌いだからなんですね。正確には無茶振りな引き継ぎでつらい目にあったからなんですが。過去のこういう記事を書いていました。

take-she12.hatenablog.com

良いドキュメントはエンジニアのたしなみ。今後もソースコードと同じぐらいドキュメント作成能力も鍛えていきましょう。

ようやくSRE本を読み終わりました

はじめに

読み終わりました。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

英語の原著が出た時点でkindleで購入していたにも関わらず読み通せなくて、その後英語版は無料公開されました。

Google - Site Reliability Engineering

ほどなくして翻訳版が出て、読まないわけにはいくまいと購入。2ヶ月ほどずっとリュックやバッグにいれて持ち歩いていました。重かった。。。

SRE、信頼性エンジニアはGoogleで古くからあり、日本でもメルカリをはじめ、現在は様々な企業でSREポジションが存在します。（言葉だけ広がって流行っているとも、見える。）

GoogleのSREにはなれなくても、SREのような考え方を大事にする場所で働きたいと思います。せっかく読み通したので振り返りをしておきましょう！

まず、Google SREのコアな考え方は9章の第2部までに集中しています。まずはここをおさらい。

原則

エラーバジェット

Google SREの中でも大切な考え方の1つ。単純に、サービスが保証する信頼性目標(SLO: Service Level Objectives)を超えているのであれば新機能のリリースができ、下回っている場合は新たなリリースができないことを開発・運用双方で合意しています。

これによって新たなリリースという障害リスクを抑制することと、信頼性向上のための施策を行うことができます。

SLO、SLA、名前はあれどそれを明確に顧客と約束したり、計測して結果を振り返ったりすることは非常に難しい。そして計測しなければこのエラーバジェットによるリリース制約はできません。

SLOの指標

では何を指標にし、どう収集すればいいのでしょうか。

これは多すぎてもいけないし、見当違いのものでもよくなく、これを決めるのはかなり経験が必要ではないかと思いました。

また、「最初から完璧でなくてもよい」とある通り、継続的な見直し、修正が基本的な考え方なんでしょう。

トイル

これもSRE本での重要な考え方の1つ。本書によれば、

プロダクションサービスを動作させることに関係する作業で、手作業で繰り返し行われ、自動化することが可能であり、戦術的で長期的な価値を持たず、作業量がサービスの成長に比例するといった傾向を持つものです。(p51)

ここでもっとも重要なことは"作業量がサービスの成長に比例する"ということでしょう。単純な手作業だとしてもサービスの成長＝機能追加の数が増えるだけで、その作業は指数的に増えるかもしれません。

本書34章まとめで、SREの進化を航空業界に例える例がありますが、まさに「サービスが数百、数万のオーダーで成長しても、"同じ人数"で信頼性を維持することが、SREでもっとも重要な考え方の1つだと思います。そのためにトイルは絶対撲滅しなければなりません。

SREの業務

SREの業務はおおよそ以下の4つに分類できます。

• ソフトウェアエンジニアリング
  • コード作成や修正、ドキュメンテーション、設計、自動化スクリプト、ツール作成など
• システムエンジニアリング
  • システムの設定変更、システムに関するドキュメント作成。1回の作業で改善が持続するようなもの。
• トイル
  • サービスを稼働させることに直結している作業で、繰り返されたり、手作業だったりするもの
• オーバーヘッド
  • サービスを稼働させることに直結していない管理的な作業。採用、人事、ミーティング、バグ整理、レビュー、自己評価、トレーニング

なるほどこの4分割は、現状の自分の業務でも納得できます。（もっとも、これらに含まれない本当にやりたくない仕事もたまにあるが）

トイルを減らし、エンジニアリングの割合を増やすこと、これがSREがいる組織と、従来のDev & Opsが分かれている組織との違いですね。

モニタリング

レイテンシ、トラフィック、エラー、サチュレーションが4大シグナル。モニタリングの設計をした経験がないので、今後やる場面になったときにもう一度読み返したい。

自動化と自律性

7章、Googleにおける自動化の進化ですが、ちょっと内容かわかりづらいんですよね。

自動化の進化は以下のような経過を辿る。

1. 自動化以前
2. 外部でメンテナンスされるシステム固有の自動化
3. 外部でメンテナンスされる汎用の自動化
4. 内部でメンテナンスされる汎用の自動化
5. システムが自動化を必要としない

最終的には5、つまりシステムが自律的に問題を解決する(自動化した何らかの解決手段を必要としない)ことを理想としています。現実的に身の回りでは2か、頑張って3ぐらいですね。。。

例えば、今の職場では共通のSSL-VPN接続端末があって、そこを経由して検証環境につなぐのですが、最初は各クライアントで使うための自動接続スクリプトを作ったんですね。(2)　それを共通基盤として使うようになって、(3) 切断を検知して(よく切れる)自動再接続するようにしました。(4)　この順序は正しいですね。

リリースエンジニアリング

いわゆるCI/CDと言われている領域に近い話ですね。

哲学として高速性、密封ビルド(一貫性と再現性の保証)があげられています。

これは継続的ビルドとデプロイメントで紹介されているビルドの速度と、パッケージ化ですね。ubuntu系のdebやrhel系のrpmのようなパッケージシステムによって一貫性と再現性を保証します。

アプリケーションやインフラのソースコード管理、そしてビルド、デプロイの自動化は最近では当たり前のようにされるようになったと思いますが、設定管理はどうでしょうか。通常、ソースコード管理で管理しない、いわゆるconfigのようなところです。

本書でもバイナリ(と呼ぶ、アプリケーションをパッケージとしてビルドしたもの)と設定は別管理をするが、フラグを使ってひも付ける例があげられていました。例えばansibleのような構成管理のタグとrpmのバージョニングを合わせて管理するのがベストといえそうです。

実践編

ここからは実践編で、理論というよりはポエムとなります。googleの社内ツールの話は理解が難しかったのであまり深く読んでません。オンコール対応も(SREとしては重要な話ですが)現職ではそのポジションにないので飛ばしました。

中でも面白かった章を紹介します。

トラブルシューティング

トラブルシューティングって、みなさんどうやって習得しましたか。ぼくはいきなり障害番号投げつけられて「これ見て」からはじめました。ひどいよね。

今思えば当たり前のことですが、

• 一般的なトラブルシューティング手法の理解(すなわち、特定のシステム知識とは関係ない)
• システムに関するしっかりとした知識

この2種類あるが、それよりは、本来そのシステムのあるべき姿を知っていることが大事だと言います。本当にそうだと思います。

システムの本来の動きも知らない、一般的なトラブルシューティング手法も知らない、特定のシステム固有の話も知らない状態で振るなんて悪手でしかないので絶対に自分より下にはそんな思いをさせたくない。この章を2年前に読みたかった。

問題のレポート、トリアージ(システムがその環境下でできる限りうまく動作するようにすること、すなわち暫定対処や復旧のこと)、検証、診断、テスト/対処という流れでトラブル対応していくことになります。最初はこの流れすら知らなかった。のちに仮説/検証のサイクルで詰めていくことが大事と自ら学んだ。悪くない経験とはいえ、遠回りしてしまった。

この章はトラブルシューティング初心者にはかなりおすすめですね。

ポストモーテム

ポストモーテムも、SREとしてかなり重要なことですね。

しばしばインシデントはドキュメント化されるというよりは、報告が義務付けられるので、何らかの形で残ってはいるのですが、それを「次への学び」に活かすという視点での活用は今の職場にはないところです。

ポストモーテムで批判を行ってはいけないことは繰り返し述べられています。

「今月のポストモーテム」や「ポストモーテムニュースグループ」「ポストモーテム読書会」はすごいいいですよね。個人的にはやってみたいな、今のチームでできないか考えてみたいと思います。ちょうど勉強会やってるし。

データの完全性

特にバックアップとアーカイブの違いについてが面白かったです。アーカイブは完全に保管するものの、リカバリ2時間がかかってもさほど問題はないでしょう。逆にバックアップはリカバリが素早くできないのであれば意味がありません。ユーザから見て対象のデータが長期にわたって使えないのであればバックアップがあっても無意味です。それが「データの完全性は手段であり、目標とするのはデータの可用性である(p363)」ということでしょう。

そしてやはり重要な学びは"多層防御"でしょう。複数のレイヤーで可用性を確保しておかねばなりません。

そして必ずリカバリの検証をすること。「バックアップできてるはず」「リカバリできるはず」ではいけません。"願望は戦略にあらず(p387)"の通りです。

管理

4章ではSREの後継の育成や、割り込みと対処、SREチームと他の開発チームとのコミュニケーションなど、より人間的な面での実践アプローチが語られています。これも今後機会があったときに読み返したいです。

おわりに

何とか通読したものの、「ウォーこれはこういうことだったのかーこの考え方は大事にしよー！」ってものと、あまりピンとこなかったものがありました。自分自身の経験に合わせて再度読み返すときっと新しい気づきがあるでしょう。システムの信頼性に関することなら、何かしらのヒントがこの本にあるはずなので、壁にぶちあたったときに手を伸ばせるように手元に置いておきたい本です。

私個人としてもSREというポジションになりたいと思っているので、読み通したかった本がちゃんと読めて、こうやってブログで振り返れてよかったです。

直近の業務で活かすことといえば、インシデントを一手に受けているので、トラブルシューティングの一般化を後輩に伝えていくこと、勉強会を主催しているのでポストモーテム読書会はやりたいということと、モニタリングについて自分自身で設計したことがないので何かしらでやってみたいです。

さて、次は同じくUberのSREが執筆した「プロダクションレディマイクロサービス」も買ったので、読んでブログ書きたいと思います。

プロダクションレディマイクロサービス ―運用に強い本番対応システムの実装と標準化

転職活動をしてみて思うことや、職務経歴書のgithub公開

はじめに

1ヶ月ほど前、この記事で「キャリアを次に進めます」とある通り、Wantedly経由でいくつか企業に訪問している。

take-she12.hatenablog.com

モチベーションとしては、自分の市場価値を確認したいということと、もし可能であれば環境を変えたいということ。今の職場・仕事内容に不満はないので、「今すぐ転職したい！」ような積極的な転職活動ではなく、情報収集をかねてやってみてるレベルである。

年度内(2018年3月まで)に何かしらの結論を出したい(するなら内定、しないならしないと自分の中で決める)と思ってる程度にはのんびりな活動ではあるが、いくつか気づきや学びがあったので書き記しておく。

カジュアル面談

wantedlyでいうところの「カジュアル面談」は、正式は採用面接ではなく、ラフに情報交換をしましょう、まずは遊びにきて少し話しましょうよ、というもの。プロフィールをそこそこ充実させておけば向こうからスカウトがぼちぼちくる。もちろん自分から話を聞きに行きたい！と申し出ることもできる。

約2ヶ月ほどのスパンで計5社訪問した。途中現業が忙しくなったこともあって期間を開けた。だいたい週に1社ぐらいが限界。あんまり早退しすぎると現職の人間に怪しまれるしね。

だいたい対応してくれるのは人事か、エンジニア系の管理職、あるいはその両方。会社によってはエンジニアを呼んで話しをしてくれるところもあり、スカウトを送ってくるほどの会社はわりと熱心に相手をしてくれる。(今すぐ面接を受ける意志がないにもかかわらず！)

だいたい1時間程度なんだけど、ここの内容は企業によって結構違う。会社側から一方的に説明して、何か質問ある？というところもあれば、面接じゃないけれど面接みたいに、どういうことがしたいですか？と聞いてくるところもある。

いずれにしても、その会社の事業領域や強みを、１：１で聞けるというのは非常にありがたいし、自分が活躍できるポジションがあるかないかはだいたいわかるので、可能な限り気になる企業とは話したほうがいいと思った。

ちなみにこれは余談で、今日受けた企業はマッチングが成立しないにもかかわらず、キャリアに関するあまりあるアドバイスをくれて、本当に良い方でした。本当は内容をブログに書こうと思ったのだけれど、会社名を伏せると何も言えなくなってしまった。笑

自分のキャリアのためになる仕事をする

転職活動をして、自分のやりたいこと、これまでやってきたことを、面談で話すということを経験すると、今の職場でも、自分のキャリアにプラスになることをしよう、という気持ちになる。

転職する気がなくても、転職活動はやるだけプラスというのはこの点にあると思う。今給料をもらいながら、その時間で何をするのか、が明確になった気がする。

職務経歴書

以下の記事の影響で思い切ってgithubに職務経歴書をアップした。

qiita.com

職務経歴書はこちら。

github.com

現職の人間が見れば一発でわかるが、一応具体的な会社名は伏せた。

定期的にメンテナンスをしていきたいと思う。今までやってきたこと、今やってきたこと、自分が何をやりたいと思っているかを、都度文章化することは大切だと思う。

おわりに

まだカジュアル面談をしただけで、転職活動しています！なんて大げさだが、少なからずメリットはあるので、やっぱり定期的に社外のひとと自分のキャリアについて話す機会というのは今後も持ち続けたいと思います。

GCPのコンピューティングサービスの料金をざっくり確認する

はじめに

カレー好きなエンジニア、たけしです。ついついGCPでがっつりカレーパーティに申し込んでしまったのですがGCPを使ったことがありません！

topgate.connpass.com

やばくない？何だこのイベント！これを機に俺もGCP好きのカレーエンジニアになるぞオォォォとなりました。

真面目な理由としては、今後仕事でクラウドを"使う側"に立つ可能性があり、AWSだけではなく、GCPやAzureで何ができるか、何が違うのかは把握する必要があると思っていること。コンテナオーケストレーションのKubernetesを使ってみたいことがあります。

で、まずは料金からです。

料金体系

公式の日本語サイトが充実しています。

cloud.google.com

料金計算ツールもあるので合わせて見ていきましょう。

cloud.google.com

App Engine(GAE)

アプリケーションを載せることができる、PaaSです。

cloud.google.com

言語はNode.js、Java、Ruby、C#、Go、Python、PHPに対応。トラフィック分割やアプリケーションのバージョニングなど、リリースに関する仕組みは気になりますね。

Herokuに似たようなサービスです。

気になるお値段は？

• インスタンスのクラスによって、0.05〜0.30 USD / hour のようです。
• 起動時には15分間の起動時間が加算されます。つまり最低課金料金が15分間ということですね。
• Google Cloud Databaseは無料枠あり。1日1GBのデータ保存まで。

料金計算ツールを使ってみました。

Outgoing Network Traffic: 1 GB
Cloud Storage: 10 GB
$0.13

1ヶ月です。適当にネットワークとcloud storageを入れてみましたが、app-engineのインスタンスには課金は発生しないようですね。search apiなど他のサービスを呼んだり、トラヒックを使うと課金されていくようです。

Compute Engine(GCE)

cloud.google.com

EC2と同等のものですね。

なんとf1-microだと料金はかからない！あとは基本的にはフレーバーのレベルによって変わるみたいです。

f1-microで1ヶ月使った場合

730 total hours per month
VM class: regular
Instance type: f1-micro
Region: Iowa
Sustained Use Discount: 30%  
?
Effective Hourly Rate: $0.0053
Estimated Component Cost: $3.88 per 1 month

わずか3.88ドル。永続ストレージ30GBをつけても

Storage: 30 GB
$1.20

合計5ドルです。めちゃくちゃ安いですね。

Container Engine(GKE)

Google Container Engine ドキュメント  |  Container Engine  |  Google Cloud Platform

ECSと同等のサービス。

クラスタ内のノード数が5までなら無料なんですね！クラスタのノードにはGCEを利用するようで、GCEの料金がそのまま加算されます。

6ノード以上だと、アイオワでは1ヶ月

6 ノード以上    標準クラスタ  $109.50

結構かかりますね。

Container Registry

cloud.google.com

DocukerHubのような、Container Registryサービスは、StorageとNetworkの料金のみしかかからないようです。

Google Container Registry では Docker イメージが使用した Google Cloud Storage とネットワーク出力に対してのみ料金が発生します。詳しくは、料金ガイドをご覧ください。

Cloud Functions

cloud.google.com

lambdaに代表される、Function as a Serviceですね。

こちらも無料枠が用意されてます。試すだけならできそうですね！

• 呼び出し

無料試用枠	無料枠を超えた料金(単価)	課金単位
200 万回	$0.40	呼び出し 100 万回あたり

• コンピューティング時間

無料試用枠	無料枠を超えた料金(単価)	課金単位
400,000 GB 秒	$0.0000025	GB 秒単位
200,000 GHz 秒	$0.0000100	GHz 秒単位

• 送信データ（下り）

無料試用枠	無料枠を超えた料金(単価)	課金単位
5GB	$0.12	GB 単位

• 受信データ（上り）

無料試用枠	無料枠を超えた料金(単価)	課金単位
無制限	無料	GB 単位

• 同じリージョン内の Google API への送信データ

無料試用枠	無料枠を超えた料金(単価)	課金単位
無制限	無料	GB 単位

結構安い気がする。何個ノード？を立てるかは関係ないのか。

おわりに

ざっくりComputeサービスの料金を見てみました。StorageやNetworkの料金が関係してくるので一概には言えませんが、個人が簡単に試してすぐ消す分にはCloud Funtion、f1-microでのGCE/CKEはそんなに大金かけずに使えそうです。

次回はTerraformを使って実際にインスタンスを作ってみたいと思います。

「友人たちのためのブラウザ」Vivaldiのショートカット調べてみる

はじめに

vivaldi使ってますか？ぼくは毎日楽しいvivaldiライフを送っています！Tシャツ買っちゃいました！

steers.jp

以前記事も書きました。

take-she12.hatenablog.com

長く使っているのにもかかわらず、ショートカット全然使いこなしていません。今から覚えよう！のモチベーションで記事を書き始めています。一緒に触っていきましょう。

チートシートを見る

まずcommand + F1でチートシートを眺めていきます。

ウインドウ

• Windowを閉じる、Command + Space + W は押しづらいですね。使いそうだけど。
• Command + E、もしくはF2のクイックコマンドはまず覚えたい
• Command + Shift + Bでブックマークが出たり消えたりする。知らなかった。

表示

• Command + / でアドレスバー。検索が早くなりそう。

• Command + F11、UI切り替え。タブやアドレスバーなどがなくなってWeb画面だけになります。

• 拡大/縮小 拡大がCommand + ^、縮小がCommand + -でした。

• F4でパネル

• F7でパネルにフォーカスを移す

• Command + Control + 何かで履歴やブックマークをだせる

タブ

• Command + Tで新しいタブ
• Command + Wでタブを閉じる。なんでWなんだろう。
• タイルにしたり縦にするCommand + F6-F9は解除しか効かなかった

表示

• Command + D ブックマークの作成​

Macのショートカットキー記号

そもそものことを言いますとMacのあのマークが覚えづらくて全然ショートカットキー覚えられないんですよ。Commandのアレはキーボードに書いてますけど、家マーク、ハット(^)、右下がりのエスカレーター、、、これのいい覚え方はないんですかね。

support.apple.com

もう2年Mac使ってるやつのセリフじゃないな。。。

その他カスタマイズ

せっかくなのでこれを機会に設定見直しました。 * アドレスバーに検索欄を表示、をオフ(アドレスバーで検索できるので不要) * マウスジェスチャー ALTと一緒にジェスチャー有効

を変更しました。

おわりに

大好きなvivaldi、たまにタイルにするぐらいしか特有の機能使っていないですが、ショートカットキーこまめに確認して少しずつ覚えようと思います。

「あなた」という商品を高く売る方法 キャリア戦略をマーケティングから考える を読んだ

はじめに

同期氏のすすめで読みました。

「あなた」という商品を高く売る方法　キャリア戦略をマーケティングから考える ＮＨＫ出版新書

キャリアをどう進めるかについては「キャリアショック」がとても良かったですね。具体的に社内で、どうやって自分の都合の良いようにキャリアを進めていくかが書かれてあります。

キャリアショック どうすればアナタは自分でキャリアを切り開けるか? (ソフトバンク文庫)

そして今回読んだこの本は、商品を売る「マーケティング」のアイデアを元に、キャリア戦略を自分という商品をどう売るかになぞって解説した本です。

以下、本書で紹介されている内容を少しずつピックアップして紹介してみます。

競争を避けること

ただ、首尾一貫していたのは、「競争を避けて、好きなことをする」ということ。結果的に、これが自分という商品の価値を高めることにつながった(kindle 位置196)

いかに戦わなくて済む領域を探せるか。レッドオーシャンではないブルーオーシャンを探せというわけである。

会社組織にいても、"出世競争"という言葉があるように、戦って上にいくという意識を持つひともいるだろう。自分もそこまでの熱はないが、"勉強し続けないと死ぬ"という気持ちはもっていて、それは周囲のひとに負けない、ついていく、という気持ちがあったのだと思う。

消費者が「より自分らしく、よりワガママに」なったからこそ、あなたを必要とする人は必ずどこかにいる。現代では、細分化されたニーズに特化すれば、競争は避けられるのだ(kindle 位置221)

ニーズが多様化、細分化したことによって、どこにでも当てはまる太いスキルというものはもはや存在しなくなった。どこかにその細かい1部分にマッチする仕事があり、それが自分が得意とする可能性は高い。

バリュープロポジション

① 自分の強み、② ターゲット、 ③ ニーズ、 ④ 自分の仕事、の四つ (Kindle の位置No.515-516)

​このように「 相手が求めていて、 自分しか提供できない価値」 のことを、「 バリュープロポジション」 という。(Kindle の位置No.495-496).

自分の中のバリュープロポジションを育てることにより、戦わずして勝つことが可能になるという。実際に考えてみよう。

とはいえ、自分の強みを自分で見つけるのはなかなか難しい。

あなたという商品の価値を高める出発点は、自分の強みを見極めて育てることだ。 しかし自分の強みは、自分だけでは意外と気がつか ないものである。(Kindle の位置No.579-581)

強みは、先天的な才能と、後天的な技術と知識の掛け合わせでできるという。ここでいう先天的な才能とはよくいう突出的な能力をいう意味ではなく、個性の１つであり、優劣はないという。

「才能」 とは、 個人が必ず持っている資質や性格のことだ。どの資質がいいとか悪いとかいうことではない。 自分が持っている資質 を、 仕事で活かすことができるかどうかが 重要なのだ。

Amazon CAPTCHA

これを参考に自分の強みを探し、育てていくことが重要である。苦手なことを克服するよりは、得意なことを伸ばしたほうがいい。

したいことと好きなこと

最初から自分のしたい仕事はできないし、選べないひとも多いだろう。それでもまず、与えられた今の仕事を好きになることが第一だという。

まずはいまの仕事を 好きになることが、 あなたの強みをつくり、 あなたという商品の価値を高める近道 だ。いまの仕事でできること をいろいろ試してみて、 好きになる部分を見つける。「 これは自分がやりたい仕事ではない」 といった先入観にとらわれず、 その仕事 で試行錯誤してみて、 自分の才能を活かす方法を見つけていくのだ。 そこを起点に自分の強みをつくっていけばいい(Kindle の位置No.681-685)

なおキャリアショックでは、今与えられてる仕事はちゃんとこなした上で、別の自分のしたいことについても勝手にやって声をあげることをお勧めしていた。そのうちそちらに需要がでてきて、本来やるべきであった仕事は他のひとにまわされることになる。

リアルオプション理論

そうはいっても、どうしても好きになれない仕事もある。つまり、新しいことに挑戦する回数が多ければ多いほど自分の好きな仕事に出会える確率は当然あがる。しかし、そう簡単になんども挑戦できるものだろうか。

そのためには、挑戦する回数を増やすこと。そしてリスクをただ回避するのではなく、リスクを上手に管理しながら、リスクを下げる ことだ。リスクを下げれば、 挑戦回数を増やせるし、 あなたの強みを創り出す機会も増える。(Kindle の位置No.847-849).

つまり、許容できるリスクを設定し、その期間内で思いっきり挑戦すること繰り返す。これにより挑戦回数を増やすことと、リスクを最低にすることができる。損切りみたいなもんですね。

仮説思考

たくさん挑戦をして、たくさん学ぶためには失敗し、その失敗から学ぶサイクルが重要。よく言われるPDCAは円環ではなく、らせん状にあがっていくものだと解説されている。

正しい仮説検証は「 円」でなく「らせん」である。まず大まかな仮説を立てて（プラン）、すぐに実行する（ドゥ）。結果を検証し（ チェック）、学びをもとに対応策を考え（ アクション）、新しい仮説を立てる（新しいプラン）。こうしてらせんを１段上がる。そして 新しい仮説を実行・検証 し、新たな仮説を立てると、らせんを２段上がる。 (Kindle の位置No.1226-1229).

僕は「なんでもやってみる」精神ではありますが、仮説を立ててやっているかというと少しかけている気がします。（もっとピンポイントに、障害調査等は仮説を立てて原因を詰めていきますが）もう少し広い範囲で、何をはじめるときにも仮説/実験を繰り返していきたい。

コンフォートゾーンからの脱出

セブンイレブンやAmazonの例をあげて、常に安泰の状態(コンフォートゾーン)にいてはならない、自ら挑戦をしてリスクのある分野に展開していかなければならないと述べている。これはまったくその通りだと思う。（セブンイレブンの紹介で、それをいえばAmazonでは、と思ったら案の定でてきた。）

セブンのトップは「競う相手は他社ではない。お客さまニーズの変化だ」と言っ ている。実際、セブンは他社コンビニと戦っているようには見えない。たとえば他社に先駆けて新サービスを始めるケースが多い。セブンはライバルではなく過去の自分と戦い続けているの だ。その結果、追いかけてくるライバルを尻目に、「 戦わずして勝つ」状態で独走を続けている。(Kindle の位置No.1304-1308).

大きな会社にいると、変わることを恐れるひとは多い。それに、何といってもソフトウェア開発では、ソースコードの変更を恐れ、「動いているうちは触るな」という伝説のような話もある。（実際にある）

ソフトウェア文化に重ねても、容易に変更可能なようにリファクタリングやテストコードを書くことであったり、インフラに関してもInfrastructure as Codeの考え方が当たり前になってきて、何度でも壊して作り直すことが当たり前になってきている。

Infrastructure as Code ―クラウドにおけるサーバ管理の原則とプラクティス

僕はInfrastructure as Codeの「アンチフラジャイル」という考え方を知って、これはキャリアも同じだなと思った。つまり、変更に強くなる。変更しても、損失しない。変更するたびに、（フィードバックを得ることによって）強くなる。自分自身の仕事内容も、どんどん変化させていかないといけないし、そのたびに抽象的な考え方を学ぶことで、他分野に活かすことができる。これが１つを極めたら2つめ、3つめを極めるのはより短時間で済む、ことにもつながっているのではないだろうか。

個人が専門分野をつくるときも同じだ。初めて地下水脈を掘り当てるまでは、 勝手がわからないため試行錯誤の回数も多く、１万時間 の集中が必要だ。しかし新しい専門 分野をもう１本掘ろうとすると、経験的に地下水脈がどのあたりにあるか見当がつくので、より短い 時間で地下水脈を掘り当てることができる。３本目は寄り道せずに、さらに短い時間で掘り当てることができる(Kindle の位置No.1427-1431).

そして話はコンフォートゾーンに戻るが、僕が現在猛烈に危機を感じているのは、（ビジネス的に、ではなく）私個人が非常にコンフォートゾーンにいると感じているからだ。会社が潰れる可能性はあるし、会社じゃなくとも自分が所属する部署、本部が経営危機になって異動や、期待しない仕事をさせられる可能性もある。しかし、それでもしばらく数年は今の給与のままで、特にストレスも失敗もすることなくやっていける確信がある。それではいけないと思っている。リスクをとって、自分自身の成長と、周囲やビジネスを動かす経験をしたい。

関連するが、チーム開発における"心理的安全"とは少し違う。私が所属する部署の上司はとても良い上司ばかりだ。否定したり、怒鳴ったり、原因究明のときに心理的に追い込むような聞き方はしないし、マイクロマネジメントもしない。必要な相談は乗ってくれるし、雑談もするし、ビジネスに必要な指示、アドバイスはしてくれる。これにより私自身は心理的安全な状態で仕事ができている。その状態で行う仕事内容が、少し物足りなく、このままでは成長スピードが遅くなってしまう、という危機感を持っている。

mirai.doda.jp

本書ででてくる"強みの掛け算"は堀江さんが言うところの"多動力"だろう。1つのプロフェッショナルならライバルが多いが、それらを掛け合わせるとライバルが減っていき、本書でいう「戦わずして勝つ」ことをやがて実現できるというわけだ。

多動力 (NewsPicks Book)

弱いつながりと強いつながり

自分の商品価値を自分のためにあげていくと、やがてそれは社会貢献につながる。その中で、昔は1企業内や家族でガッチリと絆で結ばれた強い絆がメインな社会的つながりだったが、現代は世の中の多様なニーズに対応するために絶えず新しい発想をしていかなければならず、そのために多種多様な人材を交流する弱いつながりが多くなってきたという。

滅多に会わないSNS上でつながった知り合いから、自分の周囲では誰も話題にしていないような道の情報を得たことがある人も多いはずだ。彼らは自分の周囲とは全く異なる集団に属しているから、知らないことが大きな話題になっていることも多い。つまり弱いつながりは新しいアイデアを得るのに向いているのだ。

本書では自組織では得られない発想を得るために弱いつながりが有効であると述べている。そして弱いつながりから得られる資本、ソーシャルキャピタルを元に社会貢献につなげていく。

弱いつながりといえば、東浩紀の以下の本が記憶に新しい。記事も書いた。

弱いつながり 検索ワードを探す旅

take-she12.hatenablog.com

この本は観光として出会う"弱いつながり"こそがよりよく生きるために寄与するよ、という哲学的内容になっていますが、この偶然の出会いが面白い発想なり、未知の経験を生むと解釈すれば、それはキャリアでも同じことが言えるでしょう。

自分のバリュープロポジションを考えてみる

さて、せっかくなのでここで自分のバリュープロポジションを考えてみましょう。バリュープロポジションとは

• どんな強みを活かして(自分の強み)
• 誰の(ターゲット)
• どんな悩みに(ニーズ)
• いかに応えるか(自分の仕事)

を埋めることでした。

まずは現職を考えると、最近ではCI/CDの取り組みをしたので

• ソフトウェア開発におけるCI/CD導入・実践経験の強みを活かして
• CI/CDサイクルを導入していないチームの
• CI/CDサイクルを導入したいけど何をすればいいかわからないという悩みに
• 現状を一緒に考え、必要な施策を立て、支援しながら導入していく

になるでしょうか。まぁ、まだまだ「CI/CDの導入・実践経験」で君はなにができるの？何がすごいの？っていうところを詰めないといけないですし、今時そんなチームいるのかって気がしますね。しかも自分しかできないことでは到底ないですね。

次に自分が今考えているサービスに当てはめてみましょう。

• スパイスカレーを自ら作ることができることと、ソフトウェア開発の文化をよく知っている強みを活かして
• スパイスカレーを作りたい人の
• 自分にあったレシピを探したいという悩みに
• スパイスを含んだカレー料理のレシピを共同作成できるサービスを提供する

クックパッドでいいじゃん、となってしまうので、悩みをもう少し深堀したほうがよさそうです。ただしカレー×IT両方に通じてるひとはあまりいない気がします。

趣味の音楽についてはどうでしょう。

• 作詞・作曲・ギター・ベース・ドラム・CD制作・MV制作の経験している強みを活かして
• 自分で曲が作りたい人の
• 曲の作り方がわからないという悩みに
• 曲の作り方のフレームワークを提供する

すでに多くの人がやっとるわいって感じですね。半端にいろいろ手を出してるから初学者への導入支援っていうのは自分の得意としていることなのかもしれない。確かに関心はある。ただこれも自分だけにできることではないですね。

おわりに

マーケティングの考えをベースに自分のキャリアを進める方法、付随する大切な考え方が多くのっている。非常にわかりやすい良書でした。まだ自分自身のキャリアを考えたことがない人は1度読んでみると良いと思います。

僕もそろそろキャリア次に進めます。