日々の学習が進むようになった「タスク管理」のルール

子供もすでに６ヶ月目に入り、寝返りが上手になってきました。この半年を振り返ると、子供との時間が一気に増えたことが大きい変化です。必然的に自分の時間は減ったわけですが、最近自分に課したルールのおかげで、以前よりも日々の学習は進んでいます。

※注：以下のルールは自分に当てはまったというだけで、他の人に当てはまるとは限らないことに注意してください。

目次

ルール

自分が設けているルールは以下です。「６つもあるのか...」と思いがちですが、一つ一つはシンプルなのでそこまで複雑ではありません。

• 10-20分単位のタスクに分割する
• タスクが大きいと思った瞬間に分割する
• タスクに優先順位をつける
• 進行中タスクは一つまで
• スプリントは一週間
• スプリントのタスクを終わらせたら好きなことをして良い

スクラムを学びたいと思い、いくつかの本やサイトを回った結果、「個人学習のタスク管理にも使えそうな要素があるな」と思ったのがきっかけです。結果的には書籍に書いてあるようなありふれたルールですが、自分には合っていました。

一つずつ説明し、その効用も書きます。

10-20分単位のタスクに分割する

学習したい項目を「10-20分単位のタスク」に分割します。例えば、実際にやっていることの一つに「読みたい本のKindleの位置Noを200毎に分割する」があります。以下のような形です。

一冊の本を「位置Noの200毎」にタスク分割した様子

その他の学習タスク（個人開発など）も10-20分単位で分割します。分割の効用としては、

• やることが明確になる
• 着手までのハードルが下がる
• タスク完了の頻度が上がる（Doneにする時は気持ちいい）

の３点が挙げられます。

タスクが大きいと思った瞬間に分割する

一旦タスクを分割しても、いざ着手しようとすると「何をしたらいいんだっけ？」と疑問に思ってしまい、なかなか着手できない場合があります。また、着手しても終わりが見えず、ダラダラと進めてしまうこともあります。こういうときはタスクが大きいことが原因なので、気づいた瞬間にタスク分割作業に入ります。何よりも優先して分割作業をします。効用は、

• 分割することで「10-20分単位のタスクに分割」の効用を得られる

です。

タスクに優先順位をつける

分割したタスクには優先順位をつけます。細かく分割すると膨大なタスク量になりますが、優先順位は必ずつけます。自分がやりたい学習の順番でもよいですし、複数の大項目がある場合は、それらのタスクを織り混ぜる形で順番に並べても構いません。効用としては、

• 次に着手するタスクが明確になる

です。

進行中タスクは一つまで

複数挙げたルールの中で、このルールが一番強力でした。

学習する上で着手するタスクは必ず一つにします。優先順位が一番高いタスクにしか着手しません。それが終わるまで他のタスクは忘れます。「TODO」「DOING」「DONE」のうち、「DOING」にはタスクを一つしか登録できないようにします。もし何らかの理由で他のタスクに切り替える場合は、現状の「DOING」にあるタスクを「TODO」に戻し、新しいタスクを「DOING」に移動します。これを徹底します。

ルールの効用は以下です。

• 今やるべきタスクは何かが明確になる

スプリントは一週間

一週間単位で以下を行います。

• 先週の成果を確認
• 先週のふりかえりを実施
• 今週やるタスクのリスト（優先順位有り）を作成

ふりかえりはKPTをやっています。その後、優先順位をつけて今週のタスクリストを作成します。このようなスプリントを回す効用は、

• 定期的にふりかえりをすることで、スプリント自体を改善できる

です。スプリントを始めた当初は、今回挙げているようなルールはありませんでした。ですが、ふりかえりを行い「スプリントを改善するためにはどうしたらよいか」を考えることで、今回のようなルールが見えてきました。

スプリントのタスクを終わらせたら好きなことをして良い

自分は「タスクに追われる日々」が嫌いです。何かやりたいことがあっても「あのタスクが終わってない」という思いが拭えず、心の底からやりたいことができませんでした。昔あった「20%ルール」みたいなことも考えましたが、結局その20%の中でも「あのタスクが...」という考えは拭えませんでした。そんな自分にピッタリだったのがこのルールです。効用は以下です。

• タスクを終わらせたので、罪悪感無くやりたいことに着手できる
• やりたいことをするために、タスクを進めようとする力が働く

このルールがあるので、スプリントの前半（自分は月曜始まりにしているので、月火水あたり）で今週のタスクをほぼ終わらせるように心がけています。結局、バッファ込みで金曜くらいに終わるのですが。そして土日はやりたいことをします。

