2位：ホットクック,ヘルシオ
3位：ソニーのワイヤレスイヤホン
4位： Redmi Note 9 S
5位：バレンシアガの靴とスクートのパンツと帽子
6位：厚手のカーテン
7位：敷くタイプのフローリング
8位：NEXT G (コーヒーミル)
今年 買って微妙だったもの
1位： MacBook Pro
2019年の振り返り
2019年も残り数時間となったので今年の振り返り。 今年やったこととやりたかったけどできなかったことをまとめる。
今年やったこと
技術書典で本を書いて売った
jOOQ と Ktor についてそれぞれ本を書いて売った。jOOQ の本は Word で書いて失敗したなと思ったので Ktor の本は Re:View で書いたが分量に満足いかなかったので、次の技術書典で Ktor 本の改定版を出す予定でいる。本を書くと自分の中の知識がまとまって良いので時間が取れるなら今後も継続していきたい。本を目の前で買ってもらえるとめっちゃ嬉しいので体験としてもおすすめです。
bmonster にめちゃくちゃ通った
2018年の10月後半から bmonster に通って、最初は週に1回から3日に1回くらいのペースで通っていたが、今は週5〜6ぐらいのペースで通うようになった。体型は明らかに変化し全身の筋肉を絞ったボクサーのような体型になった。運動を頭がスッキリして集中できるので仕事の効率が上がって良いので、2020年も引き続き bmonster に通う予定。
外見を変えた
15、6くらいからずっと眼鏡だったのをコンタクトにした。bmonster は激しい動きが多いので眼鏡だと動きにくいのと、眼鏡の鼻当て部分でかぶれるようになってしまったのでやめた。しばらくは1日使い捨てコンタクトを使っていたが、1ヶ月使い捨てコンタクトの方が快適だったので今では1ヶ月使い捨てコンタクトを使っている。眼鏡をかけなくていい生活はとても自由で非常に快適です。
また、髪を染めて茶色のハイライトを入れたりした。今はまた染め直してシルバーのハイライトを入れた。Skrillex みたいな髪型にしたいので2020年は髪を伸ばし続ける予定だけど、面倒になって気が変わる可能性はある。
Kotlin をめっちゃ書いて Go もそれなりに書いた
仕事で Server-side Kotlin と Go を書いていて、Kotlin がメインで Go はサブという感じです。SprngBoot + Kotlin という構成は割と普通な感じなので今後は Ktor なども仕事で使っていけたらいいなと思う。マイクロサービス的には SpringBoot はちょっと重厚すぎる部分があり、使いやすいのはいいんだけどビルドとサーバ起動に十数秒かかるのがちょっとしんどいなと思う場面が増えてきた。技術書典で本を書くために Ktor をいろいろ触って、Ktor だとサーバ起動に2、3秒だしテスト実行するのももっと早いよなー。。というのを体感した後に SpringBoot を触るのはちょっとつらみがあった。
Go に関してはそれなりに書けるようにはなったけど言語の深い部分を理解しているわけではないので、プロダクションコードの実装を真似してそれっぽいコードにあわせて書けるようになった。gorm (go の O/R mapper) は辛いことが多くて辛い。おそらくシステムの規模が一定を超えてリレーションするテーブルの数が増えるとつらみの方が勝ると思うので、そうなったらサービス分割するなりしないと手に負えなくなるんだろうなーと思った。ただ SQL をそのまま書くのはしんどいというのもあるので、型で守られてる jOOQ みたいな SQL mapper みたいなのがあると嬉しい。
自分の作っていた労務代行周りの機能がリリースされた
フリーランスとして2018年の5月からシェアフルに参画しており、労務代行機能を2018年の6月ごろから作成していた。それが2019年の9月にリリースされた。紆余曲折あって先に別の機能をリリースしたので当初の予定よりも遅れたがちゃんとリリースできてよかったです。今後も機能を拡充していく予定。
今年できなかったこと
iOS/Android アプリを作ってリリースする
技術書典で原稿を書くことに注力してしまったのでアプリを作ってリリースしたかったけどできなかった。来年は技術書典9 に参加してからは1回お休みしてアプリを作る予定でいる。
勉強会やカンファレンスなどで登壇する
Kotlin Fest などで登壇したかったがこちらもできなかった。まずは勉強会などで LT 枠として登壇して場数を踏んでから大きめのカンファレンスで登壇したいなーと思っている。シェアフルで Kotlin エンジニアの採用に苦戦しているので、勉強会などに顔を出していい人がいたら一緒に働きたいなあという感じです。
ゲーム
2017~8年は PUBG などでそれなりに遊んでいたのだけど、今年はゲームする時間がほとんどなかった。bmonster に朝通うようになって朝型の生活を送るようにしたら夜更かしができなくなったためです。やりたいゲームはそこそこあるのだけど、優先度が限りなく低いのでゲームはこのままやらなくなる可能性が高い気がする。
来年やりたいこと
ジムで体を鍛える
bmonster だけだと満足できなくなってきたので、ベンチプレスで大胸筋を鍛えていきたい。
勉強会やカンファレンスなどで登壇する
勉強会などはあんまり参加したことがなかったので、LT などで登壇していきたいなと思っている。いい人がいたら一緒に働きたい。
技術的負債の返済
2018年ごろに書いた Kotlin のプロダクションコードの作りでいけてない部分があるのでリファクタリングしたい。Transaction Script っぽくなっている箇所はビジネスロジックを Domain に寄せてテストしやすい DDD な作りに修正する。というのをやる。
アプリかサービスを作る
自分のアプリがサービスを作ってリリースする。作ってる途中で頓挫するというのを何度もやっているので完成させたいです・・。
2020年もゆるい感じでやっていきたいなと思います。2019年お疲れ様でした。
技術書典7にサークル参加した
先日行われた技術書展7にサークルで参加し「KtorによるREST API の開発」という本を頒布しました。最終的な非チェック数が「111」でした。自分が頒布した本と飯野さんが頒布した「React Native 開発日記」がそれぞれ50部ずつくらい売れていたので、非チェック数通りくらいは売れたのかなという感じです。飯野さんの本は BOOTH でも取り扱っておりますので、興味のある方はぜひチェックしてみてください。自分の本もBOOTH に出してみようと思います。
執筆に関して
今回は Re:View を使用して執筆作業を行いました。前回は Microsoft Word を使用していたのですが、圧倒的に Re:View の方がやりやすかったので、次回も Re:View でやっていこうと思います。文章を書くだけなら Word もよかったのですが、コードブロックなどをタグで囲うといい感じに表示してくれるので Word よりもだいぶ楽でした。ビルドも思ったよりも時間がかからないので、ちょっと修正する→pdf にビルドする というのを繰り返して反復的にチェックできるのでとてもやりやすかったです。
現地到着から設営まで
技術書典7は前回から会場が約2倍になった影響で、3階のサークル入場の時間が押して10時30分ごろから設営開始しました。設営中に11時を過ぎたため、技術書典開始がアナウンスされた頃はまだ慌てて設営をしていたと思います。忙しかったので記憶が曖昧ですが...。お隣は GREE 技術部さんと同じジャンルのサーバサイド Kotlin の本を売っているサークルさんという感じでした。サーバサイド Kotlin を取り扱っているのは自分のサークルとお隣のサークルさんくらいだったように思います。
技術書展の開始から終了まで
前回は16:30ごろからだいぶ暇になっていたのですが、今回の技術書展は終始ずっと忙しいような感じでした。午前中の入場が有料になったため午後から人が押し寄せたように思えるのと、2階から3階への導線的に、ある程度まとまった人数を3階に移動させるようになっていた影響かなと思います。自分も他のサークルさんの本を買いに2階から3階へ移動しましたが、特に案内などがなかったので、案内と誘導はもうちょっとわかりやすくなっているといいのかなと思いました。
自分の反省点
まずは執筆作業の時間が思ったよりも足りず、締め切り直前になってからの追い込みで一気に本を書き上げる形になったので、次回はゆとりあるスケジュールで執筆作業をしたいと思いました。次は今回書いた本の2~3倍くらいのボリュームの本を出したいです。今回は土日に作業するのを2ヶ月ほど行ったので、次回の準備期間は3〜4ヶ月くらい必要かなと思いました。あとは本を手に取ってくださった方と話をするのが苦手なので、もうちょっと積極的に会話したり、サークルの前で立ち止まっている人がいたら積極的に見本誌を渡せるようになりたいなと思いました笑 お隣のサークルの方がとても上手にされていたので見習いたいです。
最後に
運営の皆さん、サークル参加者の皆さん、ご来場いただいた一般参加者の皆さんお疲れ様でした。自分は技術書典がなかったら本を書いていないと思うので、今後も定期的にサークルで参加して本を書いていきたいなと思っています。本を書くことで新しい技術を勉強する動機付けになったり、自分の知識を体系的にまとめてアウトプットすることができるのがいいですね。自分の本が目の前で売れるのは体験としてもとてもいいです。あとは、30過ぎてからこのようなエンジニアらしい活動をするようになったので、もっと若いうちからやっておけばよかったなと思いました。そして、次回の技術書展に向けて、今のうちからネタ出しなどをやっていこうと思います。購入した本は徐々に読み進めていこうと思います。以上です。
bmonster に7ヶ月通って5キロ痩せた
2018年10月末 bmonster に通いだしてから7ヶ月が経過し、60kg の体重が 55kg になった。身長 180cm ある。痩せすぎて死ぬかも。
もともとジムに2年ぐらい通っていて週に2回は筋トレをしたりランニングマシンで有酸素運動をやっていて、マルトデキストリンとプロテインで体重を 60kg まで増やしていたので、bmonster に行き始めたタイミングでマルトデキストリンをやめた影響かもしれない。
bmonster のいいところはジムと違ってトレーニングする機材の順番待ちがないこと、インターバルトレーニングと自重の筋トレなのでジムで鍛えた体に良くある「見せるだけの筋肉」ではない体になること、心拍数をかなりあげた状態が30〜40分続くので脳がリフレッシュすること(脳科学的にも30〜40分は心拍数が高い状態で運動すると脳が活性化する効果があると認められている)サンドバッグを思い切り殴れてストレス解消になることあたりになる。
よくないところは、時間帯によってはシャワーがものすごく混むのでシャワーを浴びるのに時間が取られること、ものすごく汗をかくのでたくさん水を飲む必要があること、3時間くらい前に食事を済ませておかないときつすぎて気持ち悪くなること、プログラムと曲が微妙だった時はイマイチ乗り切れなくて運動強度が下がることなど。
あとは最近だと会員数が増えた影響からか新宿、恵比寿、青山あたりだと夜に予約を取ろうとしても順番待ちになるので予約が取れないこと。3日ぐらい前から予約を取らないと厳しい感じがある。ただ、夜はシャワーも混むし夕飯を食べるのが遅くなるので比較的空いている朝8時のプログラムを受けてるようにしている。そうすると必然的にそのまま仕事に行くことになるため、昼ごはんを食べたあとはものすごく眠くなることがあるのでそういう時はちょっと昼寝をしている。
bomonster のプログラムは人にもよるが基本的にハードなので最初は1回行くと筋肉痛が治るまで1週間ぐらい要していたが、慣れてくると週に2回行けるようになり、さらに慣れてきたので今は週に3回ぐらいは行けるようになった。あとは自宅でも筋トレをするようになったので、ジムに通っていながら全然できなかった腕立て伏せが20回はできるようになり、腹筋も100回はできるようになった。痩せすぎているせいか、今、僕の腹筋は完全にバキバキのシックスパックです。次は腕立て伏せを50回できるようになることが目標。
エンジニアをやっていると1日に8時間は PC の前にいることになるのでどうしても運動不足になりがちなのと、座りすぎていると確実に早く死ぬので強度の高い運動をやりつつ人間の原始的な欲望である何かを殴ったりしたい欲を満たせてかつ EDM が好きなら bmonster はおすすめです。痩せるかどうかは体質にもよるので人によるが(うちの奥さんも同じ頻度で通っているが特に体重が変わっていない)ストレスが減って肩こりなどもだいぶ緩和された。人間は健康になると食べ物にもある程度気を使うようになるので、ラーメンと酒が好きでタバコも吸って PC の前に長時間座っているとまあ早く死ぬので生活習慣と食習慣を改善して bmonster 駆動でやっていきましょうと行った感じで。
技術書典6で本を売ったので技術同人誌の執筆に関するまとめ
4/14日(月) に池袋のサンシャシンシティ文化会館で行われた技術書典6にサークルで参加しました。
「SpringBootとKotlinで学ぶjOOQ入門」という本を書いて売りました。
自分の予想だと30部売れればいいかなと思っていましたが、実際は50部ちょっと売れたので目標達成という感じです。
80部刷ったのでまだあまっているので、そのうち知人に配ったりしようかと思います。
自分のブースではこんな感じで売ってました。
参加した記録を残しておこうと思ったのと、本を書くために何をやったのかなどをまとめておいたほうがのちの自分のためにも良さそうなので記録としてブログにまとめました。
最初にやったこと
まずは技術書典に申し込みをしました。参加申し込みをしようかどうか迷っていたのでギリギリのタイミングでの申し込みだったのと自分のイメージだとサーバサイドに関する本はあんまりないだろうし、正直なところ当選するとは思っていなかったので、当選してかなり驚きました。 当落発表があったのは2月の頭くらいだったので、今から技術書を書いても2ヶ月弱しかないのか...と絶望するところからのスタートとなりました。
本のネタ出しをどうしたか
自分の場合は最初に書こうと思っていたネタはだいたい決まっていて、jOOQ に関するまとまった情報がなかったので自分でまとめたいと思ったのとjOOQ がもっと国内で普及したらいいなと思ったので、最近流行っている SpringBoot + Kotlin という構成で jOOQ を使うといったテーマで本を書き始めました。 技術書点はかなりニッチなテーマを扱った本が多く売られているので、商業誌では出せないような深く掘り下げたテーマで本を書くのはありだと思います。 あとネタは結構そこらへんに転がっているので、今の業務で携わっている技術をまとめるだけでも新たな学びがあったりするので、別にテーマ自体はなんでもいいんじゃないかなという気がします。 React などは進化が早くて商業誌にしづらいのと、情報が体系的にまとまっていないので初心者向けのニーズがかなりあると思うし、サーバサイドの人間が一から学ぶにはめんどくささがあるので。 関数型言語に関する本がちょっと少ないと思ったのでその辺りを狙うとか、新しいことに挑戦してそれを本にまとめてもいいですし、探せばネタは結構あるかなと。
スケジュールを作った
まずはざっくりとしたスケジュールを決めました。3月末には入稿をして4月14日に売るにはどうしたらいいかを逆算して考えたのと、どのくらいのボリュームの本を書くかを決めました。この時点では80ページくらいかければいいかなくらいな感じで考えていました。印刷所へ入稿する期限を3月31日として、本文の作成、表紙の作成、体裁を整えるなどをいつまでにやるか決める といった感じです。 ※ 実際には124ページになりました
基本的に平日は仕事で疲れているので、金曜の夜以外は本を書かないようにして、本を書く時間は全て土日を使いました。2月と3月の土日ほぼ全てを費やしたので、2ヶ月間はほぼ休みがないような状態だったのでちょっときつかったです。 あとは体裁を整える時間がなかったので、本を書くには最低でも3ヶ月くらいは見ておくのがいいんじゃないかと思います。もうちょっとゆとりをみてスケジューリングするなら、ボリュームにもよりますが4ヶ月〜半年くらい見ておけば問題ないかと。
技術書を書くにはどうしたらいいかを調べた
インターネットに技術書点に参加して本を売るまでの情報が点在していたので、そういった情報を調べました。あとは「技術同人誌を書こう！」という同人誌があったので購入してざっくり読んで、技術書を書くためにやることや気をつけることなどを学習しました。
技術書を書いてから売るまでにハマるポイントがまとまっているので、初めて参加するなら読んでおくといいんじゃないかと思います。 特に Word で書くのか re:view で書くのか Markdown で書くのかなどは最初に決めておいたほうがいいかなと思います。 自分は今回 Word で書きましたが、体裁の綺麗さなどを考えると re:view で書いたほうが綺麗になるので次は re:view で書こうと思います。 re:view で作成した本を CircleCI で回して push したら自動で PDF を作成してサーバに転送する といったことも可能だそうなので、複数人で本を書いているならそこまでできていると便利そうです。
目次を書いた
まずは作成する本のアイデアを電車の中などの隙間時間を使って google keep にまとめました。アイデアはブレストっぽい感じでやったので、とりあえず思いついたら google keep に書いてその中でカテゴリごとにまとめていって週末のまとまった時間を使って目次に仕上げていきました。目次は重要なので最初に作ったほうがいいです。
Trello にタスクを登録して進捗を管理した
技術書典用の Trello を作ってタスクを登録しました。表紙の作成、目次の作成、目次から書く本文の内容を切り出して登録などを行い、1個ずつ終わったかどうかをチェックしました。 具体的には Todo Doing Review Done でレーンを分けて、やることは Todo に登録し、仕掛かり中のものは Doing 作業が終わったら Review か Done にタスクを移動して管理しました。 特に本文を書くのにどれくらいのベロシティが出るのかを計測したかったので、本を書き始めてからの2週間の土日でどれくらいのアウトプットがあったかを指標としてどれくらい本文を書けるか見積もりました。土日に目次を4つくらいは消化できることがわかったので、それに合わせて書く内容を調節しましたが、だいたい見積もりどおりの結果に収まりました。 なので、本当は盛り込みたかったけど書けなかった内容がいくつかあり、それらも含めるとトータルで200ページ弱の本になった可能性があります...。
表紙を作成した
表紙をクラウドワークスさんなどに依頼して作成してもらうのもいいかと思ったのですが、どうせなら全部自分でやってみたほうが一通りの工程を経験できていいかと思ったので表紙は自分で作成しました。 飼っているインコの画像で良さそうなやつを適当に見繕って iPhone の画像加工アプリで絵のような見た目に加工した画像を PC に転送し、gimp を使って微調整したものを Keynote にインポートして文字などを追加して なんとなくそれっぽい感じの表紙が作れました。作成した表紙はこんな感じです。
ちゃんとした表紙を作りたい場合はかなり早めにクラウドワークスさんなどで募集するのがいいかと思います。表紙の公開は期限がかなり早いのと、いい感じの表紙だとサークルの被チェック数もかなり伸びて来るので、表紙は早めに作るといいかと思います。自分の場合は表紙の作成が3月末ごろになってしまったので、もっと早めに表紙を作っておけばよかったと反省しました。
印刷所に入稿した
技術書典公認の印刷所さんが2つあるので、印刷を依頼したのが4/7(日)と技術書典の1週間前になってしまったので、ページ数的にもねこのしっぽさんに依頼することができなかったので日光印刷さんに依頼して本を印刷していただきました。入稿した翌日には電話で確認の連絡がきたので、支払い金額などを確認して印刷をお願いするといった流れになりました。 自分の場合は 124ページで B5 にして80部の印刷をお願いしたのですが、見積もり金額が A4 の値段になっていたのと、作成した表紙が Keynote の形式になっていたので日光印刷さんでひらけなかったので表紙を pdf にエクスポートし直して再アップロードして入稿完了 といった流れになりました。 そのほかにも気になる事は印刷所の方から折り返し連絡が来ると思うので色々確認したほうがいいと思います。
必要なものの買い出しを行った
当日は結構持ち物が多く、机に敷く「あの布」というテーブルクロスや見本誌のカバー、見本誌を立てるスタンド、ポスター、ポスタースタンドなどなど、結構必要なものが多いです。前々日までに100円ショップなどで買い出しをしました。大体のものは100円ショップで揃いますが、「あの布」は配送まで最大で1週間程度かかるので早めに注文するのがいいと思います。イベント当日になってあれがないこれがないと慌てるとしんどいと思うので、前日までに全てのものが揃っているといいと思います。
イベント当日に本を売った
印刷所からの直接搬入だったので、イベント当日になるまで自分の本が確認できなかったため若干の不安はありましたが、当日に自分のスペースにちゃんと本が配送されていたので安心しました。製本された本を見ると感動しますね。 自分で割と適当に作った表紙も綺麗に仕上がっていたのでよかったです。当日は50部ちょっと売れて、最初は50部くらい刷っておけばいいかなと思っていましたが、手元に20冊くらいは残しておきたかったのでちょうどいい感じで良かったです。自分の目標としては30冊売る事だったので目標も達成できて良かったです。対面で自分の本が買ってもらえるととても嬉しいですね。
売り子をやっていると食事をする暇があまりないので、おにぎりとゼリー飲料と飲み物を買って行きましたがおにぎりは食べている暇がなかったです。ゼリー飲料を多めに持っていくのが良さそうだったので、次回はそうしようかと思います。売り子はうちの奥さんと自分の二人だったのですが、一人で売り子をやるのはしんどいと思うので、店番を頼める人を一人は確保しておくといいかと思います。ちょっと暇な時間があれば他のブースを回って買い物もできますし。
感想
技術書を書いたことがなかったのでとてもいい経験になりました。自分の学んだことをまとめてアウトプットするいい機会だったので、今後も継続してサークル参加できればいいなと思います。 次回は ReactNative でアプリをリリースする予定なので、その辺りのことを本にまとめるのと、今回出した本の内容をブラッシュアップして書けなかった内容を盛り込んで体裁を整えて200ページくらいの本にして売ったりとかもいいなあと思っているので、そんな感じで頑張ろうと思います。終わり。
プロジェクトをアジャイルに運営する自分なりの考えまとめ
はじめに
このエントリーは、アジャイル開発を実施するにあたって、自分が今まで読んだ本や携わったプロジェクトの経験から「どのような方法でプロジェクトを運営 すれば効率よく開発ができるのか」という自分の考えをまとめたものになります。実際にプロジェクトを運営する際は他にも考慮すべきことが多くありますが、プロジェクトの運営に絞って考えをまとめてみました。
参考にした書籍
プロジェクトの運営や見積もり、不確実性を減少させるためにはどうすればいいのかというような内容に関する本に絞りますが、だいたい以下のような書籍を読みました。エッセンシャルスクラムは積んでいるのでそのうち読みたい。
- アジャイルな見積もりと計画づくり
- アジャイルサムライ
- ユーザーストーリーマッピング
- エンジニアリング組織論への招待
- カイゼンジャーニー
- カンバン ソフトウェア開発の変革
- アートオブプロジェクトマネジメント
まず何をすべきなのか
まずはユーザーが何をしたいのか、ユーザーの考えていることが実現した場合、世界がどのように変わるのかということの全体像を把握する必要があるかと思っています。プロジェクトでいうところの企画段階で、このアプリやシステムが完成するとこうなりますよ〜みたいな感じです。
現在私が携わっているシェアフルでは、シェアフルが完成すると短期・単発でもっと働きやすくなり、今まで副業やダブルワークをやったことがなかったサラリーマンなどの方達に対してもリーチする可能性があり、結果的に日本社会全体における副業のイメージ変革や新しい働き方の提案ができるのではないか？というミッションからスタートしています。では、シェアフルを実現するためにはどういったフィーチャーが必要で、どのようなバリューストリームになり、そのために必要な機能はなんなのかを把握する必要がある といった感じです。
ユーザーストーリーの全体像を把握するためには
アジャイルプロジェクトではプロダクトバックログなどの形式でユーザーストーリーを管理し、ユーザーストーリーを実現するための具体的な手段を Issue にして開発を行なっていくかと思いますが、ユーザーストーリーのみに着目した場合、ユーザーストーリー全体の流れを見失ってしまいがちになります。森を見ずに木だけを見ているような状態です。自分の作っている機能がシステム全体で見るとどの部分に該当して、どのような役割を持っているのかきちんと説明できないのは非常にまずいんじゃないかと思いますし、理解の浅い状態で機能を作っていくとバグが潜在しやすくなります。
そのために、まずはユーザーストーリマッピングを作成することでユーザーストーリー一連の流れを把握し、フィーチャー全体の流れが一目でわかる状態にしておくことが大事だと思っています。大まかな粒度で何をどこまでやればいいのか把握できるのと、全部やろうとしたら絶対に時間が足りないので、まずは MVPe として何を優先的に作成すべきなのかが明確になります。また、ユーザーストーリーマッピングをステークホルダーやプロダクトオーナーと協力して作成することで、お互いの期待の一致や理解の共有、不確実性の削減を行うことが可能となります。ユーザーストーリーマッピングを起点としたコミュニケーションが活発となり、会話を継続することで、システムに対してのより深い理解や洞察が得られるようになる効果があります。このようなコミュニケーションが開発には必要不可欠です。
全体的なスケジュールを作成し更新し続ける
スケジュールは一度立てたら終わりではなく、常に改善し続ける必要があります。大まかなスケジュールを立てて、ユーザーストーリーの実現に必要なファーストリリースの MVPe を実現するためにはおおよそどれくらいの期間が必要なのかをざっくりとした感じでスケジューリングしましょう。プロジェクトの初期段階では不確定要素が多く、必要な情報はプロジェクトが進んでいくにつれて判明してくるので、「おおよそこれくらいかかるので10〜12月くらいにはリリースできるんじゃないか」というような大まかなスケジュール感から始まり、プロジェクトを進めていくにつれてベロシティが判明するので、残りのフィーチャーとベロシティからいつまでにはリリースできるようになるかの目処が立つようになります。プロジェクトを進めていく間にビジネスが取り巻く環境が変わったり、フィーチャーに対する理解が深まったことにより必要な機能が増えたり、逆に減ったり、進捗が思わしくないのでフィーチャーを削ったりとプロジェクトを進めていかないとわからないことが非常に多く、その都度計画は更新する必要があります。
ユーザーストーリーマッピングからプロダクトバックログを作成する
ユーザーストーリーマッピングがおおよそ出来上がり、第一段階リリース候補のフィーチャーが見えてきた段階で、次はプロダクトバックログを作成していきます。プロダクトバックログを作成するにあたって、どのツールを使用するかは特に言及しないですが、複数のスクラムチームからなるプロジェクトの場合、以下の4点を抑えているツールが望ましいと考えています。
- 各チームの進捗が把握できる
- チーム全体の進捗が把握できる
- バーンダウンチャートを自動で作成できる
- ベロシティがわかる
バーンダウンチャートに関しては、予定と実績の両方がわかるようなチャートになっていると予定からどのぐらい進んでいるまたは遅れている のが一目でわかるようになり、スプリントの進捗が可視化されるのでわかりやすいです。
見積もりを行う
プランニングポーカーなどの方法を用いて見積もりを行なっていきます。見積もりにおける前提としてプロジェクト全体に周知すべきこととしては、見積もりはあくまで見積もりであり、決してコミットメントではないことを理解してもらうところから始めます。また、見積もりの精度はプロジェクトの進捗によって改善されていくので、振れ幅があり完全に正確ではないことも認識する必要があります。特にプロジェクトの初期は振れ幅が大きく、プロジェクトを進めていくと見積もりが徐々に正確になっていくので、「まあだいたいこれくらいかかるだろう」という大まかな見積もりを軽い気持ちでやっていくのがいいんじゃないかと思います。
また、見積もりにバッファを含めるのではなく、バッファはプロジェクト全体にバッファを設けるようにします。パーキンソンの法則により、人間は与えられた時間を全て使って作業をしてしまうので、見積もりよりも早く作業が終わることが基本的に起こり得ません。例えばある作業が5日かかるという見積もりをした場合、3日目には作業が終わっていたとしても不要なブラッシュアップや最適化などを行なってしまい、結局見積もり通りの時間がかかってしまうからです。
ですが、見積もりにバッファを乗せて働いてきた経験が長い方からはバッファなしに見積もりをすることは反対されやすいので、まずは心理的安全性を確保してもらうために、見積もりはあくまで見積もりでしかなく、バッファはプロジェクト全体のバッファを用いるので、見積もり通りにタスクの消化ができなくてもプロジェクト全体のバッファから消化するという合意をエンジニア、顧客、ステークホルダーに対して形成する必要があります。どうしても期限を優先するのであればリリース対象のスコープからいくつかのフィーチャーを削るか、リリース日をずらす、品質を下げてとりあえずリリースするなどの対応が必要になってくるでしょう。どのような対応をするかはプロジェクトの状況やプロジェクトを取り巻くビジネス環境に依存するので、何で合意するかはまちまちです。
進捗を可視化する
どこまで何が終わっていていつリリースできるのかが明確になっていないとステークホルダや顧客は不安になり、進捗状況の詳細な説明を求められるようになります。エンジニアとしてもプロジェクト全体のフィーチャーが可視化されておらず残作業が見えていないと不安を覚えるので、プロジェクトの初期段階から進捗を可視化するのがいいでしょう。可視化された進捗は顧客とステークホルダーに対しての説明資料になり、エンジニアは自分たちの残作業量を把握できるようになります。
また、バックログから Issue 化された Issue Tracker などのツールから予定と実績のバーンダウンチャートを作成し、スプリントの予定ベロシティと実績のベロシティで進捗を可視化するのと、可能であればプロジェクト全体のフィーチャーからバーンダウンチャートを作成できてるといいかなと思います。
さらに、プロジェクトの執務室にユーザーストーリーマッピングを掲示しているのであれば、完了したフィーチャーがわかるようなシールを貼っておくと、完了したフィーチャーとストーリー全体が連動するので、大まかな進捗状況が一目でわかるようになります。
振り返りを行う
KPT を用いた振り返りをスプリントごとに実施します。1週間単位でスプリントを実施していれば毎週振り返りを行います。振り返りを行う際に大事な点は、Problem で上がった問題の深掘りを実施することと、Try を1つか2つに絞ることです。多くの Problem が上がった場合、Problem をすべて解決する Try を実施することは不可能なので、本当に解決したい Problem だけに絞って徐々に問題をなくしていくようにするのがいいと思います。また、Problemn に上がった問題は表面的なものであることが多いので、問題の深掘りを行なって問題の本質を解明するようにファシリテートして問題の早期発見と解決ができるようになると、自律的に問題を発見して解決するチームが出来上がっていきます。
1on1を実施する
これは今のプロジェクトで継続的に行なっている取り組みで、僕自身も初めて 1on1 を受けているのですが、1週間の出来事を振り返ってよかったことや悪かったこと、気になる事を整理することができるので、非常にいい機会をいただけていると思っています。よかったことや問題だと思ったことが PM に連携されるので、PM としては早めに是正する対策を取ることができるのと、メンバーが意欲的に取り組んでいる技術などを知ることができます。1on1 を実施するのはメンバーが多いとかなり時間がかかって大変だと思いますが、毎週実施してもらってありがたいです。
まとめ
アジャイルなプロジェクト運営をやっていくのは、ウォーターフォールと比べると進捗のごまかしがきかない部分が多いので、合わない人は全く合わないと思います。ですが、ウォーターフォールと違って変化を受け入れてプロジェクトを進めていくことができる手法なので、考える必要のあることは多いですが、変化に合わせて柔軟に開発を進めていくには、プロジェクトをアジャイルに適応してやっていくという気持ちで頑張ろうと思いました。
TDDでコードを書くようになってから1年経った
はじめに
昨年テスト駆動開発の本を読んでから基本的に TDD でコードを書くようにしていましたが、TDD でコードを書くようになってから自分のコーディングがどう変わったのかを書きました。また、TDD に馴染みのない方向けにはこちらのスライドがいい感じにまとまってました。
前提
Java と Server-side Kotlin + JUnit 4 or 5 で TDD を実践したので、似たような構成であれば参考になるかもしれません。
TDD やる前
だいたい以下のようなサイクルでコードを書いていました。
1.ある程度コード書く 10~20行ぐらい（まだ機能は完成していない状態）→ 2.テストコード書く→ 3.pass or fail → 4.ある程度動くことを担保したのでコードの続き書く→ 1に戻る
これも TDD に近いコーディングスタイルだと思っていましたが、本を読んで TDD を始めてからは上記のサイクルを変更しました。
現在はTDDのサイクルに従っている
TDD のマントラは レッド、グリーン、リファクタリング とあるように、まずは落ちるテストを書いて、テストが通るようにしてからリファクタリングする というサイクルを繰り返します。 現在自分が行なっている TDD のサイクルは TDD の原則に従っていますが、TDD にある程度慣れてきた現在では、サイクルの感覚を少し長くしたり、長すぎると思ったらまた短くしたりといったように、実装する機能の難易度や大きさに合わせてサイクルの粒度を調整しています。難しい機能ほど細かいサイクルで頻繁に確認したほうが確実に出来上がってきていることを確認できるのでおすすめです。決まりきったテンプレート的な処理を実装する際は TDD を適用する必要もない場合があるので (例えば O/R Mapper でただ insert するだけの処理など、ビジネスロジック的に考える余地のないような機能) その際は TDD を使用していません。
コード書く前にまずは実現したいことをリストアップする
自分が TDD でコードを書くにあたって、まずはどんなことがやりたいのかを脳内やホワイトボードやソースコードへの // TODO コメントを使用して記載します。粒度は荒く、〜取得処理, 〜登録処理 といったような、だいたい1メソッドに収まる10~20行程度のやりたいことをリストアップして、リストの上から順番にコーディングします。途中で追加したり実装途中で不要なことに気が付いたら// TODO を追加/削除します。
こんな感じでソース内に TODO を列挙する // TODO ◯◯コントローラ作成 // TODO ~取得処理作成 // TODO ~更新処理作成 // TODO ~登録処理作成
※ ここで1つの // TODO が1メソッドに収まる場合もあればそうでない場合もあるので、メソッドが大きくなりすぎたら適宜リファクタリングして処理を分割します。
テストクラスを最初に作る
IntelliJ IDEA なら command + shift + T でテストクラス作れるので、最初に必ずテストクラスを作成します。これはめちゃくちゃ大事です。
エディタを2分割する
プロダクションコードとテストコードでエディタを分割して表示します。画面切り替えなどでプロダクションコードとテストコードを行き来すると、脳内でコンテキストの切り替えが発生して脳のリソースを無駄遣いすることになるので、左右か上下にコードを並べて表示させます。最近のモニタは横に長いので、自分は左右に表示させる派です。4K のモニタを使うとまた違うかもしれないです。余談になりますが、自宅では MacBook Pro 15inch + FullHD ゲーミングモニタ2枚、職場では MacBook Pro 13inch FullHD モニタ1枚 という環境です。可能であれば 4K モニタ2枚を会社に支給してもらいましょう。
まずはレッドにする
メソッドを作成し、まずは落ちるテストケースをテストコードを記述します。まだメソッドを作成していないのであれば、存在しないメソッドをテストコードから実行してコンパイルエラーの状態を作ります。この辺りはどちらでも構わないと思っています。無事テストが落ちる (コンパイルエラーになる) ことを確認したらプロダクションコードに戻ります。
グリーンにする
なんでもいいのでテストが通るコードに修正します。テストが通ったらリファクタリングのステップに移ります。
リファクタリングする
グリーンにするために書いたコードを綺麗にしていきます。ハードコードした変数を定数にしたり、enum クラスを作成したり、メソッド分割したりなど、テストしやすさを重視した粒度にします。メソッドの行数的には10~20行程度になるかと思います。が、行数よりも重視するのは、プロダクションコードが容易にテストコードをかける構造になっているかをもっとも重視するようにしています。そもそも、テストが書きやすい構造になっていないとテストコードを書くコストが高くなり、数ヶ月後にコードを見返したときに処理の全容を把握することが非常に困難になります。複雑なコードベースに対してテストを追加した場合、全容を把握するのが困難になるため、実装上の抜けや漏れを把握しきれずにバグが潜在します。ですので、複雑なコードだとバグを産みやすくなってしまいます。
レッド、グリーン、リファクタリングを繰り返す
あとはひたすらレッド、グリーン、リファクタリングを繰り返してコーディングします。TDD より前の方法でコードを書いていたときは、テストを通すのが結構大変なことがあったので、テストを書くことの心理的負荷が高く後回しにしがちだったのですが、TDD でテストコードを書くハードルがグッと下がったので、心理的負荷がかなり低くなり、テストコードを書くのが楽しくなりました。結果的に、シンプルなコードを保ちつつコードの意図を反映したテストコードがセットでついてくるので、ある程度まとめて処理を書いてからテストを書くよりも TDD を実践したほうが品質が高くなり、テストが通らなくて悩む時間が減るのでコスト的にも安上がりになった感じがあります。
まとめ
TDD はプロダクションコードとテストコードを頻繁に行き来し、テストを通すために書いた雑なコードを綺麗な状態にリファクタリングすることにより、コードが洗練された状態になります。コードを書く上で大切な自分の書いたコードが意図した通りになっているかを確認するための非常に優れた技法です。また、テストを通すことが強制されるため、必然的にテストしやすいシンプルなコードになります。ですが、TDD はあくまでもコーディングを補助するための技法であり、TDD で書いたから業務的にも正しい仕様になっているかはまた別問題なので、あくまでもコードが自分の意図通りの挙動になっているかを確認するために TDD でコーディングするという考えで用いるのが正しい使い方になります。自分は今後も TDD でやっていく所存です。
