なぜ「マネージャー」がネガティブに響くか。それは "マネージャー" によるマイクロマネジメントによってもたらされる疲弊、でしょうか。過剰なマネジメントによってメンバーは疲弊する、プロジェクトは結果的になんとかなってしまったため成功体験として "マネージャー" はそれを繰り返す、といった悪循環が世のいろいろなところで起きている。

興味深いことですが、書籍「エンジニアのためのマネジメントキャリアパス」では、時として (ジュニアメンバーに対しては) マイクロマネジメントも仕方ないことがある、と述べられています。そのバランスが難しい。

で、この「エンジニアのためのマネジメントキャリアパス」は「マネージャー (というかマネジメントを行うということ) ってキャリア選択も悪くないよ！！」と語りかけてくれます。残念ながらこの記事を書いているいま私はテックリードとは何かという問いに結論を出せていないのですが、テックリードはメンバーのマネジメントにも責任をもつ、ということは言ってもよさそうです。

消化不良で反省。。。またの機会にリベンジします。

2018-12-05

人事になりました

入社から2年9ヶ月、エンジニアとしてプロダクト開発に取り組んできましたが、12月からは人事としてエンジニアの採用に専念することになりました。

なんで？？って100000回きかれているので改めて考えをまとめておきます。

キャリアを積むにあたってエンジニアのままでいくか

これは長年考えていることです。エンジニアリングは楽しいし、やりがいもあるし、ありがたいことに給料ももらえています。しかし、自分の強みがエンジニアとして活かせるか、自分が本当にエンジニアリングを好きなのか、という問いに対しては依然として迷いがありました。

勘違いされたくないことですが、ぼくは自身に対していろいろな面で常に問いをもっていて、その一つとしてエンジニアとしてのキャリアがあった、ということです。決してエンジニアとしてやっていく自信を失った、というわけではありません。むしろ、これから人事として幅広くエンジニアに会い、彼らがもつ新しい知識、技術の取っ掛かりから、自分のエンジニアとしてのスキルも広めたり深めたりすることにも使いたいです。

不連続な意思決定

先日、当社の社長と飲む機会がありました。そこで「最近オマエ悩み無い？」という話になったときに上記のような話をしたところ「人事いって採用やったら？」という提案を受けました。

私は岡本太郎の、人生は積み重ねるものではなくすり減らしていくものだ、という考え方が好きです。採用というキャリアの選択は脈絡がなく不連続なものですが、だからこそ、人生をすり減らす良い機会だと感じました。

組織として必要なポジション

これまで当社には、エンジニア出身で人事部専任の社員がいませんでした。当社はプロダクトの会社であり、これからどんどん拡大しようとしています。そのなかで優秀なエンジニアを採用していくためには、エンジニアリングを知っている者が採用に全力で取り組むことが有用だと、客観的に考えました。また、私は特殊な存在であることを好むので、そういった意味でも主観的に得をすると考えました。

面白そう

そして何より、素直に面白そうだと感じました。個人と対峙し、彼、彼女の人生に一部責任をもつこと。マスに向けて自社の魅力を伝えること。社内に向けて、あらためて自社で開発に従事できる喜びを共感できるようにすること。

と、夢のある話ばかりしてきましたが、成果を出さなければ意味がありません。いろいろやるべきこと & やりたいことがあるので、やっていきます！！！！

2018-12-04

IT 勉強会の司会を担当したので心がけたことメモ

↓ で司会を担当したので忘れないうちに心がけたことをメモする。

sansan.connpass.com

カミカミだったのは、ご愛嬌。もっとゆっくりしゃべろ。。

開始前

静かだと居心地悪いので BGM があるとよい。
来場者への挨拶大事！！受付直後に挨拶 & 案内要員がほしい。
WiFi の SSID / パスワードは表示されっぱなしが望ましい。 WiFi 情報とトイレ場所と注意事項なんかをアニメーションで切り替えながら投影しているパターンをよく見るが、かなりの確率で見落とされる (気がする) 。

開始のあいさつ

会の方向にもよるが、アイスブレイク重要。サクラを仕込んででも笑いを取るべき。発表者も来場者も緊張したまま発表に入ることを避けたい。

発表

