backlogよるアジリティ（Agility）の獲得

アジリティ（Agility）とDX

backlogというプロジェクト・タスク管理ツールがありますが、すごくセンスがいい気がします。
センスがいいとは、これ以上、足しても引いてもダメという最適なところでバランスが取れているということです。
機能も、UI,UXもバランスがいいです。
このbacklogをベースに、さらにAPIを利用することで、新たなシステムの可能性があるのではないかと思っています。
今風に言うと、backlogはDXを推進するために最適なんじゃないかと思っています。
つまり、様々な社内システム構築に対して、破壊的なイノベーションを起こすことができるような気がします。
システム構築に対する破壊的なイノベーションとは、アジリティが担保されるシステムであり、
事業の環境変化に対して、機敏に反応していけるシステムです。
現場風に言えば、こういう機能とデータが欲しいと言われれば、１週間後には出来上がる。そんなシステムです。

「完了」というステータス管理

仕事やタスクというのは、１人で完了するものは少ないはずで、企業内ではいくつものプロセスを通って完了します。
DXは、まさに、そのいくつものプロセスをデジタルで一気通貫させるものです。
その場合に、いま、どのプロセスまで進捗しており、完了しているのか、まだ進行中なのかを可視化する仕組みが必要です。
たとえば、ワークフロー申請システムであれば、これが実現されています。
このワークフローを組織や企業の垣根を越えて、行なえるようなシステムをイメージしてください。
それが、DXだと思います。
今までの発想だと、とんでもない大規模で複雑システムが出来上がるイメージだと思いますが、
これを簡単に、簡潔にできるシステム基盤をbacklogとAPIで構築するのがいいと思っています。

システムに対する重要性は増し続けるが、、、

昨今、政府のコロナ関連システムのニュースを見るに、これじゃダメだと思いが募ります。
システムは自前で開発するもの。システムは高価なもの。
そろそろ、その認識を変えていく必要があると思っています。
ただ、クラウトパッケージを使って、システムに合わせて業務フローを変えるという話ではありません。
これは簡単そうで思えて、実際はとても難しいです。
業務フローを変えるということは人間の意識を変革しなければならないからです。
自前システムでもなく、クラウドでもなく、今までとは違う、新たなシステムがいいと思っています。
とにかく、システムを使いたいと思ったときに、すぐに、効率よく、しかも安価に使えるシステムの仕組みです。
そうでなければ、システムがビジネスに役立つどころか、システムがビジネスの足を引っ張るだけになるからです。

システムは、インターネットとWEBブラウザで変わった

WEBブラウザはインタネットを見るためのものではなく、業務を行うものになりつつあります。
WEBブラウザさえあれば、インターネットから社内システムまで、他に何もいらないほど、万能な仕組みです。
しかも、他社のシステムにすらログインが可能で、そこで処理も行うことが出来ます。
さらに、今ではスマホさえあれば、同じようなことが可能なりました。
WEBブラウザーで動かないシステムは、それだけで無駄なコストを数倍使っていることになります。

ビジネス要件に厳格性を求めるより、運用に柔軟性を求める

ビジネス要件は、ビジネスを行ううえで、純粋に欲しいデータと機能のことです。
そして、ビジネス要件をシステムの設計に落とし込んでいきます。
システム要件の概要が出来た段階で、そのシステム構築の費用と工数が見えてきます。
そこで起こることは、そんなにお金が掛かるの？ということで、ビジネス要件の見直し、やっぱり中止という流れ待っています。
これらの課題を解決するために、アジャイルやドメイン駆動などのシステム構築手法もありますが、
肝心なことは、とりあえず、やれる範囲でやってみようという緩さと、運用しながら改修していくという進め方です。
そこに意識を変えていかないと、イノベーションは起こせないです。
イノベーションを起こすための最初の１歩を踏み出すために、backlogは相性がとてもいいと思っています。

backlogとAPIで作るDXの具体的なカタチとは

従来の企業システムは、フロントエンドとバックエンドを１つにしたシステムを構築していました。
そのため、企業内には、分散した、連携のないシステムがたくさん存在します。
また、システムの数だけ、保守コストが積み重なり、効率が悪くても古いシステムを使い続けなければなりません。

DXの具体的なカタチとは、以下の３つの要素で構成されているシステムだと思います

• フロントエンドとバックエンドは、同じにしないこと
• フロントエンドからバックエンドは、すべてAPIにすること
• バックエンドのデータベースは一元化すること

フロントエンドはすべてbacklogにして、API「Application Programming Interface」でバックエンドを連携する。
APIでは、共通のデータベースに、データを保存するようにする。
データベースには保存されたデータを、フロントエンドのシステムの領域にとらわれることなく、様々なデータ活用をしていく。
この３つの条件が実現すれば、従来にないシステムになり、これが、DXの本質そのものだと思っています。

インフラとして

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

業務として

• タスクの種別管理（タスクの種類（タスク、調査、要返信、連絡、要望）を分理できる）
• タスクの進捗管理（未対応、処理中、処理済み、完了のステータス管理）
• タスクのカテゴリ管理（タスクを業務で分類できる）
• タスクの検索（文字によるタスクの検索）
• タスクの協働作業とプロセスの可視化（コメント機能でコミュニケーションやプロセスの可視化ができる）

