メンバー間の力量差をどう埋める？SAPプロジェクトで円滑にチームを運営するために
はじめに
SAPプロジェクトはメンバーの入れ替わりが激しいわりに長期化しやすく、チームメンバーの知識や情報格差が開発の品質に影響します。
ウォーターフォール型のプロジェクトであっても、スプリント的な開発を行わなければならず、その時に知識差や情報格差があるとミスや不具合に発展してしまうリスクがあります。
今回は、頻繁に入れ替わる開発メンバーの間で生じる知識や情報の格差を埋める方法についてまとめてみたいと思います。
1.入れ替わりの激しい開発チーム
SAP ERP関連のプロジェクトは、工期が長くなる傾向にあります。一方、開発チームでは頻繁にメンバーが入れ替わることが珍しくありません。
1-1. 開発チームは年に3回入れ替わる？
あくまでも一般論ですが、SAP ERP業界では開発チームが年に2～3回ほど入れ替わることも珍しくないようです。
例えば、2年におよぶプロジェクトがカットオーバーを迎えると、初期メンバーは元請けの管理者以外、一人も残っていないというケースはザラにあります。
8～10人の開発チームであれば、プロジェクト開始からカットオーバーまで残るのは1～2人で、ほかのメンバーは半年から1年でリリースとなっていることがほとんどのような気がします。
1年で3回入れ替わる……は大げさだとしても、年間を通して一度もメンバーの入れ替わりがないチームのほうが珍しいのではないでしょうか。
この理由はさまざまですが、大体以下のようなものだと思います。
・予算の都合からスポットの開発人員しか調達できない
・案件や機能などで仕事の区切りがつけやすく、それに伴って人員の調整がしやすい
・業界の慣習としてフリーランス人材が活躍しやすく、開発メンバーの契約形態がバラバラである
いずれもSAP以外のIT業界全般に言えることなのですが、SAP ERPでは特にこの傾向が強いように感じます。
SAP ERP関連で長く活躍している人材は、「個」としての自分を大切にする傾向があり、同じプロジェクトに長期間在籍することを好まない人がいるようです。
これは良い・悪いの話ではなく、あくまでも業界の風潮ですからそういうものとして考えたほうが良いでしょう。
2.開発標準だけでは追い付かない「業務知識の差」
しかし、実際にチームを運営する側からすれば、メンバーの頻繁な入れ替わりは歓迎しにくいことでもありますよね。
開発チームのメンバーが頻繁に入れ替わると、まず「新メンバーを受け入れるために要するコスト」や「新メンバーが業務にアジャストするまでのコスト」を計算しなくてはなりません。前者はそれほど大きくないのですが、問題は後者です。
注意してほしいのは「新メンバー」が「新人」でない場合でも、コストが生じるということ。
新人であれば、そもそも基礎的な知識や業務知識が不足しているので、致し方ありません。
しかし、ある程度の経験をつんだ中堅メンバークラスであっても、業務へのアジャストが難しいという事態は、日本のSAP ERP業界特有のもののように感じます。
皆さんご存じのように、日本で導入されているSAP ERPシステムはアドオン開発によって成り立っています。
最もS/4 HANAの導入に伴って、「Fit to Standard」の風潮が強くなっていますので、今後はアドオンの塊というシステムは減っていくでしょう。
しかし、それでもECC6.0までのSAP ERPはアドオン開発がふんだんに使われていますし、これを無視した移行は難しいはずです。
また、何よりも重要なのは「アドオンで作った機能には、企業独自の業務プロセスが組み込まれている」という点。
開発チームの新メンバーを受け入れる際にコストを要する原因は、ここにあります。
アドオンの比重が高いシステムを扱うために必要な知識は、標準機能やABAP関連のものだけではありません。
クライアント企業のビジネスプロセスや業務の特性が反映されているため、まずはこの点を理解する必要があるわけです。
2-1. 開発標準では埋められない情報格差
SAP界隈に限らず、ITプロジェクトの開発チームでは開発標準を作成し、メンバー間で共有していることがほとんどだと思います。
開発標準では、開発における禁止事項や標準仕様をまとめていますが、ここにはクライアント企業独自のビジネスプロセスや業務の方法などは書かれていません。
したがって、開発者固有のスキル・認知の差を埋めるためには役立つのですが、「業務にスムーズにフィットさせる」という点では不十分なのです。
2-2. 現実はメンバーの個人的な「学習」に支えられている
では、多くのプロジェクトでは、どのように新メンバーを業務に適応させているのでしょうか。
誤解を恐れずに言えば、実際には新メンバーが着任当初から猛烈に学習し、半ば強引に知識を身に着けているという状況が大半ではないかと思います。
当然のことながら、理解度は個人の素養に左右されますし、皆が同じ情報を、同じ粒度で理解するという保証はありません。
つまり、徐々にメンバー間で情報格差が広がっていても、管理者はそれに気が付かないわけです。
この状態でさまざまな仕事を振り分けると設計ミスや不具合を引き起こします。
3.メンバー間の情報格差をどう埋めるか
メンバーの入れ替わりが防げないのであれば、少なくとも情報格差を常に最小化する努力はすべきでしょう。
そうでなければ、開発の質は担保できませんし、延々と同じミスを繰り返すことになります。
では、どのように情報格差を埋めるべきなのでしょうか。
現実的な解決策としては、以下のような方法があると考えられます。
3-1. 基本設計、概要設計レベルの情報は手順書形式で資料化する
設計書は正確な情報が集約されている一方で、ビジネスプロセスや業務の流れが見えにくいという弱点があります。
よく、新メンバーがアサインされると同時に「設計書類はここにあります」というアナウンスだけを出して、あとはメンバーの個人的な学習にまかせるという管理者がいますが、これは情報格差を生む温床になるでしょう。
なぜなら、
・機能Aの設計書で書かれている項目名が、機能Bでは別の項目名に変わっている
・機能Cと機能Bでテーブルから同一の項目値を抽出するが、日本語の説明がまったく違う
といった設計書間の齟齬を吸収できないからです。
プロジェクト開始当初から着任しているメンバーであれば、クライアント企業のビジネスプロセスや業務の流れが何となく理解できているので、こうした齟齬も受け入れられます。
しかし、新メンバーにはすべて「正解」として理解されるため、正確に作業を進めれば進めるほど不具合のリスクが高まってしまいます。
これを防ぐためには、基本設計や概要設計の情報を手順書的に、読み物の特性を持つように解説し、まず全体として何をしているかを共有しなくてはなりません。
「設計書を手順書のように解説する」ことに違和感を覚える方は少なくないと思います。
しかし、着任してすぐのまっさらな状態で「大元のストーリー」を理解することができれば、設計書間の齟齬やミスにも気が付きやすくなることは確かです。
まずは、基礎となる資料を「読みやすく」「ストーリー性を持った」状態で提示することで、メンバー間の情報格差が生じるリスクを減らすのです。
勘の良いメンバーであれば、設計書の祖語にいち早く気が付き、適宜修正の許可を申し出てくるでしょう。
また、設計書に齟齬がない状態でも、各機能間の関連性や依存関係を早期に理解できるので、チームの軌道に乗るためのコストが小さくなります。
3-2. 自分の現在地が確認できる資料を作る
大規模なプロジェクトになるほど、機能の数も増えていきます。
着任したばかりの開発メンバーは、今こなすべき仕事がシステム全体のどの部分に該当するかを、理解できていない可能性もあるでしょう。
SAP ERPシステムは機能間の依存関係が複雑であり、周辺機能を全く知らない状態での開発は不具合の遠因になります。
したがって、どの機能が何を実現していて、自分が担当する機能はどの位置にあるのか、といった「図」が頭に入っている状態にしておくべきです。
システム鳥瞰図で代用できることもありますが、業務との関連づけを説明しながら分かりやすく図式化した資料があれば、メンバーの早期育成に役立つはずです。
4.管理者以外でも役立つ
以上の内容はチームを運営する側、つまり管理者側に対するTipsです。
しかし、実際にさまざまなプロジェクトを渡り歩くエンジニアやコンサルトであっても、着任したプロジェクトを図式化するクセは非常に役に立ちます。
まずは、自分の頭の中に大きな図とストーリーをインプットし、そこからブレイクダウンして目の前の仕事にとりかかる。
この習慣が身についていけば、新しいプロジェクトでも、スムーズかつストレスなく仕事に取り掛かれるようになるでしょう。
