PR

 「自分が担当している範囲に関してはいつも完璧にやっているのに、別のチームとか顧客がちゃんと仕事してくれないから、自分の仕事まで進められなくなったり、やり直しになったりすることが多くて、腹が立つ。こんな仕事は割に合わない。」ITプロフェッショナルの方からこのような話を耳にすることがあります。

 せっかくご自身の担当領域をきちんと進めているのに、別の部分との接点や関係からうまくいかなくなるということで、悔しい思いをされているご様子が伝わってきます。いつもそうだということであればなおさら、お腹立ちでもあるのでしょうね。

分業と接合点

 IT業界に限らず、サービスや商品がエンドユーザーに届くまで、一人だけで完結する仕事はほとんど無く、分業し各々の担当のメンバーやチームで仕事が進められていますよね。その際に、様々な理由から担当の部分を当初の予定どおりにできないとか、各々が担当する内容が共有されていないとか、分業した時点で隙間に抜け落ちている事柄があるといったこともありそうです。

 スタート時点で全貌をくまなく把握して隙間なく分業し、各々が担当領域を完璧にこなすような仕組みを導入することによって、円滑に仕事が進み全体が予定通りに完成するといいでしょうし、実際にそうして常にうまくいっているという方もおられるかもしれませんね。しかし一方で、そのようにした上でもやはり、技術的な課題や顧客の要請から、その都度、担当者やチームの間を調整する機能が必要なケースもあるように思われます。

「組み合わせ」と「擦り合わせ」

 ものづくりの考え方に、モジュラー(組み合わせ)・アーキテクチャとインテグラル(擦り合わせ)・アーキテクチャというのがあることをご存知の方も多いことでしょう(藤本隆宏さんなど)。モジュラー型は、機能と部品が単純に1対1で、汎用部品だけで簡単に組み立てられるパソコンなどがそうであり、インテグラル型は、乗用車に代表されるように、様々な部品ごとにその機能を相互に調整しながらつくりあげる場合をいうのだそうです。(超小型パソコンは、中身のレイアウトの複雑さから汎用部品では駄目でインテグラル型とされます。)このことを初めて知ったとき、例えばシステム開発は、どちらに近いかしら?と考えました。

 標準化・マニュアル化が徹底され、各担当が足並みを揃えてやっていくようなファクトリー型の開発はモジュラー型、マルチベンダで常に刷新される機能を持ち寄り、また顧客固有の要望に合わせた機能を実現しようとする開発は、インテグラル型の要素が大きいように、わたくしには思われました。

 技術的な課題や顧客の要請とも絡んで、他のチームの作業工程や出来具合が、自分のチームの仕事と影響しあうというのは、インテグラル型の特徴だとしますと、分業体制のなかで、担当者間やチーム間の微妙な調整や擦り合わせをすることは、不可欠と思われます。「担当のチームがちゃんとやってくれないから」とか「これは、アチラさんの担当だから」などと、待っていたり放置したりしますと、スケジュール面でも品質面でも、自分たちにとっても開発全体としても、いい方向に進みそうにありません。

モジュールとモジュールの間

 相手が単にサボっているというのは論外としても、自分たちの仕事が進み全体として開発がうまくいくために、適切な解決を図る必要がありますよね。ひとり憤慨したり疲れたりしているよりも、「ここはどうなっていますか」「こうしてもらえるとウチは助かるんですけど」といった働きかけや、ときには「こうしてみたらいかがですか」と相手のチームに入り込むなど、分業体制の間を繋ぎ合わせるような行動が重要ではないかと思います。

 併せて、それに伴って生じる費用のことも含めた議論も必要になりますよね。何にしても動けば費用がかかるからと、最低限の責任範囲以外には関わらないというのでは、協働者にも顧客にも不誠実ですし、長期的には信頼を損なうものと思われます。

 大袈裟にアーキテクチャなど持ち出さなくても、自分の仕事をやりやすいように相手にも働きかけたほうがいいのでは、という単純な話でもあるのですけどね。システム開発の仕事はすべからくモジュラー型だ(その用語を知らなくても)、つまり各パートと機能はぴたっと対応するはずで微妙な調整など不要なはず、という思いがどこかにあると、他のメンバーやチームに対して無意味に腹が立ったり、自ら相手へ働きかける行動が削がれたりするような気がして、そんな話しもしてみました。

 (組織能力の視点から、米国と中国はモジュラー型で競合し、日本はインテグラル型で強みを発揮するともいわれていますよね。システム開発においてはどうか、個人的に関心を寄せています)

 それでは、今日もイキイキ☆お元気に。