💡
作りたいアプリのリスト with グラフ理論
グラフ理論(graph-theory)を活用するとうまく作れる. かつ個人的に作りたいアプリをまとめてみた.
アプリ1: エンジニア向けのwishlist
- 目的: みんなで仲良く仕様書を作っていくためのプラットフォーム.
- 似ているツール: Miro, Wimgical, Mindmeister
why? diff? def?
- なぜグラフ理論なのか?: 粒度の異なる意見をまとめるのにGraphは適切
- 既存ツールとの差異: 議論のtext化やgithub連携を活かしたコミュニケーションが差別化のポイント
- Graph定義: 種類 DAG
- node: 意見
- edge: 意見と意見の関連
usecase: 個人で使う(SNSとして使う)
ユーザA: 作りたいものがあるけど、目的しか書けない...
ユーザB: ん〜 Aさんの作りたいものは, このアプリかな? linkを教えてあげよ
ユーザA: Bさんからlinkがきてる! イメージと違う部分は追記しておこう。Bさんありがとう!
usecase: チームで使う(memoとして使う)
開発者A: 要件についての合意しているのはどこまででしたっけ?
開発者B: nodeの色が黄色いやつまでですね。
開発者達: ...(続く)
アプリ2: スケジューラ
- 目的: クリティカルパスを描画するためのwebアプリ
- 似ているツール: Lucidchart
why? diff? def?
- なぜグラフ理論なのか?: クリティカルパスが重み付のDAGそのもの
- 既存ツールとの差異: Excelへ読み込める形式(.csv)で出力できることがポイント
- Graph定義: 種類 DAG
- node: タスクと工数
- edge: タスクとタスクの依存関係
usecase: 個人で使う(プライマリ管理ツールとして使う)
ユーザA: はじめてだし、どのくらいでできるかわからないな。
知人B: とりあえず、やることだけ書いておいたら?
ユーザA: たしかに! 趣味だしやることが決まってるならそれで十分かも! Bさんありがとう!
usecase: チームで使う(エクセルとクリティカルパスの連携ツールとして使う)
開発者A: その機能の実装コストってどの程度ですか?
開発者C: 本仕様変更についての影響範囲はモジュールA~Zまでですので、完成の見込みはn月からn+x月に変化しそうです。
開発者達: ...(続く)
アプリ3: タスクスイッチリスト
- 目的: タスクの切り替わりを管理するwebアプリ.
- 似ているツール: 確認中...
why? diff? def?
- なぜグラフ理論なのか?: 目的と手段は多対多になりがちで複雑になりがちなため
- 既存ツールとの差異: UIの操作ログが生成されるため振り返りが簡単になるのがポイント
- Graph種類: DAG
- node: 管理するもの(目的, タスク, 開発環境, テスト, log)
- edge: 管理するもの同士の関連
usecase: 個人で使う(ツールを統合するツールとして使う)
ユーザA 10:00: 今日はxxxって機能を実装しようかな〜
ユーザA 12:00: お昼ご飯だ!
ユーザA 14:00: この機能の目的ってなんだっけ?(start->管理) OK プログラミングするぞ!(管理->コーディング)
ユーザA 22:00: 実装できた! (コーディング -> テスト実行) テスト通るかな? OK!!
ユーザA 23:00: 今日の振り返りするか(テスト実行 -> 振り返り -> end) 思ったより時間がかかったけど、こんなものかな。
usecase: チームで使う(メンバレベルの生産性測定ツールとして使う)
開発者A: なんでこの遅延っておきてるんだっけ?
開発者C: タスクの中断と再開が8回/日で発生しているので、生産性の95%が失われているようです。
開発者達: ...(続く)
アプリ4: Pythonのローコードツール
- 目的: .pyファイルの実行
- 似ているツール: CLI, AirFlow
why? diff? def?
- なぜグラフ理論なのか?: 目的と手段は多対多になりがちで複雑になりがちなため
- 既存ツールとの差異: 課題とソースコードの関連の可視化
- Graph種類: DAG
- node: 管理するもの(目的, 入力データ, ソースコード, 出力データ)
- edge: 管理するもの同士の関連
usecase: 個人で使う(ツールを統合するツールとして使う)
ユーザA: 入力データ変わったから再実行しとくか。ポチっ(後続の処理まですべて実行完了)
Discussion