毎週のスプリントを回していると、土日でもタスクが残っていることがあります。その場合はふりかえりでそのことを挙げ、次週のタスク量を調整します。これもスプリント改善の一つです。

before/after

以前、なかなか学習が進まなかった理由を考えてみると、以下のようなことが挙げられます。

• 学習項目のゴールが遠く、着手までの心理的ハードルが高かった
  • 心理的ハードルを頑張って超えたとしても、何をしてよいかが明確ではなかった
  • 実際に着手してもゴールが遠いので、モチベーションが続かなかった
• 学習したい項目がたくさんあり「AもBもCもやりたい」という思いや「Aをやっていたら時間がかかってしまい、Bをやっていないことに焦りを感じる」という思いがあった
  • 結局どれに着手しても焦りを拭いきれなかった

今回のルールは、上記の問題を解決しています。以下にルールを再掲します。

• 10-20分単位のタスクに分割する
• タスクが大きいと思った瞬間に分割する
• タスクに優先順位をつける
• 進行中タスクは一つまで
• スプリントは一週間
• スプリントのタスクを終わらせたら好きなことをして良い

これらのルールのおかげで、

• 迷わない
• すぐに着手できる
• 完了多数でモチベーションが続く
• 他のやりたいこともできる

という状況を作り出せています。

仕事にも活かす

実際に自分の学習タスクでうまく行っているので、毎日の仕事にも活かしています。チームのタスク管理にも提案しました。合うかどうかはチーム次第なので、合わなかったらまた別の改善をしていくのですが、なんらかのアクションとして前進できそうです。

ツール

使っているツールはJIRAです。このルールを運用するにあたって、今のところ不満はまったくありません。日々、スマホアプリからでもDoneを量産しています。

累積フロー図は現在こんな感じです。

課題の累積フロー図

開始当初にガツンとTODOが増えています。その後、運用していく中で所々TODOが増えている箇所があります。これはタスクが大きいので分割した結果です。また、「In Progress」がほぼ見えません。これは「進行中タスクは一つまで」というルールの表れです。

こういった流れをグラフで見られるのもモチベーション維持につながっています。

今後

毎週どんどんスプリントを改善していきます。

PME (Product Maintainability Engineer) （自作造語）を目指してみる実験

GWにキャリアについていろいろ考えたので、アウトプットの第一歩として書いてみます。

---

目次

---

キャリアを考えるきっかけ

エンジニアのキャリアについては正直、今まであまり深く考えてきませんでした。ところが最近は、キャリアについて考えることが面白くて自発的に思考しています。きっかけは以下の２つです。

• 毎週の1on1で、なりたいエンジニア像の言語化にチャレンジした
  • 「なりたいエンジニア像」をいきなり考えるのではなく、次のような段階を踏んでいた
    • 最近の仕事ぶりを振り返ってみてどうか → 理想とのギャップはあるか → その理想ってどんな姿だろうね
  • この段階的流れはとても良かった。自発的に理想を考えるきっかけになった
• SOFT SKILLS を再度読んだ
  • キャリアについて関係のある箇所をつまみ食い的に
  • 具体的な考え方が書かれているので、今の自分に刺さった

1on1がきっかけでキャリアについて考え始め、積読していた SOFT SKILLS で具体的に思考し、どんどんおもしろくなってきた、という流れです。

自分の目指したいブランド

SOFT SKILLS で印象に残っているのが「自分のブランドを持とう」という話です。自分のブランドを確立し、自分を売り込んでいくのです。自分のブランド、、、何も思いつかないな。そう思ったので真剣に考えてみることにしました。

ただ、「今の自分のブランド」ではなく「目指したいブランド」を考えます。今後は、なりたいエンジニア像を「目指したいブランド」として話を進めます。

まず、ブランドに必要な要素は以下の４つです。

• メッセージ
• ビジュアル
• 一貫性
• 反復的な接触

この中でも一番大切なものは「メッセージ」です。自分のブランドは何についてなのか。自分はどういう人なのか。例として著者は「シンプルプログラマー」を挙げていました。「私なら、複雑なものを単純にして、誰でもわかるようにする」というメッセージだそうです。

メッセージを考案する際はニッチ戦略が重要です。市場の隙間を狙って優位性を得ることが大切です。広い一般的なメッセージではなく、ひねりを加えたメッセージにします。メッセージは戦略的に考えていきます。