発表前と発表後の拍手！！個人的には食い気味くらいが好き。
発表の切り替えをどうするか。発表者同士がマイクを受け渡すのか、司会が中継するのか。発表者が発表後に戸惑うと格好悪いので、司会はよく発表者の様子をみて、そうなりそうだったら素早くマイクを中継するようにする。ちなみに、この瞬間に沈黙が訪れるのが個人的に嫌なので、司会は一言コメントを挟むのが好み。
休憩を挟む場合、急に静かになると気まずい。ここでも BGM があったほうがよさげ。

懇親会

転換が必要かどうか事前に判断しておく。
いろんな人と会話できるようにするため立食がよいだろう。
一人になってる人がいたら話しかける。

締め

司会は飲みすぎない。
酒が入るとだいたい盛り上がる。終了したい時間の10分前には「あと10分で終わるよ」のアナウンスを入れる。
- アナウンスはゆっくりしゃべるのが大事。「なんか喋ってんな～」を気づかせるため。また、全員が静かになるのを待つ必要はない。静かになっちゃうと次に話し始めるのが気まずい。
本当に締めるときは「ありがとうございました～」で、拍手。
締めたら BGM を流し、片付けを始め、帰ってねオーラを出す。

2018-12-03

技術力向上だけに固執するのもダメかもしれんけど技術力も当然大事だよという話

先日、弊社CTOのインタビュー記事が軽くバズっていました。

type.jp

ちょっと自分と考え方が違う、あるいは誤解されてそうなことがあるので書きます。

この記事で主張されているのは、「プロのエンジニアなら、経済価値に直結するコードを書くべき」とあるように、技術は価値をもたらさなければ、自己満足に過ぎない。つまり、技術力向上のみを目的としていて、価値をもたらすことを放棄してしまったエンジニアはダメだ。ということ。

ここで邪推されがちなのが、「では経済価値を生むのであれば、どんな汚いコードやアーキテクチャでも良いのか」ということ。これは決して真ではない。論理の誤謬だ。大事なのはバランスだし、かつ、「コードが経済価値を生むかどうか」と「コードが美しいかどうか」は純粋なトレードオフではない。

ここで技術者のちからが生きてくる。いま経済価値を生み、かつ美しい、すなわちメンテナンス性が高かったり不具合を起こしづらかったりするコードやアーキテクチャをいかに作るか。

記事にある、「世界で戦える事業」を支えるプロダクトは、2,3年で出来上がるようなものではなく、長期に渡って変更を繰り返すことが求められる。そこでは高い技術に基づく美しいコードやアーキテクチャが必要。これは弊社 CTO も当然認識しているはずだし、弊社の多くのエンジニアが共感してくれることだと思ってます。

そのためにはやっぱり技術を楽しむことが大事だし、新しい優れた技術を身につけることも必要。

尖った記事は、ただそれだけの断面を切り取られてバズりやすいけど、その根底には暗黙的に大事にされることがあるわけで。はてぶブコメから引用させていただくと、

シリコンバレーで働いて気付いた「技術力向上」だけに固執するエンジニアのダメさ【Sansan CTO 藤倉成太】 - エンジニアtype | 転職＠type

結局ベースにそれなりの技術力があって言える話しだからねこれ。前面に技術の話が出てこないだけで裏ではちゃんとキャッチアップしてるわけで。
2018/11/28 07:32

b.hatena.ne.jp

そのとおりです！！

2018-12-01

vue で日付選択ドロップダウンリスト

vue

ひとり Advent Calendar 今年もやります。ネタはやりながら考えます。

adventar.org

去年のぶんはこちら

adventar.org

vue で年月日をドロップダウンで選択する。よくみる UIでだけど各月が何日まであるか？を出すのが意外と面倒。

うるう年とか考えたくないのでそのへんは Moment.js にお任せしました。

あと、年や月が変更されたときに日が存在しなくなることがあるので最終日にするなどしてみた。

js の Date オブジェクトもそうだけど内部的には月が 0 始まりなのがハマりどころ。

codepen.io

もっとシンプルなやりかたがあるような気もしつつ。

2018-11-30

ひとりタスクボード

2日目です。

adventar.org

タスク管理について。

僕はこれまでは、おもに Todoist と Google Calendar でやることを管理してました。

Todoist は Toggl と相性がよく、ポモドーロテクニックに向いているのが個人的に気に入っていました。

