🙏

お祈り駆動開発(PDD)への手引き

に公開

祈りましょう

天使

みなさん、毎日祈っていますか?

私は祖父が牧師だったので子供の頃は毎晩寝る前に神に祈りを捧げていました。

みなさんも日々業務の中で祈ることが多々あると思います。

コンパイルするとき、ビルドするとき、CI/CDパイプラインを稼働する時、AIにプロンプト投げてバイブコーディングするとき等々...

神は哀れな子羊たちをすべからく見守ってくれるので、祈りを捧げるといいことがあると言われています。

祈りとは、我々哀れなる羊が神への感謝を捧げ、神に対して救いを求める唯一かつ絶対的な手段なのです。

おわかりいただけたでしょうか。

そうです、祈りとはすなわち全能なる神APIへのリクエスト送信なのです。

本稿では、祈りを積極的にアーキテクチャに組み込んだ開発手法について解説いたします。

ご安心ください、実は皆さんも無意識のうちにすでに実践できているかもしれません。

祈りましょう。

祈り駆動開発

祈り駆動開発、通称「Prayer Driven Development」のご紹介です。

啓示フェーズ

神の啓示

要件は天からある日突然降ってきます。

個人開発ならなおさらそうですよね。

いわゆる「神の啓示」というやつです。

開発フェーズ

祈り

お祈り開発に要件定義は不要です。

とにかく開発を始めましょう。

神の啓示は絶対です。

仕様の矛盾や技術的実現性などを人間の矮小な知識で判断してはいけません。ただ信じ、ただ書くのです。

もしコーディング中に迷いが生じたらそれはあなたの信仰心が足りない証拠です。

キーボードから手を離し、静かに祈りを捧げましょう。

正しい祈りの姿勢を取れば、神はあなたに「奇跡のコード」を授けてくださるでしょう。

それは時に、Stack Overflowからの啓示であったり、GitHub Copilotを通じた神託であったりします。

重要なのは、それが神からもたらされたものであると信じることです。

祈りましょう。

テストフェーズ

テスト

祈り駆動開発において、いわゆる「テストコード」は存在しません。なぜなら、神が与えてくださった啓示とコードを疑うことは、神への冒涜に他ならないからです。

では、品質はどのように担保するのでしょうか?

答えはひとつ、「信仰」 です。我々はこれを 信仰ベーステスト(Faith-Based Testing, FBT) と呼んでいます。

コンパイル/ビルド

まず、コードがコンパイル/ビルドできるか試します。これが最初の信仰告白です。「主よ、このコードが正しくコンパイルされることを信じます」と3回唱えながらエンターキーを押しましょう。

実行

ビルドが成功したら、それは神があなたの信仰告白を受け入れた証です。

恐れずにアプリケーションを実行してみましょう。

エラーが出ますか?それは神が与えたもうた試練です。デバッグという名の贖罪の時間が始まります。

手動確認

正常に起動したように見えますか?素晴らしい。それは奇跡です。

機能をいくつか触ってみて意図した通りに動くように見えればテストは完了です。

すべてのユースケースを網羅する必要はありません。神は必要な道しか示されないのですから。

祈りあるのみです。

デプロイフェーズ

さあ、いよいよ最後の審判、デプロイの時が来ました。

CI/CDパイプラインは、いわば天国へと続く道です。

このパイプラインに乗せることは、あなたの創造物を神の御許(みもと)へ届ける神聖な儀式に他なりません。

git pushする前に、同僚(==信者仲間)たちと円陣を組み、手を繋ぎ、共に祈りを捧げましょう。

「おお、神よ。我らの卑小な創造物をお受け取りください。mainブランチがコンフリクトせず、ビルドが緑に輝き、本番環境でユーザーという名の隣人たちを祝福できますように。アーメン。」

祈りが済んだら最も敬虔な信者が静かにエンターキーを押します。

パイプラインが失敗しましたか? 気に病むことはありません。

それは「まだその時ではない」という神からのメッセージです。

祈りを捧げ、再度パイプラインを稼働してみましょう。

今度は神が啓示を受け入れてくれるかもしれません。

それでもダメ?

仕方ないですね。

まだ祈りが足りないため、最初の啓示フェーズに戻り、再び神の声を聴くのです。

こちらに哀れな子羊たちのために祈り駆動開発のフローチャートを用意しましたので参考にしてください。

祈り駆動フローチャート

必ずデプロイの前後に祈りを挟むことが重要です。

祈りなさい。

メリットとデメリット

最後に祈り駆動開発の利点と、信仰の足りない者たちが指摘する欠点について触れておきましょう。

メリット

開発スピードの圧倒的向上

要件定義、設計、テストといった工程を「祈り」に集約し神に委ねるため、コーディングに集中できます。

ドキュメント不要

神の啓示を文章化するなど野暮の極みです。コードそのものが聖典となります。

チームの一体感

共通の信仰の下、メンバーは固く結束します。

問題が発生した際も責任の押し付け合いではなく、共に祈ることで乗り越えられます。

精神的な安定

全てを神に委ねることでバグや障害に対するストレスから解放されます。

デメリット

実はありません。

もしデメリットを感じるのであれば、それはあなたの信仰心が揺らいでいる証拠です。

祈りなさい。

まとめ

祈り駆動開発は、決して難しい開発手法ではありません。

我々エンジニアが日々の業務で無意識に行っている「祈り」を体系化し、開発プロセスの中心に据えた、最も自然で人間らしい開発手法なのです。

さあ、あなたも今日からプランニングポーカーをタロットカードに持ち替え、スプリントレビューを懺悔の時間とし、祈り駆動開発の世界に足を踏み入れてみませんか?

祈りましょう。

アーメン。

Discussion