はて、自分はどうなのか。目指したいブランドがぱっと思いつきません。そこで戦略的に考えていきましょう。例えば、今の会社の期待と全くズレたメッセージを掲げると、なんだか厳しいことになりそうです。なので、会社の期待に沿ったメッセージを考えてみます。かつ、自分のモチベーションが上がるメッセージです。今の会社はレガシーな部分があり、なかなかスピーディに開発が進まない場面があります。保守性の問題です。そこで思い浮かんだのが以下の資料でした。

speakerdeck.com

何度読んでも良い資料です。改めてこれを読んで生まれた感情が「今の現場でも保守性を上げ、スピーディに開発したい！」というものでした。そして自分の目指したいブランドのメッセージとして「保守性を向上させるエンジニア」が浮かび上がりました。その姿に向かっていき、キャリアを構築していこうと考えました。

より良いメッセージ

自分の目指したいブランドのメッセージは「保守性を向上させるエンジニア」に決まりました。まだこの領域には至っていませんが、向かうべき姿は決まり、キャリアの構築を始めていきます。ただ、「保守性を向上させるエンジニア」という言葉だけだと、モチベーションがどんどん湧かないというか、何か勢いが足りないと感じました。「シンプルプログラマー」のような、端的でかっこいい何かが欲しいのです。再度 t_wada さんの資料を見ると「Maintainability：保守性」という単語が目に入りました。ここからはもう一直線でした。

• ~ability という単語はいろいろ聞く
• Maintainability Engineer とかどうだろう
• ~ability Engineer って SRE があった
• 「プロダクトの保守性向上を目指す」ということで PME (Product Maintainability Engineer) ってどうだろう

自作造語です。

PME (Product Maintainability Engineer)

PME は、プロダクトの保守性向上を目的とします（と定義します）。先述の資料の中で、Maintainabilityの構成要素は以下の３つとありました。

• Testability：テスト容易性
• Understandability：理解容易性
• Modifiability：変更容易性

これらの要素にアプローチして保守性向上を目指します。そのためには、どこがボトルネックになっているかや、修正コストはどのくらいかなど、多方面の知識や技術が必要になってきます。また、３つの構成要素の分かれているおかげで、スコープを絞って学習・実践ができるのではないかと思います。

ブランドのメッセージとしてはキャッチーですし、期待してほしいことも明確になっていると思います。言葉からくるモチベーションは意外と重要だと思います。

メッセージを決めたことによる効果

自分の目指したいブランドのメッセージを掲げたことで、以下のメリットがあると考えます。

• 学習の意味付けができる、学習の方向性が決まる
• その姿に近づくことによる満足感と、さらなるモチベーションの獲得
• 日々の行動に一貫性が生まれる
• 自分を表現できる

こうして内発的に「目指したい姿」を定義できれば、これらのメリットが得られると思います。

PMEを提唱するわけではありません

自分は今回、PMEを提唱したいわけではありません。勝手に自分のやる気が出る言葉を作ったに過ぎません。その点をご了承いただければと思います。

今後

PMEを目指して日々の行動を変えていけるのか？という実験をやっていきます。うまく回ったらまたブログで報告します。「やっぱりだめだった」という場合も、何らかの対策を考えてブログに書こうと思います。

まだ「ニッチ戦略としてどうなの。広すぎない？」という疑問も残っていますし、具体的に日々をどう変えていくかも考え中です。とりあえず宣言をしてみる意味で今回の記事を書きました。

技術書典６終了後メモ

技術書典６、お疲れ様でした！ 今回も大盛況でとても楽しかったです。

終了して記憶がおぼろげにならない内に、半年後の自分に向けての箇条書きメモです。

目次

頒布物紹介

• 「におうコードの問題集」の新刊既刊合わせて３種類
  • BOOTH
    • 【PDF】におうコードの問題集 〜ソフトウェア設計に立ち向かう編〜 - Grand Pa-Ma - BOOTH
    • 【PDF】におうコードの問題集 〜セキュリティホールに立ち向かう編〜 - Grand Pa-Ma - BOOTH
    • 【PDF】におうコードの問題集 〜バリエーションに立ち向かう編〜 - Grand Pa-Ma - BOOTH
• 【委託】「Introducing Crystal Programming Language」
• お品書き

レビューをお願いしてよかった

• 構成案の段階でレビューを依頼
  • GoogleDocsにて箇条書きで各章の内容を書いて共有
  • コメントを書いていただく
