Jira_組織構造の作成手法

組織構造のフレームワーク

Jiraで組織構造・プロジェクト構造を作成する場合、唯一絶対の答えではありませんが、下記のフレームワークが例として挙げられます。

  • テーマは、組織全体にわたる大規模な重点分野です。
  • イニシアチブは、共通の目標達成のためのエピックの集合体です。
  • エピックは、より小さなストーリーに分割できる、まとまった作業です。
  • ストーリーは「ユーザーストーリー」とも呼ばれ、要件またはリクエストをエンドユーザーの観点から簡潔にまとめたものです。

弊社の組織を構造化する際に、3つの組織構造の選択肢が頭に浮かびました。

https://docs.google.com/document/d/e/2PACX-1vQui9eNEGS0BixwQg3PZ26UYNbO-ALGKs45MBXV26GWQCIxNhiKYWiAJWHhzs8EdmqFLK1WbkyRfWbS/pub?embedded=true

案①

まず頂点のテーマに販売活動(顧客を獲得)、サービス(商品・サービスを作成し提供)、業務管理(社内全体の管理業務)を持ってくる。

その下の階層に業務の大分野(求められるスキルセットが異なり担当者もこの分野ごとに割り当て)の階層(イニシアチブ=プロジェクト、例:経理・税務・IT・業務管理支援etc.)を設定する。

その下に担当者ごとの大テーマ(エピック、例:支払管理_経理・申告書の作成_税務・ソフトの導入_IT・マニュアルの作成_業務管理支援)、小テーマ(ストーリー、例:A社の支払管理・B社の消費税申告書の作成_申告書の作成・IT_C社のSalesForce導入_ソフトの導入、D社のJira導入_マニュアル作成)、小テーマの詳細な手続(サブテーマ、例:①A社をPCに取り込み××フォルダに格納②請求書をもとにGドライブのA社××フォルダの〇〇月振込.csvに仕訳を入力③〇〇月振込.csvをA社会計ソフト●●にアップロードetc.)を設定する。

案②

まず頂点のテーマに顧客会社を持ってくる。各テーマはA社、B事業者、C相続人などになる。その下のイニシアチブの階層に経理・税務などを設定する。しかし、この構造を弊社の販売活動を組織構造にもっていくと、構造的に最上位のテーマ階層にもっていかざるを得ず、テーマ階層にA社、B事業者、C相続人、弊社販売活動、弊社業務管理などが並列になり管理しづらいという問題があります。また、顧客毎を最上位テーマにすると、管理面で会社ごとに異なる手続きをする方向に寄りやすく、効率化や質の向上等のスケールメリットが得づらくなります。

案③

案①と同様にまず頂点のテーマに販売活動(顧客を獲得)、サービス(商品・サービスを作成し提供)、業務管理(社内全体の管理業務)を持ってくる。

その下の階層にA社、B事業者、C相続人などの顧客単位(または契約セット単位)でイニシアチブを設定する。

その下の階層に業務の大分野(求められるスキルセットが異なり担当者もこの分野ごとに割り当て)の階層(エピック、例:経理・税務・IT・業務管理支援etc.)を設定する。

その下に担当者ごとの大テーマ(ストーリー、例:支払管理_経理・申告書の作成_税務・ソフトの導入_IT・マニュアルの作成_業務管理支援)、小テーマもしくは手続(サブテーマ、例:①A社領収書をPCに取り込みXフォルダに格納②領収書をもとにGドライブのA社フォルダの〇月振込.csvに仕訳を入力③〇月振込.csvを会計ソフト●●にアップロードetc.・消費税申告書の作成_申告書の作成・IT_SalesForce導入_ソフトの導入、Jira導入_マニュアル作成)を設定する。


問題は3つのうち、どの組織構造をとるかです。

組織構造の作成目的

組織構造を作成する目的は、組織がどのような考えに基づいて行動を行うかによって変わります。まず、弊社は営利企業のため、目的は①利益の向上②規模拡大にあります。①と②を同時に達成しようとすると求められる組織構造の要件は、㋐職能・職責の分担によりスキルを資産化して向上させやすいこと、㋑各業務担当者から見て直感的にタスクがわかりやすいこと、㋒手待ちが少なく次のタスクがなにかを探す時間が少ないこと、㋓業務担当者ごとの業務負荷や生産性を管理しやすいこと、㋔業務の漏れや抜けが把握しやすいことだと考えました。

採用する組織構造

上記㋐~㋔の観点から、早い段階で職域ごとにわけてしまう案①が最善だと判断しました。

一度、案③を採って、Jira上に顧客ごとにプロジェクトを作成しようと思いましたが、プロジェクトごとのカンバンに経理、税務、労務、法務、ITなどがならんでしまうのでやめました。各担当者が見て、異なる種類の自分の職責でないタスクが並んでいる状態は、全員が総合職や同じ専門職で他人のタスクをカバーしあう組織(多くの日本企業や同じスキルセットのプログラマ組織)であればよいかと思いましたが、弊社の思想とは異なりますし、仮にカバーしあう状況が発生すると誰がどの業務を何時間やったのかが把握できなくなり、業務改善ができなくなります。また、業務ごとの専門性も向上しづらくなり、加えて、頻繁に引継ぎなどが発生し、時間単位あたりの生産性も下がります。※さきほどトヨタ生産方式の書籍を読みましたが、同様のことが書かれてあり、案③はカンバン方式の思想とも異なるように思います。

よって、弊社においては、案①で組織を作っていこうと思います。

※なお、案③であっても、設定やカスタマイズにより、実質的に同じ目的は達成できますが、結局視覚的な効果などにより組織がどういった方向に傾きやすいかという点で案①を採用しました。

※案①の問題点として、例えば経理プロジェクトにA株式会社支払管理、B株式会社現預金管理、A株式会社資金繰り表の作成などが顧客の増加によって、例えば30社の顧客がいると100個以上のタスクが並んでしまうことが想定されます。しかし、これはむしろプロジェクトが担当者ごとに設定されているため業務負荷が視覚的にわかりやすく、例えば経理②というプロジェクトを設定することでプロジェクトごとのタスクの膨張を防げます。

公認会計士・税理士 上原英知

コメントを残す

%%footer%%