2024年11月22日
データ・アプリケーションは将来に向けて、データ連携領域以外でも新しい事業の創出に挑んでいます。そのミッションを担うNP開発室が、新事業第一弾としてワークマネジメントプラットフォーム「Placul(プラカル)」のサービスをスタートしました。
私はインフラ分野を除く領域以外で、フルスタックの開発エンジニアとして参加しています。役割としては開発メンバーの一員ではありますが、バックエンドの主要な機能などを中心に開発をすることが多いです。
私自身は作業の担当者としてこれまでは世の中にあるさまざまなツールを「利用する立場」でした。これまで利用したツールの多くは、あくまで作業の状態を管理することを目的としたものです。いわゆる「管理ツール」です。
それらの管理ツールは、気軽に更新して情報をそのツール上に残すというようなことができないものばかりでした。管理ツール上に情報を残せないので、代替策として例えばExcelやWordといったパーソナルなツール上に詳細な情報を残すことになります。そうすると情報の検索などが困難となることで、知識の共有化および資産化がうまくおこなえていませんでした。
結果として、その作業を担当者もしくは近しいメンバーのような一部のメンバーしか知らない情報が蓄積され、新しく参加したメンバーはその情報にたどり着けず長くプロジェクトに参加しているメンバーに情報が偏るというようなことが起きていました。
製品の分野として近い領域であるAsanaやClickUp、国内製品だとBacklogなどはよくチェックしていました。これらの製品は既に現在の市場において広く利用されている製品であるため、プラカルの機能開発時の方向性を考える上で参考としています。
これまでの社内の製品開発では主にオンプレミスで利用するパッケージ製品の開発であるため、IaaSやPaaSといったクラウド型のインフラサービスを意識して実装をする経験があまりできませんでした。プラカルの開発ではAWSのような外部サービスを利用した機能の開発などもチャレンジすることができました。
これにより、外部のサービスに関する理解およびメリット、またサービスを利用することで気をつけなければならないことなどを学べました。
また現在のプラカルの開発では、ある程度の大きな機能を自身の裁量で設計/開発することができる場面があり、これまでの開発ではなかなかチャレンジが困難だった領域も挑戦できる場面が多く、それらの経験を得られたことは開発に携わって良かったと考えています。
園田さん自身もプラカルのユーザーのひとりです。実際に開発チームでのコラボレーションやワークマネジメントのプラットフォームとして使ってみて、プラカルの3つの特長について、導入効果はいかがだったでしょうか。プラカルを利用する前と利用後の決定的な違いや、チーム生産性の観点など、多面的に教えてください。
日々の作業として業務タスクを実施すると、どうしてもそのタスク単体のミクロな視点での作業となりがちです。木を見て森を見ずという感じでしょうか。そのタスクがそもそもどのような目的/目標のタスクであるかということがどうしても意識から薄れてしまいます。
その点プラカルは、タスクと目標が密に紐づいていることでタスクと目標が常にセットで表示されており、かつ自分の個人目標などもグローバルヘッダー上でいつでも確認することができます。これにより、自分の作業そのものが目的/目標を達成するための作業であることを意識して作業できるようになったと思っています。
仕事というものは、「誰かにやらされている」と考える場合と、「自分の目標を達成するためにやっている」と考える場合でモチベーションが大きく異なります。プラカルは後者の環境を提供してくれていると感じています。
私は通知をなるべく早くチェックしたいという性分。ですから、以前より常にいくつものシステムやツールから届く大量の通知をチェックしていました。
プラカルでは通知そのものが大きく2種類に分類されているのでチェック時に自分で最初に通知の分類分けをしなくて済むことで、チェックの負担が減ったと考えています。また、特に重要なインボックスのメンションでの通知が更に分類されていることで、重要な通知を見逃すことが減ったと思います。
自分が通知する側の観点でも2種類の通知機能は有効に働いています。作業中に「タスクの協働者に連携はしたいが、メンションで通知するほど優先度が高い内容ではない」というようなケースの場合、コメントなどを使ってメンション無しの通知をすることで、他のメンバーに疎な情報連携ができる点がとても重宝しています。
業務タスクに着手するにあたり、作業量が多いタスクの場合は、作業の分割や、確認するためのチェック項目が多くなるケースがあります。担当する業務によっては、作業量の多いタスクばかりということもあるでしょう。プラカルを利用すると、タスクそのものに直接紐づく形でノートが用意されていることで、別の資料を作って整理する必要がなく、プラカル上でそれらの情報整理が完結するのが便利だと考えています。
チームなどの組織で作業をする場合、すべての作業が一人で完結することはあまりありません。必ず誰かに担ってもらう部分が出てきます。「この部分の作業は別なメンバーに依頼したい」というようなケースでプラカルを利用すると、ノート内のマイクロタスクを利用することで別の新規タスクではなく、その作業中のタスクから派生した依頼とすることができ、かつそこに依頼した作業のコンテキストも集約されます。チームなどの組織的な作業では、一般的に個々の作業の情報が散らばることが多いですが、プラカルの利用により、こうした情報散逸を防ぐことができるのも良いと思っています。
情報が散らばるのを防ぐという点では、その作業タスクに紐づくドキュメントなどを別なファイルサーバーなどに配置して、それらを参照するような形となるケースが多いと思います。私たちも以前はそうでした。ところが、ドキュメント数が一定数を超えると、この管理・維持が問題になってきます。そのため、追加でドキュメント管理システムの導入が検討されます。プラカルの場合、少なくとも日常の業務タスクに関連する範囲では、こういった考慮が必要ない点も良いと思います。
例えば、事務職などでもチーム内で業務タスクに必要な情報を共有するのに適用できるのではないかと考えています。
事務職のような部署だとプラカルのように連絡を取るようなワークマネジメントプラットフォームをそもそも利用しておらず、電話やFAXで連絡を取り、付箋を使ってその内容の担当者に通知するなどの手法が利用されている組織があると思います。それらについても例えばプラカルを利用してタスク+メンションで連絡することができるのではないかと考えます。
上記の例であれば、その電話・FAXの内容をタスクの内容に落とし込んでもらうことで、それらの情報が電話でやり取りをした担当者だけではなく、他の従業員にも共有することができるようになり、例えば担当者が不在である場合にも対応できるケースが増えるのではないかと思います。これは取引先対応の改善につながります。
また、事務職であっても組織や体制は年度ごとに変わります。退職者もいれば新しい人材の入社もあります。もちろん、取引先の体制も変わると考えるのが普通です。こういった場合、「引継ぎ」が行われ、規定類や業務フローのマニュアル、個々の取引先との契約条件や留意条項を新しい担当者に伝えます。プラカルで日常の業務タスクを管理すると、これらに加え、個々の取引に関する過去のやり取りや、そのときに気付いたメモなど、一般的な引継ぎでは伝えきれない現場の生の情報をチーム内で共有することができます。。
これらがうまく会社内で文化として定着することで、ワークマネジメントプラットフォームに溜まった情報そのものがその会社の資産として活用することができるものだと考えています。一般的な事務職のような分野でも、チーム組織で協力しながら働くのであれば、プラカルが実現する情報の可視化と共有の仕組みは、組織内部の生産性を上げ、取引先満足度を向上させるものと思います。
データ・アプリケーション Placulマーケティングチーム |
|
経歴・実績 株式会社データ・アプリケーションは、日本を代表するEDIソフトウェアメーカーです。設立は1982年、以来EDIのリーディングカンパニーとして、企業間の取引を円滑に効率化するソリューションを提供しています。1991年からは日本の標準EDIの開発やSCM普及にも携わっており、日本のEDI/SCM発展に寄与してきました。現在は、EDI/SCM分野のみならず、企業が所有していデータの活用についてもビジネススコープを広げています。ハブとなるデータ基盤提供を始めとして、さまざまな角度から幅広く研究・分析を行っており、その提言を通じて企業のDX推進を後押ししています。 |