エンジニアの一番の基礎体力はタイピングスピードだという話
転職して8ヶ月ほどになるかと思うが，今年も新卒のメンターになる運びとなった．
今年も新卒のメンタリングをして改めて思うのは， エンジニアにとっていくつかある基礎体力のうち，一番最初に伸ばせるのに誰も本気で取り組まないのがタイピングスピードだということ だ．
日本のスポーツや武道の世界に「心技体」という言葉がある．競技を行う上で，精神力 (心)，技術, 体力の3つが大事になるという話だが，このうち入門者に一番最初に求められるのは「体」だと思う．
技術を磨くには圧倒的な鍛錬の時間が必要だが，この鍛錬を積むためには体力がなければいけない．*1
かつて，横浜ベイスターズに石井琢朗という選手がいた．彼が引退するにあたって，とあるプロ野球 OB によって書かれた 『66番だった』という記事が個人的には非常に印象的だ． ameblo.jp 石井琢朗はもともと投手として横浜大洋ホエールズに入団したのだが，後にシーズンオフの秋に野手転向が決まると，そこから朝も夕方も夜間も特打，特守と嵐のような練習量で，翌年の終わりには三塁手の定位置を獲得していた，という話．
翻ってエンジニアはどうかというと，やはり誰かのコードを読んで，自分でコードを書くことが一番の練習であり実戦である．同じ1時間*2で，100 行しかコードを書けない人間と，500行書ける人間では，間違いなく後者の方が圧倒的に成長する．
こういう話をすると，「でも500行に渡って中身のないコードを書くことに意味があるのか」とイチャモンをつける気持ちも芽生えるが，ここで言いたいのは500行の中身ではなく，どれだけのサイクルでどれだけの量のフィードバックサイクルを回せるかという話である．タイピングスピートがあるエンジニアは，自分のアウトプットに対するフィードバックを受けた後，それをすぐに解決することが出来る．すると次のフィードバックがやってくるから，また次の成長機会がやってくる．
そう考えると，たとえクソコードでも，間違いなく1時間に500行書けるエンジニアの方が成長するに決まっている．
キーボードという入力デバイスを用いて何かを書く作業の行う上での究極の理想は，「思考が寸分の遅れもなくエディタ上に実現すること」だ．そうすれば自分の書いたコードをコンパイラに食わせること，テストコードに通すこと，環境にデプロイすることまでのオーバーヘッドとなる時間も無くなる．将来，音声入力の精度が高くなれば僕は音声入力を使うだろうし，脳波を探知して入力してくれるデバイスがあれば間違いなくそれを使うだろう．*3
そのためだったらキーボード上でホームポジションから指を離さない指運だって鍛錬すべきだし，少しでもホームポジションから手のひらを動かさずにタイプ出来る英字キーボードを好むべきだし，「思考の速さで編集する」ことを目的に，自らの使うツールの効率的な使い方に鍛錬するべきだと思う．
ちなみに，宗派戦争に巻き込まれるのはごめんだから深くは書かないが，自分のこれまでのエンジニアとしてのキャリアで効果があったのは，Vim のコマンドにある程度精通したことだと思う．一通りのヤンクの操作とテキストオブジェクトを使いこなすことで，間違いなく生産性は 2.5 倍以上は上昇したと思う．
- 作者: ＤｒｅｗＮｅｉｌ,新丈径
- 出版社/メーカー: KADOKAWA / アスキー・メディアワークス
- 発売日: 2014/01/28
- メディア: Kindle版
- この商品を含むブログ (4件) を見る
Git / GitHub 初級者をメンタリングするときに考えていること
Git や GitHub を全く触ったことがない人や，使ったことはあるけど複数人でのチーム開発で読みやすさやレビューしやすさを意識した運用をしたことがないエンジニアや，エンジニアの卵のメンターになることが多いので，自分なりのポリシーをメモ程度に列挙してみる．
もちろん，プロジェクトでポリシーが決まっていればそれに従うべきだが，自分が今いるチームや，これまで所属してきた組織では「なんとなく」でしか決まってないので，そんなチームでメンタリングするときは，「どんな現場に行ってもある程度はしっかりできる素地」みたいなのを意識している．
半分くらい http://qiita.com/meganemura/items/8a034e2065b299135c87 の焼き直しになってしまっているけど，気にしない．
ポリシーに「必須度」を付けているが，おおよそ以下のような感じ．メンタリングする時は，まず必須度 A が出来るように，少し口うるさくでも言う．本人が，自ずと他のエンジニアとのコラボレーションを気にかけるようになったら，B や C の内容をヒントとして与えていくイメージ．
- 必須度 A : 必ず守る
- 必須度 B : 難しいケースもあるけど，守れるなら守る
- 必須度C : やってあると嬉しい
コミットメッセージのフォーマット 編
1行目は，行った変更のサマリーを 100 文字以内で書く．(必須度: A)
100 文字というのはおおよそだけど， GitHub 上で 120 文字？あたりで折り返されちゃうみたいなので，長くならないように意識している．
PR 画面のコミット一覧で見栄えがすればよれでよし．
2行目は空行，3行目以降に必要であれば詳細を書く (必須度: C)
2行目空行は異論ないと思う．
ちゃんとしたプロジェクトだと，3行目以降に書くことのフォーマットが決まってたりすると思うけど，ここはメンバーの善意に任せている感じです．
でも，個人的には，例えば不具合の改修で，修正した場所と，実際に起きた不具合の根本原因の箇所が遠い場合などは，後からコミットログを読んだときにどういう問題に対処する修正なのかが分かるように，意図を説明するようにメッセージを書いたりしています．
内容のないコミットメッセージを書かない (必須度: A)
「コンフリクトを解消」とか「修正」とかっていうコミットログをやめましょう，という話です．初歩的だけど，技術ではなく姿勢の問題なので，1行の変更でも，何が問題で，何が間違っていたので修正したかを説明するようにします．
コードレビュー後の「指摘事項修正」も，レビューを受けてどういう問題を直したのか，というのが分かるようにしたいですね．
コンフリクトの解消に関しては，「それを言うのは初心者には酷じゃ…??」と思う方が多いと思います．自分もそう思ってて，他のエンジニアの作業と大きくバッティングするようなタスクを渡さないとか，大きすぎて長く時間のかかるようなタスクはそもそも振らない，というメンターの問題だと考えています．メンティーの状況に応じて， rebase を教えるチャンス，とも捉えることも出来ると思います．
句点やピリオドは使わず，英語なら命令形，日本語なら「xx した」と書く (必須度: A)
自分のコミットログを見返すと，守ってないケースもあるけど…
英語のコミットログだと，「主語を使わず現在形の動詞から始める」「ピリオドで終わらない」というのがよくある規約です．英語の場合はこれを守るのですが，
日本語の場合だと，やはり主語は使わず，「xxx をした」で終えるようにしています．これは「xx する」でも「xx しました」でも良いと思いますが，プロジェクト内で統一されているべきですね．
ソースコード生成のコマンドがある場合はコミットメッセージに含める (必須度: C)
これはできればで良いのですが，例えば Rails の bundle install ... や rails generate scaffold ... は，可能であればコミットログに含められると，後からそのコマンド自体にも問題は無かったのかなども振り返ることができます．
コミットの作り方
自動生成や Initial Commit 以外で巨大コミットを作らない (必須度: A)
どれくらい，という指標はないのだけど，「ついでに xx も直していっしょにこのコミットに入れました！」みたいなことをやっているのを見つけたときは，早めに指摘をするようにしています．
どのコミットタイミングでも，ビルドやテストはすべて通るようにする (必須度: B)
可能であれば，ですが．
アプリケーションやシステムの挙動を変えるコミットと，挙動を変えないコミットを分ける (必須度: B)
リファクタや不要な変数や文の削除などは，それだけでコミットを作るようにします．レビューの対象になる主変更はそれだけでコミットをするようにすると，レビューがし易いですね．
例えば，新しい API の追加をする際に，既存のコードやテストコードをリファクタして拡張性を担保して，新しい API を追加するという手順を取る場合，リファクタのコミットと API の追加のコミットを別にします．
このように作業するように心がけると，未使用変数の削除などのコミットは眺めるのに2秒もかけないで済むし，最初のリファクタに問題点はないのかの観点でもレビューされやすいし，追加した API が妥当かのレビューに注力し易いです．
新しく追加した class や API に対するテストは，同じコミットにする (必須度: B)
例えば 「xxx クラスを追加した」というコミットの後に 「xxx クラスのテストを追加した」というコミットをつけるのではなく，この2つは一つのコミットにすべきです．
ひとつのコミット内容を見たときに，追加した API やクラスと，その使い方を示したり正しさを保証しているコードは一緒になっているべきだと考えるからです．
ブランチ / PR 運用
PR は小さく．
これは，「どれくらい」というのが言えないので必須度が付けられないのですが，やはりなるべく1つの PR は小さくある方がレビューしやすいです．
利用している言語によっても違うのですが，普段の自分は Scala プロジェクトで 300 行を超える変更が生じると頭を下げながらレビュー依頼を出し，700 行を超える PR はほとんど作っていない…はず…
Java だとボイラープレートが多いので，1,000 行超えるケースもあるかな，という感じです．
マージ先ブランチ上に rebase してから PR のレビュー依頼を出す (必須度: B)
大きい修正をするときにはどうしても競合は起きがちですが，先にあった「意味のないコミットログを作らない」という観点からも，更新されたマージ先のブランチに rebase したものをレビューに出すようにします．
先にも振れましたが，メンティーに仕事を振るときのメンターの気の遣いどころでもあります．
人によっても違うと思うし，書き忘れているところもあると思いますが，僕は上記のような感じでやっています．
皆さんはどうですか？
ラップトップで何でもやる時代に手書きマインドマップの話をしたい
新しい職場に転職して 3 ヶ月経ったが，仕事をする上で明らかに使うことが増えたのが手書きマインドマップだ． 今日は，なぜ手書きマインドマップを使うケースが増えて，僕がどう使っているかについて書こうと思う．
なぜ最近になって手書きマインドマップを使うようになったのか
エンジニアに Macbook が，ビジネスに Thinkpad や Let's Note が支給される会社に転職したのが一番の理由だと思う．
前職のオフィスは据え置き PC が配置されており，会議や打ち合わせは誰かの PC にリモートで繋いでアジェンダや資料を大画面で一緒に読み合わせたり，資料の印刷をしていたのだが，今の職場では誰もが会議室や講堂にラップトップを持ち込む．
しかし，やってみて気づいたのは，少し自分に関係ないトピックになるとすぐに内職したくなってしまうのは自分だけではないことだった．特にエンジニアだと，会議が始まる前に書いていたコードが気になってしまうのは仕方が無い側面もある．
逆に話す立場からすれば，本当にこの人は話を聞いているんだろうかと疑う気持ちが芽生えてしまうことも無いわけではない．現に，自分は転職活動をしている中でいろんな企業の面接官がラップトップをカタカタやっていたのが結構気になっていたし，間違いなく自分の話に興味があるであろう採用面接というシーンですらそういう風に感じる人がいるということは，ラップトップを開いていないということが話を聞いている姿勢を表すのに一番効果的なのかなと思うようになった． (議事を取るときだけはしっかり断りを入れてラップトップを開いてメモを採るようにしている)
とにかく話し手聞き手どちらにとってもラップトップがあることで会議の生産性はきっと下がってしまうと感じて，極力手書きで会議に参加しようと思い始めて，その際に便利だったのがマインドマップだった．
また，考え事をするのに PC にメモを書いているだけだと気が散ってしまうので，ラップトップを閉じて考える時間を確保するための手段であったことも理由としてあげることが出来る．前職ではメールだけだったのが，新しい職場に移って Chatwork や Slack まで飛んで来るようになって，ラップトップを閉じるときには閉じるという習性が身についたのだと思う．
手書きマインドマップの良いところ
自分なりにマインドマップの気に入っているところを挙げると，以下の3つが大きいと思う．
順序のない非構造データ
前職のときまでは，こういうブレーンストーミングをするときには箇条書きでひたすら書いていくことが多かったのだけれど，それと比較してマインドマップが良いのは，項目と項目のネットワークによる構造データでありつつ，順序性が無い点だと思う．
一直線に話が進んでゆく文章や，一方向に項目を並べていく箇条書きでは，当然ながら重要なものが最初に来るべきである．それと対比して，思いつきというものは重要な順に出てくるとは限らないし，人に文章やプレゼンで説明するときには順序を変えるだけでストンと腑に落ちるケースが多い．だから，思いついたことをひたすら書くフェーズの後に，順序などの構成を考えるという作業にマインドマップは効率が良い．
書くことで気持ちが落ち着く
文字に落とすことなく，気持ちや頭のなかで整理できないまま不安や不明点を抱えていると，それ自体の不安が雪だるま式に大きくなってくることがある．それをきちんと紙の上に落とすことで，どこからどこまでが不安だったのかの境界線が，少しだけ客観的に分かるような気がする．
自分がこういう手段を取るようになったのは，ファーストリテイリングの柳井さんの本にあった「若かった頃に，夜中仕事で不安になったら逃げないで不安に思っていることを紙に書く．そうすると"なんだ，こんなちっぽけなことで悩んでいるのか" という気分になる」という旨の記述を読んでからだった．
「そんな簡単な方法で…」と読んだときには疑ったものだったが，いざやってみるとうまくいくから不思議である．
やり方に制限がない
アナログなツールであるからこそ，やり方に制限がない．マインドマップの Mac アプリケーションや Windows アプリケーションも数多くあるし，自分も使ったことがあるが，自分の気持ちや思いつきのままに好きな構造，好きな文字の大きさでぱぱっと書けるのは思考を妨げないので，個人的には手書きが良いんじゃないかなぁと思っている．
むらみん流手書きマインドマップ
マインドマップの使い方など，市販の書籍やネット上を漁ればいくらでも出てくるのだが，ここでは，今回のブログ記事を書くときに使ったマインドマップを題材に，自分なりのやり方を3つ挙げる．
始点は少し左側に置く
右利きの場合，右から左に線を引くより左から右に線を引く方が間違いなくナチュラルだし，何も制限がなければ線は左から右に書きたくなる．自分の場合，中心にスタートを置いてマインドマップを書き始めても，左半分は本当に真っ白になってしまう．
物の本に当たると，マインドマップは中心から始まって広がってゆくのが大事とかいう説もあるが，きれいに書くのが目的ではないので個人的にはどうでも良い．
ゴールを決めて，遠いところからも始める
この記事を書くに当たってのマインドマップはそれほど明確で難しいゴールがあったわけではないが，例えば「現状煩雑なサーバーの運用を簡単にするにはどうしたらよいか」とか「チームが上手く回っていない気がするのはなぜか」みたいな，ちょっと複雑だったり難しいトピックとなると，ゴールありきではあるものの，導きたい結論は一旦抜きにして現状認識から始めたり，逆にゴールを噛み砕いたりを繰り返して，お互いがつながるポイントを探したりする．そうすると，「一つの武器で2つの問題点が解決する」みたいな状況が見つかったりする．
色ペンを必殺技にする
今回のマインドマップでは「ブログの構成を決めて文字起こしに着手する」というゴールがあったので，書きたいトピックをひたすら書き出した後，順序を決める段階になって色ペンを持って話すべき順番を色付けしていった． 基本的に思いついた順に上から書き出しているのだが，振られた数字を見れば，必ずしも思いついた順に数字が振られているわけではないことがわかると思う．
さいごに
自分は前職の上司にマインドマップを教えてもらったときに，すぐに本屋でトニー・ブザンの本を買って読んだのだけれど，当時は「モワッとしたことしか書いてないなぁ」くらいの感想しか持たなかったけれども， 各個人なりのやり方があるのが前提として，とはいえ使い方の手本や型を学ぶという意味では発案者が書いたもの以上は無買ったのかなぁと思うので，そんな本を紹介してこのブログの結びとしようかと思います．
「プログラマの三大美徳」と「HRT」を使い分ける - 「コードを憎んで人を憎まず」
TL; DR
「プログラマの三大美徳」はソフトウェアに向けるものであり，人に向けるものではない．
「HRT」は人に向けるものであり，ソフトウェアに向けるものではない．
プログラマの三大美徳
プログラマの三大美徳というものがある．Perl を開発した Larry Wall が提唱したもので，「怠慢」「短気」「傲慢」からなる．
詳しくは上述のリンクにある各解説記事に譲るのだけど，例えば「怠慢」とは，「エンジニアとして手間を省くために最大限の努力をする気質」を指す．元の Larry Wall の記述では当たり前過ぎて省略されているのだけど，「最大限の努力」とは「仕事をしないために交渉する努力」ではなく「技術で手間を解決する努力」を指すものだと思われる (勿論，場合によっては前者が大事になるケースも有るのだけれど) ．
「プログラマの三大美徳は "怠慢", "短気", "傲慢" である」というワーディングは非常にキャッチーであり，それが故に誤用されることがあるのかなぁと思うのが私の問題意識である．「(プログラマ | エンジニア) は (怠慢 | 短気 | 傲慢) じゃなきゃね」と言い始めてしまい，その本質を見失ってしまうケースに遭遇したことが少なくない．ビジネスチームの依頼に対する態度に (怠慢 | 短気 | 傲慢) さを出してしまったり，，ユーザーファーストで考えなきゃいけない状況でエンジニアファーストで (怠慢 | 短気 | 傲慢) さを表に出してしまったり，という様子を目にしたことや，自分のことを振り返って思い当たる節があるのは，私だけではないと思う．
こういう道徳的な話は言葉にしてしまうと当然なことにしかならないし，「自分はそんなことない」と思ってしまいがちだけど，こういう誤解をして間違った (怠慢 | 短気 | 傲慢) をまとっているときこそ，理性を失って正しい選択を出来ない状態になっていはずだ．常日頃から「自分はプログラマの三大美徳を勘違いしていないか」を問いかけるべきだと思う．
HRT
一方で，プログラマやエンジニアが人に対して持つべきマインドセットを表すものとして有名なものに HRT がある．『Team Geek』という本で「優れたチームが優れたソフトウェアを作るのに必要な三本柱」として紹介されているもので，「謙虚 (Humility)」「尊敬 (Respect)」「信頼 (Trust)」の頭文字を取ったものである．
HRT が大切というのは自明というか当然なのだけれども，HRT は人 (チームメンバー) に対して適用するべきで，チームのソースコードに適用するべきではないことには少し気をつけるべきだとも思う．
それまで本番で大きな問題なく動いているコードだからと「尊敬」を持ってリファクタやアーキテクチャの見直しを躊躇ったり，テスティングの不十分なコードはきっと動くはずと「信頼」してデプロイした後に毎度手動で動作確認をしたり，というのは間違った HRT の使い方である．
特に，自分よりも経験のある，尊敬するエンジニアが書いたコードだからと遠慮してしまうことが，自分にはよくある．しかし，彼 / 彼女が書いたコードが必ずしも正しい解決策とは限らないわけで，変に遠慮せず自分が正しいと考えていることをしっかり (HRT を持って) 議論する姿勢が大事だと思う．
コードを憎んで人を憎まず
こういう文脈で，前職時代に後輩に一度話したことがあるのが，「コードを憎んで人を憎まず」という言葉である．
自分がこの言葉を口にするようになったきっかけはいろいろあるのだけれど，大学時代のゼミ教官がディベートや卒業論文の中間発表をするときによく口にしていた「論を憎んで人を憎まず」というモットーが自分の中でのルーツなのかなぁと思う．
特に卒業論文の中間発表では，中途半端なものやツッコミどころをたくさん抱えたものが出てきたときは，教官もゼミメンバーもバンバンと叩かなきゃいけないのだけれど，このときに人格否定になってはいけない．ゼミメンバーはお互いリスペクトを持ち，2年間のゼミ活動が最後まで円滑に進めるために必要だったのが「論を憎んで人を憎まず」の精神だったのだと思う．
この精神はアジャイルチームにも全く同じことが言えて，チームは一度コードを書くだけで終わるのではなく，プロダクトが続く限りは続くのだから，チームメンバー間の HRT を保ちつづける姿勢は非常に重要だと思う．
ということで，2017 年は去年よりも更に，チームが正しい場所で「プログラマの三大美徳」を発揮し，正しい場所で「HRT」を発揮できればなと思う．
Tech と Poeme の間とは
TL; DR
このブログの目的を書く．
About this blog
「TechとPoemeの間」とは，自分がエンジニアとして働く中で考えていることを書く場所として準備したはてなブログである．
なぜ新しくブログを建てるのか
これまで，高校時代は Livedoor Blog, Oricon Blog, SpoNavi Blog と渡り歩き，社会人になってからは Blogger, はてなブログ，Ameba Blog と使ってきた中で，なぜまた新しくはてなブログを建てるのか，という話になると思う．
自分が現在書いているブログは，主に趣味の野球観戦のことを書く ベイファンとITエンジニアの狭間で と，仕事の雑感や，気持ちの面での振り返りを書く むらみのもくめ がある．
Ameba blog ではない理由
特に，昨年の転職を機に，自分の勤務先企業が運営しているプロダクトを触ろうと Ameba Blog を始めた．しかし，実際に書いてみてわかったのは，Ameba Blog は気軽なエッセイを書くためのものであり，順を追って組み立てた文章を書いたりするのには向かないし，当然プログラミング言語のシンタックスハイライト機能も無いので，エンジニアが仕事の話を書くにはあまり向いてないんだなぁ，ということだった．
Qiita ではない理由
技術的な話は Qiita に書いてきたし，今後もそうするつもりなのだけれども，必ずしも Qiita が適切ではない話も多い．例えば，昨年末に書いた 3回目の転職活動で初めて転職した話 - Qiita は，転職の話であり，エンジニアのキャリアの話であるから，正直 Qiita に書くのは不適切なのかな，という気が今でもしている．それでも，自分が持っているブログやメディアで適切なものも見当たらなかったし，Qiita の Advent Calendar のエントリとして書いた記事だったので Qiita に書いた．
これからも，「こういう技術的なトライをしてみたい」とか，チームマネジメント，アジャイルチームのファシリテーションとか，エンジニアという仕事をする上での気持ちの持ち方，考え方などについて文字にする場所が欲しいと思ったのが，今回のブログを建てた一番大きな理由である．
自分が技術的に突出した存在でなくても仕事ができているのはメンタリティの部分が大きいと思っているし，チームのコミュニケーションを回したり，チームの生産性を最大化させるためにどういうトライをしているかというのをを，文章にすることで整理できたらと思っている．
ということで
タイトルにある「Tech と Poeme の間」というのはそういうことで，技術的な知見や Tips はこれまで通り Qiita に，エモくて秩序立てていない文章は Ameba Blog に，という線引きをした上で，その間に落ちる，エンジニア業のことを書いていきたいと思う．
とはいえ，直接的なきっかけと言えば明日アップする記事をどうしても書きたかったという他に無いので，しっかり継続できるように話題のピックアップとか，やっていきたいと思う．
