アカウントＳＥとのぶつかり合い（後）

さて、シリーズの最後になります。

まず、僕がアカウントSEに対し、投げかけた主張は以下になります。

1. 暗黙知の形式知化をもっと積極的に推進すべき
2. ITSSにおけるITアーキテクト:アプリケーション・インテグレーションアーキテクトを戦略的に育成すべき
3. 職務とＰＪにおける役割と責務の開示と明確化を行うべき

１、２番目の主張に関しては、前回の記事参照

• 2007-04-03 アカウントＳＥとのぶつかり合い（上）
• 2007-05-20 アカウントＳＥとのぶつかり合い（中）

今回は、３番目の主張について記述します。
「職務とＰＪにおける役割と責務の開示と明確化を行うべき」

この主張は、知識労働者というSEの性質に起因します。

• 2007-03-08 RoleとResponsibility

でも触れたのですが、今回はもう少し踏み込んで書きたいと思います。

「大辞林」にはこうあります。

• 役割
  • 役目をそれぞれの人に割り当てること。また、割り当てられた役目。
  • 集団内の地位に応じて期待され、またその地位にあるものによって学習される行動様式。社会的役割。

• 責務
  • 自分の責任として果たさねばならない事柄。つとめ。

弊社は最大手クラスのSIerでしたが、役割と責務に関しては徹底されていませんでした。
これは同期各位に聞いても同じ答えが返ってくるので、SI部門は全社的にそうなのでしょう。

役割、それはミッションと同等であり、そこには責務が伴います。

SIのプロジェクトにおいて特定の役割というのはほぼ確立されています。
例えば、以下のような役割があります。

• プログラマ：仕様を満たし、かつ案件毎の要件（抽象度、パフォーマンスの確保など）に沿ったプログラムを作成する
• 構成管理者：モジュールの構成、バージョンを管理する
• テスタ：テスト仕様書に沿って、テストを実施する
• 障害票管理者：各障害票のOPENからCLOSEまでの管理を行い、障害票一覧を最新の状態に保つ
• 内部設計レビューア：内部設計のレビューを実施する

責務はそれぞれの役割に付加するもので、アクティビティレベルで定義するとよい
と思います。

• 構成管理者
  • 各チームからのモジュールの受け入れからリポジトリに反映するまでのフローを定義する
  • 定義したフローをドキュメントとして記述する
  • 各チームから適切にモジュールを受け入れる
  • 受け入れたモジュールのバージョンの整合性をチェックする
  • 受け入れたモジュールの差異をログに残す
  • 受け入れたモジュールを統合する
  • 統合したモジュールをリポジトリに反映する
  • いつでも各時点のモジュールに戻せるようにしておく

• 内部設計レビューア
  • レビュー票を起票する
  • チェックリストに従って、内部設計の成果物に対し、チェックを行う
  • レビュー票に記入する
  • レビュー結果にNGがあった場合、成果物の更新を促す
  • 成果物の更新後、再度レビューを行い、NG項目が解消されているかチェックを行う
  • レビュー完了時（NGであっても）、レビュー結果管理票にレビュー票の内容を反映する

こういった役割を、各人が１人１役ではなく、１人複数役を兼ねる事になります。

これらを明確化し、割り振ったものをメンバー同士が共有する事で、
下記のメリットがあります。

1. 知識労働者として役割に徹し、力を注力できる
2. 付加価値のある役割に意識してアサインさせる事ができ、競争力をつけていける
3. 特定の人に負荷が偏るオーバースペックを防ぐ
4. 責務が見える事により、責任のなすりあいの防止とプロセスの継続的改善が可能

また、デメリットとして

1. 抜け漏れなく考えなければならず（MECE）、そもそも定義が難しい
2. ＰＪの状況による頻繁なアップデートに伴うコストが必要
3. 役割外の事に無頓着になる可能性がある

私の印象だと、こういった部分をプロジェクトマネージャが経験則に基づく
「頭の中マネジメント」でやってしまっているので、各人がアサインされた役割に
抜けがあって、それをカバーさせられる特定の人に負担がかかったり、
そもそも誰がやるのか曖昧なままプロジェクトが進んで、後でタスクが抜けていた、
もしくはコストがかけられず品質が目標に達していないという事が
往々にして起こっています。

また、「頭の中マネジメント」をされるとその人の暗黙知に依存してしまうため、
スキルの引継ぎにもコストがかかってしまいます。

「役割と責務」に基づいたフレームワークを策定し、割り当ててこそ、
初めてプロジェクトらしいプロジェクトと言えるのではないかと思います。

以上が、私が現場で感じた問題点であり、アカウントＳＥに報告した内容になります。

余談ですが、よく思うのは、既存の仕事の流れに馴れ切ったSIerの団塊ジュニア世代の方には、
上記のように自らフレームワークを定義し、適用するといった考え方はできない方が
多いのではないかという事です。
そういった考え方を「フレームワーク思考」と言います。

例えば、PMBOKを覚えるためのPMPという資格試験のはずが、いつしかPMPの資格勉強
になってしまっているケースがあります。
PMPを持っているのに、いざプロジェクトが始まるとリスクマネジメントが
されていなかったり、統合マネジメントが意識されていなかったりするのです。

結局、既存の仕事の流れをベースにやろうとしてしまうため、やはり同じ失敗を繰り返す
というわけです。

恐らく、ビジネス環境の変化によるプロジェクトの複雑化はその世代にとっても
初の体験である事が多いのでしょう。

私はそこに意識ある若手が、フレームワーク思考の必要性を訴え、定義し、
適用していくといった役割を担っていく事で、良い形でプロジェクトを進めていく事が
できるようになるのではないかと期待しています。