ただ、最近以下の事情により、ちょっとやり方を変えてみることに。

細切れのタスクが増えてきた。
細切れのタスクがたくさんある場合、ポモドーロテクニックはあまり効果的じゃない。
実際の作業はかなりの割合で PC で行う。タスク洗い出しやステータス変更などの行為を実際の作業を切り分けたい。

というわけで、物理的なタスクボードを使うようにしてみました。何年か前にも使っていたのですが再導入です。

ホワイトボードに区分を用意して、タスクをふせんで貼っていくというもの。区分は以下のとおり。

today

今日やるタスク。

future

いつかやるタスク。

doing

いまやってるタスク。

waiting

他者がボールをもっているタスク。

done

その日に終わったタスク。

よくあるタスクボードは todo / doing / done の3つの区分ですが todo の数が多すぎると優先度がわからなくなる and モチベーションが下がるので today と future で分け、また人に渡したタスクの扱いが所在なくなるので waiting を追加。というアレンジを加えています。

僕はもともとタスクの洗い出しとか何か考える際はプロジェクトペーパーを使っているので、その流れでタスクをふせんに書き出す、というのが自然にやれています。集中するポイントの転換にもなる。

課題は、 future がいつまでも残り続けること。。だいたい7つの習慣でいう第2領域なんですけどね。。

2018-10-12

.NET とか Node.js で KeyVault を触る

Azure C# Node.js Azure KeyVault

KeyValult の値をコードから触りたい場合。

.NET の場合

こうする。

var client = new KeyVaultClient(new KeyVaultClient.AuthenticationCallback(new AzureServiceTokenProvider().KeyVaultTokenCallback)

App Service からは MSI で認証しにいく*1。ローカルなら、Visual Studio が Azure で認証した内容が保存していて、クライアントを new するときに勝手にその情報を使いまわしてくれる。

.NET を使用した Azure Key Vault に対するサービス間認証 | Microsoft Docs

あとは client. で Tab ポチポチしたらだいたいわかる。 VS 最高。

Node.js の場合

npm から azure-keyvault をインストール。

npm i azure-keyvault

インポート。

import msRestAzure = require('ms-rest-azure');
import KeyVault = require('azure-keyvault');

App Service からは MSI で認証する。環境変数に MSI_ENDPOINT とか MSI_SECRET とかが入ってるのでそれを参照できる。

const client = await msRestAzure.loginWithAppServiceMSI({ msiEndpoint: process.env.MSI_ENDPOINT, msiSecret: process.env.MSI_SECRET, resource: 'https://vault.azure.net' });

ローカルの場合。こちらは VS / .NET のときと違って、勝手に解決してくれない。

interactiveLogin を使って画面からインタラクティブにもやれるが、バックエンドを想定するとこう。 Azure のログインユーザー名とパスワードを生で環境変数にセットする、というのは良い気分ではないが((CLI から az login した認証情報を使いまわせたりするのかな))。。。

const client = await msRestAzure.loginWithUsernamePassword(process.env.KeyVaultLocalUsername, process.env.KeyVaultLocalPassword);

というわけで、合わせてこうなる。

const client = new KeyVault.KeyVaultClient(
  process.env.MSI_ENDPOINT 
    ? await msRestAzure.loginWithAppServiceMSI({ msiEndpoint: process.env.MSI_ENDPOINT, msiSecret: process.env.MSI_SECRET, resource: 'https://vault.azure.net' })
    : await msRestAzure.loginWithUsernamePassword(process.env.KeyVaultLocalUsername, process.env.KeyVaultLocalPassword));

Secret にセットするときはこんなかんじ。すでに存在したらバージョンが increment される。

const result = await client.setSecret('VAULT_URL', 'SECRET_NAME', 'SECRET');

result の中身はこんなかんじになる。

{ 
  value: 'SECRET',
  id: 'https:\\KEY_VAULT_NAME.vault.azure.net\secrets\SECRET_NAME\VERSION',
  attributes: 
  { 
    enabled: true,
    created: 2018-09-04T07:03:25.000Z,
    updated: 2018-09-04T07:03:25.000Z,
    recoveryLevel: 'Purgeable' 
  } 
}

*1:なので App Service で MSI を有効化し、 KeyVault の Access Policies からその MSI を許可しとく必要がある