プロジェクト管理ツールは自作できるか　4つの作り方と、それぞれの限界

プロジェクト管理ツールを自分で作るという選択肢は、AIの登場で、ぐっと身近になりました。

この記事では、自作の4つの作り方を比べ、それぞれの手間と限界を整理します。先に結論を書くと、プロジェクト管理ツールは作れます。問題は「何人で、いつまで使い、だれが直すか」です。

※この記事は、GeckoFlagの開発元が書いています。GeckoFlagは、開発者が自分で作った課題管理ツールを製品にしたものです。この連載では、自作した立場から、自作のよい点も大変な点も書いていきます。

なぜ自作したくなるのか

自作を考えるきっかけは、人によって違います。まずは理由ごとに、自作が本当に解決になるのかを整理してみます。

「高い」「多すぎる」という理由なら、ほかの既製品を探すことでも解決できるかもしれません。一方で、「仕事の流れが特殊で合わない」「作ることそのものが目的」という場合は、自作に向いています。

理由がはっきりしていると、このあと紹介する作り方を選ぶときにも迷いにくくなります。

作り方は4つある

プロジェクト管理ツールの作り方は、大きく分けて次の4つです。

表は横にスクロールできます →

どの方法でも、「課題を登録して、担当者と期限を付け、状態を変える」という基本の形は作れます。違いが出るのは、使う人が増えたときと、作ったあとに直すときです。順番に見ていきます。

スプレッドシートで作る

一番手軽なのは、ExcelやGoogleスプレッドシートで作る方法です。最小の構成なら、列は次の4つで足ります。

• 課題：やることを1行に1つ書く
• 担当者：だれがやるか
• 期限：いつまでにやるか
• 状態：未着手・対応中・完了などをプルダウンで選ぶ

期限を過ぎた行に色が付くように条件付き書式を設定すれば、遅れもひと目で分かります。1人〜数人で、数か月で終わる案件なら、これで十分に回ることも少なくありません。

ただし、人数や課題の数が増えると、表は少しずつ崩れていきます。経緯を書く場所がない、担当者を書いても本人に知らせが届かない、といった点です。

関連スプレッドシートで管理するときの限界は、初心者向けの連載「はじめてのプロジェクト管理ツール」の第2回「Excelのタスク管理は、どこで限界が来る？」で詳しく取り上げています

ノーコードツールで作る

NotionやAirtableのようなノーコードツールでは、データベースを作り、それを一覧・カンバン・カレンダーなどの形で表示できます。プログラミングをしなくても、課題管理の仕組みを組み立てられます。

項目を自由に足せて、見た目も整えやすいのが強みです。自分たちの仕事に合わせた形を、試しながら作れます。

一方で、次のような点には注意が必要です。

• 人数で費用が増えやすい：使う人の数に応じて料金が上がる料金体系が多く、結局は既製のツールと同じくらいかかることがあります。
• 作った人しか構造を知らない：どの項目がどこにつながっているのかを、作った人しか分からない状態になりがちです。
• サービスの都合に左右される：サービス側の仕様変更や料金改定があれば、その影響をそのまま受けます。

コードを書いて作る

プログラミングができるなら、ゼロから作る方法もあります。自由度は一番高く、自分たちの仕事にぴったり合わせられます。学習の題材としても優れています。

ただし、時間がかかるのは、課題の一覧や登録画面といった目に見える部分よりも、画面に見えない部分です。

• ログインと、パスワードの管理
• だれがどこまで見られるか、操作できるかという権限
• データの保存と、消えたときのための備え

さらに、作ったあとの不具合の修正や、サーバーやプログラム言語の更新への対応も、すべて自分で行うことになります。作る時間より、作ったあとに直し続ける時間のほうが長くなることも珍しくありません。

AIに作らせる

いま一番注目されているのが、AIにコードを書いてもらう方法です。「課題を登録できて、担当者と期限と状態を付けられるアプリを作って」と頼めば、数時間ほどで、画面の上で動くものができることもあります。

コードが書けなくても形になるのは、大きな変化です。ただし、注意したい点があります。

それは、出来上がったコードを自分で読めない場合、不具合が出たときに直せないことです。AIにもう一度頼めば直ることもありますが、別の場所が壊れることもあります。どこが壊れたのかを判断するには、結局コードを読む力が必要になります。

また、AIが書いたコードの安全性や権利の扱いは、使うサービスの規約や、作ったものの使い方によって変わります。業務で使う場合は、使うAIサービスの規約を確認しておきましょう。

連載実際にAIでどこまで作れるのかは、第2回「AIに課題管理アプリを作らせてみた」で実験します（近日公開）

どれを選ぶかは「何人で、いつまで、だれが直すか」

4つの作り方のどれを選ぶかは、ツールの機能よりも、使う状況で決まります。「何人で」「いつまで」「だれが直すか」の3つで目安をまとめると、次のようになります。

また、仕事の流れが特殊で、既製品ではどうしても合わない場合は、人数や期間にかかわらず、自作（コードを書く、またはAIに作らせる）を検討する価値があります。

この表は、あくまで目安です。1人や少人数でも、ツールを使うと楽になる場面はあります。

特に気にしてほしいのは、最後の行です。社外の人が使う、何年も使う、作った人が異動や退職でいなくなるかもしれない。こうした条件が1つでも当てはまるなら、作り始める前に、第3回以降も読んでみてください。

「動く」と「使える」の間にあるもの

自作を始めると、多くの人が途中で気づくことがあります。それは、「動く」ことと、「何人もが長く使える」ことの間には、大きな距離があるということです。

たとえば、次のようなものは、最初の画面を作っている間は思い浮かびにくい項目です。

• メンバーごとの見える範囲：社外の人には、この案件だけを見せたい
• パスワードを忘れたときの再設定：本人がメールで再設定できる仕組みがほしい
• 通知メール：担当になったとき、コメントが付いたときに知らせたい
• データのバックアップ：サーバーが壊れても、課題の記録を失いたくない

どれも、使う人が増えたとたんに必要になります。そして、1つずつ作るたびに、確かめることと直すことが増えていきます。

連載自作で後から気づく項目は、第3回「『動く』から『使える』までの距離」でチェックリストにまとめます（近日公開）

まとめ

• プロジェクト管理ツールは、スプレッドシート、ノーコード、コードを書く、AIに作らせる、の4つのどの方法でも作れる
• 自作が一番効くのは、仕事の流れが特殊で既製品が合わない場合と、作ること自体が目的の場合
• どれを選ぶかは「何人で、いつまで使い、だれが直すか」で決まる
• 「動く」と「何人もが長く使える」の間には、大きな距離がある

自作は、決して無謀な選択ではありません。ただ、作る前に、作ったあとのことまで考えておくと、遠回りを減らせます。

次回は、実際にAIに課題管理アプリを作らせて、どこまでできるのかを試します。連載の最後には、自分でツールを作った開発者として、自作と既製品のどちらを選ぶべきかの結論を書く予定です。

AIを仕事で使うようになって、タスク管理そのものがどう変わるのかは、連載「AIと働くチームのタスク管理」の第1回「AIを使い始めたら、タスク管理ツールはいらなくなる？」で取り上げています。