システム開発現場で必要な社内教育という物を考えます。
自己学習とは別に、なぜ社内教育が必要なのか。
はじめに
少し思うところがあって、社内教育について考えてみました。
自分の頭の整理のような投稿になっています。
整理した上で、この必要性を訴えていきたい。
年明けからちょっと重いテーマです。
少々組織を批判的にとらわれる様な記述しているところがありますが、攻撃が目的ではありません。
プロスポーツの選手達は皆、それぞれトップの技術を持ちチームに参加しています。
では、トッププレイヤーだけを集めれば最強のチームになり得るでしょうか。
私はなり得ないと考えています。
これはシステム開発でも同じです。
個々が役割を果たし、チームプレイが出来、尊重し合うチームワークが形成されて初めて、最強たり得るチームが形成されます。
チームプレイを発揮するとき
プロスポーツの選手達の本番とは試合です。
試合で最高のパフォーマンスが発揮できるように、チームプレイを日々練習しているはずです。
システム開発の本番とは開発プロジェクトです。
プロジェクト開始直後から最高のパフォーマンスを発揮するためには、同じくチームプレイが必要です。
チームプレイは何時、訓練しておくべきか。
私は「社内教育とはプロジェクト開始時点から チームプレイ が発揮出来るようにする訓練」だと考えています。
プロジェクト開始前にチーム作りは完了しておくべきです。
そして、チーム作りは組織の使命です。
では、どうしたらシステム開発の現場で、プロジェクト開始時点でチームが出来あがるのでしょうか。
ここを私なりに考察してみたいと思います。
何故なら、チームプレイ無くして開発プロジェクトのリリースというゴールを迎えることが出来ると考えているからです。
チームプレイに必要なもの
チームプレイに必要な物は、役割と、ルールです。
なぜ、役割とルールが必要なのでしょうか。
役割
サッカーで言えば、フォワード、ミッドフィルダー、ディフェンダー、ゴールキーパー
みんな自分の役割を分かって試合をしています。
いちいち試合中に自分のポジションを聞いたりしません。
みんなそれぞれ自分の役割で動きます。
監督は全体を見つめながら大局的な指示を出すのみです。
プロジェクトにおけるチームプレイも同じです。
各々が自分の役割を認識し、自分の役割を全うできないと、プロジェクトは回りません。
チームプレイとは役割の認識から始まります。
組織は役割を明確に定義しなければなりません。
代表的な役割
役割はプロジェクトの特性や、戦略でも変わってきますのでここではサンプルに代表的な役割を紹介します。
本当はもっと細分化されている場合もありますし、境界が曖昧な場合もあり、組織、組織でそれぞれです。、
- プロジェクトリーダー／マネージャー
- プロジェクトの司令塔にあたります。
- 全体を見渡してプロジェクトをゴールへと導きます。
- SE
- ユーザとの要件詰め、仕様作成を行う役割の人です。
- 顧客とプログラマーとを繋ぐ接点になります。
- プログラマー
- プログラマーは、SEの定義した要件を実現する役割です。
- 品質管理・テスター
- プログラマーが実現化したプログラムの品質を担保する役割です。
- プログラムの品質のみならずドキュメントの品質等も担保する役割です。
役割の明確化
チームで動く場合は役割を明確にしておく必要があります。
複数の役割を一人の人間が担う場合もあるでしょうし、全てを一人でと言うケースもあるかも知れない。
でも今、自分が
- どの役割で行動しているのか。
- どの役割の視点で物を語っているのか。
明確にしておくことで、作業の羅針盤にもなるはずです。
ルール
サッカーで言えば、役割が分かっても戦術に則ったパス回しが出来ないと意味がありません。
チームプレイには的確なパスが必要なのです。
システム開発ではパスは、役割と役割の間をつなぐルールになります。
何をルール化するのか
パスをうまく繋ぐには、
- プレイヤーが的確にボールをトラップし
- ボールコントロールし
- 次のプレイヤーが受けやすい場所にボールを送り届ける
ことです。
そうして繋いだ先にゴールはあります。
システム開発では
- 「インプット」を理解し
- インプットを元に自分の役割の「作業プロセス」 を実行し
- 次の人に「アウトプット」を伝達する
ことで情報伝達が可能となる。
これを属人化せず体系化した物がルールです。
このルールの連携の先にプロジェクトのゴールは見えてきます。
何故ルールを決めるのか
例えばルールのひとつ、SEからプログラマーへの設計書。
プロジェクト毎にフォーマットが変わり、記述されている粒度が異なっていたとしたらどうでしょうか。
受け取る側は、その都度その都度、異なるルール（設計書）で作業しなければなりません。
これでは、訓練（設計書の読み方）しようもありませんし非効率です。
こういったことが起こらないためには、組織が機能するためのルールを定義しておく他ありません。
これは組織の仕事です。
これらがそろって初めて、以下の訓練に取り組むことが出来ます。
- ルールに則って正しくインプットを理解できること。
- ルールに則って役割の作業プロセスを実行できること。
- ルールに則って正しくアウトプットを伝達すること。
社内で教育すべきもの
では
役割と、ルールを決めたらチームプレイが出来るか？
そんなわけがありません。
ルールは決めることより、運用することが難しいのです。
だから社内教育は必要
いきなりルールを決めたから実践で使えと言われても出来ません。
スムーズに運用するにはひたすら訓練しかありません。
そして、チームプレイは組織的活動でしか経験値を積めないのです。
これを訓練するには役割間の情報伝達のルールをしっかり取り決める事が前提となります。
では何を教育するか
大きく分けて、二つです。
- チームプレイに耐えうる個人スキルの教育
- ルールに則ったチームプレイの教育
個人スキルの教育
個人スキルは個人で磨くべきと言う意見は最もですが、 個人スキルと言っても実に様々です。
ここではチームプレイをするために必要なスキルに限定します。
役割を全うするために、ルールの中で発揮できるスキルの教育です。
例えば新人にいきなり役割を与えて、期待する作業を全うしてもらえるでしょうか。
必ず、誰かがサポートについて教育しつつ作業をしているはずです。
（サポートしている工数はちゃんと組織に理解してもらいましょう）
役割を全うできるまで持っていく教育が、ここで言う個人スキル教育です。
主に三つです。
- インプットを理解できる様にする教育
- プロセスを全うできる様にする教育
- アウトプットを作成できる様にする教育
どちらかというとルールの理解に対する教育となるので、リーディングが主体のです。
インプットを理解できる様にする
チームプレイの大前提となります。
インプットの情報をもらっても理解できなければ作業が出来ません。
ここでの教育の目標は、インプット情報の目的と意味の理解です。
これは組織の役割分担の違いによって異なってくる内容ですので、ベテランであっても全くルールの異なるプロジェクトに入る場合には同様に教育が必要になります。
同じく、ジョイントで開発する際など別組織のメンバーに参画してもらう場合なども同じです。
なので、個人で理解出来る物ではありません。
組織が提供するルールを知ってもらう必要があります。
インプットの情報が自分の果たすべき役割とどう関連付いているのか教育する必要があります。
作業プロセスを実行できる様にする
インプットが理解できたとしても、ルールに沿って役割と全うできなければなりません。
これも作業プロセスはルールによって異なってきますので、個人での学習が難しい領域です。
ここでの教育の目標は、インプット情報を元に実際に作業が行えることの確認です。
プログラミングを例に取れば、以下の様な教育が必要になると思われます。
- 使用する開発フレームワーク
- コーディング規約
- redmineの様なプロジェクト管理ルール
- svnやgitなどのソース管理ルール
もう一例に品質管理の仕事をとっても
- 試験に関する環境や、データのルール
- 不具合管理表とプログラマーへの伝達ルール
等など、役割役割で作業前提となる知識が必要となります。
ローカルルールも多いところです。
組織運営に必要な教育は組織のサポートのもと必要です。
アウトプットを作成できる様にする
作業プロセス完了後、次の作業に結果を引き継がなければなりません。
これは役割間のインターフェースにあたる物なので、組織の決めたルールに則って作成してもらう必要があります。
これが謝っているとチームプレイが崩れ、組織の機能不全を起こします。
ここでの教育の目標は、アウトプット情報の目的と意味の理解です。
例えばSEは以下のアウトプットの目的と意味を知るべきです。
- 要件定義書
- 基本設計書
何を作成すれば良いかは、ルールに定義されているべきです。
そうでないと、担当者やプロジェクトによって記述が揺れてきます。
明確に定義されているのだとすれば、ここはルールの記述方法を教育できるはず。
でも、個人にやる気が無い人に対して
こればっかりは、仕方ありません。
教育しても無駄という人は一定数います。（残念ながら）
非情なようですが、いることで他のメンバーの足かせとなるようなら去ってもらうしかありません。（もしくは、単純作業だけさせるとかね）
同じ理屈でBrilliant Jerkはチームプレイにはマイナス要因が多いので、一概に能力があるからチームプレイが出来るわけでもない。
チームプレイの教育
個々の役割の作業が出来るような教育が行われたとして、今度は自分のアウトプットを、実際に次の人に渡してみなければ、次の人のインプットたり得ているのかをはかるすべがありません。
個人スキルの教育が「単体試験」なら、チームプレイの教育は「結合試験」です。
では、ここで行うチーム教育とは何でしょうか。
スポーツであれば、練習試合などが可能ですが、日々業務を行いつつテストケースのプロジェクトを立ち上げるなどは現実で気ではありません。
私は最初に「社内教育とはプロジェクト開始時点から チームプレイ が発揮出来るようにする訓練」と定義しました。
私が考えるチームプレイの教育は、教育と言うにはちょっと違うかも知れません。
どちらかというと、OJTに近いかも知れません。
OJTと違うのはトレイナーと研修生の関係ではなく実践に近い形で、ルールを再確認していくと言うところでしょうか。
私の考えるチームとしての教育と組織の役割は以下です。
- 些細な作業でもチームで行う。
- 行った作業はチームで振り返る。
- 振り返り時にルールの改善点なども話し合う。
- 組織は振り返りの時間を業務として認める。
- 振り返った内容でルールをアップデートする。
- 組織はルールのアップデートの権限をチームあたえる。
開発時点でチームプレイを実行するには、その訓練はプロジェクト開発のない平時や、閑散期となります。
その間、仕事がないと言う組織はそんなに無いでしょう。
それなりに保守業務等で追われているのではないでしょうか。
そんなときに行える実務と兼ねた訓練方法を二つ紹介します。
具体例①運用/保守で訓練
既に運用に乗っているシステムでは、基本的には必要なルールにあたる資料/情報はそろっているはずです。
そして保守などで、改良依頼は一部の機能を改善する様な、比較的短期間で少額案件で行われる場合が多いと思います。
その少額案件が訓練のチャンスです。
ここで重要なことは、一人でやってしまわないことです。
大半の少額案件は一人で行うことが可能です。
でも、ここをぐっとこらえて、チームで実施するのです。
少額案件はスピード感も要求されるので、ほどよい緊張感とボリュームです。
いざとなったら、一人で何とかしてしまえるという安心感（？）があります。
また、少額とは言え全ての作業要素が含まれます。
- 要件/仕様詰め
- 設計書の改版
- 改版部分のプログラミング
- テスト
- そして納品
これを活用しない手はありません。
そして、スピード感が求められるが故に、ルールの不備（これ必要？等）も見つけやすいので一石二鳥です。
具体例②リファクタリング作業で訓練
古いシステムを引き継いだときに、過去のルールで作られている情報が既に形骸化している場合があります。
もしくは、そういった情報がそろっていないシステムなどがあります。
もし、リファクタリングが許されているのなら、迷わず行うべきです。
ここでのポイントはリファクタリングの結果を次の役割の人にレビューしてもらうと言うことです。
その場合に、各情報を最新のルールにリファクタリングすることで、必然的にルール作成の訓練になります。
そして、リファクタリングすることでシステムの理解が深まります。
リファクタリングは失敗が許されないので、特に品質面での訓練に最適です。
社内教育の壁
チームプレイという物を組織だって行うには、今まで話してきたような準備が最低限必要になります。
改めて文章に起こすと、相当な労力であることが分かります。
しかし、この訓練無くしてプロジェクトがうまくいくとは思えません。
出来るとすれば、それは相当に場数を踏んだメンバーで構成された時のみでしょう。
そんなスペシャルメンバーがそろうことはまずありませんし、実はそういったメンバーは共通する概念とルールを持っていて、動的にルールを作り出すことが出来ます。
でも、実際に組織での教育の重要性を訴えると必ず出てくる壁があります。
この壁を何とかしなければなりません。
今回この投稿の大半を、チームプレイをするためには多くの下準備が必要であることに裂いたのは社内教育という物の必要性を納得してもら為でもあります。
チームプレイをするための一番の難関でもあります。
教育はコストか投資か
必ずでてくるのが「そのお金はどこから出てくるの？」問題です。
社内教育というのは非採算活動です。
それが、直接的に収益になるわけではありません。
しかし、疎かにすることで収益は間接的に確実に減ります。
困ったことに疎かにしたからと言って、急激には落ちません。
じわじわと落ちていくことになります。
逆に言えば、訓練してもじわじわとしか上がらないのです。
でも、数字を管理する人にはこの活動はコストでしかないんです。
しかも、教育は長期的にこの活動をしないと効果を示せない。
ここを納得してくれて投資と判断してくれる組織なら、社内教育を計画的に行っていけます。
ここを納得してもらうには、やっぱり草の根運動で訓練していたチームと、訓練が疎かだったチームとのデータを目に見える形にするしかないのでしょうか。
プロジェクトの特性によっては比較が出来ないこと、突発的な要因でうまくいかないこと等もあり、なかなか比較が難しく、訓練の成果で比較できない場合も多い。
完全なルールが最初から必要か
次に出てくるのが「誰がルール決めるの？」問題です。
この質問はスタートアップと同時に100%ルールがそろっていることが前提で話されています。
ルールはアップデートされていくべき物です。
ならば、100%のルールができあがったとしても、アップデートのルールがなければそのルールは陳腐化していきます。
アップデートを業務の一部と認めてさえくれれば良いはずです。
そうすればスタートアップはもたつくでしょうが、徐々に落ち着いていくはずです。
この徐々にってのが計画性がないと言う言葉で片付けられてしまいますが
だって今だって、開発や保守など、どんな形であれ運用しているから組織として成り立っているはずです。
ならばルールが明文化されていないだけで土壌は十分ある。
後は、必要なところから順次必要なときにルールをそろえていけば良い。
それすらがチーム教育の一環となる。
最初から全てきれいにそろってから用意スタート！ってのはかなり抜本的な組織改革でもしないと無理です。
こここそ、アジャイルであるべきです。
だって、システム屋のお得意じゃないですか。
誰が教師たりえるか
またこんな事も言われます。
「誰が教えるの？」
ここをつかれると難しい、だって体系立てて教育という物を考えて、方針立てていかないと教育者の育成も出来ないから。
だいたい教育者たりえる人は、プレイングマネージャーに奔走しているイメージです。
だから、おいそれと頼むわけにも行かない。
究極の理想は教育部隊の設立ですがそんなことが現実にしてもらえるはずもありません。
だけど、いくら強力なスキルを持っていたとしても、一人は一人です。
限度があります。
その一人が育てたメンバーに、その一人のスキルが継承された時に得る利益を考えられないだろうか。
むしろ、先にルールが出来れば、教師はルールブックがになってくれます。
そうなれば、教師の負担はぐっと下がる。
ルールのアップデートの権限を与えてくれれば勝手に改善されていく。
ただ、これらの作業を業務時間内に行えるように考えてくれないと行けない。
そこだけ組織が認めてくれれば良いのですか。
おねがい
だいたい議論すると、鶏が先か、卵が先かと言うはなしに陥ってしまいます。
もし、自分はこういう説得、こういう手法でこれらを解決したと言う方は教えてください。
参考にさせて頂きたい。
まとめ
- チームプレイをするためには役割とルールが必要
- チームプレイが出来るようにするのは組織の役割
- ルールを決めたらルール通りに運用できるように訓練が必要
- これらを組織に理解してもらう。
さいごに
どちらかというと現場目線で対組織向けに訴えている感じです。
それは違うと言う異論もあるでしょうが、ひとまず私の中での整理です。
偉そうなことを言っていますが、もちろん現実はそれほどうまく行きません。
むろん、異論は教えて欲しい。
凝り固まった頭では見えない視点はいっぱいあるはずです。
是非意見があれば教えてください。
何もしないのは後退でしかないですからね。
チームプレイのその先
チームプレイはあくまで組織側が決めたルールに則って行う行為です。
しかし、チームで活動していくと、そのチーム独特の一体感がでてきます。
その一体感はお互いの役割を尊重し合う事で発生します。
そこにチームワークが発生します。
そういうチームで作業をした経験は今でも忘れられません。
各々が何をすべきか分かっており、
お互いの役割を気遣え、
いざとなったら担える。
そういう体験をみんなにしてもらいたい。
^-^;)…今のチームが悪いって事じゃないですよ 。
そのときのチームが良すぎたのです。
コメント