• 鋭い指摘をいただけたり、言葉の定義の曖昧さを指摘していただけた
• ただ、もう少し余裕を持ってお願いするべきだった
• 次回はPDF版でレビューをお願いできる余裕を持ちたい
• 関係者の皆様、本当にありがとうございました

もうちょっと早めに早めに動くべきだった

• 毎回言ってる
• ねこのしっぽさんの「116P以上最終締切」までに書き切ろうと思ったが、その日付の時点で「ガーッと書き切ったけど未推敲」という状態だった
  • ページ数は118pくらいだった
• この状態で出せないと判断し、もう一週間で推敲する決意＆116p以内に収めないとダメという制約が発生
• そこから一週間は推敲＆ダイエット
• 最終的に慌てずに入稿できた
  • 前回よりは進化した（前回は大慌てだった）

委託文化がもっと広がると良い

• 事前のイベントやTwitterなどでいろんな方と話していると、「落選したけど委託で販売できた」というケースを多く見た
• この流れがないと「その本が世に出なかった」
• これを考えると、委託の流れはもっと広がると良いなーと思った
• 委託による交流も生まれる

ワンオペの辛さを改めて実感した

• 今回はワンオペではなかった（急遽売り子をしてくださった知人の方が！感謝感謝です🙏）
• ちなみに前回はワンオペだった
• ワンオペではない今回の体験を持って「ワンオペやばい」を再認識した
• 「休憩できる」ってほんと大事
  • 途中、体調悪かったので本当に助かりました
• 「列整理」「支払い対応」「在庫を箱から出す」などなど、これを並列で一人で全部とか無理
• 頒布状況の改善案を出せる余裕ができる
  • 先にDLカードを本に挟んでおくとか、机の上の配置はこっちのほうが良いよねとか、お釣り出しやすいように5000円札だけ別にするとか
  • ひとりでやってたら、会期中に改善する余裕はない

高速頒布テクニックが知りたい

• 開始から10分くらいでブース前に行列が（ありがとうございます🙏ありがとうございます🙏）
• こちらの捌き次第で列の消化が決まる
• ひたすら頒布したけど、滞る場面がいくつかあった
  • 以下の２点
    • かんたん後払いのQR読み取りに時間がかかる
    • 見本誌を見たい方と会計したい方の入り乱れ
• 改善提案
  • 高いポスターを掲げるのではなく、高い位置にかんたん後払いのQRをデカデカと掲げて、遠くからでも決済できるようにしたら良かったかもしれない
    • そうすれば、レジ前に来たときには確認画面のチェックだけでok
  • 各サークルの島の間に、近隣のサークルの立ち読み場があると良さそう
    • 読み手も「ブースの前で読む」という若干のプレッシャーを回避できる
    • 売り手としても、会計の人の割合が高くなり、頒布しやすくなる
    • 立ち読み後、サッと近くのブースへ買いにいける

現地割引は効果があったと思う

• 売り手側の戦略の話になってしまうが、一定の効果はあったと思う
• 現地のみ、２冊セットは500円引き、３冊セットは1000円引き
• かんたん後払いのために、マイページの頒布情報で、全パターンの頒布情報を記載した
  • 「赤＆緑2500円」「赤&青2000円」など、全パターンを登録
    • セットもアプリで選べるようになる
  • DLCもzipで固めて、全パターンアップロードした
• 最初は頒布オペレーションで戸惑いがあったが、すぐに慣れたので問題なかった
• 前回の技術書典５でも思ったが、セット購入してくださる方が思ったより多い
  • ありがとうございます🙏

高く掲げるのは効果アリ

• 中盤から後半にかけて、スキがあれば本を頭上に高く掲げた
• やはり、１秒でもちらっと見てくださる方が多い
• 結果、掲げたときと掲げないときでは、（肌感ではあるが）掲げたほうが購入頻度が多かった
• 一瞬でも目に留まってくださるのはありがたいし、一定の効果はありそう

エゴサ絶対するよね

• 戦利品ツイート、本当に嬉しいです
• 書籍名を入れての感想ツイート、鼻血が出ます
• 本の内容についての質問、失神します
• こうやって盛り上がりが循環して、技術書典自体が盛り上がっていくのは本当に良い流れだと思う
• 次回も書きたくなるよね

シリーズ化の強み

• 最初から意図したわけではないが、シリーズ化することでいろいろ恩恵があることがわかった

今回、「におうコードの問題集」シリーズ３作目を出したけど、徐々に「シリーズ化」の恩恵が大きくなってきている。

・執筆環境構築がほぼゼロ
・表紙デザインの考案コストが少ない
・上記２点より内容に集中できる
・認知度が徐々に上がっている
・登場キャラクターのファンの方を発見🎉 #技術書典

