管理ツールはあくまで手段！結局大事なのは使い方だと思ったある日のこと

システム開発に限った話ではありませんが、プロジェクトを管理する上での管理手法、管理ツールって多種多様です。

これまでにプロジェクト進行で使ったことのある数々のツールに想いを馳せて、ふと辿り着いた答えを今日ここにまとめておきたいと思います。

IT業界を中心に使われている様々な管理ツール

まずは、プロジェクトマネジメントやタスク管理、Wikiをまとめるツールとして主に使われるもので、私が触ったことのあるサービスを列挙してみます。

天下のGoogle

• スプレッドシート
• ドキュメント
• スライド

Atlassian 製品

• Jira
• Confluence
• Trello
• Bitbucket

Nulab 製品

• Backlog
• Cacoo

その他

• Redmine
• esa
• Github
• Gitlab
• Asana
• Jooto
• Notion
• Wrike
• Flyle
• Miro

いや、色々ありすぎる・・・書いてる途中でアレはなんてサービス名だっけ？って調べ始めたらすでにクローズされてたり買収されてたりでカオスでした。

クライアントワークで色々な企業さんとお仕事させていただくが故、このように利用する管理ツールが増えていくことは日常茶飯事です。（その上、アカウントも毎度違ったりするので切り替えが大変！という話はまた次回）

私のPM経験と管理ツールの変遷

たくさんツールを列挙しましたが、どういう案件でどのタイミングでそれらのツールに触れたのか改めておさらいです。

開発が活発なサービスは日々追加機能が進化していますので、私の感想はあくまで使った当時のものであり、最新の状況はわかりません。

初めての案件で使っていたツール（当時2014年）

自分がSIerでエンジニアになって初めて使ったツールはBacklog＋Google系ツールです。

まだBacklogにガントチャート機能がない時代、Issue管理やクライアントとの調整はBacklog、タスクのスケジュール調整はGoogleのGantterを先輩が使っていた覚えがあります。

このツールしか知らなかった頃は、ソースコードもBacklog内のGitで管理しており、Githubと無縁の駆け出しエンジニアでした。

右も左もわからない中、先輩の指示に従って使っていたツールに慣れるのが精一杯で良し悪しの判断なんてできていないのが正直なところです。

PM補佐を任された時、管理ツールの派閥争いに巻き込まれる（当時2015年）

その後、某大企業の案件でPLポジションを担当しますが、この頃になると自社のプロジェクト管理にとどまらず、クライアント先との仕様調整や顧客折衝的なことも経験します。

そんな中で突如直面したのは、Jira派とRedmine派の社内抗争！（大袈裟に表現しています）

Redmineで降ってきたはずのIssueを、なぜかJiraに移して対応していたり、Redmineがある日突然更新されなくなったり、なのにWikiはJiraに移行されていなかったり…

そんな混沌としたプロジェクトでしたが、その頃はJiraのUIのほうが操作性がよく感じたため、結果的には自分もJira派の一員となりました。その後がどうなったかは知りません。

開発ではなくマーケティングの部署でPM（当時2017年）

エンジニア3年目の頃、クライアントワークとしてのPMではなく、自社サービスも任されるようになり新たな部署を立ち上げました。部署としては資金の余裕もない状況で、この頃は無料で小規模のタスク管理ができるAsanaやTrelloを活用していたように思います。

以下は私が書いたQiita記事です。
https://qiita.com/maimax/items/e81e7fa19b775fd817c0

独立してベンチャー・スタートアップへ（当時2019年〜）

自分で会社を設立し、Web系ベンチャー企業とお仕事させていただくことが増えてからは、圧倒的にGithub管理が多くなりました。IssueもWikiも、エンジニア中心にGithubを使っています。

とはいえGithubは無料で使える範囲に制限が多いため、自社サービスではなるべく費用をかけないようGitlabやNotionを使っています。

他は、お仕事する会社さん次第でConfluence、Jooto、Wrikeなど使いつつ、次々にツールが増えていっている次第です。

結局、どの管理ツールがPMしやすいの？

これだけのツールを使う機会があれば、やっぱりこのツールはいいけどアレはだめだよね、みたいな感想が出てくるのは当然です。

使うたびに「う〜んGithubよりGitlabのほうが使いやすいな〜私は」などと思っていた頃もありました。

ただ、その時期はもうとうに超えてしまったようです。

近頃はプロジェクトにどんなツールが導入されていようともあまり気にしません。

なぜなら、プロジェクトを進めるのは管理ツールではなくあくまでPMであって、ツールは使い方次第でどうとでもなるからです。

だから、最近はある程度の使い方のルールを統一化することのほうに注力しています。

ルールその1. 情報の階層を守る

フォルダ整理などにも同じことがいえますが、無秩序にあちこちに散財された情報ほど見つけるのに苦労するものはありません・・・。人が情報を探してたどり着くまでの時間は別のことに当てられたかもしれない貴重な時間。そう考えて、最初は（それこそPMが）情報の階層を設計してあげたほうが良いと思います。

難しく考えず、Wikiにはまとまりごとの階層を作るとか、Issueのタグをどういう粒度でつけるとかをざっくり決めるだけでも◎

決めたら絶対変えてはいけないわけではないので、後から見直して変更するのも全然アリだと思っています！

ルールその2. テンプレートを駆使する

どの管理ツールにも、よく使われるテンプレート（議事録、開発Issue、Todoなど）が用意されていることがほとんど。

起票する人による粒度ブレや俗人化が発生しないよう、あるものは最初から使うのがベストです。

ルールその3. サマリを常に最新化する

Issueの対応方針や、開発ルールなどは日々アップデートされてしまうもの。後から入ってきたメンバーが混乱しないよう、常に最新情報にしておく必要があります。

コメント欄でやりとりされた決定事項、MTGで話したことなどを拾ってトピックに反映させます。

ルールその4. 更新の担当を決める

最後に大事なのは、誰が更新するのか、です。

最新化しよう、と思っても後回しにしがちなIssueやWikiのメンテナンス。決まったことを更新するだけであればさほど工数かかる作業ではないので、その場で誰が更新するか決める or 名乗り出てしまうのが早いと思っています。

MTG中であれば、宿題事項としてアサインしておくと確実です。

管理ツールに振り回されないPMになるために

ここまで振り返ってつくづく思うのは、管理ツールは結局いつか慣れるということ。どれがいいのか悩んでいるより、最低限のルールを決めて使い始めてしまうほうが良いと思っています。

クライアントワークで様々な案件をこなすPMはもちろん、自社事業のPMだって、チームの要望で新しいツールを導入したり、自分が試したくて管理ツールを取り入れたりすることもあるはずです。

その度に使い方を1から学ぶのはそれなりに体力が奪われる・・・。そんな時は、無理にインプットせず使っているうちに慣れるのを待ちながら、ルールに沿った運用を心がけてみてはどうでしょう。

私も日々まだまだ実験、試行錯誤中！

この記事を書いてる間に、前にツールの組み合わせとか勉強会で話したな〜と思ったので紹介しておきます。

---

管理ツールに関する記事は、りゅうじさんの以下記事もご参考まで。

プロジェクト期間で利用する管理ツールを変えてみよう