  |
はてなキーワード: インプリメントとは
元アジャイルコーチとして、アメリカのガチの、ガチのシステム開発現場に、言うたらエスノグラフィ（行動観察調査）をしてるようなもんです。三流プログラマながら。
そういうリファレンスみたいなことをお伝えしたら、皆さん（Regional Scrum Gathering Tokyo 2022の参加者）が喜んでくれるかなとか思って、内容を構成しています。
ただ、僕が知っているのはマイクロソフトだけですし、自分の職場だけなので、主語が大きすぎるとか、そう言うのはやめてください。心が傷つくから（笑）
そういうのを踏まえて聞いてください（笑）。全部一次情報で、人から聞いたものではないです。ちょっとだけマネージャ関連のところはマネージャに聞いたところもありますが、基本的には自分が経験したことのみで構成します。
ウォーターフォールは使われていない
まず滝。ウォーターフォールがどれぐらい使われてるのかって話ですけど、これは簡単です。ゼロパーセント、本当に見たことないです。
だからといって本当に素晴らしいスクラムをみんなやってるかっていうと、そうでもない。どれぐらいプロセスに対してマチュア（成熟）かはチーム次第なんだけど、少なくともイテレーティブじゃないのはないし、アップフロントデザイン（開発前の仕様策定）を大量に時間をかけてやってるというのもない。
デザインドキュメントっていうのを書く人もいれば書かない人もいて、書く人が多いですけど、書いても5ページぐらい。
何年か前にサム・グッケンハイマーというDevOpsで有名な人が日本に来たときに日本のお客さんに「ウォーターフォールとアジャイルのメリットデメリットを教えてください」って聞かれて、彼が「ウォーターフォールは全くメリットがないのでやめておきなさい」って言い放って。
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
分かります。誰も使ってないんだから。やっぱりもうやめといた方がいいですよね、正直話無理があります。
次は、僕のチームがどんな感じで運用されてるかっていうお話をします。
マイクロソフトには統一プロセスとかなくて、基本的にチームをどう回すかはチーム次第なんですよ。でもだいたいみんな似たような感じでやってると思います。
基本的にはスモールチームです。どんな大きなプロジェクトであっても、スモールチームの集まりって感じです。
自分のチームについては、これがよいやり方かは分からないですが、個人商店みたいなもので。「IC」というのはIndividual Contributorですね、開発者。
マネージャからアサインされるバックログが基本的にはふわっとしているので、ICがそれを明確にします。
ICが仕様を自分で明確化して、自分でデザインして、インプリメントする。だからそれぞれがレスポンシビリティを持っていて、それぞれが実装をする。
ただ、同じマイクロサービスをメンテする役割の人みたいなのがいて、それは「Buddy」（バディ）みたいになっていて、僕の場合は例えば「スケールコントローラー」っていうのを開発していますが、スケールコントローラーのチームでバディになってると、質問というかお互いに話が聞きやすい。すぐに答えてくれやすいですね。
他のチームとかになると、ちょっとバリアがあって。やっぱりみんなそれぞれの仕事をやっているので、プライオリティがそれぞれあるんですよ。だから違うチームの人になると意地悪じゃなくて彼らのレスポンスは1日に1回とかになったりするわけですよね。仕方がないことです。
多分このチームの単位はマネージャが管理できる最大以下の人数で構成されてるんじゃないかなと思います。だから本当に自分のチームはそれぞれが個人商店みたいな感じですね。自分でレスポンシビリティを持って自分でやる。それは新人であっても一緒です。
司会）ここでちょっと会場から質問が入りました。このチームというのはどういう単位なんでしょうか。プロダクトの単位なのか、どういう単位なのか。
（右下の点線で囲われたところ）このチームはスケールコントローラをやっていて、（右上の3つのICを指して）このあたりはプラットフォームと言って中の基盤みたいなことをやってたりします。
でも基盤もかなり巨大なので、内部でいくつか分かれているんですけど、同じマネージャが見て、みんなを助けている、という感じですね。
司会）隣のチームと、このチームを分けているのは、マネージャが違うだけ？
ええと、大きな機能で分かれているというのがあります。例えば隣のチームはランタイムっていうチームなんで、Azure Functionsのランタイムを担当してるんですよ。
さて、エンジニアの評価っていうのはどんな感じになってるかっていうと、この図にはマイクロソフトは入っていないのですが、僕の友達に「ゆうさん」っていう人がいて、彼がブログでGAFAの給与体系みたいなをまとめてくれて、マイクロソフトも似たような感じです。
参考：GAFA米国本社のエンジニアの年収をジョブレベル別に比較してみた【Google・Amazon・Facebook・Apple】
こういう情報って外部に公開されてるので別に隠すことはないし、マイクロソフトの給料の額とかも調べられるんですよ。
どういうふうになってるかっていうと、エンジニアとしてランクがあるんですよね、「SDE1」「SDE2」とか。マイクロソフトの場合は「シニアソフトウェアエンジニア」があって「プリンシパルエンジニア」がある、みたいな。
このランクの人はこういうことができる、っていうのが明確に定義されていて、それによって給料が決まるんですね。
だから自分が給料を上げたかったらどうするかっていうと、プロモート（ランク上げ）してもらえるように頑張るって感じです。他の人との戦いじゃないんです。
いまより一つ上のランクの仕事をしばらくしていれば、マネージャが「こいつは今はシニアだけどプリンシパルの仕事してるからプロモートしよう」とノミネートしてくれる。
そうやってノミネートされたら次のレベルに行けるし、行けなかったら転職をする。転職するとそこでネゴシエーションしやすいので、その時に例えばシニアとかプリンシパルになれればその給料がもらえる。
ただ、そういうふうに上に行くとレスポンシビリティも大きくなるので、自分でチョイスする感じですね。自分でチョイスするし、自分との戦いなので。だから他の人と比べて不公平とか全然思わない。
給料を上げたかったら次のレベルになればいい。そういうアクションをとればいいので、あくまで自分との戦いって感じになります。
マネージャの存在っていうのは僕的にはすごい（日本と）違ってるように感じています。
日本にいるときはマネージャって進捗管理や課題管理をしたりとかして、プログラマとか開発者を指揮するとかそんなイメージだったんですかね、僕のイメージとしては。
アメリカの場合は、彼らが重視してくれるのは僕のキャリアなんですよ。僕がハッピーかどうかとか、僕がキャリアで成功するかっていうのをすごい重視してくれるんです。
これまで何人かマネージャが変わりましたけど、みんなそうでした。マイクロソフトには明確にそう定義されているんです。だからマネージャはみんなそういう動きをしてくれます。
マネージャのすごく大事な仕事に「アンブロック」というのがあります。IC、つまり開発者の人がどこかで詰まっている状態になると、マネージャが助けてくれる。ブロックされているものをアンブロックしてくれるんです。
例えば、僕が技術的に詰まるとして、誰かに聞かなあかんけど、誰か聞かなあかん人がなかなか答えてくれへんとか、そういうこともあるかもしれないです。
そういうブロックをされる状況が一番生産性を阻害すると思うんですね。
そういうときにマネージャがアンブロックを手伝ってくれる。ある人に繋いでくれたり、マネージャ経由で他の人が僕に協力してくれたりとか。
マネージャが、このプルリクエストを見たら分かりやすいよと教えてくれるとか。
あと結構面白いのは、少なくとも今の僕の職場では、納期が基本的にない感じです。
あるときもあるんですよ。どんなときかっていうと、マイクロソフト最大のイベントの「Build」というのが5月ぐらいにあって、そのキーノートで発表される予定のプロダクトみたいなもの。それが決まったら納期があるのかもしれないですけど。
マネージャも僕に対して「早くしてください」って言ったことは1回もないですね。どっちかというと、僕が「何か遅くてごめんな」とか言ってたら、「いやそんな気にすんなよ」って、「よくあることだよ」とか言われたりする。
これは多分いろんな意味合いがあるんですよね。多分クラウドのプラットフォームって、難しいことがいろいろあって、例えば自分が1週間でできるって思ったのに2カ月かかったりとか、ほんまにあるんですよ。
例えば、JVMにあるJarをアタッチするだけに見えた仕事に、僕は半年かかりました。
僕の能力のなさもあるかもしれないですけど、そういういろんな予想外のことが起こる。
やっぱり世界中の人が使うプラットフォームなので、よく分かってない実装とかしたらむちゃくちゃになるんです。ちゃんと理解して、より良いアーキテクチャを作らないとひどい目にあう。
だから多分マネージャは絶対に急かさないんだと思います。ちゃんと理解して出来るようになれば、次からは開発が速くなる。だからマネージャとしてはそこで急かさないことによって未来への投資をしてる感じなんじゃないかなと、僕は思ってます。
バックログはあり予定もあるが、達成されないこともしょっちゅう
司会）すいません、マネージャの話しに行く前に。質問が集まっていて。納期がないという話に関して皆さんが大混乱に陥っていてですね（笑）。納期がないとすると逆に何があるのか。バックログみたいなのがあるのか、ロードマップがあるのか。どういうものを始点に駆動されていて、牛尾さんの仕事が始まるのか。
バックログですね。大きなトピックだけはある。今期はこれをやろう、というのはあるんですよ。
だいたい今期はこれとこれをやっていこうというのがあって、それを荒い粒度ですけどブレイクダウンしたストーリーにして、それをICにアサインするんです。
でも、それが今期に達成されないということはしょっちゅう起こります。
思ったよりもすごく難しかったとか、あるシステムで改変が入るのでそれまで作れないとか、そういうのがしょっちゅうある。でもそれでそのICが責められることはないです。
変化は見通せないので仕方ないですよね。オーガナイズはされているけど、できなかったときはできないと認める、ということです。
司会）お客様からバックログの元になるような要求がきて、それがリリースされるまでのタイムスパンはどのくらいなんでしょうか？
僕らの場合はプロダクトオーナーみたいなチームとしてプロダクトマネージャがあって、バックログの発生元はプロダクトマネージャが決めるのですが、そのインプットソースとしては、彼らの戦略（ストラテジ－）とカスタマフィードバックですね。
あとはハッカソンでエンジニアがなにかプロポーズするときもあります。
そういうもののなかからプロダクトマネージャが、今期これをやればインパクトがあるんじゃないかと考えるものがピックアップされます。
で、それが達成されてリリースされるまでの期間は本当にピンキリです。
僕の場合は、早いときは1週間で終わりましたけど、さっきの話みたいに1週間で終わると思ったやつが半年かかったこともあります。
僕の上にはプリンシパルマネージャがいるんですね、それが日本で言ったら課長みたいなもので、その上に部長みたいなのがいて、で、テクニカルフェロー、これは事業部長みたいな感じです。
彼らの技術力はどんな感じか。
僕の1つ上の上司は、Azure FunctionsのJavaランタイムをイチから書いた人です。
その上の人は、Azure Automationの開発をしている人で別チームなので細かいところまでは知らないのですが、技術力がハンパない、ということだけは分かります。
何でかと言うと、どんなテッキーな話題を振っても、ものすごく早く深く理解するんです。彼が経験したことのないことであっても、Kubernetesでも、彼がやったことのないPythonとかでも、完璧に理解してアーキテクチャの深い話をするんです。
で、テクニカルフェロー。これはAzureの主要なサービスをイチから書いていたりします。
つまり何が言いたいかというと、僕の上司で僕よりもプログラミングができない人なんて一人もいないんです。
そしてこういう人が僕の仕事のサポートをしてくれる、応援をしてくれるわけです。
だからこんな上司に何かを説得する必要なんてないんです。彼らがテッキーなミーティングに参加して、しかも僕らにすごい鋭いアドバイスをくれるんですよ。
皆さんがもしマネージャをやるときには、こういう人たちと世界で戦わないといけない、ということをちょっと意識していただきたいんです。
↓
だから、外部に良く知られているバブルソートですらN=1,Bigっていう特殊解（一般的ではないが現場では良く使う）がある。
選択用の項目が１６個あるだけで6万通りの組み合わせがある。
部品ひとつでそんな感じなものを、１つ１つ大学で教えてもらうような理論を初歩として多数組み合わせて選んで
比較的楽な、オープンソースですら内部をけっこう読み込んでいって合わせこむか、こまないかで
他の職業だってそうだけど、ITは大学で学問があるくらい大変なコース。
みんなと、お話し合いができる簡単なバブルソートでこのざま。もうちょっといくと『木の均衡』とかがでてくるけどこの辺になってくると
増田がとんこつラーメンを食べるとき、まずgoogleで検索ボックスの中に「とんこつラーメン」と入力し、途中ラーメンの部分をザーメンと入力してしまったことに気づいてカーソルをラの字に移動した後に一文字消してラに書き換えて検索実行するわけだよな。
そしてその後google社が提供しているgoogleマップという地図アプリに表示されているとんこつラーメン店である場所のアイコンに向かって、地図を見ながら歩き出す訳だよな。
（長くなりすぎるので中略）
「何を親とするのか」がまずあり、これはルールによって「サイコロを振って出た目の数だけ左回りに移動した最後の家」が親になることもあれば「目という器官が最初にとらえた映像」であることもあるわけだ。
では、「目という器官」が最初に捉えたものがフグだったらそれが親になるのだろうか？
そこも違うよな。「大凡親である者が何か」のルールも何故か決まってるんだよな。
じゃあその「あったかくて」はどうしたら判定できる。
ここくらいでやっと情報がリニアにシグナルとして処理できるレベルになってくる。
あったかいかあったかくないかの判定は割と簡単だ。あったかければあったかいほど水銀の体積が大きくなる。
そういう単純な情報として処理できることこそが「複雑度が少ない、単純でおそらく本能としてインプリメントされている行動」だと言える筈なんだ。
だから、猫で言えば「モノを高い所から落とす行為」は本能ではないと言えるしなめる行為も本能レイヤーとは別の第五の力もしくは第六感（いずれも科学的には解明されていない）が働いている可能性も否定はできないんだよ。
第1章 並行プログラミングとGHC (上田和紀) 1.1 はじめに 1.2 ターゲットを明確にしよう 1.3 はじめが大切 1.4 GHCが与える並行計算の枠組み 1.4.1 GHCにおける計算とは，外界との情報のやりとり(通信)である 1.4.2 計算を行う主体は，互いに，および外界と通信し合うプロセスの集まりである 1.4.3 プロセスは，停止するとは限らない 1.4.4 プロセスは，開いた系(open system)をモデル化する 1.4.5 情報とは変数と値との結付き(結合)のことである 1.4.6 プロセスは，結合の観測と生成を行う 1.4.7 プロセスは，書換え規則を用いて定義する 1.4.8 通信は，プロセス間の共有変数を用いて行う 1.4.9 外貨も，プロセスとしてモデル化される 1.4.10 通信は，非同期的である 1.4.11 プロセスのふるまいは，非決定的でありうる 1.5 もう少し具体的なパラダイム 1.5.1 ストリームと双方向通信 1.5.2 履歴のあるオブジェクトの表現 1.5.3 データ駆動計算と要求駆動計算 1.5.4 モジュラリティと差分プログラミング 1.5.5 プロセスによるデータ表現 1.6 歴史的背景と文献案内 1.7 並行プログラミングと効率 1.8 まとめ 第2章 様相論理とテンポラル・プログラミング (桜川貴司) 2.1 はじめに 2.2 様相論理 2.3 時制論理 2.4 多世界モデル 2.5 到達可能性と局所性 2.6 純論理プログラミングへ向けて 2.7 Temporal Prolog 2.8 RACCO 2.9 実現 2.10 まとめと参考文献案内 第3章 レコード・プログラミング (横田一正) 3.1 はじめに 3.2 レコードと述語の表現 3.3 レコード構造とφ-項 3.3.1 φ-項の定義 3.3.2 型の半順序と束 3.3.3 KBLとLOGIN 3.4 応用――データベースの視点から 3.4.1 演繹データベース 3.4.2 レコード・プログラミングとデータベース 3.4.3 いくつかの例 3.5 まとめ 3.6 文献案内 第4章 抽象データ型とOBJ2 (二木厚吉・中川 中) 4.1 はじめに 4.2 抽象データ型と代数型言語 4.2.1 抽象データ型 4.2.2 代数型言語 4.2.3 始代数 4.2.4 項代数 4.2.5 項書換えシステム 4.3 OBJ2 4.3.1 OBJ2の基本構造 4.3.2 モジュールの参照方法 4.3.3 混置関数記号 4.3.4 モジュールのパラメータ化 4.3.5 パラメータ化機構による高階関数の記述 4.3.6 順序ソート 4.3.7 属性つきパターンマッチング 4.3.8 評価戦略の指定 4.3.9 モジュール表現 4.4 おわりに 第5章 プログラム代数とFP (富樫 敦) 5.1 はじめに 5.2 プログラミング・システム FP 5.2.1 オブジェクト 5.2.2 基本関数 5.2.3 プログラム構成子 5.2.4 関数定義 5.2.5 FPのプログラミング・スタイル 5.3 プログラム代数 5.3.1 プログラム代数則 5.3.2 代数則の証明 5.3.3 代数則とプログラム 5.4 ラムダ計算の拡張 5.4.1 ラムダ式の拡張 5.4.2 拡張されたラムダ計算の簡約規則 5.4.3 そのほかのリスト操作用演算子 5.4.4 相互再帰的定義式 5.4.5 ストリーム(無限リスト)処理 5.5 FPプログラムの翻訳 5.5.1 オブジェクトの翻訳 5.5.2 基本関数の翻訳 5.5.3 プログラム構成子の翻訳 5.5.4 簡約規則を用いた代数則の検証 5.6 おわりに 第6章 カテゴリカル・プログラミング (横内寛文) 6.1 はじめに 6.2 値からモルフィズムへ 6.3 カテゴリカル・コンビネータ 6.3.1 ラムダ計算の意味論 6.3.2 モルフィズムによる意味論 6.3.3 カテゴリカル・コンビネータ理論CCL 6.4 関数型プログラミングへの応用 6.4.1 関数型プログラミング言語ML/O 6.4.2 CCLの拡張 6.4.3 CCLに基づいた処理系 6.4.4 公理系に基づいた最適化 6.5 まとめ 第7章 最大公約数――普遍代数，多項式イデアル，自動証明におけるユークリッドの互除法 (外山芳人) 7.1 はじめに 7.2 完備化アルゴリズム 7.2.1 グラス置換えパズル 7.2.2 リダクションシステム 7.2.3 完備なシステム 7.2.4 完備化 7.2.5 パズルの答 7.3 普遍代数における完備化アルゴリズム 7.3.1 群論の語の問題 7.3.2 群の公理の完備化 7.3.3 Knuth-Bendix完備化アルゴリズム 7.4 多項式イデアル理論における完備化アルゴリズム 7.4.1 ユークリッドの互除法 7.4.2 多項式イデアル 7.4.3 Buchbergerアルゴリズム 7.5 一階述語論理における完備化アルゴリズム 7.5.1 レゾリューション法 7.5.2 Hsiangのアイデア 7.6 おわりに 第8章 構成的プログラミング (林 晋) 8.1 構成的プログラミング？ 8.2 型付きラムダ計算 8.3 論理としての型付きラムダ計算 8.4 構成的プログラミングとは 8.5 構成的プログラミングにおける再帰呼び出し 8.6 おわりに：構成的プログラミングに未来はあるか？ 第9章 メタプログラミングとリフレクション (田中二郎) 9.1 はじめに 9.2 計算システム 9.2.1 因果結合システム 9.2.2 メタシステム 9.2.3 リフレクティブシステム 9.3 3-Lisp 9.4 リフレクティブタワー 9.5 GHCにおけるリフレクション 9.5.1 並列論理型言語GHC 9.5.2 GHCの言語仕様 9.5.3 GHCのメタインタプリタ 9.5.4 リフレクティブ述語のインプリメント 9.6 まとめ
出来てないコーダー、つまり『安藤忠雄の設計を渡されて、ただ、組み立てているだけの大工が見たいな奴』が、名声を嫉んでスーパークリエイターとか未踏の人間を叩いてるんだろ。
未踏に受かるためには
・面白くてわかりやすい提案書作成能力
・それを成し遂げることが可能と思われる実績
が全て必要。
なのに、最初の提案書作成から問題がある奴が多すぎる。
・短期間で優秀な設計をする能力
・短期間で虫取りをこなす能力(これは設計が優秀なら極力必要なくなる。)
が全て必要。
そのどれが欠けてもなれない。
ITアーキテクト、コンサルタント、投資銀行ストラテジスト、アルファブロガーから成る我々MBAホルダー探検隊一行は、東南アジアはミャンマーの魔境「チョイワル」へと向かった。その魔の密林に住むという未知の生物「ライフハック」を捕獲するためである。
ライフハックの身長は15m、太古に生息した恐竜を思わせる、武器にもなる長い尾「ロングテール」を持ち、モテる男の恋愛術を使いこなす、現地ではまさに「エバンジェリスト」と恐れられているのだ。
我々一行は、紛争地域モヒカンの真ん中をコンティンジェンシー・プランを施した男の隠れ家であるハマーH3で進んだ。クルマから降りればたちまち反体制勢力ネットイナゴの攻撃を受け、炎上させられる。
やがて道が途絶えたところで我々はハマーを止め、そこから徒歩でチョイワルに向かうこととした。何かがブロゴスフィアの密林の中から常に我々を監視している、そういう気配がした…そのとき！何者かが我々に突如毒矢を放ち、アラートを上げながら我々を制止したのだ。
それは、成功するイメージを身にまとった未開の自由人アーリーアダプターだった。
アーリーアダプターは、デキる男の武器を手に手に我々を威嚇していた。我々は現地ガイドをアサインした上で、なんとかネゴシエーションを試みた。
現地ガイドの説得によって誤解が解けた我々は、彼らの村にインビテーションされることとなった。
そこでは今まさに彼らは戦略会議の真っ最中であった。我々もその席に参加した。この席でアグリーメントが結ばれ、やがてWin-Winの関係に至るとファシリテーションに夢中の長老CTOは語った。
我々は、長老にチョイワルとライフハックについて聞いてみた。長老によると、チョイワルはこの村から一つ山を越えた先にあるという。しかも、長老はチョイワルで仲間と週末フットサルの最中にライフハックを目撃したと言うではないか。
しかしながら、長老はこれ以上語りたがらなかった。それが長老の他に対する差別化戦略2.0なのだろうか。いずれにしても、我々は礼を述べ眠りにつくことにした。
「明日はいよいよチョイワルだ。それじゃあみんな、タイムマネジメントはしっかりな」twitterにメッセージが流れた。
翌朝、我々は日の出とともに目を覚ましてすぐ、チョイワルへ向かう準備を開始した。
チョイワルは、特殊な地形と強力なシナジー効果のため、方位磁石はおろかNAVITIMEすら効かない。さらに危険な動植物が我々の行く手を阻む。まさに文字通りのクリティカル・パスなのだ。我々はメンズエステを施すのみならず、男の戦闘服であるスーツを装着した上で、念には念を入れた。
ちょうどそのころ、アーリーアダプターの集落では、GTDメソッドに話の花を咲かせながら男の手料理による朝食の準備を始めていた。我々も朝食に呼ばれ、村の中心部にある男の隠れ家的ワインセラーにお忍びで集合した。
彼らの主食はユビキタスと呼ばれ、家庭のみならず収穫や狩猟の場でも食べられるという、まさにCGM社会に生きる我々にとってはうってつけの食べ物であった。
朝食後、長老が我々の成功を願い祈祷を捧げてくれると言うではないか。長老は奇声を上げ、コーチングのポーズを取りながら呪文を唱えた。
「迷わず行けよ、行けば分かるさ！ダーー！！」
長老によると、この呪文は男の美学をアップさせ、誰にも真似出来ない自分を演出させてくれるという。万全を期した我々一行は、村人に丁重に礼を述べ、チョイワルへ向かうため村を出た。
険しい山道とジャングルを進み続けること数時間、それらしき場所に到達した。そう、若い男性に人気の萌えショップが立ち並ぶ、この新レイヤーが魔境チョイワルである。我々は恐怖と興奮のあまり少年の心が甦るのを感じた…まさにそのときである！隊員のコンサルタントが怒号のような悲鳴を上げたのだ。
「ぐああああぁっ！！ロジカルシンキングがなっとらん！！」
なんと、獰猛ながら本格派の粋Z（ジー）に会議で刺されたと言うではないか。すぐさま我々に同行していたITアーキテクトがトラブルシューティングを開始した。アーキテクト曰く、この場で引き返すか、複数のサービスをインプリメントしたマッシュアップによるソリューションの提案しか方法は無いと言う。
我々はマッシュアップを選択するというディシジョンメーキングを行い、隊員のアントレプレナーシップが回復するのを待つため、ここでブートキャンプを設営することにした。スキルに秀でた隊員達は、手際よく必要なコモディティを配置、行きつけのジムと同じ設備をアレンジメントすることに成功した。そして、負傷した隊員をリラグゼーション・スペースに運び、ここで治療を続けることにした。
と同時に我々は、ライフハックを捕獲すべくキャンプの近くにdel.icio.usアカウントを設置、繁殖期でフォークソノミー体質のライフハックをアルファギークに大人気のソーシャルメディアで誘い出すという作戦だ。
それとは別に、夜間撮影対策を施したXactiを数台設置。捕獲できなくても、せめてその姿を夢を諦めないことの証明のために撮った上で、FlickrとYouTubeでシェアしたいとの思いである。
やがて夜を迎え、隊長は危険な生物が我々を襲わないよう見張り役にシフト勤務を伝えた。
次の朝、我々はdel.icio.usアカウントがなくなっているのに気づいた。ついにライフハックが現れたのか？「すごいディールだ！」隊員達は全てのソーシャルメディアを確認した。しかし、del.icio.usアカウントがスプーフィングされただけで、ライフハックの姿はどこにもなかった。ビデオに映っているかもしれない。我々はビデオをすぐさま再生。もちろん、行きつけのジムで。しかしながら、ビデオに映っていたのは、いかにもニートで喪男風な野生の貧相なキツネだけだった。
とはいえ、負傷者が出てしまった以上、ここに長居をすることはできない。我々はプライベートは大切にしたい自分を悔やみつつも、チョイワルを後にした。
この魔境に絶対ライフハックは存在する。今も、ライフハックの、そんな彼の普段の顔は勝ち組風でパートナーの気を引いているのだから…。我々がアウトローである以上、会社の歯車にはならないぜと、隊員達は各々胸にポジティブな思いを秘めながらジャングルを眺めていた。
