実装者を職人にするために

COBOL全盛の時代は,1つのメーカによる統一的な「閉じた」アーキテクチャだったために,ロックされたベンダーが提供する技術情報を身に付けるだけで,多くの案件をこなすことができた。それに,COBOLをやったことのある人ならわかると思うが,OSやデータベースなどによって提供されるサービス(トランザクションモニタやロギングなど)は非常に手厚く,しかも個々のプログラムで全く意識する必要はなかった。1プログラマから考えたら,COBOL全盛時代の方が現在よりも,よっぽどEoDの恩恵に預かることができていたと言えるだろう。 しかし,オープン化の波が押し寄せ,異ベンダー,異機種,異プロトコルは当たり前となり,日々システムは複雑になっていく。それに伴って,当然アーキテクチャも複雑になり,システム全体を考えた場合の必要とされる技術的な知識量も増加しているのが現実である。つまり,システムを構築するために組閣されるプロジェクトのメンバーの中で,必要となる技術の全てを把握できる人間は,非常に限られる。確実に5%は下回るだろう。 その5%の人間が何を考えるかというと,メンバーの役割とそれに対して必要な技術的知識を可能な限り絞ってあげること,である。つまり,実装メンバー全員について,個々人が何らかの技術の専門となってもらうのである。「画面よりな技術だけ」とか,「データベースに近い知識」とかが,分野として一般的だろう。前者であれば,JSPが書けて,HTMLがわかって,JavaBeansのプロパティのセットとゲットがわかる程度で何とかなる。後者であれば,SQLが書けて,O/Rマッピングツールの仕組みと実装方法,そしてトランザクション境界の決め方が理解できていれば十分である。 このように必要となる技術的知識を制限することで,実装開始時点での学習時間および技術に慣れた後の量産効率は,もちろん全技術的知識を対象とした場合に比べて,有効な結果をもたらす。 これを実現するために,アーキテクトはシステムを2層,3層にレイヤ分割したりして,役割と必要技術を狭めていく。それによって,1機能を満たすためには2,3人が携わるようになるために,個々人の成果物の結合が問題となる。しかし,ファクトリパターンやDIなどを駆使することで,インタフェースに対するプログラミングを徹底することが可能となる。結果として,インタフェースによる契約が取り交わされることになり,結合時のリスクを低く押さえられる。さらに,実装メンバー個人個人が持つ技量によって,適切な配置も可能となる。システムの構築要素を領域分割した際には,それらは均等ではなく,求められる技術的知識の量にムラが出てくる。そのムラに応じて担当メンバーをうまく配置できることも強みになる。 しかし,世の中そううまくいかない。専門職的な性質が強くなればなるほど,1機能の実装に必要な人間の数は多くなる。よって,プロジェクトの管理をする側にとっては,「1機能の実装を1人割り当てて,○月○日〜○月○日までで作業する」といった単純かつ明瞭な進捗管理ができなくなる。アーキテクトが分割した領域の単位で進捗管理をする必要が出てくる。 さらに,1機能1人という割り当てをした瞬間に,実装メンバー全員に対して「システム全体で必要となる全ての技術的知識を身に付けろ」という指令を下したことになる。実装者のレベルは,それこそ千差万別だ。なのに,均一に全員「優等生になれ」といったところで,それは現実的ではない。仮に全員が優等生になれたとしても,その頃にはプロジェクトの納期はすぐそこまで来ているだろう。 システムを領域分割し,それぞれに専門性を与えて,最適な実装者を当てることは,アーキテクトが実施可能。そして,実装者はそれぞれの領域の中で実力を発揮することができ,量産効率もアップ可能。 そして,残る問題は「管理側が管理できない」あるいは「細分化された管理を拒否する」ことが多いという点に集約される。そう,複雑な技術要素を使って実装を進めるための管理手法または管理者のレベルが,現場レベルでは全く向上してきていないのではないか,という感覚を自分は非常に強く持っている。 この原因としては,明らかに管理対象項目が増加すること,1機能という単位が崩れるために1機能あたりの進捗が曖昧になりがちなこと,そして何よりも,アーキテクチャを理解しなければいけないこと,が大きなウェイトを占めるだろう。技術的な理解がある程度なければ,何を管理しているのかさえ,見失ってしまうはず。技術的な理解があってこそのタスクの組み換えや見積りなはずなのだが,近年技術的に弱い人間が管理のみをこなすような状態が多く,そのためにどうしても現場との乖離が発生している。結局正確な残工数を図ることすらできずに,手遅れな状況に気がつかずに時間が過ぎていくことになってしまう。 アーキテクトは技術的な面と,実装者の属人的な面,そして残工数の見通しについての手法がある程度はっきり想像することができる。それをうまく管理者に伝え,そして管理者と現場の状況の差を限りなく0に縮めていくための行動も,プロジェクトをゴールに導くために必要になる。そのためにも,まずはアーキテクトは「ソフトウェアのベースを作る仕事」という偏った認識を持つ管理者を補正し,正しい進捗管理方法も技術的なベースに基づく一つの成果物なんだということを理解してもらって,それを実施するために管理者自身も実装者と同じ学習曲線を辿ってもらえるようにしなければならないだろう。 はぁ,アーキテクトの仕事は,何て広範囲なんだろう。。。

このエントリーをはてなブックマークに追加

関連記事

スマートスピーカーはもう終わったデバイス?

QMK FirmwareとRaspberry Pi PicoでSPLIT_USB_DETECTを使わない方法

40%キーボードに慣れるためにやったこと

Lunakey PicoでQMK Firmwareを動かしてみました

Googleアシスタント向け会話型アクションが1年後にシャットダウンされます