ラップトップで何でもやる時代に手書きマインドマップの話をしたい
新しい職場に転職して 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 に，という線引きをした上で，その間に落ちる，エンジニア業のことを書いていきたいと思う．
とはいえ，直接的なきっかけと言えば明日アップする記事をどうしても書きたかったという他に無いので，しっかり継続できるように話題のピックアップとか，やっていきたいと思う．