仕事を分解していくとタスクになる

どんな仕事でも、分解していければ、タスクという単位になります。
そのタスクをこなしていくのが、仕事になります。
そして、そのタスクは、一人でやるというよりは、複数人、組織でやっていくものです。
そこにコミュニケーションが発生します。
backlogは、タスク管理、コミュニケーション、タスク遂行の３つを行うことが出来ます。
出来ますというよりは、そのためのシステムです。
つまり、backlogだけあれば、すべての仕事が出来てしまうことになってしまうのです。

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

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

非定型な処理

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

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

数字を見たら、１回疑うべき。その裏付けを調べる。
そして、その数字が正しいと分かれば、より正しい判断に導いてくれるはずです。
数字が正しいかどうかは、複数の視点で見ることで、その数字の信ぴょう性を見ることです。
営業の数字でも、プロジェクトの進捗でも、複数の視点で数値化できることが重要です。
データをDBに保存するということは、そういうことで、様々な切り口で数値を見ることが可能になります。

DB化するためには

DB化するためには、まず情報があつまる仕組みが必要です。
この情報があつまる部分がフロントエンドで、そのフロントエンド次第で、集まってくる情報が変わってきます。
定性情報と定量情報であれ、重要な情報であれ、ちょっとした情報であれ、同時に扱うことができればベストです。
これは、まさにbacklogで十分というか、最適だと思います。
言い方を変えると、今まで扱えない情報でさえ、簡単に情報が集めやすくなるからです。
これが、DBに直結しているシステムだと、扱う情報を変更するたびに、DBの設計変更が必要になります。
これが、まさに時間と開発コストの無駄です。
フロントエンドをbacklogに１本化して、そのバックエンドでDBと連動させるだけで、すべて解決できるような気がします。

ワークフロー

複数人でタスクを完了させる典型的な業務です
申請者が居て、承認者がいます
申請したものがすぐに承認されることもあれば、何度もやり直すこともあります
急いでいる承認もあれば、代理で承認することも、金額に応じては、さらに承認者が増えることも
申請内容ごとに、ひな形が用意されており、申請書を選んでから申請するなど、まさに非定型な業務の典型です。
また、日々、数十件から数百件の申請があるならまだしも、めったにない申請も存在します。
これは、backlogだと思われます。
申請種類と申請内容をbacklogで登録して、承認者を担当者にして、登録するだけです。
添付資料があれば、それも添付することができます。
申請内容のひな形が必要なら、wikiに登録しておきます。
定量情報化したいデータがある場合には、APIを使うという運用が最適だと思います。

顧客情報管理

これは、１顧客を１タスクにして、顧客の動きはすべてコメント欄で記載していく方式が最適です。
これだけで、誰が、いつ、どんな顧客対応をしたのか、可視化することができます。
顧客の対応内容はひな形や項目に制約されることなく、自由に書くことができる。
また、必要な関係者には、通知機能を利用して、お知らせすることもできます。
また、情報更新日順に並べる変えることで、最近御無沙汰している顧客一覧など、なんなく作成することができます。

営業案件管理SFA

顧客を親にして、案件を子課題にする。
また、売上や受注金額などの金額を管理する場合は、カスタマイズ属性を利用して項目を作成して、別途管理する
案件単位で、案件開始日、案件完了予定日、現在の進捗、最終的な受注失注管理、金額の管理できます。
また、コメント機能を利用をすれば、そのときに必要な顧客対応なども共有したり、協業したりできます
SFAと同じような使い方がbacklogだけでできます。

営業情報管理の応用（SFAとbacklogの面白い使い方）

ドラッカーの目標マネジメントの実行計画に該当する部分をbacklogに書いて、それの進捗を管理していく。
実行計画は、本人が書いても、本人以外が書いてもいいし、ひな形を用意してもいい。
あとは、実行計画が実行されたかどうか、実行したことで行動目標や達成目標に近づいたか可視化していく。
これは単なる応用例ですが、効果は結構あると思います。
で、backlogのいいところは、思いついたら、すぐに出来ること、またすぐに辞めることが出来ることです。
これが、今のシステムに対する考え方で出来てないことです。
独自のシステムを作るのにコストが掛かる。コストを掛けた以上はつかわざるおえない。
これでは毎回ホームランを求めているのと同じです。誰もシステムを使って新しい試みをしようとしません。
また、上記のようなマイクロマネジメントは、永遠するものではなく、１か月限定でやってみることで十分です。
その１か月の中で、気づきや、慣習が生まれ、それが今後の営業活動につながっていく、研修みたいなものです。
１か月限定のためにシステムを作るのは難しいと思いますが、backlogなら工夫次第でやりたいことができます。

サポート管理

インターネット上に問い合わせ画面を用意して、問い合わせ内容は、APiを使って、そのままbacklogに保存していく。
問い合わせ内容を見て、カテゴリ化して、担当者をアサインして、進捗管理を行っていく。
また、蓄積された問合せ内容から、問い合わせの傾向把握やFAQなどのドキュメント展開も可能になります。