作業の中心にエンジニアを置くための情報と技術のあり方

人は起きて欲しくないことが起きるまでは、たとえそれが起きた時にどうなるか類似の経験をしていても見向きもしないし、どちらかと言えば思い出したくもないような経験であればあるほど自分の視界からそれを遠ざけるものです。

システム開発でのそれはトラブルがそれにあたります。

情報の流れ

ウォーターフォール型のシステム開発を採用している場合、システム開発に必要な情報は、チームの組織構造の上位層から下位層に流れます。

トップマネジメント層からプロジェクトマネージャへ、顧客からプロジェクトマネージャへ、プロジェクトマネージャからアーキテクトへ、プロジェクトマネージャからSEリーダへ。SEリーダからエンジニアへ。

プロジェクトの継続を左右する重要なことであればそうした情報の流れは強固になります。

ところでプロジェクトチームでシステム開発の作業プロセスの担い手は誰でしょう。

誰もが間違いなく答えられるとおり、プロジェクトチームでの作業プロセスの担い手はエンジニアです。トップ層であるトップマネジメントでもプロジェクトマネージャでもありません。

プロジェクトチームのエンジニアが作業を遅滞なく進めなければプロジェクトは緩やかにブレーキを踏んだ状態でアクセルを踏むことになり、知らず識らずのうちに取り戻せない負債を抱え込むことになります。

では、エンジニアの作業を滞らせることは何か。

それは、システム開発上で要件を実現するために要件を具体化するために必要な情報です。

エンジニアは無形の要件を情報の加工、つまり、情報の詳細化を繰り返し行うことでコードに変換できるサイズまで分解し、コードに組み替えて今度は、無形のシステムとして再構成を行います。

作業の担い手であるエンジニアは、情報がなければ何も作り出すことはできません。

冒頭のように、システム開発でトラブルが起きてから情報共有をエンジニア全員にし始めることが多いのは、作業の担い手と情報を誰が必要としているかという組織における情報を必要とする処理プロセスを理解できていないと見ることができます。

これは、階層型組織構造を取る組織においても同じことです。

トラぶれば、朝会や全体ミーティングを頻繁に開き、エンジニアの作業時間を奪ってまでプロジェクトチーム全体を巻き込んで情報共有をし始めます。

これは何のために行なっているのか。

作業の担い手に、必要な情報を確実に共有するために行なっているのです。

組織をフラットにするという考え方があります。これは中間管理層を減らすことで情報共有と意思決定の速度を上げるというものです。

これと同じようにプロジェクトチームの中でも情報についてはチームの中でフラット化をすることが平時からの情報共有を確実にオペレーションするために必要な組織構造のあり方となるのです。

つまり、プロジェクトチーム内のロールは階層を示すものではなく、これまでの過去のエントリでも繰り返し述べて来たとおり、ロールは担う役割の識別子でしかないとう考え方を実現しなければならないということです。

プロジェクトチーム内の情報のフラット化による共有は、全体で共有する仕組みを作り、継続して共有を続けなければどうしようもありません。

プロジェクトの中での方向性や今後の計画については集合形式の情報共有による1:Nの拡散で実現できるテーマもありますが、技術の共有についてはそれは成り立ちません。

聞いているだけでは技術は身につきません。

そこで出てくるのがモブプログラミングです。チーム全員でそれを行うことで技術の共有を一度に行うことができる多分ただ一つの方法です。

情報を平時からフラット化したチームの組織構造の中で共有し、作業の担い手であるエンジニアがシステム化するための適用技術をモブプログラミングにより技術情報の共有を図ることを実現できるからこそ、ここ1年でモブプログラミングが脚光を浴びつつあるのです。