運用で問題が起きやすいところを先に潰しておく
前回は環境編の目次でしたが、今回は組織編の目次を作成しました。
プロジェクトが始まって、要件分析や要件定義を行っていると、ついつい個別のアプリケーションを設計したくなります。しかしながら、intra-martで運用時にトラブルが起きやすい箇所が組織や役職、ロールといったワークフローの構造を決める部分です。ある程度は開発サイドで組織構造や職位による基本的な設計方針を考えておく必要があります。私もプロトタイプが完成してから発覚したワークフロー上の要件を満たすために大幅な設計変更を行った経験があります1。人事や経営企画の経験者が揃っているチームならもう少しハードルは下がるかもしれません。
ともかくとして、自社開発するときのリソース状況から苦戦しやすいポイントと思われるので、組織についてだけで一章を割きます。書きたいと思っている内容は次の節です。
組織編目次
- 各種組織構造の表現方法
- 機能別組織を考える
- 事業部制組織を考える
- マトリックス組織を考える
- チーム制組織を考える
- 異常に正常な組織または正常に異常な組織
- 職務による意思決定が必要なケース
- 組織によって同じ役職名の職位が異なるケース
- 組織によって同じ職位の役職名が異なるケース
- 概念上の組織や役職が存在するケース
- 待遇としての役職が存在するケース
- 権限の委任が存在するケース
- 副、代理、補が存在するケース
- 実質的院政による権限の二重構造が存在するケース
-
私の分析力が低いと言われればそれまでのことですが… ↩