1人開発者として、どうやって体系的に管理していますか？

 (news.ycombinator.com)
53 ポイント 投稿者 xguru 2024-06-25 | 6件のコメント | WhatsAppで共有
  • チームで働くときは、スクラムのような短期目標と体系的な作業バックログが、集中力を保ち、やるべきことを追跡するのに本当に役立っていた
  • しかし一人で開発すると、適切なアプローチを見つけられず、しばしば脇道にそれて目標を見失っていた
  • 皆さんは目標に忠実でいるために、どんなツールや手法を使っていますか？

CharlieDigital

  • 紙のノートを使う
  • 情報を共有する必要がないときは、あらゆるアイデアを広げて何度も見返すのに、ノートほど良いものはない。ログインも不要で、どこへでも持ち歩けるし、ベンチに座ってアイデアを考えたり、ジムに行ってアイデアを書き留めたりできる。
  • 毎日の目標をチェックリストに書き、ひとつずつチェックしていけばよい。他人と状態を共有する必要がないので、GitHub Projects のようなものも不要

olooney

  • TODO.md ファイルを使う
  • GFM(GitHub flavored markdown)で次のようにリストを書く 
      1. [X] Dockerfile  
  2. [ ] Bulk Inference  
  3. [ ] CLI  
  4. [ ] Logging
  • 将来のアイデアのための「バックログ」セクション、修正すべきバグのための「バグ」セクション、現在の項目がある名前なしのセクションを先頭に置く
  • リリースのようなマイルストーンに到達したら、完了した項目をすべて削除する

jasonb05

  • 未来の自分に向けてたくさん書く
    1. 週・月・四半期・年ごとの列がある Trello
    2. マウスの横に置いたノートを開く
      2a. 左ページ: ペンと紙による日次 ToDo チェックリスト。（1日に2〜3行）
      2b. 右ページ: 走り書き、図のスケッチ、付箋など
    3. リサーチ、URL、論文、考え、アイデア、進捗、拡張機能などを記録する開発日誌
    • すべての GitHub プロジェクトにはこのメモ用の dev/ フォルダがあり、ファイル名は yyyymmmdd-n.txt
    • 必要に応じて、毎日プロジェクトごとに新しいファイルを書く
    1. 一時的なアイデア用の黄色い付箋（画面の下、ノート、またはホワイトボードに貼る）
    • たいていは、プロジェクトの正しい方向性を示す格言（例: "誰も決して rtfm しない"）
    1. ホワイトボード、プロジェクト別の列、印刷物 + マグネット（プロジェクト進捗の月次チャート）、付箋、将来のプロジェクトのためのアイデア、各種の物
  • 自分は未来の自分と過剰なくらいコミュニケーションを取ろうとしている
    • 期待値、進捗、障害など、今の自分の考えを整理するのに役立つ
    • 障害は作業ではなく自分自身だ
    • 作業はたいてい「じっくり考えた」あとに数で表される
  • 8年間、一人でこのやり方で働いている
    • 2000年代初頭の博士課程のころから、リアルタイムの開発日誌のために /dev dir と .txt ファイルを使ってきた。膨大な時間を節約できた (grep)。
  • あと、毎日同じことをする。ほぼ毎日
    • たとえば顧客サポート、宣伝、執筆、コーディング、それから……考える必要なく、その作業をして次の作業に移る

liampulles

  • サイドプロジェクトを進めるときは、「Readme 主導開発」がモチベーション維持とスコープの制限に役立つ

Tehnix

  • 日次・週次・月次の目標を立て、Linear、Todoist、Notion などのアプリでそれを体系化する
  • 月次目標は非常に高いレベルで、数個程度（例: "PoC を作る"、"ブログを再設計して再公開する"）
  • 週次目標はより具体的で限定的（例: "Swift コードから Rust を呼ぶためのアプローチを決める"、または "記事のデザインとスタイリングを完了する"）
  • 日次目標は非常に具体的（例: "Swift バインディングを生成するために UniFFI パイプラインを設定する"、または "ブログページ全体に新しいテーマを実装する"）
  • 実装中に新しい作業が発生して、日次目標を翌日に持ち越すこともある
  • 今のところ、この方法は集中力を高めるのに効果的で、複数のプロジェクトにまたがる進行中の多数の作業・課題一覧から、週次の重点事項に基づいて日次目標を選んでいる
  • 進行中の各作業をプロジェクトとして設定し、作業を追加するときにすぐ優先順位を付けておけば、進行中または今後やりたい大小さまざまなプロジェクトを一目で把握しやすい
  • 紙は好きだが、一時的なことにしか使えない。移動中にアイデアが浮かんだときにスマホから簡単に追加できるデジタル方式のほうが好み。また、キーボードで書くほうがはるかに速く、作業中や何かを調べている間にもさまざまなタスクを情報の保管場所として活用できる

