Backlog

backlogというプロジェクト・タスク管理ツールについて
Backlogはセンスがいい気がする。センスがいいとは、これ以上、足しても引いてもダメという最適なところでバランスが取れている。
機能もそうだし、UI,UXもバランスがいいと思う。
このbacklogをベースとして使うことで、新たなシステムの可能性ができるのではないかと思っている。

システムに投資する時代は終わった


●システムに投資する時代は終わったと思う

自前でシステムを開発する。システムは高価なもの。
その認識をそろそろ変えていく必要がある思います。
ITに合わせて業務フローを変える。これは簡単そうで実際は難しい。
業務フローを変えるということは人間の意識の変革を必要とすることを意味するからである。
今までとは違う、この中間にあたるシステムがあるといい。
とにかく、システムは使いたいときに、すぐに、効率よく、安価に使う。
そうでなければ、ビジネスに役立つどころか、ビジネスを足を引っ張る可能性すらある。

●システムは、ブラウザに変わる

ブラウザはインタネットを見るためのものではなく、業務を行うものに変わる。
ブラウザさえあれば、社内システムからインターネットまで、他に何もいならい。
スマホがあれば、外部からも使うことが可能になる。
企業は、複数人で完結するタスクがほとんどで1人で完結するタスクはほぼない。
1人で完了するタスクは、わざわざシステムを使う必要はなく、EXCELで十分かと。

●システムに柔軟性を求めるより、柔軟に運用することでコストを下げる

用途別にそれぞれシステムを用意して、社内に多くのシステムが存在することは、誰も得をしない。
極力シンプルに、1つのシステムを使って、運用レベルで、用途を満たすことで十分なことに気づくはず。

backlogを導入しただけで実現出来てしまうこと


●インフラとして

  • どこからでも(会社のPCから、出先のスマホからアクセス可能)
  • タスクにひもづけたファイルの共有と管理(ファイルサーバでディレクトリで管理から解放される)
  • backlogの更新があればメールでお知らせしてくれる
  • メールを廃止して情報共有(通知機能を使えば特定の人にお知らせができる)
  • APIを利用する(backlogのデータを取り出してさらに様々な連携をする)

●業務として

  • タスク管理(未対応、処理中、処理済み、完了のステータス管理)
  • タスクの検索(文字によるタスクの検索)
  • タスクの作業プロセスの可視化(コメント機能で作業プロセスを可視化していける)

これからのシステムのあり方としてのbacklog


●フロントエンド、バックエンド、APIのシステム構成

backlogをフロントエンドとして、backlogのAPIを利用してバックエンドと連動する。
さらに、バックエンドから、ブラウザー経由でシステムを拡張していく。
APIでバックエンドという大げさで、全然シンプルではないのではと思うかもしれないが
フロントエンドをbacklogに任せるということは、backlogのデータしか使えないということで、複雑になりようながない
シンプルなデータ構造のまま、それをいかに運用で回すかで、様々な可能性を広げることができる。
そのために、必要最低限な要素をbackogがすでに持っている。
データ構造を複雑にするから、システムが複雑になるということを避けることができる。

●非定型な処理

非定型な処理が少しあるだけで、システムの世界は専門家の世界に突入し、コストが一気に跳ね上がります。
複雑なシステム、例外に対応できないシステム、いつまでもシステム化できない業務になります。
ときたま起こる非定型な処理は、システムにさせるののではなく、人が対応することで、十分な気がします。
すべてをシステムで詳細に定義して、そのようなシステムを作るために、コストを費やすのは現実的ではなく、
さらに、これからの時代、個別対応ではありませんが、ますます非定型な対応は増えていくはずです。
その都度、システムを改修していては、本末転倒というか、何が本来の仕事なのか、わからなくなります。

backlogのデータをマネジメント業務で使うために


backlogのデータをAPIでDBに同期し、DB側に新たな情報を付与する。
DB側で入力エリアを作ってもいいし、backlogに一定にひな形を用意して、そこから情報を抽出してもいい。
新たな情報を付与することで、フロントの業務とは異なるマネジメント業務などが可能になる。

●DB化が変えるマネジメントの意味

数字を見たら、1回疑うべき。その裏付けを調べる。
そして、その数字が正しいと分かれば、より正しい判断につながっていく。
複数の視点で見ることで、その数字の信ぴょう性を見ること。
営業の数字でも、プロジェクトの進捗でも、複数の視点で数値化しておくことが重要。
データがDBに保存されていると、それが可能になる。
DBによる情報化のポイントは、情報さえあれば、複数の視点で数字を探ることができるようになること。

