00:00
私の愛しいアップルパイへ。
えっと、昨日スーパー行ったら、あの355mlのレッドブルーめっちゃでかいやつ売ってて、つい買ってしまった、jMatsuzakiです。
はい、先日とあるところでですね、カフェなんだけど、カヌーレというお菓子を、この名前として知って初めて食べて、へーと思ったのも美味しかったです。
僕カヌーレ大好物なんですけど。
そうなんですね。僕はそれと知らずに何回か食べたことがありましたけど、あの名前と名称と味が一致したのは前回。
いやー美味しい。
炎上案件の始まり
はい、人生で一番働いた時期っていつかなって思ったんですけど、多分去年なんですよね、僕。
働き過ぎでは。
今はね、2024年ですね。この年はね、本当にね、よく乗り切れたなってね、今は思いますけど、めちゃくちゃね、働きましたね。
あの忙しい自慢嫌われるだろうなっていうのを理解してもなお言いたい。2024年、一番働きました。
これ別の放送でも多分話すと思うんで、ちょっと触りというかだけ話すんですけど、とにかく2023年末に雇用したプログラマーにとこそこ騙されてたっていうことが分かりまして、
はいはいはい。
2024年一発目から、それをもう取り戻すとこから始まったんですよ。4ヶ月間フルで入ってもらってたプログラマーがいて、その人が作ってくれてるはずのものだったものが何もなかったっていうことが分かって、
4ヶ月マイナスからスタートしたんですよね。で、その4ヶ月分を取り戻す上に、そもそも僕たちは作んないといけない、その人担当じゃない分も作んないといけないってことになって、それをね、もう2024年頭から、タスク集のクラウド2なんですけど、
はいはいはい。
ずっとやりまして、正直あんまり記憶ないんですけど、もうめちゃくちゃね、大変でしたね。
うーん、なるほどね。
もうよく乗り切れました。
うん、確かに。いつぐらいまでかかったんですか?大筋、大筋っていうのは今もかかってるのはあるんですけど。
はいはいはい。いやー、あのですね、もともと1月の時点で、これ佐々木さんも多分その時、結構やり取りしてたんで、覚えてるかもしれないんですけど、1月の時点でこれダメだってなったじゃないですか。
克服への道
はいはい。
で、そもそも、その4ヶ月前に開発始めたんですよ。4ヶ月経った時に、そろそろリリース目処立ってないと、会社のキャッシュ的には結構厳しくなってくるよねっていう時期だったんですよ。
はいはい、なるほど。
で、その1月の時点で、あ、何もないじゃん、中身っていうことに気づいて、で、本当はその時点でもうリリース目処立ててないといけないのに、むしろこれからスタートなんだってなって、で、そっからもう1回計算してさらにプラスで4ヶ月ね、4月まで、1月か4月までに形にならないと流石にやばいんじゃないかっていうことはわかったんですよ、計算して。
で、まあじゃあとりあえずもう4ヶ月でどうにかしようってなって、8ヶ月かかりました。
ということは8月?
8月。
なるほど。
もうね、あれですよ、朝9時とか10時くらいに起きて、0時までプログラム書いて、で、そっから100日チャレンジとか、タスク仕事協会のなんか諸々のやつをこうやるみたいな感じで。
で、何時に寝るの?
いや、4時とか5時とかですかね、はい。
で、また9時に起きて、またコード書き出すという。
そうなんですか。
本当に何回も、何回も僕夢でプログラム書きましたからね。
なるほどね。それを8ヶ月?
それを8ヶ月。
そんぐらいの忙しさで1ヶ月とかだったら、多分まだあったんですよ、僕サラリーマン時代とかでも。
本当にいわゆる炎上案件みたいな。
炎上案件で腹ね、結局ね。
そうなんすよね。
で、会社員の頃は良かったなって思うのは、正直やっぱり僕が働いてた会社って、そこそこ中堅の規模の会社だったんで、
マジでヤバかったら、誰か助っ人入れてくれるんすよね。
なるほどね。
で、本当にすいません、もう体調的に僕ヤバいっすって言ったら、休ませても多分くれるんすよ。評価とかは分かんないですけど。
でもやっぱあるじゃないですか、人的リソースが。
フリーランス自営業怖いのって、それがないんすよね。
上司がいないし、すいませんちょっともうダメっすって無理じゃないですか、ないじゃないですか、ダメっすって本当にダメじゃないですか、もうそれって。
本当にダメになっちゃうんで、もう排水の陣も良いところでしたね。
なるほどなー。
今は動いているし、使えてますからね。
いや本当に良かったですよ、諦めなくて。
諦めそうになった?
もう諦めそうになりました。1月のこれ中身何もないやつ納品されたわっていうことが分かって、それもいろいろあるんですけどね、経緯がね。
それはまた話しますけど、とにかく中身が空っぽのプログラムが納品されて、これヤバいなと。
でその時点で、僕ともう一人エンジニアさん、昔からタスクシュートクラウドのスマホ版作ってくれた人なんですけど、その2人で開発してたところもあって、全体の進捗30%くらいだったんです。
で30%って超微妙な進捗じゃないですか。
全部無しにするには結構進んでる。
でもこのままいくにはあと7割はあるみたいな。
撤退するか、でもこのまま頑張るかみたいな感じで、みんな残った人で話して、
行ってみようと3割はあるんだしと、この行動を捨てるっていうのはもったいないし、何よりその4ヶ月間で融資を受けてるんで、それを返さないわけにはいかないんですよね、絶対に。
でそれ返すためには新しい事業で収入がないと厳しいから、これはもう作り上げて事業を育ててで融資も返済するし、
で以前よりも事業が育ったっていうところをとりあえず目指してみますかみたいな感じになってですね、諦めずにいきましたね。
プロジェクトの成功
なるほど、おめでとうございます。
いやーありがとうございます。
お疲れ様でした。
その後本当にありがたいことにリリースしてから佐々木さんとかも色々と広めてくださったんで順調にユーザー数も伸びて、
ちょっとね最近本当にようやく一段落というか、とりあえずプロジェクトは一段落ついたよかったなっていうところまで来たんですけど。
13ヶ月から16ヶ月ってところだね。
いやそうですね、覚えてるかもしれないですけど8月にリリースしたじゃないですか。
その前クローズドベータでそこから本番リリースっていう正式版としてリリースっていうのがあるんですけど、そのタイミングが大体2週間くらいだったんですよ。
クローズドベータを埋めてから本番リリースするっていう。
普通そんな短いはずないんですよ。
でもちょっとお察しくださいなんですけど、やばいぞとこのままいくと。
もうこのままいくと俺と管理の貯金全部尽きるぞってなって。
もうそれのギリギリが2週間。
もう8月の半ばくらいにどうにかリリースで、そこからバグフィックス3ヶ月くらい毎日出してどうにかなったって感じなんですけどね。
よくその状況で総決算までやろうっていう気になりましたよね。
本当ですよね。本当そう思いますよ。
これでもですね、僕も何回かポッドキャストの中でお話ししてると思うんですけど、
2020年くらいコロナ禍の時にメンタル崩して、結構生き方とか働き方変えたっていう、そのターニングポイントだったっていう話をしてきたじゃないですか。
これはその後なんですよね。
ターニングポイントを迎えた後のプロジェクトということになって、それ以降で一番厳しい状況だったんですけど、
たぶんあのターニングポイントっていうものを経験する前の状態でこうなってたら、僕はとてもじゃないけどサバイブできなかったと思うんですよ。
なるほどな。
なぜかというと、僕の以前の働き方って、ゴール決めて計画立てて一個一個やっていきましょうってやり方だったんですよ。
今回みたいに、もうやばいぞと、あとないぞと、もうどうにかするしかないぞってなった時に、
ゴール決めて計画立ててやることを洗い出して一個一個潰すっていうことをやったら、本当にね、耐えられないと。
でも、そういう状況になった場合は特にそういうふうにするわけでしょ、以前の。
そうなんですよ。だから潰れちゃうんですよね。始める前に。これもう無理だと、ダメだと。
で、毎日毎日辛い、辛い。で、どんどん落ち込んでっちゃう。
僕がその2024年、やっぱり一番サバイブできた理由っていうか、ここがね、正直こんなに働かない方がいいし、こんな状況にはね、今これ聞いてるエレガントなリスナーの方は落ち入らないでほしいんですけど、
落ち入ってしまった僕の経験化すると、これを乗り越えられたのはもう完全にタスクシュートなんですよ。
これツール的な意味じゃなくて、メソッド的な意味です。ツールとしてのタスクシュートは昔から使ってたんですけど、
考え方としてもタスクシュートと完全に同期できるようになったっていうのが、やっぱりこの主語年で。
こうなったことによって、僕は一切タスクリスト持たなくなったんですよ。
タスクシュート上に今日やることっていうのがルーチンから生成されたものですね。
今までこれやってたから今日もやるよねっていうシミュレーションみたいなものがあるっていうのはあるんですけど、
でもそれってちょっと普通のタスクリストと違うじゃないですか。
普通のタスクリストってまだ終わってないものをリスト化したものであって、これまでやってきたものが自動でコピーされたものとはちょっと違いますよね。
この従来のタスクリスト、まだ終わってないことのリスト、これからこれやらないといけないよね。
計画ゼロの働き方
完成までにこれ必要だよねっていうことが書かれた詳細なトゥールリスト、タスクリストっていうものを完全に作らなくなったっていうのが、
僕は一番いいことだったなと思って。
これがないことによって、とにかく1日を生きるっていう。
このとにかく1日今目の前にあることをやる。
これだけをやってきたんですよ、2024年365日。
僕はこれがタスク仕事クラウド2っていう、ああいうシステムを作るものにも適応できるんだっていうことがある意味自分の中で証明できた。
自分の中で経験できたっていうのはすごい大きかったです。
これで僕は専門家じゃないんでね。
若干ザクッと質問させてもらうんだけど。
なんでシステムをやるときに全部先に洗い出すというGTDっぽい手法を取るかというと、
おそらくは抜け漏れを生まないということがシステムを作るために必要だからであって。
もう一つは手戻りというものが発生しないためにも、手順というものを最初に明らかにしておく必要というものが多分システムでは求められていると考えられているからだと思うんですよ。
そうっすね。
だからそんなに大きなものの適当って言ったら変だけど行き当たりばったりに作り始めると、こっち先に作っちゃったから、
例えばプラモデルで言うとここを先に作っちゃったら部屋通せないじゃんみたいなことが起きるから。
全部組み上げる前に移動させておきましょうとかそういう手順というものが必要になると。
あとはこうやって膨大に作っちゃったけどこれとこれとこれが考えてみるとないよねみたいなのが後から発生すると困るんで、
先にチェックするっていうことなのかと。
この2つが今のJさんの話とどう整合するんだろうという。
私からすると今回のタスクシュートクラウド2は抜け漏れはないんですけどね。
多分二度手間はあったのかもしれないけど、それは僕には見えないことだからあれなんですけどね。
時間が全くなかったから二度手間とかは多分発生させたくはなかったと思うんですよ。
その辺はどうなんでしょうねっていう。
これねめちゃくちゃそれ鋭い質問でシステム会社の上司に言われそうな指摘なんですけど。
めちゃくちゃ本当に理にかなった質問で。
これね僕まだに僕の中でまとまってないんですけどちょっと面白いなって思ったことがあって。
タスクシュート式にタスクシュートクラウド2を作ってるじゃないですか。
そうなるとプログラムもちょっとタスクシュート的になっていくんですよ。
っていうのはプログラムの作り自体が大前提として手戻りは絶対あるし、どんなに設計したってそれが完璧では絶対ないっていう。
それは事前に設計していようがどれだけ詳細に分析していようがそんなことは絶対わからない。
ある意味未来予測できないよねっていうタスクシュート的な考え方がプログラムにもものすごく色濃く反映されてて。
プログラムの仕組み作りとしてどんだけ手戻りがあってもいいよねっていう設計になったんですよね内部的に。
わからないけれどもそうなんですね。
旧タスクシュートクラウドって全然そうなってなくてこの設計じゃダメだよねこれ手戻り必要だよね。
タスクを見極める
ちょっと方向性変えないといけないよねってなった時に大きい方針転換が全然できないですよね。
2だとずいぶんそれはやりやすくなったし正直画面から全部作り直そうっていう話になったとしても完全に全部ゼロには戻らない。
本当に根幹のところは使い回せるっていうことになってて。
この辺はなんかねちょっとこう設計が非常にちょっとタスクシュートに似てるというかタスクシュートが前提としていることをそのままソフトウェアに適用されてるっていうか。
面白い話ですね。
そうなんすよね。
それがまず一つ絶対正解なんていうのはリリースする前に正解は絶対わかんないっていうのが大前提とした設計になってるっていうのがまず第一にあるのと。
あとこれタスクシュートクラウド2っていうのを2010年ずっと作ってきて。
あとそれと並行して100日チャレンジもちょっと何回やったかわかりませんけど結構何回も回したし。
これを並行してやろうという気になります。
Jさんは今の話をするそのスタートの段階の1月のないじゃんっていうのがわかった時に実は本を売ってたっていうのを覚えてます?
いやそうですよ本当ですよ出版タイミングだったんですよねあれ。
出版タイミングだったんですよあれは。
てか日本に来てましたよね。
日本にも行ってましたよ。
ちょうど今の時期。
そうそうそうそう。
そんなことをやってたんですね。
そうなんですよ。
でそういうことをねやっていく中でこれなんとなく僕は薄々思ってたんだけど実際マジでそうだったっていうある意味確信を持てたっていう大きい出来事があって。
これが直感で決めたものは論理的に決めたものよりも正しいっていうことなんですよ。
僕はこの1年間何やってたかっていうと本当にその日1日のことしか考えてなくてその日1日の中で今やるとしたらこれしかないだろうなっていうものだけをただやってたんですよね。
これをやったらこれがあってこれをやったらこれがあるからそしたらこれも必要じゃんっていう考え方は一切しないようにしたんですよ。
とにかくなるべく頭を空っぽにした状態で今本当に必要これはやらないわけにはいけないいかないよねっていうのは何なんだろうって考えてポンポンポンって出てくるんですよね。
それを疑わないそれを疑わずにもうそれが正しいと思って。
でこれの精度めちゃくちゃ高いんだなっていうのをすごい分かったんですよ。
なるほどね。
この例えばタスクシュートクラウド2だったら今とりあえずルーティンをタスクにするところから作る必要あるなっていうなんか分かるんですよねこれって。
これは全体の設計機能がどれだけ盛り込まれるか最初のバージョンとかは全然分かってないんですよ。
でも次に必要なのはこれだよなって設計があろうがなかろうがっていうのって大体分かるんですよね。
でそしたらそれしかやらないんですよ。
で作っていくとあそしたらこれいるなこれは絶対いるなってなってそれができたら次それやるみたいな感じで一歩進んだら次の一歩決めてまた一歩進んだら次の一歩決めるっていうやり方が事前に計画を立てておくやり方よりもむしろ精度高いっていう僕の中ではもう確信できたんですよね。
全体像を持たないことの利点
これが一番失敗しそうなソフトウェアの装置化でもうまくいったっていうのは僕の中ですごく大きくて。
それを本を書くんなら分かるんだよ。
はいはいはいはい。
なぜなら本は少々内容に矛盾があってもコードと違って動くんだよ。
まあ動かないからなんだけどね。
なんかこういやいやバグが出ましたからとかはないわけなんですよね分子の場合はね。
だけどコードだとだってそれは動かなくなるじゃんっていうか何て言うんだろうね。
分かんないんですけどね。
システムには矛盾があっちゃいけないんじゃないかって考えてるから。
そうなんですよね。
それを恐れてアウトラインを作り出してしまうという話が出てくるぐらいなのに僕は本に関しては今Jさんがおっしゃった通りの書き方しか絶対にしないんですよね。
Jさんと書いた時もそうなってたしJさんもそう書いたしだからそれでよかったんだけど本はねそれでいいよねっていうことにできるんだけどどうしてもシステムがねそれでいいっていうのがね普段僕が喋ってることと逆になっちゃうんだけど不思議なんだよね。
分かります。
そうなんですよね。
これがうまくいったっていうのはすごく大きかったですね。
これなんでうまくいったのかなって改めてちょっと考えてみると事前に機能を洗い出して設計して仕様書書いてその通りにプログラムを書く。
これがトップダウン的な従来のというか一般的なソフトウェアの作り方なんですけど。
これやっぱりこのやり方でやると結構ねうっかりが結構あるんですよ言うて。
なぜかっていうと設計段階って別にコード書いてないじゃないですか。
はいはいはい。
コード書いた時に分かることって結構あるんですよやっぱり。
でも設計する時ってリアリティがないんで割と雑なんですよその時に詰めた仕様って。
でも設計書があって仕様書があってそこまで詰められている状態でプログラムを書いていこうってなった時に結構仕様を信じちゃうんで。
そうでしょうね。
割と仕様の時に漏れてたことって気づく時は気づくんですけど気づかないことも結構あるんですよね。
逆にそういうものがなくてとりあえず今必要なのってこれしかない。
だからこれを本気で作ろうっていう気持ちになるじゃないですか。
これを本気で作ろうっていう気持ちでそのことだけ考えてると結構ヤバそうなところはそのタイミングで結構分かるんですよ。
すごいな。
すごく注意深くなるというかその1個の完成度はめっちゃ高くなるんですよね。
なるほどなるほど。
これを結局続けていくと全体としてはクオリティはかなり高くなるっていうのもあるし。
やっぱり全体像がないから先送りしなくなるってのがありますね。
これだけあるんかいっていう明日から頑張ろうではならないっていう。
なるほどね。
とりあえず続き作ろうしかないんで。
それで多分本当に先送りっていうのは1回もなかったし本当に毎日10時間くらいずっとコード書いてたんですけど。
逆算から順算へのシフト
それが続けられたっていうのは全体像が見えてることによるプレッシャーが一切なかったっていうのも大きかったと思います。
素晴らしいね話として。
なるほど。
いやいやもうそれで十分でございます。
あえて補足をするならば僕は本を何冊か書くうちにつまり今の話でいうところの仕様書に相当するものを先に作るじゃないですか。
非常に雑なんですよ。最初からもう雑だってことは仕様書と違って分かってるんですよ。
はいはいはい。
文章書いてないからね。で文章書き出すと絶対こうはならない。
もうなんか3行ぐらい書くと絶対こうはならない。
仕様書書くってのは不可能なんだっていうことが分かるんだけど、
まあ本の書き方としてそうはなってないから世の中的には。
さもそういうふうに書きましたという顔をしれっとするんだけど実はそうは書いてないということは何度も何度もやってきてですね。
それは知ってたんだけど今のが全く同じことがコードに当てはまったのがとても不思議な感じが。
僕はコード書いたことがないからね。
はいはいはい。
っていう感じがしますね。不思議な感じがするけど本はそうです。間違いないですよね。
いやそうですよね。
アウトラインから書いて何かがうまくいったってことは僕は1回もない。
60回近くやって1回もないですね。
うーん。いやそうですよね。
たぶん普通本、みんな普通の人本書いたことないと思うんですけど、たぶん本書いたことない人からしたら最初に目次があってターゲットがあってみたいな。
入念に計算されて書いてるんだろうなってやっぱ思うと思うんですけどね。
それね僕一番僕の自分のやり方というか、まあやむを得ずこうなってるんだけど確信をしたのが森博史っていう推理小説作がいるのね。
はいはいはい。
全てがFになるっていう割と有名な作品を出してる。
彼が推理小説なのに先にオチやネタを考えることはないって。
そうなんすね。
書いてるうちにこれだけ書けば出てくるだろうと思って書き続けると。
そうすると最大7割ぐらい書いたところで考えつくんだって。
そんなことは僕にはとても理解できないんだけど、だってそれじゃあさ伏線張れないじゃんって思う。
矛盾起きそうですよねそれこそ。
そうなんだけどそういうふうに言ってて。
まああれを100丸々信じなくったとしても私のビジネス書はこれでいいはずだって思えた。
あの2010何年頃にそれを読んでね確信したんだよ。
推理小説が逆算じゃないのに俺が逆算して何になるんだと思った。
いや確かに本当っすね。
で今Jさんがコードすら逆算でないならまして本は逆算で書かないよねっていうのを確信した感じがしました。
プロジェクト完成のための思考方法
ありがとうございます。
ということであの僕たちね逆算やめましょうって話を結構してきたじゃないですか。
逆算っていうゴールを描いてそこに向かっていこうっていうやり方。
まあこれが逆算ですよね。
それに対して反対の言葉として順算でやっていきましょうと。
まずは目の前のことで集中する。
それが終わったら次の一歩に集中する。
そんな感じで一歩進んだらまた一歩。
これが順算思考と僕たちが呼んでいるものなわけですけれども。
この話をすると順算思考でどうやったらプロジェクトが完成するのか分かりませんっていう話をよく聞かれるわけですよ質問を。
だからこれの回答です。
順算思考の方がむしろちゃんとプロジェクトは形になりますというのが今回言いたかったことかなと思います。
すごいと思いました。
はいということでですね。
いやー今日から逆算じゃなくて順算でプロジェクトを進めていこうって思ってくださった方は是非このポッドキャストチャンネルのフォローですね。
それからレビュー。
そしてこの放送に是非ね感想コメントの方をお寄せいただけますと幸いでございます。
はいこれねモチベーション。
はい僕と佐々木さんは放送しておりますんで何卒応援をよろしくお願いいたします。
ということで今日は以上にしたいと思います。
佐々木さんありがとうございました。
ありがとうございました。
あなたの従順なる下目。