OogieM

  • Obsidian Vault の中で、それぞれをフォルダとして管理している
  • フォルダには似たような共通要素が入っている
    • 画面構成（各画面にどんな機能やアクティビティがあるか）のために、Kanban プラグインを使った Kanban ノート
    • 各機能の詳細を含むロードマップノート
    • そのアプリやコンポーネントに関するさまざまな作業を含む一般ノート
  • Tasks プラグインを使って、具体的に何に取り組んでいるかを追跡する
    • このフォルダには、特定のアプリに関連するスクリーンショット、参考資料、そのほかのノートなどの追加ドキュメントが入る
  • 自分のプロジェクトは、家畜と希少品種登録を管理するプログラム群だ
    • そのため、Farm Mobile(Android)、Farm Desktop(Python)、Registry Web(Flask)、Registry Desktop(Python) の各アプリと、データベーススキーマ(SQLite)をそれぞれ別の GitLab リポジトリとして持っている
  • 今は共同作業者が3人増え、Obsidian Sync を通じて Obsidian Vault を共有している。ソロ向けの仕組みがチームワークにも対応できるよう拡張された

robomartin

  • 何年もの間、Kanban に着想を得たシンプルなテキストファイルを使っている
  • 小規模プロジェクトから数百万ドル規模のプロジェクトまで、この方法ですべてを管理している
  • 各プロジェクトにはメインのログファイルがあり、分野ごとの固有ファイル（電子、機械、光学、製造、テストなど）もある
  • ファイルの内容 
    <project name> log file  
-------------------------------- WORKING ON NOW   
<task currently being worked on>  

-------------------------------- TO DO   
- <start each task with a dash>  
  - <indent related subtasks or notes>  

-------------------------------- IDEAS  
<free-form notes>  

-------------------------------- RESOURCES  
<free-form resources>  

-------------------------------- DONE  
<move completed things to this section>  
<leave timestamps if you want>

kkfx

  • Emacs/org-mode/org-roam で管理している
  • 今年のノートの org-agenda を使い、ノートは1日1ファイル、1年1ディレクトリという形で共通の org-roam ディレクトリに時間単位でファイルを分けている
  • こうすると org-agenda が移動しなければならないファイル量が減り、年ごとの要約ノートで年をまたぐ長期実行の資料も減らせる

makz

  • 退勤前にコードへコメントを残す: "今はこの作業をしていて、動かすには A、B、C... をやる必要がある"
  • 次にコードエディタを開いたとき、何をすべきか正確に分かる

qntmfred

  • Obsidian Daily Note に日次ルーティンのテンプレートがある。その日について集中し、気分を高めてくれる
  • 毎日、自分に与える最初の [X] は日次ルーティンのチェックリストを完成させること
    • 生産的な1日を始めるための無料の W
  • 実際にはメモの大半を Windows の音声入力で書いているので、毎日のスタンドアップをしているのに近い
  • また、1日中ライブ配信していることも多い。視聴者が自分一人だけでも（もちろんプライベート配信なので毎日やるわけだが）、何かの深みにはまって見失う前に、20分ほど前に何をしていて何を考えていたかを思い出す助けになる。実際、Windows Recall も良い
  • 自分の1日は、2人以上の組織で他の人たちと働くとき（いわゆる会議）にかなり近い形で進む

mentos

  • Done / Doing / ToDo の3つのリストがある Trello ボード
    • やるべきことを全部リストアップする
    • 優先順位を付ける
    • 一番上の項目を ToDo リストに移して作業を始める
    • 完了したら Done に移す。次の項目を ToDo リストに移して繰り返す
  • Trello の他のリストは、リサーチ用カードの管理や、v1 に不要な機能を ToDo リストから外すために使っている

macNchz

  • 小規模チームで働くときと似たやり方で仕事をするのが好き
    • 多数の項目を含むチェックリストが、マイルストーンごとに緩やかに整理された GitHub Issues を管理する
      • コードに近いので、行番号リンク、コピペ用コードブロック、リンクされた PR ドラフトなどで簡単にメモを残し、中断した箇所を思い出せる
      • どの端末からでも非常にアクセスしやすいので、アイデアが浮かんだり、バグに関するメールを受け取ったりしたら、スマホや開発機以外の端末からでもその場で素早く Issue を作れる
      • 適切なタイミングで他の人を呼んで、すぐに作業してもらうのも簡単
      • 良い API とさまざまな統合機能（例: エラー追跡システムから直接 Issue を作成・リンクする機能）がある

