非同期の世界観

私はかなり以前から、私たちの世界は非同期的で分散的な性質を持っていることに気づいていました。このことに気づき、それをどう活用するかを考え始めると、複雑な問題を解決するための壮大なコンセプトが容易に浮かび上がってくる。今回は、私がすでに使っているアイデアのいくつかを説明したいと思います。特定のソースから得ているわけではなく、複数の経験や自分自身の考えを組み合わせているのです。この原則は、すべてのケースに通用するわけではありません。

環境と目標の設定

私がこれまで取り組んできたほとんどのプロジェクトは（一人でもチームの一員としても）、かなり具体的に目標が設定されていました。このアプローチは、私たちが何を望んでいるかを知ることが重要であるため、非常に理にかなっています。一方で、複雑な環境では具体的な目標を定めることは不可能であり、実行中に「実は別のところに行きたい」と気づくことも多いと思っています。

だから、特定の目標ではなく、代替案があるような異なる目標の領域を構築する。あるいは、まったく新しい独立した目標でも、意味があれば正しい目標になりうるのです。

実践からの例

• 徐々に他の市場にも広げていく必要がありますね。実装中に発見したサブゴールの1つは、ウェブの機械翻訳かもしれません。
• プラハ周辺の異なる場所で6つの貨物をピックアップする必要があり、最短ルートがわかりません。面倒なことはしたくないので、とりあえず一番遠いところへ向かい、途中で他のルートへ計画を変更します。例えば、Andělで乗り換えたとき、先に到着したトラムに乗ることにして、次のルートプランにダイナミックに影響を与えます。
• この記事を書かなければならないのですが、1時間もまとまった時間がとれません。そのため、個々の章として地下鉄に乗りながら部分的に書くことができるのです。そして、今後、このフォームへの最終的なマージを行う予定です。
• クライアントの商品還元を計算するアルゴリズムが分からないので、プログラムを作り直したい。だから、同時に複数の人にクエリを出して、その間に別のことを解決してしまうんです。2日間非同期で、複数の異なる回答が来るので、それを元に後で判断するだけです。
• サーバーにあるPHPを長い間排除する必要があるので、1ページずつ少しずつReactに書き換えています。徐々にクラウドにサイトを移行し、静的に生成されたNectで構築しています。

どの目的地も最終目的地ではありません。点ではなく面で作業していれば、当たる可能性は高くなります。同時に、目標を達成した後に、将来の楽しみがなくなるというのは最悪の事態ですから、ここではモチベーションを高めることが効果的です。

同じような考え方をするためには、失敗してもいいようなかなり安定した環境が必要だと言うことも大きいです。この方法では、特定の1つのタスクを解決するために、特定の期限を保証することはできません。一方、キューに到着した順番とは限らないが、できるだけ多くの並列タスクをできるだけ短時間で解くことを最適化することができる。

この原理は、例えば、並列プログラミングにおける計算の仕組みに例えることができるだろう。要するに、タスクを個々のスレッドに分解して、異なるサブタスクを一度に解決し、すべての答えが出たら、解決策を構成するのです。

新しいバージョンのソフトウェアの導入

どこでもよく苦労しています。

通常、ソフトウェア開発では、ユーザー向けに本番稼動する安定版があり、次に新しい開発が行われるテスト環境があり、たまにテスト環境から本番稼動にニュースを移す、これがリリースと呼ばれる方法です。この工程は比較的安全で時間がかかります。

私は徐々に、アプリケーションのフロントエンド（ユーザーが見るもの）とバックエンド（計算やデータ処理が行われる場所）を完全に分離したマイクロフロントエンドアーキテクチャに移行してきたので、リリースプロセスは異なる方法で作業することができます。

今でも1つだけ、常に動作する本番環境があります。そこから、特定の機能に対応するために、タスクごとに新しいブランチを作成する。フロントエンドのホスティングにVercel（非常に優れたクラウドプロバイダー）を使用しているため、各開発ブランチにカスタムURLを設定することができます。

新機能がテストされると、すぐにマージされ、非同期処理で本番環境にデプロイされます。そのため、1日に15回くらいは新しいバージョンのデプロイが行われることもよくあります。

これは、LMCで教えてもらった「たとえ不完全な状態でも、明日お客様に提供する機能の方が、完璧にデバッグされて1年後まで利用できない機能よりもはるかに価値がある」という考えと大いに関係があることなのです。しかし、これはニュースを素早く配信する方法、つまり典型的なウェブ開発があって初めて機能するものです。