— at_grandpa@技術書典-く06 (@at_grandpa) April 16, 2019

• マゴのファンの方のツイートをみて、イラストレーターさんにも伝えて、二人でめちゃくちゃ喜んでました

まとめ

次回、上記で改善できそうな部分は改善していこうと思います。 他の方の後日ブログも見て、いろいろ吸収していこうと思います。

次回

第４弾はDBをテーマに考えています。

次の「におうコードの問題集」、テーマはDBかなと考えてる。モデリング、アンチパターン、パフォーマンスなど、分野は多岐に渡るけど、例えば「こういうテーブル構造があります。どうクエリしますか？」というのは問題にしやすそう。

そして何より、表紙の色を決めるのに半年かかりそう。 #技術書典

— at_grandpa@技術書典-く06 (@at_grandpa) April 15, 2019

何卒よろしくお願いします。

技術書典６で「におうコードの問題集〜ソフトウェア設計に立ち向かう編〜」を頒布します

「におうコードの問題集シリーズ」の第三作目は「ソフトウェア設計に立ち向かう編」です。 問題集形式でソフトウェア設計について学ぶことができます。

また、委託で「Introducing Crystal Programming Language」も頒布します。 Crystal言語の入門本です。

共に「く06」でお待ちしています。

techbookfest.org

#設計飲み という勉強会を開催しています

設計飲みという勉強会を開催しています。

前回

sekkeinomi.connpass.com

次回（締切済み）

sekkeinomi.connpass.com

connpassグループ

sekkeinomi.connpass.com

技術書典６に向けての Re:VIEW+CSS組版 環境構築

前回の技術書典５では、Re:VIEW+CSS組版にチャレンジしました。

at-grandpa.hatenablog.jp

今回もこの構成で行こうと思っていますが、docker周りが複雑で分かりづらかったのと、自分のリポジトリとして公開してもいいかなと思ったので取り組みました。また、Re:VIEWがちょうど3.0.0になったので、良い機会だと思いました。

目次

「依存性逆転の原則」の自分なりの解釈

「依存性逆転の原則（DIP：Dependency Inversion Principle）」に関して考える機会があり、自分なりに言語化できそうなのでまとめます。ご指摘は大歓迎です。

目次

TL;DR

• より安定したモジュールの方向へ依存するよう設計し、ソフトウェアの安定性を高めることが重要
• 不安定なモジュールが 依存されている と修正範囲が大きくなるため、 依存されない ようにしたい。そのために、依存方向を逆転させたい
• DIPは「モジュールへの依存方向は逆転可能」ということを示し、「その方法」を解説している

プログラミング言語 Crystal の解説書同人誌「Introducing Crystal Programming Language」

この記事は Crystal Advent Calendar 2018 の15日目を埋める記事です。

Crystal言語を触ってみたい方に、技術書典５で頒布された同人誌「Introducing Crystal Programming Language」をおすすめします。日本語で書かれており、Crystalの基本的な文章から開発方法まで網羅しています。

crystal-jp.github.io

トップページの説明を抜粋します。

Crystal の基本的な文法から Web アプリーケション・ CLI 開発の方法まで解説したこの一冊があれば、Crystal での開発を今日から初めることができるでしょう。

Web上でも閲覧できますし、PDF版もダウンロードできます。Crystalに興味のある方はぜひご参考にしてください！

Crystalの自作CLIビルダーライブラリを使ってgitコマンド風のCLIツールを作ってみる

この記事は Crystal Advent Calendar 2018 の３日目の記事です。

自作のCrystalのCLIビルダーライブラリをアップデートしたので、AdventCalendarに便乗して紹介します。

githubは以下です。 clim と言います。簡潔に、直感的にCLIツールを書けることを目指しています。

github.com

過去に紹介したブログ記事はこちらです。

at-grandpa.hatenablog.jp

この記事が古くなったのでupdate記事です。

目次

技術書典５でチャレンジしたこと・うれしかったこと

おつかれさまでしたー！めちゃくちゃ楽しかったですね！

#技術書典 撤収完了しました😆一般参加、サークル参加のみなさまご来場ありがとうごさいました🎉🎉🎉また来年、春の技術書典6でお会いしましょう🙏 pic.twitter.com/CPXL5UuY06

— mhidakaあ11@技術書典5 (@mhidaka) October 8, 2018

次回に向けてのメモと感想を書いていきます。ブログを書くまでが技術書典。