- 変化の激しい初期のビジネス環境では、最も簡単な解決策で問題を素早く解き、限界が見えたときに要件を再評価して置き換えや補強を行うのが賢明
- Google Sheetsは急速に変化する環境で効果的な問題解決手段であり、複雑なツールを開発するよりも、実際の使いやすさと無駄の削減の面で有利
- 筆者は実務で汎用ツールより先に専用システムを急いで作り、スコープの不確実性を見落として時間を無駄にしたと振り返る
- 中核となる方法は、最小で最も簡単な解決策から始める → 実際の業務でスコープを把握する → 必要に応じて段階的に改善するという小さく始めて反復する戦略
- ただし、あらゆる問題をスプレッドシートで解決できるわけではなく、スコープが明らかになるまでの一時的な利用が適切であり、組織の文脈に合わせた賢明な選別が重要
問題解決のための最も簡単な選択
- どんな問題でも、最も簡単に適用できるソリューションをまず選ぶことが重要
- その方法がビジネスに合わなくなったら、新たな要件に合わせて既存のソリューションを改善するか代替を探す必要がある
- 筆者が経験した環境では、ほとんどの場合、新しいGoogle Sheetを作ることが最適な方法だった
急速に変化するスタートアップ環境とツールの有用性
- 約9か月前に職場へ入社し、小さく立ち上げ段階の会社向けに新しいツールやサービスを作ることへの期待は消えていった
- 2か月ごとにビジネスの方向性が変わる環境で、多くのプロジェクトを始めては中断することになった
- かなりのケースで、Google Sheetで簡単に解決できたにもかかわらず、不必要に複雑なプロジェクトへ時間と労力を投じてしまった
時間の無駄になった事例
-
貨物管理アドミンパネル
- ビジネス向けの入庫貨物の管理と追跡のためのアドミンパネルの設計と構築に2か月を要した
- 荷物と顧客データを分類し、よりうまく管理できるようにするのが目的
- このアドミンパネルは2回使われただけで、その後は二度と使われなかった
- Google Sheetで簡単に置き換えられ、現在はその作業に使われている
-
関税自動計算MVP
- 特定の商品注文時に関税と税金を自動計算する見積もりシステムMVPの作成に3週間を要した
- ジンバブエの税金と関税は非常に複雑で、顧客が正確な支払額を把握できればより良い顧客体験を提供でき、外部の関税処理会社からすべての問い合わせ回答を待つ必要もなくなり、プロセスを加速できる
- 結局、競合の税金・関税分類表を見てGoogle Sheetにコピーして使った
-
CRM選定プロセス
- ビジネスで使う良いCRMを探すために、調査、会議（1時間以上）、検索に2か月を費やした
- さまざまなCRMの機能と価格を比較し、分析していた
- 最終的にOddoの無料版を使うことにしたが、ビジネスの中ではあまり活用されなかった
- 驚いたことに、数週間前にGoogle SheetsにCRMテンプレートが組み込まれていることを知った
Google Sheetsアプローチの原則
- Google Sheetを作ることがあらゆる問題に対する最善の解決策ではないが、筆者の状況ではしばしばそうだった
- 実際の作業を始めるまで、問題の全体像を決して把握できない状況にしばしば置かれる
- これはプロジェクトを計画すべきでないという意味ではない
- チームはワークフローや必要な情報を議論すべきだが、実際の作業を始めるまでは問題の全体像は分からない
- 問題の全体像が見えたら、手元のソリューションを構築したり改善したりし始められる
- この方法は、最良の場合には不要な機能をすべて追加してしまう余分な作業負担を避け、最悪の場合でも失敗するプロジェクトに時間を使ってしまうことを防ぐ助けになる
- 問題の全体像を把握する方法として、最小で最も簡単な基本ソリューションを実行し、必要ならその後に反復するのが、これまでのところ最善だった
制限と注意点
- このやり方にも欠点はあり、たとえば一部の組織では数千行に及ぶスプレッドシートにすべての取引と情報を記録している
- Google Sheetsは問題の全体像を把握する前にのみ有用
- どの問題がGoogle Sheetで解決可能かについての経験と判断力が必要
- 時間を無駄にせず、実際に使えるツールの開発を重視すべき
- ただし、誰にでも当てはまる助言ではないため、それぞれの状況に応じて慎重に判断する必要がある
結論
- 最小の労力で、最も単純なソリューションから始め、必要なときにだけ拡張や高度化を行うやり方は、スタートアップや変化の多い環境に非常に適した戦略
- 個人的な開発実験は自由に行ってよいが、ビジネスでは本当に必要なものだけを作り、不必要なことに時間とエネルギーを使わない姿勢が重要
3件のコメント
私も基本的には同意ですが、今は Google Sheets よりも、初期ベースライン用途として Notion Database を使うほうを好んでいます。似てはいるのですが、どうせテンプレート設定をするのは 1 人ですし、他の人はその基盤の上でデータを管理すれば、雑然とした状況を防げます。App Script ほどではないものの、もう少し簡単に自動化も実装できます。初期設定の難易度がほんの少し高いと言えば高いですが、大きな差ではなく、柔軟性なども同じくらいだと思います。しかも最近は行単位の権限管理までできるようになったので、Good.
Notionは学習コストが低いので、良いと思います。
Hacker Newsのコメント
見落とされがちな点だ。スプレッドシートは、データベースと、すばやく簡単にカスタマイズできるUI、そして反復しやすくデバッグもしやすいデータ処理環境を1か所にまとめている。世界中の会社員がすでに理解して使っているツールであり、作り手が望むとおりに実装できる自由度もある。可搬性も非常に高い。特にコーディングできない人たちにとって、創造的で強力なツールだと確信している。もちろんこの自由さには欠点も伴うが、オンラインかどうかや、どのベンダーがよいかという議論とは関係なく、スプレッドシートへの深い愛着は少しも薄れない。私たちが作ったオーサリングツールの中で最も優れたものだと思う。スプレッドシートに似たモデルとしてはHyperCardを挙げたい。さまざまなアプリ、データ、UXなどをつなぎ合わせられる柔軟な作業台だった。HyperCardが永遠に記憶されてほしいと思う
その通り、スプレッドシートは参入障壁が本当に低い。農場のど真ん中でスマホからGoogle Sheetsに作物の成長記録を入力することさえある。電波が弱くてもオフラインモードで記録しておき、家に帰れば同期される。記録が雑でも、何もないよりずっとましだ。農業は大量のデータを必要とするのに、意外にもデータが不足しがちな環境だ。学習サイクルは1年単位と長く、その1年も毎回違う
コーディングできる人にとっては、Appscriptがスプレッドシートをほとんどスーパーパワーに変えてくれる。知らない人のために言うと、Google Sheets内蔵のWeb IDEで単にJSだけを書かなければならないわけではない（実際、それでもかなり実用的だが）。claspを使えばローカルIDEでTypescript開発を行い、ビルド時にJSへコンパイルしてスプレッドシートにそのままデプロイできる。ツールチェーンを整えておけば、開発体験（DX）もかなり良い
強く同意する。データベース+UX+ロジックが1つに統合された作業台の価値こそ、私たちが何度も繰り返し作っているようなアプリの核心だ。だからVisual Basicもいまだに使われている。もちろん方向性が明確に固まった後では最善の方法ではないが、素早く反復しながら本当の要件を見極めるにはこれ以上ない
スプレッドシートをデータベースのバックエンドとして、もっとよい形で使えるようになればいいのにと思う。たいていの人がスプレッドシートでやっていることのかなりの部分は、データベースのほうがうまく処理できるはずだ。だがデータベースにはより多くの教育が必要で、教育が足りないと、かえってスプレッドシートより悪い結果になることもある
なぜスプレッドシートからカスタムUIを備えた完全なデータベースへ、現実的に段階移行できる道筋がないのか、ずっと疑問だった。スプレッドシートはその役割の一歩手前にあるのだから、構造化データ、ネイティブSQL、カスタムUI要素、IDE統合など、いくつかの必須機能さえあれば十分に実現できそうだ
"Ask HN: Is the world run by badly updated Excel sheets?" という投稿を思い出した。スプレッドシートの限界を身をもって知るには経験が要る。バージョン管理がなく、テストもない。変化せず寿命の短い作業には向いているが、継続的に進化しなければならないなら問題になる。https://news.ycombinator.com/item?id=33611431 参照。そのスレッドにはこんなコメントがあった。結局、社内ではExcelの所有者のやり方にみんなが合わせることになる。嫌なら自分で新しいExcelを作ってコピペすれば済むので、各自が勝手に管理する。知人のプロジェクトマネージャーは、複数の作成者によるスプレッドシートの版をひたすら調整するのが日常だった
2000年代のアメリカでコーダーとして働き始めた頃、自分の仕事は、Windowsのネットワークドライブ上にあって常に誰かが大事に世話しなければならないスプレッドシートをWebアプリに置き換えることだと思っていた。とはいえ、今でも多くの企業はスプレッドシートベースでうまく回っている。結局いつかはスケーラビリティの問題が噴き出し、そのときにはアプリへ移行しなければならないが、完璧を目指して何もできないくらいなら、まずやり切ることのほうが大事だ
「バージョン管理ができない」と言うが、実際にはExcelにもバージョン管理機能はある。「変更履歴の記録」を使えば、他人の変更を承認または拒否できる。ただ、この機能をRube Goldberg的なスプレッドシート自動化で仕事を回している人たちはほとんど使わない。必要なら使えることは使える
情報が複数のスプレッドシートに散らばっているときに問題が起きるのを何度も見てきた。関係者は、どのスプレッドシートにどの情報があるのか、どれが正なのかを把握していないことが多い。だから誰かがAファイルだけ更新しているのを知らず、別の人はBだけを触る、という衝突が頻繁に起こる。実際のプログラムやデータの問題というより、プロジェクト内でのファイル管理の仕方が問題だった。複雑な共有フォルダや、ネットワークのどこかに放置されたファイルなど、管理の迷路になってしまう
「問題解決には常に最も簡単な方法を使い、その方法がビジネスに合わなくなったら新しい要件に応じて改善するか代替策を探せ」という助言に同意する。今ある問題を解決することに集中すべきで、将来起こるかもしれない問題や、こうなってほしいと願う問題を先回りして考えても、うまく当てるのは難しい。今の解決策が将来不適切になる可能性はあるが、どう不適切になるかを予測するのは難しいからだ
将来どのように不適切になるかを予測するのは難しいが、それでも将来の解決策を妨げない、あるいは阻害しない形で現在の解決策を選ぶことはできる。選択肢を残し、ベンダーロックインで抜け出せなくなる状況は避けたほうがよい
予測しやすい典型的な不適合の例は、特定ベンダーに完全依存した結果、サービスから追い出されたり、徐々に値上がりする料金を受け入れざるを得なくなったりするケースだ。これは十分に予測可能な問題だ
余計な仕事を増やさずに問題領域全体をカバーする形で解決策を作れば、少しの変更で変わる要件も吸収できるので、解決策の堅牢性を高められる。そうすれば自然に将来の問題までカバーできる
アメリカの有名な大企業で働いている。うちの部署は2つのスプレッドシートに大きく依存している。私の工場に対する3度のM&Aを生き延びてきた。7年前に入社した時点ですでに古い仕組みだった。2年前、新しいマネージャーがこれを全社システムへ移そうとしたが失敗し、そのシステム自体も近いうちにさらに新しいシステムへ置き換えられる予定だ。それでも2027年になってもまだスプレッドシートを使っている気がする
元Google社員だ。5年間、Sheets（社内ではTrixと呼ばれていた）だけで、プロジェクト管理、CRM、四半期計画、レポーティング、面接、財務など、あらゆる業務をこなしていた。単にGoogle製品だから使っていたわけではない（競合製品も普通に使っていた）。スプレッドシートは、目的達成に十分なものをすばやく作れるという点で圧倒的に便利で、仕事の本質に集中できる環境だった
「入社9か月目」という誰かの意見について、正しいか間違っているかは別として、まだ1年も経っていない経験でこれほど断定的な意見を述べるのは、かなり大胆だと思う。OPが見落としているのは、「一時しのぎほど恒久的なものはない」という真理だ。目先では速くて即席の解決策を選ぶとしても、その解決策のライフサイクルを完全に自分で制御できる場合に限る。誰かに頼まれて急いで渡したものの上に、継続的に新しい用途を積み増していこうとするなら……初期コストが少し高くても別のツールを強く主張することになる
その問題の「数か月ごとに1回…」というくだりには、思わず笑いそうになった。筆者は、シンプルなツールで仕事を片づけるのが大原則だという点はうまく捉えている。既存のツールをそのまま使えて、必要をそこそこ満たせるならそれが一番いい。実際の現場ではビジネス要件が数か月ごとに変わるので、「一時しのぎが恒久策になる」現象を避けられる場合もある。だが大半の人にとっては、何年たっても後始末をすることになり、「必要になったら作り直そう」というシナリオはほとんど機能しない。そして筆者はまだ1年後、その先を自分で経験していない
私は特に「数か月ごとに…」のくだりが印象的だった。せいぜい4回くらい経験したうえで出てきた話なのだろうかと気になった
大きなスプレッドシートにうんざりしている人にとって、MS Accessはかなり有効な解決策だった。スプレッドシートに構造化と保守性を加えつつ、アクセスしやすさと開発難易度の低さは保っていた。多くのコーディング知識がなくても優れたUIを作れた。20年たった今、Accessの代替が何なのか私にもよく分からない
OPの意見に完全に同意する。1つ付け加えるなら、Google Sheetsでは扱いきれないほど複雑な要件が出てきたとき、Google Colab（あるいはJupyter notebook）がその一段上の選択肢になる。本格的なアプリを作る前にはいつも自分にこう問う。1. これは単なるスプレッドシートで済むか？ 2. それが無理ならJupyter notebookで済むか？ ちなみにSheetsとColabの連携も素晴らしい
私の考えでは、jupyter notebookは単にpython scriptを書くよりずっと複雑な段階だ。python scriptにもコメントは書けるし、わざわざ「ローカルWebサーバーを立ち上げて、コメントを見るためにコードブロック単位で実行する」やり方はあまり好みではない
既存のgoogle sheetにあるものをcolab notebookへアップグレードするにはどうするのか気になる。gspreadのpythonパッケージでシートのraw dataは読めるが、既存のグラフやインタラクション要素までjupyter notebookへそのまま持ってくるのは難しそうだ。結局作り直しになる気がする
Google Apps Scriptも良い代替手段だ。データ取得のような簡単なスクリプトだけでも、かなり多くのことができる
ビジネス自動化における最大の問題の1つは、いわゆる「シャドーIT」、ローコードプラットフォーム、そして完全に「正式な」プロジェクトのあいだにあるギャップだ。「google formでとりあえず作る」と「reactアプリにCI/CD、テスト、CDNまで全部載せる」の間に、ちょうどよい移行経路が空白になっている。どちらも互換性のない囲い込みの庭のような代替手段ばかりだ
Google Sheetsですべての家計管理をしている。Expense TrackerのUIも自作して、5,000件以上の支出履歴を何年も蓄積してきた。最近はvibe codingでGoogle Service Accountを使うWeb UIツールも作り、それをPWA化してスマホでも使っている。シンプルな用途、特に1人用アプリケーションなら、DBの代わりにGoogle Sheetsで十分だ