Next.jsフレームワーク（Rectoベース）とVercelで気に入っているのは、GitHubのリポジトリを直接Vercelに接続し、コミットごとに自動的にビルド、テスト、そして問題がなければ本番環境へのデプロイが行われるという原理です。そのため、開発者は何も心配することなく、1時間ごとにアプリをデプロイすることができ、労力はゼロです。定型的なことを形式化し、それを自動化することはとても大切なことです。

コンテンツパブリッシング

私はApple Notesでより高い数十のトピックとポストを私と一緒に分解しています。トピックごとに、新しいアイデアをどんどんメモして、タグで分類しています。1つのトピックに複数のノートが発生した場合、それらをチャプターに変換し、チャプターのグループを記事やFB投稿に変換しています。

この原理の特徴

• 何本の記事を掲載することになるのか、事前にわかりません。
• でも、それにしても、多いかもしれませんね。
• 私は、それぞれの投稿が、時間をかけて熟成された情報、洞察、アイデアに満ちていることを確認することができます（この投稿は熟成に約3ヶ月を要しました）。
• 持続性があり、一度に大量の文章を書く必要がなく、忘れ物をするリスクもないので、楽しめそうです。

そして、出版作業。

私は多くのコンテンツをまずウェブ上でひっそりと公開し、Googleが先に気づいてページがインデックスされるようにします。キーワードの網羅性が高く、全体として満足のいくものになると、その話題はソーシャルメディアなどに流れていきます。

多くのトピックについては、興味を持たれないし、むしろ迷惑になる可能性が高いと思っています。でも同時に、将来誰かが検索してくれるかもしれないので、オンラインにしておきたいとも思っています。その場合、記事はウェブ上にしか残りません。その一例がオーバーレイ記事です。このオーバーレイ記事は、サイト上でできるだけ多くのトピックをカバーできるように、トピック全体をリンクさせるものです。表紙の記事は、より専門的で退屈なものが多い。あるいは、複数の記事をトピックとして整理し、誰かが検索したくなるようなキーワードをできるだけ多く網羅した、機械的に生成されたカテゴリーです。

知識、教育、テスト

私は、いつか何に使えるか最初からわからないような技術で勝負するのが好きなんです。

機械翻訳のように。一見すると、接点のない読者のために何十本もの記事を外国語に翻訳する意味がないように思えますが、実はそうではありません。一方、前提条件を満たす必要がある、将来の意思決定のステップの一つである場合もあります。

一般に、未来がどうなるかは誰にもわからない。ですから、少なくとも表面的には理解したい、将来的には取り組みたいと思うような可能性をできるだけ多くカバーすることは、私にとって非常に意味のあることなのです。ステップを単に解決した作業と考えるのではなく、最終的な到達点のない、終わりのない進化の過程と考えるのがよいでしょう。

この方法は、カスタムプロジェクトの納品にも有効なのでしょうか？

ほとんどの場合、ノーです。

クライアントは自分のパートナーであり、たとえそれが最後までわからないと前もってわかっていたとしても、お互いに最善の解決策を提供したいと思うものでなければなりません。

私たちのビジネスでは、これをアジャイル開発と呼びますが、この原則はこれをベースにしています。一方で、私が知っているようなアジャイル開発が直接的に自分に合わないことも観察していますし、曲がった代替案を考えるのも好きです。

アジリティの場合、特定のスプリント内で誰が何を解決するかという点で、コミットメントの原則をよく見かけます。それよりも、今一番必要なこと、あるいは私の精神的なキャパシティに応じて、膨大なタスクのバックログを解決していくような環境を構築する方が理にかなっていると思いますね。例えば外出先では、パソコンがなくても外でできる発展的な思考課題に取り組むことが多いですね。オフィスに戻ると、よりアルゴリズムや計算が必要な仕事に取り組みます。なぜなら、完全に集中し、多くの精神的エネルギーを投入することができるからです。

この原則は、あなたが真新しいeショップを立ち上げている場合や、あなたのビジネスが破綻している場合にはお勧めしません。自走する安定した環境が必要で、ジュウタンをするだけです。しかし同時に、何もしなければ安定した環境がいつか終わることも分かっています。