6.5 新規メンバへの情報共有方法
業務まで踏み込んでクライアントのWeb構築を行い、クライアントの業務に活用され続けるように、安定してシステムが運用されるようにシステムの運用も請け負っていくためには、Webの新規構築時のメンバだけではなく、継続的に、それぞれの役割/職種に新規メンバを加えていく必要があります。対象のWebがある程度以上の規模のものになってくると、ドキュメントは整備されていたとしても、そのドキュメントのボリュームも大きなものになりますので、なかなかドキュメントを読んでWebを操作してみて全体像を自分で把握してもらうことを期待するのは難しくなってきます。
a. Webディレクタ
Webディレクタとして新しいメンバが機能するようにもっていくためには、当該Webシステムの全体像を把握してもらう必要があります。開発案件のWBSを作成するにあたり、どのような工程がこの案件では必要となり、各工程ではどの程度の期間が必要であるのか、誰かが教えてくれるのであれば、当該システムの全体像を把握していなくてもWBSを作成することはできますが、そのような場合はWBSを作成している人はディレクションを行っているわけではなくWBSの作成というサポート業務を行っているにすぎません。ディレクションが行えるようになるためにはシステムの全体像を把握する必要があります。
また、新規機能を追加するにあたり、既存システムの各種の既存機能を利用して、既存機能との整合性も検討した上で要件定義や設計を行うためには、もちろんシステム全体を把握しておく必要がありますが、運用が始まってから加わってもらった新メンバに全体像を把握してもらうことは、システム規模が大きくなるにつれて難しくなってきます。
システムの全体像を把握してもらう手順を考えるにあたり、Webディレクタにはその業務内容的に有利な面があります。ある新規機能を追加する開発案件のディレクションを行うのであれば、その開発に関係する部分の既存システム/既存機能を把握しておけば、その開発の設計はできる面があるところです。比較的小規模な開発案件があるのであれば、そのディレクション/プロジェクトマネジメントから担当してもらうのは、新規のWebディレクタに加わってもらった際のスムーズな導入の仕方のひとつといえるかと思います。
また、進行中の開発案件がある場合には、そのテスト/動作検証に新メンバを加えてテスト打鍵してもらうのは、システム全体の把握のためには必須のプロセスといえるかもしれません。やはりWebは実際にアクセスして操作してみるのがどのような画面がありどのような操作を行うことができて、どのような仕様となっているのかを把握するのに早いやりかたです。
b. 運用担当エンジニア
運用担当エンジニアは、当該Webシステムの実装/プログラムについて、全体像を把握している必要がありますので、当該Webシステムの開発にたずさわっているチームメンバの中からピックアップするか、すでに全体像を把握している先輩運用担当エンジニアとともにある期間いっしょに業務を行うことにより全体像を把握していく必要があります。ある期間とはシステム規模やそのシステムの複雑さなどにもよりますが、一か月や二カ月のような長さではなく半年や1年は必要となる認識は必要かと思います。運用担当エンジニアは、画面操作レベルの要件や仕様だけでなく、どのように実装されていてどのような仕組みで動いているか、具体的な実装・設定を把握している必要がありますので、プログラム/実装について教えてもらえる存在が必要であり、先輩運用担当エンジニアに教えてもらう期間を設定するのが基本的な引継ぎとなると思います。
また、運用担当エンジニアは技術者ではないクライアントからの問い合わせなどにも対応する必要がありますので、要件レベルの把握も必要です。要件レベルの把握には、Webディレクタの場合と同様に動作検証/テスト打鍵に加わってもらうのはドキュメントを読んでもらうことと合わせて有効な方法です。
同じように新規の機能追加がされる場合には、すでにシステム全体を把握している運用担当エンジニアにも合わせてテスト打鍵に加わってもらうことは、新規の機能についてその既存運用担当エンジニアに把握してもらうのに有効です。特に、既存機能とは仕組みレベルから異なる新規機能を追加するようなときには、既存運用担当エンジニアがその新規機能部分はよくわからないということにならないように、テスト打鍵メンバに加えるのは必須と考えておくとよいと思います。
c. 大規模システムへの新規メンバの加入
ある程度の規模までのシステムの場合には、導入時に自然に把握が進む業務を組み合わせて身近なメンバのサポートなどもあれば、ある期間を経ればシステム全体の把握までできていきますが、大規模なWebシステムの場合には、新規メンバが1年経過しても担当した機能部分は把握しているものの、参画前からの既存機能についてはテスト打鍵して把握できるような表面的なところ以上は把握できないままでいるということは珍しくありません。どの程度の期間でどのような規模のWebシステムに対して全体を把握できるようになるのかはいろいろな要因で変化しますが、主に下記のような要因が関係してくるかと思います。
p. 新規メンバの能力
q. 新規メンバの当該Webへのコミットの程度および仕事に対しての取り組む姿勢
r. 整備されているドキュメントの種類
s. サポート体制
t. システムの規模/複雑さ
p. はある意味明確ですが、q.およびpとqの組み合わせについてすこし説明が必要かと思います。大規模なWebシステムの既存機能を把握するのはかなりレベルの高い能力を必要とします。また大規模なWebシステムの全体を把握するのは一か月程度では難しく、この種の作業にこのような多大な労力をかけることは、その作業に対してきちんと業務として認められて十分な給与/支払いがされたとしても、そのようなレベルの高い人間がやりたいと考える業務ではない面があります。既存のシステムの対応よりも新規のシステム開発を好みますし、一システムの既存機能の把握に多大な労力をかけることよりも、最新の技術を適用するシステムを取り扱うことを好みます。あるいは一般的な最新技術情報をもとにコンサルティングを行うことを志向する人が多いと思います。その中でも、クライアントに寄り添いクライアントやユーザが求めているものをかなえてあげて喜んでもらうことに仕事の喜びを見出すようなタイプの人であれば、自然に対象システムの把握を自律的に行うと思います。そうしないと正しい判断ができず、自分が下したジャッジが正しいと判断もできないからです。別の言い方をすると仕事に対しての姿勢の問題ともいえます。大規模なシステムを運用するチームの中心的な役割を担うメンバを新規に選ぶ場合にはひとつのポイントとなる観点と思います。
rはこれまでの説明の中にも含まれていた内容でもありますが、要件定義書とシステム設計書の二段階のドキュメントだけだと大規模なシステムを把握するのには難しくなってくる面があります。そのときに、処理シーケンス図や状態遷移図のような各種補足資料もあれば、システムの仕組みについての理解も容易になりますし、具体的な問題に対応している際にも、問題箇所を絞り込むための助けになったりします。
sは困ったときにまわりが助けてくれたり、気軽に聞くことができるとよいということで、tはもちろんシステムの規模が大きくなれば全体を把握するのは難易度が高くなるということですが、システムの複雑さといったときに、ふたつの側面での複雑さがあることは認識しておくとよいひとつのポイントです。もちろんシステムの処理としての複雑さ、実装面での複雑さがそのひとつですが、もうひとつは「業務」レベルでの複雑さです。業務としてシステムが想定しているある型に沿って行うことをマストとはせずに、状況に対応してさまざまな使われ方がされたり、例外的な使われ方をすることを許容する場合には、当該Webシステムの運用を担当する人間に求められる能力・理解の程度が高いものになるので注意が必要です。
大規模なシステムを長期的に運用していくためには、基本的には運用を担当するメンバが短期に入れ替わらないで、ある程度以上の期間は継続して働いてもらえることが望ましいので、そのための会社や職場としての働きやすさや当該Webシステム・サービスの世間的な認知度や社会的な意義などもある方が、人が定着して運用品質面でも有利に働くのですが、下記について最後にまとめますと以下のようになるかと思います。
「ある程度の頻度では人は入れ替わる中でどのような新規メンバを入れてどのような運用体制を構築・維持していくのがよいのか」
システムが大規模になればなるほど、ひとりの人間が全体を詳細に把握するのは困難になります。従って、基本的には、より多くの人間で役割分担を行って、しかも各メンバの役割の重複部分を大きくしていくことが必要になります。役割分担して各メンバが担当する領域が細かくなるほど、隣接領域との関連が見えにくくなりますので関連するメンバで相談するにあたっても、お互いが隣接領域のこともある程度は把握できていないとなかなか話がかみ合いません。この隣接領域との重複部分を大きくするというのは、同じレイヤの各サブシステムごとの担当間という横での隣接領域での話だけでなく、プログラムを書くところからシステム設計を行い全体の要件をクライアントと調整するレイヤまでの上下のレイヤ間でも同様にいえます。
実績もあり能力もある人間を新規メンバとして中心的な役割として参画してもらう場合には、1年や2年はシステムの詳細は把握できない状態でその新規メンバが機能できる必要がありますので、その人間の下にシステムの詳細を把握しているメンバがいることが必要になります。システムのことも基本的にはわかっていてクライアントと業務面も含めて調整を行うことのできる人間がいないと運用面がまわっていかないWebシステムの場合には、そのポジションを担ってきたメンバがいなくなる場合には、新規のメンバをその役割に補充する必要があります。
技術的には優秀で論理的な思考能力にも優れてはいて当該Webシステムのことも把握しているメンバがいても、経理などの業務面のことをクライアントにヒアリングして詰めていくようなことはやりたいと考えないタイプの人間もいますので、そのような場合には外部から新規メンバをアサインする必要があります。しかし、そのような場合にシステムの詳細を把握している上記のようなメンバがいて聞けばすぐに答えがかえってくるのであればよいのですが、一部のシステムについてだけ把握しているメンバしかいなかったり、プログラム実装レベルは把握しているもの業務レベルでの相談をしても話がかみ合わなかったりすると新規のメンバがいちいちシステムの詳細まで調べて確認しないかぎり判断できなくなるので、システムの運用・開発が動かなくなってしまうので注意が必要です。
また、なんらかの経緯により当該Webシステムを中心的に担っている人間がシステムの詳細まで把握していて、そのシステムの詳細まで把握していることにより日々の業務もまわっているような体制である場合もあるかと思います。このような体制は長期的にはチームメンバを増やして各担当業務領域の重なり具合も増やした体制にできるとよいわけですが、短期的な対応策のひとつとしては、若くて潜在能力のある人間を補助的な業務から入ってもらって、小規模の開発のディレクションなどもしてもらい、順次中心的な役割をになってもらうことを目指すというのも新規メンバの補充のひとつのやり方です。
体制の構築・維持ということでは、あるスペックの人材を採用・補充しようとしてもなかなか見つからないということはよくあることですので、複数の人材採用・人材登用の進め方を併用しておくことも必須です。
Webディレクタとして次のステップをさがしている方たちへ
これからのWeb構築・Webディレクションとして、業務にまで踏み込んでディレクション/プロデュースすること、それが近年のバズワードであるDXにもつながること、そしてWebの進化とともにWeb構築の各種ツール/サービスやSaaSが広がってきていることにしたがって、業務とシステムの両面からWeb構築・運用していく人間が求められていくこと、そのためにどのような知識や能力を身に着けていくとよいかについて解説している「マガジン」です。