こんにちは！freee の債権請求書領域の開発をしている hachi です。この記事は freee Developers Advent Calendar 2024 - Adventar の 13 日目の記事です。
今年ももうすぐ終わりますね。みなさん今年はどうでしたか？私は今年を振り返って自分は発表 Driven で開発するのが一番捗るなと思ったのでその話をします！
Presentation Driven Development とは、発表の予定を先に押さえておくことで生産性を著しく上げる開発方法です。（勝手に作った用語なので後ろで詳しく説明します。）
今年の振り返り
今年は以下の登壇・執筆を行いました！（細かいものを挙げるともう少しあります）
Drive Your Code ~ Building an RC Car by Writing Only Ruby~ - Speaker Deck
やりたいことを仕事でやる技術 / The Technique of Turning Your Passion into Your Profession - Speaker Deck
いいチームでいるためにやっていること/Things we are doing to remain a good team - Speaker Deck
freee請求書プロダクトにおけるFiber活用/Utilization of Fiber in the freee Invoice Product - Speaker Deck
Raw HID とOLEDで広げるキーボードの可能性/Expanding Keyboard Possibilities with Raw HID and OLED - Speaker Deck
ラジコン作成本は Ruby on Rails チュートリアル の 読み物ガイド でも紹介いただきました！
これらの発表を通して自分はPresentation Driven Development (PDD) が向いているなと改めて感じました。
自分に似た人にこの記事が刺さってくれたら嬉しいのでまずは私がどんな人なのかをご紹介したあと、PDD についてお話します。
自分という人間について
自分は何も与えないと基本怠惰な人間です。先日も休日に Factorio を朝から晩までずっとやっていて絶望しました。
Factorio は Space Age が出てしまったのでしょうがないですよね？？？みなさんはどこまで行きました？自分はまだ宇宙行ったばっかりです。
あと妻が家にいるときは料理をよくするんですが、たまに一人で食べるととたんにコンビニの弁当とかになります。誰かが食べてくれないと作る気起きなくないです？
一人の時の自炊モチベーションを保つ方法を募集しています。
……まあそんな怠惰な人なので基本的には開発とか学習とかをあまりしません。
ただ、そんな怠惰な自分をそのまま受け入れられないぐらいには普通の人間なので、なんらか抗いたいという気持ちはあるわけです。生きづらいですね。
怠惰に抗うにはどうしたら良いでしょうか？
自分の場合、怠惰というよりは手軽に楽しいものに流れがちという性質だと思うので、「やりたいしやったら楽しいんだがちょっと大変なのでやらない」というものをやらせるには締切を作るのが一番だと考えます。
ただ、自分で決めた締切は容易にサボることができてしまいます。ブログとかはそれの最たるもので、明日でいいかーとなりがちです。そこで発表ですよ！
Presentation Driven Development (PDD) とは
やり方は簡単です
- 登壇日/プロポーザル提出日/執筆締め切りを決めます
- やりたいことがあればそれをやります or 必死にネタ出しをします
- 締切日まで全力で走ります
- なんとかして発表します
- 気づいたら色々学べているしアウトプットもでている！
とても簡単ですね。「必死に」とか「なんとかして」とかふわふわした言葉を使っていますが本当にこうなんですよ。
結局このメソッドの肝は「公開されていて」かつ「引くことができない」「締め切り」を設定すると言う点にあります。
何より大事なのは締め切りです。これは今やどこでも言われているので特に語ることはありません。残りの２つの条件はこの締め切りを重要なものに昇華するための条件です。
公開されていることは、自分へのプレッシャーとして重要です。先ほどのブログの例のように公開されていない締め切りというのは容易に破れてしまいます。
特に、上に挙げたようなプロポーザル提出日や執筆締め切りは自分で設定するものではなく与えられるものなのでとても強い制約になります。
引くことができないというのは自分にとってモチベーションが高く、インセンティブがあるという意味です。Ruby Kaigi LTで登壇することはそれ自体がインセンティブになりますし、登壇するために解決する課題が自分にとって面白い課題であればその課題を解くことがインセンティブになります。
登壇したい場所ややりたいこと自体の設定をうまくやると強いインセンティブになりますね。
結局はよく言われる目標設定のフレームワークである SMARTの殆どをこの方法が担保してくれるということです。（R: Related は他の方法で担保するしかない）
今年はこの方法がかなりハマりました。
とりあえず技術書典に応募して新刊を落とさないように頑張って執筆したり、スポンサーセッションに立候補してスポンサーセッションで話す内容を必死に実装したりと、登壇のために必死になって学習や実装を進めるという動きができていました。
PDD の効果
この方法の良いところはもちろん否が応でも成果を出さないといけなくなり、自然とアウトプットが増えるところです。このおかげで今年もいろんなことを学びました。
また、発表を意識することによって最終アウトプットの形が明確になります。これは Amazon の "Working Backwords" で開発の最初にプレスリリースを書くことによっていい製品を作るアプローチに似たような効果が得られると考えています。
逆に良くないところはスケジュールの見積もりを誤ると自分を追い詰めることになります。今年も何度か締切に間に合わないのではという瞬間が何度もありました。これが今年の反省につながるわけです。
今年の反省
ということで今年の反省はスケジューリングです。
出したかったプロポーザルにどうしても間に合わなかったり、間に合ったとしても自分や家族にそれなりに負荷がかかってしまったりと、スケジュールの見積もりが甘かったせいでできなかった時もありました。
来年はこの反省を活かして早めに実装や準備を進めるようにします。
具体的には今年開催されていたイベントから、CfP が出る時期や締め切りを考慮し、その前から準備を進めておくこと、マイルストーンを必ず切ることを来年のアクションにします。
来年も頑張っていきましょう！良いお年を！
