はじめに
目次
- はじめに
- ブログ（記事21本）をふりかえる
- 登壇（5分間LT×2回）をふりかえる
- GitHubでの「草生やし」（100日間）をふりかえる
- おわりに
- Special Thanks to @kakakakakku
GitHubに草を生やして100日目の節目に
昨日、GitHubのコントリビューショングラフへの着色*1（いわゆる「草を生やす」）が5月3日から連続100日目を迎えました*2。
上記のツイートへの反響が大きくて驚いています。#100daysofcodeというのもありますし、100という数字にインパクトがあったのでしょうか。いずれにせよ、ひとつの節目になるこのタイミングでブログを書き残しておくことは、自分のために有意義であるだけでなく、少なからず誰かのためにもなるのだろうと感じさせられました。
アウトプット全体をふりかえる
草を生やし続けたことについての「ふりかえり」をしようと考えましたが、僕の場合はGitHubへのコミットは独立して存在するものではなく、当ブログを中心としたアウトプットの一環としての位置付けです。そこでこの記事では、ブログ、登壇、GitHubという3つのアウトプットを総体的にふりかえってみようと思います。
この100日間+αでのアウトプットは以下の通りです。これらについて、順にふりかえっていきます。
- ブログ
- 頻度：週1回更新
- 記事数：21本
- 技術記事：14本
- 登壇報告：2本
- イベントレポート：2本
- その他：3本
- 登壇
- 回数：2回
- 内容：
- 2018/6/26「行動を無駄にしないために必要なこと」
- 2018/7/27「httpモジュールから始めるNode.js入門」
- GitHub
- 草を生やした日数：100日
- コミット数*3：227コミット
ブログ（記事21本）をふりかえる
意図：技術の勉強を駆動する&長い文章を書くために
「エンジニアにとってアウトプットをすることが重要である」という趣旨の言説は、しばしば説かれ、少なからざるエンジニアにとって受け容れられているものと思います。あえて権威に訴えようとすれば、Matzの若手エンジニア向けの講演や、『SOFT SKILLS』を挙げることができます。
アウトプットの媒体として、やはり人気があるのはブログでしょう。ブログは簡単に始められますし、内容もタイミングも分量も自由、また顔も声も本名も出ない媒体ということもあって心理的なハードルが相対的に低いのも魅力です。
このような魅力に加えて、僕の場合は長い文章を書くことへの苦手意識があり、それを払拭するためにもブログというアウトプットを選択しました。このあたりについては、ブログの最初の投稿でも書いています。
週に1回、技術系の記事を書くことをノルマとしていました。イベントレポートなどは、あくまでオプションという位置付けに留めていました。その理由は、僕が「プログラミング大好き！」というタイプの人間ではなく、放っておくと開発手法や組織論といった方向に偏ることがわかっていたからです*4。
実績：投稿した記事を一覧にしてふりかえる
投稿記事一覧
更新頻度については、週1回のペースを守って合計21本の記事を書くことができました。「週1回」というのを「月〜日の間に1回」として、土日のどちらかに書くというのを原則にしていました。月曜日に投稿していることが何回かありますが、これらは全て「日曜日に書こうとして日付が回ってしまった」パターンです（翌日の月曜日、その後の1週間が辛かったことは言うまでもありません）*5。
内容についても、「技術系記事を」というのを概ね達成できました（記事の内容についての縛りを目標に追加したのは5月に入ってから）。7月最後の週に投稿した記事は登壇報告ではありますが、スライドの内容にソースコードが含まれているので技術系の投稿ということにしました。こうして並べてみると、Web系の技術、それにAWSについて中心に勉強していたことがわかります。Vue.jsの勉強は最近止まってしまっているので再開したいですね。
感想：ノルマは守れている。しかし、ただそれだけだ。
当初立てたノルマを守ることで、習慣になりつつあることはよいです。当初はまったく更新できる気がしなかったのですが、今では「あー書くかー」くらいの気分で書くことはできています。もっとも、辛いことにはまだまだ辛く、毎週苦しみながら書いているというのが正直なところです*6。
技術面の勉強を駆動するという意味でも、平日のうちに勉強しておかないと土日でネタを探すのは辛い*7ので、勉強のネタを探すようになりました。また、日頃のプログラミングの中でエラーに直面したときなどは、「しめしめ、これでブログが書けるぞ」と逆にポジティブに捉えられるようになりました。また、よく言われる「外部記憶装置」としての意義も大きく、一度やったはずのことを忘れてしまった時に自分のブログを見るという機会がすでに何度かありました。
課題は、「技術系の記事を週1」というノルマを達成することで満足してしまっていることです。何度かノルマを引き上げようか検討したこともあったのですが、結局このノルマに安住したままになっています。あくまでノルマなので、当人の心がけ次第ではあるのですが、実情として達成に資する技術系の記事の執筆だけにフォーカスしてしまっているのは確かです。
目標としたいのは、技術系の記事を定期的に投稿しながらも、それ以外の記事もバシバシ投稿するような状態です。記事の質については、上げようとするとペースの方が犠牲になる、あるいは嫌になってしまってブログ自体やめてしまう危険性があるので、当面は過度に意識することはしませんが、もう少しあげられたらとは常々思っています。
登壇（5分間LT×2回）をふりかえる
意図：コンフォートゾーンに留まらない
ブログは自分のペースで書けますし、読みたい人だけ読んでくれればというスタンスで、質をそこまで意識しないでいられます。当初は、ブログを書くだけでも精一杯だと思ったので、これでもよかったのですが、ブログを続けていくなかで、（ノルマを変更しなかったこともあり）自分に満足してしまいそうになっていました。
一方で、アウトプットの別の形として、登壇というのはかなり初期から意識していました。5月半ばに参加した「WEBエンジニア勉強会 #07」の最後に、OSCA（@engineer_osca）さんが勉強会の趣旨を説明されているなかで、登壇歓迎と仰ったのを聴いて以下のようなTweetを残しています。
三点リーダ×2が示しているように、このときは登壇に対してはあまり前向きではなかったと思います。しかしその後、「コンフォートゾーン」という言葉を目にするたびに、自分がアウトプットについてコンフォートゾーンに陥り、そこに留まってしまうことへの危惧を覚えました。そこで、ブログの次は登壇だろうということで登壇することを考えました。
実績：ブログの記事でふりかえる
6月末と7月末に1回ずつ、合計2回のLT（5分間）を経験しました。それぞれ、ブログ記事を書いています。
感想：登壇に必要な安心感、学生症候群
エンジニアにはブログを書く人は結構いる印象ですが、登壇する人はその中でもごく一部なのではないかと思います。登壇というのは聴衆の前に身を晒すことですから、（本名を明かす必要こそありませんが）ブログのような気楽さはありません。この心理的ハードルを乗り越える経験ができたのは収穫です。
「勇気を振り絞ってやってやった！」というような書き方をしましたが、登壇については安心して自らを晒すことのできる場の存在があって初めて実現したものだと思います。これまで登壇させていただいたのは、どちらも自分にとってそういう場でした。すなわち、過去のイベントに参加したことがあったり、中心メンバーの方*8と懇親会の場やTwitterなどで交流する機会があったりしたコミュニティです。いきなり見知らぬ人ばかりのイベントで登壇するのは難しくても、このような場で訓練を積んでからであれば心理的にも随分と楽になるのではと思います。
登壇をすることによって気付くことができたこともあります。1週間で1本のブログと異なり、登壇は1ヶ月くらい前から予定が決まるので、準備に使うことのできる時間が長くなります。したがって、ブログでは意識せずに済んだ自分の悪癖を嫌でも思い出させられることになります。それは、学生症候群です。夏休みの宿題に8月下旬まで着手しなかったり、試験前日に慌てて勉強を始めてしまうあれです。学生症候群については、7/27の登壇の報告記事でも書きましたが、これはブログだけやっていたら気付かなかったものだと思います。
感想ということからは少しずれますが、プレゼンという面で、とても印象に残っているのが、ajitofmの和田卓人（@t_wada）さんゲスト回です。テスト駆動開発の伝道師であり、プレゼンテーションの名手として知られる和田さんが、どのようにプレゼンの準備をしているのかを語っています。準備の重要性というのはよく知ってはいますが、登壇をすることでより実感しますし、準備をすることが簡単ではない（単に時間をかければいいというものではない）こともよくわかりました。
GitHubでの「草生やし」（100日間）をふりかえる
意図：技術から逃げないこと。Write Code Every Day
ブログで技術系の記事を書くのと同じで、技術から逃げないために続けていました。開始当初の下記の記事でもその旨が表明されていました。
技術で解決されるべき問題をエモい話で解決しようとしてしまったり、業務で与えられた技術的課題を自分の技術力の不足によって解決できなかったりするという怖れがある以上、技術の勉強をすることは不可欠だなと考えています。
フロントエンドの勉強としてGitHub PagesでダメWebサイトを公開してみました - こまどブログ
また、Write Code Every Dayというキーワードにも強く背中を押されました。このキーワード自体は、以前から知ってはいましたが、GitHubに草を生やしはじめてから「やってみよう」と思いました。
おじさんになるのも怖かったみたいです。
実績：コントリビューショングラフとTweetでふりかえる
書いたコードの内容は以下の通りです。
- 静的Webサイトの入門（HTML、CSS、JavaScript）
- Vue.js（基本文法、Vue-CLI、Vue-Router、Vuexなど）
- Webpack
- AWS Lambda（言語はNode.js、扱ったのはDynamo DBやAPI Gateway、LINEとConnpassのAPI）
- Code Kata（JavaScript、Ruby）
開始直前〜継続期間中のTweetも載せておきます。
- 【2018/4/28】 Git/GitHubの使い方を学び始める
- 【2018/5/3】GitHub Pagesに草を生やす（翌日にブログ投稿）
- 【2018/5/21】自戒する
- 【2018/6/22】8週間を達成（継続のために毎日の時間を短縮している）
- 【2018/8/10】100日間を達成
感想：「草」を目的にすることの功罪
「草が生える」というのは、モチベーションとしてはかなり大きく作用したと思います。途中で何度もコントリビューショングラフのスクショをとって嬉々としてTwitterに貼っていました。他人に見てもらいたいという気持ちが強かったと思います。動機としてはあまり褒められたものではありませんし、そのための弊害も後述するようにありましたが、「草を生やしている自分に酔う」というのはそれなりに使い道のあるものです。
GitHubでの「草を生やす活動」については、良かったことと悪かったことがはっきりあります。まず、良かったこととしては、以下の2点が挙げられます。
- ブログで技術系の記事を書く準備になった
- 朝の時間を有効活用できるようになった
「草を生やし続ける」ということは、毎日コードを書くということです。毎日コードを書くことで、ブログに書く材料を継続的に供給することができました。土日だけでネタを探すのは辛いというのは先述の通りですが、平日にも毎日コードを書いていると何かしらネタにはなるわけです。言い方を変えれば、ブログ執筆における学生症候群を防いでいたとも言えるかもしれません。
また、夜は飲み会などがあって時間を確保できない、場合によっては日付が変わってから帰宅することもあるということで、コードはほぼ朝、会社に行く前に書いていました。始める前は、朝は寝坊したり、ネットサーフィンしたりと無駄に使っていたことも多かったのですが、コードを書くようになって有意義に使うことができるようになりました。
一方、悪かったことは以下の2点です。
- ネタが断片的になった
- 「草の生えないこと」をしなくなってしまった
毎日書くというのはハードルが高く、続けるために1日あたりの時間は少なくせざるを得ませんでした。じっくり設計について考えたり、方針を考えたりする機会を設けることもしませんでしたから、必然的に書くコードは場当たり的になります。100日間続けた割に、技術を身につけたという感覚に乏しいのは、このあたりの事情もあるでしょう。
また、「草を生やす」を目標にしてしまったことの弊害もありました。最も大きいのは、「コードを書くことではあるのに、草は生えないこと」をしなくなってしまったことです。ブログでも書いたように、UdemyのVue.jsのコースを受講していました。このコースは、講師のGitHubリポジトリからプロジェクトの土台のソースコードをクローンし、そこを編集することで進めて行くものです。しかし、GitHubの仕様上、他人のリポジトリからクローンしたものへのコミットはコントリビューション扱いにならず、草が生えません（当然といえば当然）。
6月半ばごろまでは、Udemyのコースの勉強も進められていました。しかし、少し忙しくなってきてから、これは一番最初に生活から抜け落ちました。理由は当然、それが「草の生えない活動」だからです。講師の方の説明もわかりやすく、実践的な内容でもあったUdemyのコースは、自分としてもモチベーション高く取り組めていたはずのものでした。そうであるにもかかわらず、「草」を優先したのは、もちろん「草を途絶えさせたらコードを書くのをやめてしまう」という危惧があってのことでしたが、このような選択をすることになったノルマの設定の仕方が悪かったことは疑いようがありません。
おわりに
以上、ブログ・登壇・GitHubの3つに分けてふりかえってみました。最後に、全体的な感想と、今後のアクションについてまとめておこうと思います。
全体的な感想
ノルマとして設定したものについては、守ることができている印象を持ちます。もちろん、今回「ノルマ設定した」と書いたこと以外に、Twitterやら何やらで「こうしていく」と宣言したことで、実際にできていないこともあります。しかし、毎日コードを書き、週に1回ブログを書くという明白で基本的なノルマを守ることができたのは、自信になりました。これからもノルマをうまく設定して取り組んでいこうと思います。
一方で、質については修正が必要です。これまでは頻度を維持するため、質を問うことはしてきませんでしたが、習慣化ができつつあるので、既に習慣になっている部分を中心に質も向上させたいです。そのためにも、場当たり的な記事・コードではなく、ある程度の計画をもってアウトプットを組み立てていきたいです。
今後の方針
下記をアクションプランとします。
- ブログは週に2本で、1本は技術系の記事（2本目は、イベントレポート、書評、雑記など、何でも可）を書く。
- ブログはすぐに公開せず、必ず推敲する（上から下まで読み通して修正し、修正点がなくなるまでこれを繰り返す）。
- 2ヶ月に1回は登壇する（ジャンルは問わない）。
- 1週間に4日はプライベートで1ポモドーロ以上コードを書く（草には拘らず、Trelloで管理）。
ふりかえってみて感じたこと
最後に、今回の記事を書こうとしてみて思ったことを。アウトプットのふりかえりというのが今回の趣旨ですが、ふりかえろうとして思ったのは次のことです。
ブログとGitHubでのアウトプットについては、習慣化というのを強く意識したものでしたが、ふりかえりを同時に習慣に組み込めていなかったのは失敗でした。今回の記事が書きづらかったこともそうですが、ここまでに書いてきた反省点の中には、もっと早く自覚し、修正するアクションを起こすことのできたものも含まれています。
ふりかえりを習慣にするというのは、何度も何度も決心し、その決意を周囲の人に伝えることまでしていたにもかかわらず、結局できずにいることです。もちろん、日々行動しながら「今のはよくなかったな」とか「うまくいっていないな」とかは感じていますが、それは一過性のもので、すぐに忘れてしまいますし、アクションに繋がっていきません。
今回書き出してみて、一度感じていたはずなのに忘れていたことをいくつも思い出しました。おそらく、思い出せていないものもあるはずです。やはり、ブログの記事という形をとるかはともかくとして、「定期的に」「アクションプランを伴って」ふりかえりを行うことが必要だと思いました。
というわけで、アクションプランを追加します。
- ブログは週に2本で、1本は技術系の記事（2本目は、イベントレポート、書評、雑記など、何でも可）を書く。
- ブログはすぐに公開せず、必ず推敲する（上から下まで読み通して修正し、修正点がなくなるまでこれを繰り返す）。
- 2ヶ月に1回は登壇する（ジャンルは問わない）。
- 1週間に4日はプライベートで1ポモドーロ以上コードを書く（草には拘らず、Trelloで管理）。
- 1ヶ月に1回ふりかえりの記事を書く（その週の2本のうちの1本としてよい）。
- 月次のふりかえりでは方針の見直しを必ずする（これ自体も見直す）。
この記事を書いていたら、土曜日が終わってしまいました（扱う対象も記事自体も大きすぎる）。コードを書いていないので、GitHubの草も途切れました。変なものに執着しても仕方がないので、来週から上記の方針でまた気分を入れ替えて頑張って行こうと思います。乞うご期待。
カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで
- 作者: 市谷聡啓,新井剛
- 出版社/メーカー: 翔泳社
- 発売日: 2018/02/07
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉
- 作者: 湊川あい,DQNEO
- 出版社/メーカー: シーアンドアール研究所
- 発売日: 2017/04/21
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (3件) を見る
- 作者: ジョン・ソンメズ
- 出版社/メーカー: 日経BP社
- 発売日: 2016/06/02
- メディア: Kindle版
- この商品を含むブログ (6件) を見る
エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESSプラスシリーズ)
- 作者: 西尾泰和
- 出版社/メーカー: 技術評論社
- 発売日: 2018/08/10
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
Special Thanks to @kakakakakku
僕がアウトプットについてふりかえるとき、欠くことのできない人がいます。それは、カカカカック（@kakakakakku）さんです。ここまでの記事では、彼への言及は全て脚注に落としておきましたが、それは本文に出すと「アウトプットのふりかえり」という記事の趣旨がブレるからです。とはいえ、最後に言及しておかなければなりません。
ブログを書こうと思ったきっかけをくれたのも、マネジメント方面に傾く僕に敢えて技術系の記事を書くように勧めてくれたのも、ブログの書き方を教えてくれたのも、困ったときにネタを提案してくれたのも、登壇に向けて背中を押してくれたのも、カカカカックさんです。僕がアウトプットを曲がりなりにも続けられているのは、カカカカックさんのおかげです。感謝します。思い切ってお願いして良かったです*9。
*1:本来は他人のリポジトリへのプルリクエスト等で「貢献」した実績がこのグラフに表れるべきなのでしょうが、僕の場合はすべて自分のリポジトリへのコミットだけです。OSSコントリビュートもできるようになれるとエンジニアとしては一段階上がる感じがしますが……
*2:アクセスしてみると、6/1については草が生えて見えるときとそうでない時があります。この日は、他のユーザからリポジトリをフォークして、そこに対して修正を加えていた日で、厳密には草を生やしたことになるのか怪しいのですが、実態としてコードを書いてはいたのでアリとしています。
*3:自分のリポジトリに対してなのでこの数字に意味はありませんが。
*4:この傾向は自覚はしていましたが、それを踏まえて「技術系を週1」というノルマを提案してくれたのはカカカカックさんでした。
*5:日付が変わってしまって月曜日から寝不足で会社に行くのはサラリーマン的には褒められた行為ではありませんから、合理的な判断としてブログを翌日に先送りする選択をすることもできたと思いますが、ブログを書かないと眠れないのです。
*6:三大欲求の一角を「ブログ欲」が突き崩してしまった方も世の中にはいるようですが……。
*7:カカカカックさんからも指摘を受けました。
*8:『カイゼン・ジャーニー』の著者の市谷（@papanda）さんと新井（@araratakeshi）さん、WEBエンジニア勉強会のOSCAさん。
*9:5月から2ヶ月間、「ブログメンティ」として上記のようなサポートを受けました。その内容については、他のメンティのみなさんが卒業エントリとして書いているものをご参照ください。
