横断組織と各組織との連携も仕組み化にメリットがある

開発横断組織に所属

私はシステム開発の横断組織と呼ばれるチームに所属しています。
プログラムを書いたりシステムを構築するような業務はなく
開発に関する様々な方針やルールを考えて上位メンバーと合意形成をしたり
さまざまな組織とのハブ役となる業務がメインです。

全社から様々な対応依頼、ヒアリングを受ける

私のチームでは日々、全社からの様々な開発対応依頼やヒアリングを受け、
管轄している10以上の組織へ依頼を行う業務があります。
例えば、担当システムで○○を利用しているかどうか、
○○を期限までにバージョンアップしてほしいなどです。
さらに依頼を受けた組織はその中で複数のチームへ依頼を渡します。
私のチームでは一方的に依頼をするだけでなく、
期限内に全ての管掌組織が対応完了したかどうかも確認します。
依頼内容とステータス一覧をドキュメントにまとめ、
対応が完了したら管掌組織にステータスを更新していただいていましたが
更新もれが多く、こちらから確認することがよくありました。

依頼を受ける組織が普段使っているタスク管理ツールを利用開始

そこで、私たちの対応コストを減らすために、
依頼を受ける組織が普段使っているタスク管理ツールを利用して
依頼や進捗管理を行うことにしました。
本来の目的はツールを各組織に合わせることではありませんでした。
開発組織がタスク管理に使っているツールと連携し
期限前に自動でリマインドが届くようなbotを作成するためでした。

管掌組織のやり方に合わせた事によるメリット

当初目的としていたリマインドの自動化によって
手作業でのリマインドコストが下げられただけでなく
下記のような効果が見られました。
(一部は様子からの推測も含みます)

• 依頼を受けた組織内の対応連携もスムーズになった

  • 依頼を受けた組織内では普段の業務と同じように同じタスク管理ツールを利用した連携やコメントの記録が行われていた。

• ステータス「対応完了」への変更忘れが減った

  • タスク管理ツールによって「未完了」のタスクに気づきやすくなった

似たようなフローに寄せて習慣化することで確認コストと漏れの削減につながる

これまで、横断組織において進め方を変えると
問い合わせが頻繁にあり、
定着まで時間を要することが多くありました。
この業務もwikiのようなドキュメント作成ツールでの運用から
タスク管理ツールへ移行という比較的大きい変更だったため
慣れるまで混乱するだろうと予想していました。
しかし、実際移行してみると、問い合わせはほぼゼロでした。
過去と比較してもこのようにスムーズに仕組みを変えられた事はありませんでした。

これはタスク管理ツールの効果もありますが、
各組織が普段の業務と進め方が似ていた効果が大きいと考えています。

例えば、普段の依頼でドキュメントツールに入力している依頼を
ある1回だけドキュメントツールに加えて
Excelにも入力をお願いすると必ず対応漏れが発生します。
それは全体を見なくても
普段からドキュメントツールに入力するという習慣がついているから
だと考えています。

このように依頼の進め方もできるだけ似たようなフローに統一し、
習慣化すると依頼元、依頼先双方で確認コストや対応漏れが減り、
スムーズになると感じました。