エンジニア立ち居振舞い：何やってるのか分かるようにする
うまく整理できるかわからないが面白そうなので、思いつくままに書きなぐってこっそり差し込んでおく。 チーム構成によってメンバーへの接し方を変えるのがよいという当たり前の話になりそう。ときどきできてないこともある。
チーム構成が固くて分担できる場合
自分がマネージャーになる場合は、適宜タスク整理、チームのガイドライン整備、PRのレビュー、忙しそうなメンバーのサポートをする。 チームだからできることというのも多いので、うまくメンバーの能力にレバレッジをかけていく。
例えばドキュメンテーションの経験が長い人からはその話をちゃんと聞いて、現状とすり合わせてよさそうな方法を一緒に考える。 技術習得に熱心なメンバーがいる場合は、自分がやりたいのをこらえて「こういうのが主流みたいなんだけど着手できてないんだよねー」「このへん読むとなんかよさそうなんだよねー」みたいな感じでヒントを出しておくと自分よりもいい感じで調べて整理してくれたりすることがある。 自分にフロントエンド経験が全くなかったときは、より豊富なメンバーに完全にお任せしていた。
ただしいずれにしても、各メンバーの裁量でどうにもならないところは自分が引き受ける。 要件ヒアリング、外注先対応、他チームとの調整（ミーティングアサイン含む）、SlackやQiitaやConfluenceなどチームにあったコミュニケーションツールの選定、スクラム・リリースフローの調整、アクセス権限整理、リソースのコスト管理、メンバーの手に負えない技術調査、他社の事例調査などがこれにあたる。
メンバーの強化したい領域も推移していくし、のっぴきならない事情で自分が引き継がないといけない場合もあるので、分担は暫定と考えて、折を見て各メンバーから話は聞いておく。 他人がやってくれるからと上流に行き過ぎて手が動かなくなるとチームの価値発揮・自分のエンジニアキャリア双方危うくなることがあるので、それは避けるようにする。同様に、自分のやったこともちゃんとどこかに残す。再現性重要。あとチームの冗長化重要（とくに自分が休暇とって動けなかったりするとき）。
エンジニアメンバー（あるいはエンジニアの理解者）が少ない場合
チームに自分が入った時点でドキュメントがない場合はひとまず要件・業務フロー・全体の構成・シーケンスあたりをざっと書いて整理するところから始める。 その後は、何やってるか外から見てわからない感じにならないことが意外と重要かも。 「よく知らないけどこれくらいでできるんじゃないの」と言われたら、「あーまたわかってないな」と言いたくなるのを我慢して、後で潰すことも考えてとりあえず設計して実装して何かしらの目に見える進捗を見せる。 プロトタイプと割り切って、書いたコードにあまり思い入れないようにする。 少し落ち着いた時にコツコツリファクタしたりインフラの置き換えをやるというように、緩急つける。 もし可能であれば、スタックは自分が使いやすいもの、あるいは将来新しい人が入ってきてもググれば分かるくらいのよく使われるものにしておく。
その他
いつかのRebuild.fmで「自分が技術的にはやりがいがないと思う仕事ほど、逆に感謝されたりする」という話があったような気がする。 自分の興味と周りの要望のバランスはどうしてもとらざるを得ない。 とはいえ、こういう理由からエンジニアはふとしたきっかけで虚しくなったり孤独になりやすいような気がする。 ということで、自分が何をやってるのかわかるようにすることは、チームだけでなく自分のためにもなる。 一緒に盛り上がれるエンジニアが周りにいない場合は、他の環境のエンジニアとランチするだけでも結構救われたりする（隣の庭の芝生は青くみえることも時々あるけど）ので、そういうのを避けないで参加するとよいと思う。
他に何か思いついたら追記する。
年齢と嫉妬
SFのミートアップのCode of Conductに時々、ハラスメントになりうる項目にgender, race, religionに加えてageも入っているのがよい。年齢を気にしている暇があれば何か作れよというメッセージを受け取る。
自分のほうは、かつては世代論を表に出していた時代もあったし、自分も30歳という節目（英語で何というのだろう？）になって、同世代の多くがいい感じに温厚な人生を送っているのを見るたびに、不覚にもこれでいいのかという気持ちになることはままある。 端的に言えば嫉妬しているのだ。
嫉妬が成長のきっかけにもなることは否定できないとはいえ、嫉妬に苛まれる時間は正直無駄だと、今は思っている。 自分の人生も時々意図にかかわらず他人に嫉妬をさせる側でもあったことと、他人の嫉妬やひがみに対して逆に自分も軽蔑的な気持ちにさせられていたのを思い出すと、やはり嫉妬なんてなくてもいいのではないか、どうやったらその苦境から離れられるのだろうと考える頻度が増えている。 嫉妬はぽっと反応的に発生するものでコントロールするのは純粋に精神の鍛錬によるしかないか、自信がないことの裏返しなので自信のつく何かをやれというわけかもしれない。
SFの人達を見ていると、何歳からでも挑戦はできると本気で考えているし（その真偽を考えるのは別として）、本当に考えるべきことにリソースを費やしているようで励まされる。そもそも日本人のほとんどはアメリカ人からすると年相応より若く見えるので、自分が30歳であることすらどうでもよくなってくる。ますます日本での生活に支障が出そうだ。
長いようで短い一ヶ月
まとまった時間を振り返るときに使う「長いようで短い一ヶ月だった」という言葉には、ほぼ社交辞令であることが多いとはいえ、若干の混乱や複雑さがあるように思える。
単純な判断基準の一つは 「経験した主観の時間が実際の時間より長かったか短かったか」 という「時間の濃さ」ベースのものだ。 つまり、「二ヶ月前だと思っていたら一ヶ月前のことだった」場合には「長い一ヶ月だった」を、「一週間前だと思っていたら一ヶ月前のことだった」場合には「短い一ヶ月だった」を使う。
しかし恐らく、実際には「この時間の過ごし方を続けたいか、続けたくないか」という時間の使い方に対する価値判断が紛れ込むだろう。 「早く終われ」と思って続けている日々なら「長い一ヶ月だった」になるし、「終わらないでくれ」と焦っていれば「短い一ヶ月だった」になる。
例えば、「目分量で二ヶ月かかりそうなタスクに対して一ヶ月しか与えられなかった」という気持ちがあれば、 「時間が足りなかった」という意味で「短い一ヶ月だった、あっという間だった」という発話がなされることはありえる。 ここではその一ヶ月がいかに濃密に過ごされていようが関係なく、「やるべきことがやりきれなかった」という無念感が強く出るだろう。
また、人との別れを惜しむときに、「初めてお会いしたのは一ヶ月前だったが、正直あなたとは一週間分の記憶しかない」というのは実際はそうであっても角が立ちすぎるので、一ヶ月分濃密な記憶があることを伝えつつ、上記のような「一ヶ月では全く足りない」という寂寥を伝えるために「長くて短い一ヶ月」のような不思議な言葉が生まれたのかもしれない。
人の欲に限りはなく、かつ時間が止まってくれないものである以上、たいていの人生は何をやっても「時間が足りなかった」ということになるので、「短かった」人生の方に偏るのだと思われる。いろいろな人生観があるものの、そうならないように時間の過ごし方を変えていくことが重要だと今のところは思える。
I agree with Dylan. pic.twitter.com/vVgve16MOF
— You Had One Job (@_youhadonejob1) 2016年10月19日
走るのが嫌い
走るのは昔からスポーツの中で一番嫌いで、やることが単調、テニスのような爽快感がない、汗だけかくのは損しているような気がする、などの理由からだが、ビーチで走るときだけはこういうネガティブな要素がなくて悪くないと思っている。Ocean Beachのような人のいない広い場所で、波音を聞きながら延々と走るのは、あまり苦痛ではない。とはいえ運動不足で、30分も走るともういいやとなるし、次の日には情けないことに筋肉痛になっている。
せっかくなのでトラッキングしようと思いとりあえずAndroidにStravaを入れて使い始めた。 Akihiko Satoda | Runner on Strava
これが機能的に他のアプリよりいいのかはよくわからず、サンフランシスコのミートアップでスピーカーの話を聞いたから身近になった、という以外のきっかけはない。知り合いにも使っている人がいて、見ていると走っている人もいるし自転車に乗っている人もいる。
継続する意志は正直そんなにないが、走るのが必ずしも嫌いじゃなくなっている自分がいるな、という発見。
Get Hands Dirty
今週はたまたま手を動かすミートアップが続いた。
- ブレッドボードでの回路制作のミートアップに行った。内容は簡単だが英語で聞くのは初めて。
- ドローン設計のミートアップに行った。
- レーザーカッティングの講習会に行った。
Get hands dirty! #lasercutting
英会話がきついが、とりあえず足を運んで人と目を合わせるってのがスタートでもいいじゃないかという気がしている。
技術メモを書く
クズでもいいから何かしらアウトプットするのは重要だという認識を今更ながらもち始めており、技術メモにもそれを試してみている。 とくに技術の場合は、忘れた技術をすぐに再現する必要があるときが往々にしてあるので、手順書としての記録が意味をもつ。 自分が時間を割くことになりそうなトピックを何かみつけたらKobitoでとりあえずQiitaのエントリを起こす。内容は試行錯誤のヒストリーを書いて、徐々に埋めていく。 やっていることが一気に扱うには大きすぎると感じてきたら適当なサイズに分割する。 書き始めはチュートリアルをやってみるとか、別の技術要素と組み合わせてみるとか色々あると思う。 そうやっていくつものアウトプットを並行で作って、最終的にpublishするのは1割もないが、0よりはマシだ。 Githubのリポジトリを作るのも同様によいかもしれない。
マイクロな思考
文章にしても技術メモにしても、つい何度も時間をかけて推敲してしまうのだが、それだと思考が追いつかないときがある。 正確には、アウトプットが思考に追いつかないということかもしれない。 周りが英語ばかりの環境に移ってからというのもあるが、単に歳のせいかもしれない。 人に見てもらえるように考えて整理して伝えるのは重要だが、整理や推敲を重ねる前の細かくアウトプットを重ねていくのも同じくらい重要だろう。 とりあえずマイクロな思考とでも呼んでおくが、それを出力する方法を考えている。 書かなければ揮発し、書いたそばからほとんど永続化していくような（イミュータブル？）思考・出力フロー。
ツールとしてはTwitter（それこそ昔はマイクロブログと呼ばれていた）がぴったりじゃないかという気がするが、ソーシャルな要素が気になりすぎて結局妨げになる。 次に自分がよく使うのはEvernoteだが、これはプライベートすぎる。Mediumは視覚的な美しさにこだわってしまうのでまたよくない。 とりあえずブログがいいような気がする。ブログは適当さを出しながらもアウトラインすることができる。こうしてはてなブログの新しい（古い？）使いみちを見つける。
