- Ninoは、ドキュメント・シート・スライド・フォーム・ドライブ・カレンダー・サイト・ブログ・チャット・ミーティングなどを1つのインターフェースにまとめた、プロ向けのモジュール型ワークスペース
- 情報はページとブロック単位で再利用され、ページソーシング・ページ埋め込み・ブロック埋め込み・ブロックミラーによって、同じ内容を複数のフローにつなげる
- オフラインでの閲覧・編集、ローカル保存ベースの高速オープン、全モジュール対象の統合検索を提供し、アプリが増えても資料へのアクセスをシンプルにする
- 無料プランでも無制限のメンバーとゲストをサポートし、リアルタイム参加表示・ライブカーソル・チャンネル・チャット・外部共有スペース・無制限のビデオ会議を含む
- Webサイト・ブログ公開、カスタムドメイン、1クリックロールバック、メタタグSEO、200以上の都市のCDN、サーバー側メトリクス分析まで、業務ツールと公開機能を1か所に集約
モジュール型ワークスペースと開始方法
- Ninoは複数の業務アプリを統一されたインターフェースにまとめ、ブロックレベルの相互運用をサポートする
- 提供モジュールには Doc, Sheet, Slide, Form, Drive, Calendar, List, Site, Blog, Chat, Meet, Collab などが含まれる
- 開始オプションは Download Nino for Linux と Use the web app に分かれる
- 基本的な使い勝手は、複数モジュールに散らばった業務資料を素早く見つけて開くことに焦点がある
- オフラインモード: インターネットなしで閲覧と編集が可能
- 高速オープン: ローカル保存ベースで即座にアクセス可能
- 統合検索: すべてのモジュールを一度に検索可能
ページ・ブロック再利用構造
- 中核構造は、ページとブロックを別の場所で再利用する方式
- Page sourcing: ページを別の方法で表示
- Page embed: ページを別のページに同期
- Block embed: ブロックを別のページに同期
- Block mirror: 同じページ内でブロックを同期
- 例示されるワークフローは、プロジェクト管理、ナレッジ管理、データベース管理に分かれる
- プロジェクト管理では Collection, Board, Todo, Grid, Channel を組み合わせ、作業作成、担当者フィルタリング、ダッシュボード、議論を構成する
- ナレッジ管理では Notebook, Slide, Doc, Drive でページ・ブロック・チャート・ファイルブロックを埋め込む
- データベース管理では Sheet, Form, Site, Calendar でアンケートデータ、フォーム、キャンペーンサイト、キャンペーンカレンダーを接続する
- カスタムワークフローには、テキスト、コード、数式、ファイル、画像、動画、音声、テーブル、コメント、リンク埋め込み、ページ埋め込み、ブロック埋め込み、ブロックミラー、地図埋め込み、ボタン、チャートなどが使われる
コラボレーションと公開機能
- コラボレーション機能は、内部チームと外部コラボレーション空間の両方を対象にしている
- 無料プランでも無制限のメンバーとゲストをサポートする
- ページ上にいるユーザーをリアルタイムで確認でき、ライブカーソルで共同編集できる
- Channel は無制限のグループサイズ、Chat は1対1またはグループ会話、Collab は外部共有スペース、Meet は無制限のビデオ会議を提供する
- 公開機能は、ページをWebサイトやブログとして公開するノーコードのフローを提供する
- Version control により1クリックでロールバック可能
- カスタムドメインまたは nino.page サブドメインを使用可能
- カスタムメタタグベースのSEOと200以上の都市のCDNを提供
- 埋め込まれたブロックのスナップショットを含む統合ページをサポート
- 分析はサーバー側メトリクスのみを収集し、ブラウザー拡張によるデータ損失を防ぐ方式
プライバシー・セキュリティ原則と長期計画
- プライバシーとセキュリティの原則は、アプリ追跡を行わず、機能クッキーとエラー報告のみを使う方針に沿っている
- 製品改善はユーザーからの直接フィードバックに依存する
.appドメインで動作し、HTTPS接続のみを使用する
- 長期計画は、ナレッジワークのための数百のモジュールを作ること
- Doc, Sheet, Slide, Form, Drive, Calendar, Collection, Notebook, Channel, Gallery, Canvas, Board, Todo, Grid, List, Site, Blog, Chat, Meet, Collab が列挙されている
1件のコメント
Hacker Newsの意見
初期段階でデータモデルをきちんと設計することが、最大の技術課題。規模が大きくなった後では変更が極めて難しく、慎重でないと JSONB カラムの乱立、重複データ、孤立行、劣悪な性能につながりかねない
顧客は Docs に想像以上に大きな項目を保存しようとするはずで、その際に S3 のような外部ストレージへ逃がさず、インラインで入れたくなる可能性がある
Chat は実質的に別のデータベースが必要。Discord は Scylla を使い、Slack は MySQL 上の Vitess を使っているが、チャットのアクセスパターンは他のストレージとは要求事項がまったく異なる
active-active 構成を採るなら、いずれそこから抜け出す計画を立てておくべき。息が詰まるほど高価なハードウェアなしにはスケールしない
これは競合で DBRE として働いた経験から出てきた話
オフライン保存をやる点はすばらしいが、Ditto [0] のようなものを使っている印象もある。記憶が正しければ内部では MyRocksDB を使っていたはずで、直接の経験はないが、Ditto で働く非常に優秀な人たちを知っている
[0]: https://ditto.live
統合とモジュール性は解決策になり得るが、人は問題なしに解決策を買い回ったりはしない。「アプリの混乱」は大半の人にとって抽象的すぎる問題
Google Docs を Slack で共有するのが難しいのか、SharePoint と Teams の統合不足で企業が苦労しているのか、このツールのほうが優れているのか、似ているがもっと安いのか、もっと安定しているのかをまず明確にすべき
人々が実際に直面している具体的な問題と、この統合ソリューションがそれをどう解決するのかを冒頭で定義しなければ、誰も関心を持たないだろう
二つ目の大きな問題は、異なるアプリ群を個別ソリューション以上に使いやすくできるほど一貫したインターフェースデザインチームが必要だという点。Firefox、Blender、Signal のように専門デザイナーを雇う組織が管理するプロジェクトを除けば、人気のある一般向けアプリが開発者主導の FOSS からほとんど生まれないという事実は、開発者中心の UI/UX の限界を示している
これは、数年間フルタイムの開発者として働き、FOSS に何千時間も貢献した後でデザインに転向した立場からの話
「エンジニアはプロダクト担当ではない」の典型例に見える
データモデルを簡単に変えられる形でソフトウェアを作れたらよいのにと思う
そのためにはシステム内のあらゆるデータ依存関係を追跡できる必要があるが、まだそれをしてくれるツールがない。皆が既製のデータベースを選ぶが、この目的にはどれもまともに役に立たない
アプリ自体は見た目こそ非常に印象的だが、フィードバックを求めるなら、プロダクトの観点で何なのか、なぜ重要なのかがあまりにも分かりにくい。
ビジネスユーザーの立場からどう使うべきか、なぜ関心を持つべきかが明確ではない。
最初の画面の文言は「Ninoは均一なインターフェースでブロックレベルに相互運用されるアプリ群…」のように機能説明を並べているが、monday.com や Asana のようにユースケースと実際の適用から始めるものと比べると差が大きい。
Monday は「何を管理したいですか？」から始まり、Work Management、Sales CRM、Dev といったカテゴリを見せ、各項目を押すと具体的にどう役立つかを説明している。
散歩しながら5分ほど使ってみようとし、Web アプリを試したが iOS Safari はサポートされていなかった。iOS アプリをダウンロードして登録したところ、オンボーディングもテンプレート/サンプルも既存の Google Sheets を取り込んで規模感を確認する方法もなく、完全に空のアプリが出てきた。
データソースといくつかのフィールドを追加してみたが混乱し、その間に散歩が終わった。
https://www.youtube.com/watch?v=u4ZoJKF_VuA
本も読んでみることを勧める。
この理論で見ると、伝える順序は Why、How、What であるべきだが、今は What から始めている。
プロダクトの核心を完全に把握したわけではないが、「複数のシステムで文書、メール、チャットを探して時間を無駄にしないでください。会社を運営するために20個の単機能サービスにお金を払わないでください」のように再構成できそうだ。
すべての情報を一か所に置けば、会社全体で探して共有しやすくなり、文書・チャット・スプレッドシート・フォームなどを組み合わせて、既存アプリの考え方に合わせるのではなく、自分たちのプロセスや思考を支えるツールを作れる。
Nino はモジュール式のビルディングブロックでカスタムフローを素早く作り、必要なツールとすべての情報を一か所に置けるようにすると言える。
デスクトップの OLE / OpenDoc のように、Word 文書の中に Excel シートや Access フォームを埋め込む感じでもある。それが可能ならかなり印象的なデモになりそうだ。
ただ、最初からこうした総体的なビジョンを受け入れることは、最初は集中して後からスコープ拡大に押されるのとは違うのかもしれない。
多くの人は事業を特化しなければ死ぬと言うが、むしろ誰もあまりうまくやれていない領域を取る良い機会があるように見える。たとえば ISO 9001 のようなユースケース向けの垂直統合型文書管理システムだ。
ユースケース1は文書管理である。文書バージョンを「発行」でき、そのバージョンを恒久的に閲覧可能にし、会社の命名規則に従って文書識別子を自動生成して文書内に自動挿入できる必要がある。文書 ID は SOP-2401001 のような形式になりうる。
文書が発行されたら読み取り専用であるべきで、エクスポートした PDF コピーや署名済みコピーのような成果物を発行済み文書と一緒に置ける必要がある。
ユースケース2は 文書のサイロ化 だ。文書管理で最も難しい部分の一つは、手順用フォームを作り、人々が記入した後でもそのフォームの文書管理を壊さないように教えることだ。
フォームへの記入を始めたら自動でコピーを作成し、新しい文書 ID を付与したうえで、同じ種類の他のフォームとまとめてくれるサイロをずっと望んでいた。
自動化プラットフォームと統合してフォーム記入時に誰かへメールを送ることもできるし、さらに洗練させれば文書ごとのワークフローを定義し、ビジネスプロセスを文書の横に視覚的に表示することもできる。
数分使ってみた第一印象は、強力な機能が非常に多くありそうなのに、アプリとサイトにガイドとオンボーディングがほとんどなく、何をすべきか、どう学べばよいのか分からないということだ。
Mac にインストールして、名前、電話番号、誕生日のような基本フィールドを持つ連絡先レコードのセットを追加し、別のモジュールからそのレコードをクエリしたかった。
ところがアプリは、それをどうやるのかまったく案内してくれない。開くと空のタブしか見えず、モジュールを追加する方法を見つけようといろいろなコントロールを押してみる必要があった。
クエリ可能なレコードを追加するにはどのモジュールを使うべきか分からず、Board を試した。
Board を追加した後、最初のレコードは入れられたが、2件目を追加する方法がないように見えた。「None」と「Unnamed」というカラムがあり、「None」の中に最初の連絡先が入った。隅の「+」ボタンは新しいカラムを追加する。
結局、レコードを「None」から「Unnamed」へドラッグすると「None」が消えて「Unnamed」だけが残り、そのとき初めて別のレコードを追加できた。
もう少しいじってみるつもりだが、人々が設計された利用モデルを自力で把握してくれると期待するには限界がある。モジュールは多いが、互いにどうつながるのか分からず、仮想チーム向けの設定例があれば大いに助かると思う。
本当にとても良さそうに見える。
使ってみたいが、そのためには既存のツールとワークフローを置き換える必要がある。ユーザーの立場としては、データの所有権とアプリケーションのホスティングの両方を確保できないなら、そうしたいとは思わない。
Ninoがうまくいかず製品が終了した場合、密結合された独自データにどうやって引き続きアクセスできるのかが気になる。セルフホスティングが可能なのか、ソースコードは公開されるのか、ドキュメント形式はオープンなのか、熱心に導入したあとで失敗したときに被害を避ける方法があるのかを知りたい。
データを入れたあとで製品が合わなかった場合、どうやってデータを取り出せるのかも重要だ。
ツール固有の利点、たとえばグラフ構造による文書間の統合は失われるかもしれないが、成果物は誰でも使える汎用形式で保存される。
Ninoの要素の大半には広く受け入れられた標準があり、統合もしやすそうなので、そうした保証は可能に思える。
セルフホスティングはセットアップが複雑すぎるかもしれないが、シングルテナント提供が役立つのではないかと思う。個人ユーザーにも意味があるのかは分からない。
HTMLやCSVに加えてJSONエクスポートのオプションもあり、さらに多くの形式をサポートしている。ある意味ではオープンな形式（.json）だが、関連ドキュメントを追加する必要がある。PDF対応もいずれ入る予定だ。
間違いなく非常に印象的で、おそらくほぼ個人開発に近い仕事であり、途方もない努力が注ぎ込まれているのだと思う。
フィードバックをするなら、まず顧客が誰なのかを明確にすべきだ。彼らの1日がどんなものか、そしてNinoが仕事をより良く、より速く、より安く終わらせるのにどう役立つのかを説明できる必要がある。
彼らが抱える上位5つの問題は何か、Ninoが競合製品より明確に優れている点はどこかを具体的に示すべきだ。ワークフローを見せることが重要だ。
彼らがどこで働き、誰と協業し、何を協業しているのかについても、同じように既存ツールと並べて比較し、なぜNinoのほうが優れているのかを示す必要がある。
最後に、人々に今のやり方から乗り換えてもらうのがどれほど難しいかを決して過小評価してはいけない。今は1990年ではなく、人々は知識労働の問題を解決するツールを何十年も使ってきた。なぜ乗り換えるべきなのかが必要だ。
「アプリ混乱問題」が本当に存在するのか、よく分からない。私が経験した会社や職務のワークフローでは、それぞれのユースケースを解決するアプリの組み合わせがあった。
たとえば前職でデベロッパーリレーションズ責任者をしていたときは、社内ドキュメントと作業追跡にはAtlassian製品を、外部チームとの共同作業にはGoogle DocsとSheetsを、外部ドキュメントのビルドにはGitHubとMarkdownを使っていた。
どれもテキストではあるが、ワークフローは異なり、権限のような要件も違っていたので、結局は各作業に合ったツールを見つけた。
この試みは応援しているが、「アプリ混乱」ではなく、もっと具体的な問題を見つけようとしていることを願う。
リリースおめでとう。本当に素晴らしいし、生産性ワーカーのアプリ混乱問題は現実の問題で、解決可能だと思う。
私も似たものを作っている。10年以上にわたって複数のアプリを毎日使う「ハイリスク」なホワイトカラー業務をしてきたあとで始めた。
まだ初期段階で、切り口は少し違うが、2つのビジョンの間には重なる部分がある。私はより少ないアプリ群に集中しつつ、機能をより密に作り込み、既存の強者たちとの機能同等性を保ちながら自分の機能も追加する方向だ。だから、きちんと形にするまで時間がかかっている。
Ninoがどう発展していくのか気になるし、こちらも何か見せられるものができたら、あとでつながってみたい。
以前、似たようなものを作ったことがある。私のものはWebベースだった: https://github.com/GWBasic/ObjectCloud
若い頃の自分に言えるなら、事業の始め方に関するYC資料をもっと読めと言うだろう。私は必要だと思ったものを作ったが、実際の顧客ニーズに基づいて、もっとずっと多く反復すべきだった。
つまり、こうしたユースケース間の密接な統合を必要としている顧客を何人か見つけ、その人たちのニーズが実装を導くようにすべきだった。
理由は、すでに同じ機能を持つアプリケーションがたくさんあるからだ。MS OfficeやGoogle Driveなどは成熟しており、市場全体もよく理解されている。
3つ以上のアプリケーションやユースケース間の相互運用性の低さのせいで行き詰まっている顧客を何人か見つけ、そのユースケースに集中することを勧める。
MS OfficeやGoogle Driveのような製品と同じくらい成熟するには15年以上かかるだろうが、特定のニッチにある具体的で切実なニーズを解決できれば、顧客は気にしないはずだ。あなたなしでは事業を運営できないからだ。
セキュリティとプライバシーは難しい訴求ポイントだ。思っているより、そのどちらかに関心を持つ人は少なく、既存プラットフォームも、関心のある人たちが認めたがるよりはるかに多くの機能を提供している。
また、「ツールが多すぎる」というタイプのピッチは、不安定な長広舌のように聞こえる。単にさまざまなツールが存在するという事実が不便だという主張は、「じゃあ全部使わなければいい」という反論に耐えにくいので、表現をもっと工夫したほうがよさそうだ。
その代わり、利便性とプラットフォーム内部の統合に集中したほうがよい。そこが実際に価値が加わる部分だからだ。
幸運を祈る。
2つ目はその通りだ。私の表現が良くなかった。フィードバックありがとう。