●DB化するためには

情報があつまる仕組みが必要
この情報があつまる部分がフロントエンドで、そのフロントエンド次第で、集まってくる情報が変わる。
プロントエンドは、まさにbacklogで十分というか、最適だと思う。
なぜなら、定性情報と定量情報を同時に扱うことができるため、 言い方を変えると、今まで扱えない情報でさえ、情報があつまりやすくなる。
これが、あからじめDB1本だと、扱う情報を変更するたびに、DBの設計変更が必要になる。
そこに時間と開発コストが必要になる。
フロントエンドをbacklogに1本化して、そのバックエンドでDBと連動させるだけで、
システムの領域や柔軟性が一気に拡大する。

backlogの業務領域の可能性


backlogはタスク管理やプロジェクト管理の仕組みとして有名であるが、運用次第で、何でも出来るのがすばらしい。
数百万から数千万円を費やしていたシステムコストが、月に数万円で運用が可能になるはず。

●ワークフロー

複数人でタスクを完了させる典型的な業務
申請者が居て、承認者が居る
申請したものがすぐに承認されることもあれば、承認するために何度もやりなおすこともある
急いでいる承認もあれば、代理で承認することや、金額に応じては、さらに承認者が増えることも
申請内容により、ひな形が違うのは当たり前など、まさに、非定型な業務の典型です。
また、日々数十件から数百件の申請があるならまだしも、めったにない申請も存在する。
これは、backlogで十分のはずです。
定型処理はある程度のルールのもとbacklogで行い、
定量情報化したい場合には、APIを使うという運用が最適だと思います。
運用例としては、
申請書の種類ごとにプロジェクトを作成して、プロジェクトのwikiに申請方法等を記載するだけ
定量的な情報を扱いたい場合は、タスクのひな形を用意して、定量情報がわかるような記載方法をルール化して、
APIでその定量情報を抜き出す仕組みを用意する

●顧客情報管理

これは、1顧客を1タスクにして、顧客の動きはすべてコメント欄で記載していく。
これだけで、誰が、いつ、どんな顧客対応をしたのか、可視化することができる。
顧客の対応内容は文字の入力になり、自由に書くことができる。
さらに、そのときの顧客対応の種類(クレーム対応、問い合わせ)や顧客の反応(おおむね好評とか、不評)などの 情報を付与することにより、顧客対応の状況分析等にも活用できるようになる。
顧客にはIDというユニークな番号が付与されるケースが多いが、 baclogは、1つの課題でユニークやURLやAPIであれば、固有IDを持つことが可能になる

●営業情報管理

顧客管理をさらに深掘ぼると、顧客別の案件管理という単位になる。 案件単位で、受注した、失注したの情報単位になる。
また、その案件の商談進捗管理というとらえ方もできる。
この商談がどこまで進んでいるのか、最終的にクロージングできる可能性はどれくらいか、いつまでにクロージングなのか
商談の進捗を見るために必要な情報を手間をかけずbacklogで行うことができる。

●営業情報管理の応用(SFAとbacklogの面白い使い方)

ドラッカーの目標マネジメントの実行計画に該当する部分をbacklogに書いて、それの進捗を管理していく。
実行計画は、本人が書いても、本人以外が書いてもいいし、ひな形を用意してもいい。
あとは、実行計画が実行されたかどうか、実行したことで行動目標や達成目標に近づいたか可視化していく。
これは単なる応用例ですが、効果は結構あると思います。
で、backlogのいいところは、思いついたら、すぐに出来ること、またすぐに辞めることが出来ること。
このようなマイクロマネジメントは、永遠するものではなく、1か月限定でやってみることで十分。
その中で、気づきや、慣習が生まれ、それが今後の営業活動につながっていく。
これを、わざわざシステムを作ってやろうと思えば、開発期間も、開発コストも結構掛かる。
出来てたとしても、使われないとかに、まさに営業情報管理の失敗例を作っていくようなもの。

●問い合わせ管理

インターネット上に問い合わせ画面を用意して、問い合わせ内容は、そのままbacklogに保存していく。
その問い合わせに対する対応進捗状況と対応内容をbacklog上で管理していく。
また、問い合わせ内容に応じて、必要な人たちにも、お知らせするようにする。
適用例
APIを使って、問い合わせフォームからbacklogへの保存していく。
問い合わせ内容をさらにカテゴリ化して、担当者をアサインして、進捗管理を行っていく。
また、蓄積された問合せ内容から、問い合わせの傾向把握やFAQなどのドキュメント展開も可能に。