rerdavies

  • GitHub Projects を使っている
    • 特別におすすめしたいわけではない
    • しかしタスクリストとバグを管理するのは、実際のところロケットサイエンスではない
    • 数十万ドルもするプロジェクト管理ソリューションも使ったことがあるが、それよりずっとひどかった
  • GitHub Projects は挙動が奇妙で、あまり愛されていなくても、最低限の機能としては十分
    • 自動化できるはずだと思うことはたくさんある
      • たとえば、スクラムボードのすべてのクエリを手動で修正しなくても、数クリックで新しいスプリントへロールオーバーできることなど
    • それでも、自分のやりたいことはできる
      • 他人が決めたプロセスに縛られて柔軟性なく生きるより、はるかにまし
      • ある意味では、このミニマリズムは利点かもしれない
  • 心理的には、これはリスト管理の問題だ。それほど複雑ではない。そして GitHub Projects はリストを十分うまく管理してくれる
  • 紙ベースまたはカードベースの作業リストよりも GitHub Projects を勧める理由の一つは、
    • バグ報告や機能要望がどう処理されているかをユーザーが公開で確認できること
    • また、ディスカッション掲示板の内容をバグ報告に変えたり、開発作業（保留または進行中）に変換したりするのがとても簡単なこと
  • 一般的なスクラムのルールが適用される。すべてのバグは新しい作業を始める前に修正し、作業は完全に終わったときだけ完了状態へ移す
  • 必要なのはリストだ。自分はその上にスプリント構造があるのが好きで、中間アップデートや継続的リリースに役立つマイルストーンを与えてくれる

leros

  • 自分は、プロダクトマネージャー、プロジェクトマネージャー、ソフトウェア開発者、マーケティング、ビジネス運営、事業全体のリーダーといった役割を分けて、一度に一つだけこなす
  • たとえば、
    • 事業全体のリーダーとして座り、望む戦略的方向性を決めることができる
    • その後でプロダクトマネージャーの帽子をかぶり、何を作るかを決める
    • その後で、そのアイデアをプロジェクトとして管理し、優先順位を付ける
    • その後で、プロダクトマネージャー兼デザイナーになって、優先順位を付けた機能を具体化する
    • その後で、完全に別の時間を取り（たいていは丸1日）、機能を開発する
    • 機能をリリースしたら、マーケティングの帽子をかぶって関連するプロダクトマーケティングを進める
    • これが、ひとつの機能を開発する一種のライフサイクルだ
  • 危険なのは、すべての役割を同時に飛び越えてしまうこと。生産性が落ちる可能性がある
  • 戦略的であるべき時、創造的であるべき時、ただ実行すべき時があり、それぞれに異なる頭の使い方が必要だ
  • Notion ですべての計画を立てつつ、目的に応じていくつか異なる Kanban ボードを使っている

urda

  • 自分は階段状の「知識」システムを使っている:
    • ポケットサイズのモレスキンのノートに、ふと浮かんだ考え、メモ、切れ端、図などを記録する
    • それは最終的に、Issue トラッカーの「チケット」になったり、自分の Wiki サーバー上の「Wiki」または「Wiki 更新」になったりする
    • それが最終的に、スニペット、設定メモ、記録文書、アーカイブ、ランブックなどにつながる
  • 最終的には、ドキュメントを最新の状態に保ったり、課題を見つけたら適切なバックログに入れたりすることが「自然な」ことになった

関連記事

6件のコメント

 
xguru 2024-06-30

私は、何であれ自分にとってルーティン化できる方法がいちばんだと思っています。ほかに準備作業が多くて、管理用ドキュメントを開いて始めるまでに時間がかかったり面倒になったりすると、だんだん遠ざかってしまうんですよね。机を片付けたあとで、どこかにしまっておいたノートを取り出して開くこと自体も、ひと仕事のように感じてしまいます。

そういう意味では、私は家と会社のPCでほぼいつもVS Codeを開いているので、その上に表示している「やること.txt」に内容を書いたり消したりするのが毎日の習慣です。何を開けばいいか考えなくて済まず、ルーティン化しやすいのが良いと思います。内容はGitHubのPrivate Repoで同期しています。
 
mytory 2024-06-26

私は Googleスプレッドシートに、プロジェクトのやることを30分から1時間単位に細かく分けてすべて書き出し、完了までにかかった時間を記録しています。予測しやすいですし、一つずつクリアしていく感覚もあります。
 
devsepnine 2024-06-26

私は主に Trello を使っている感じですね。リストアップして、説明を整理して……
どこからでもアクセスできるので……
 
tested 2024-06-25

私はDiscordに個人用サーバーを作って、カテゴリ/チャンネルで分類し、TODOなどの個人的な用途に使っています。
 
porteleaf 2024-06-25

いろいろな方法を試してみましたが、まだ一つの方法に定着できていません。今はメモをObsidianで取り、実務のことは必要なときにリーガルパッドに書いています。
これも、揮発しやすい記憶を補うためのメモだからなのか、時間が経つと何をメモしたのか忘れてしまうことが多い気がします…。
この記事を参考にして、もう一度仕組みを整えてみようと思います…。
 
hwan0317 2024-06-25

必ずしも1人開発をしていなくても、汎用的なモチベーションや計画管理に役立つ内容ですね！