設計と製造の工程を分離することと自ら選ぶキャリアは別の話

on


余り、他のブログを引用して書くことはないのだけれど、これまで書いてきたことと重なる部分もあるのでちょっとだけ書こうと思う。

優れた仕様を決定するために必要なこと - GoTheDistance
ソフトウェア設計とは何か 〜 設計にはプログラミング経験が必要か否か | Social Change!


設計と製造の分界点について
大規模なシステムの中には、下表のような開発工程を踏むものがある。

項番 工程名称 説明
1 要件定義 業務要件を整理し業務仕様とシステム仕様を定義する
2 基本設計 システム方式(機能仕様と非機能仕様)を設計する
3 詳細設計 実現仕様を設計する
4 プログラム設計 プログラム仕様を設計する
5 製造 コーディングする
6 単体テスト 単体モジュール機能の動作を確認する
7 結合テスト インタフェースの観点で動作を確認する
8 総合テスト システム運用の観点で機能をテストする
9 受入テスト 業務運用の観点で機能をテストする

端的に言えば、設計というアクティビティは項番4まで、です。それ以上でも以下でもない。工程は、入力と変換と出力の行為のセットであるから、項番5のコーディングをしたいのであれば、コーディングできるまでの情報を出力する工程を探せばよいのです。だから、項番4なのです。


ただ、このような工程を踏むことは、投入するコストが掛かり過ぎることと、顧客がより早くビジネス価値を得たいという要求からリーンだったり、アジャイルのスクラムのようなスピード感のある開発方法を選択する方にシフトし始めたことで、エンジニア自身が体感する機会が少なくなったために、設計と製造の工程の界面を意識しなくなったことも一因にあるのではないか、と思うのです。


設計と製造を分離して考える必要性
ウォーターフォールとアジャイル、設計と製造、プロジェクトマネージャとプログラマ、なぜ、対立項で語ろうとするのか、その気持ちがわかりません。


顧客が望む業務を肩代わりするシステムを実現することがシステムエンジニアの存在理由であると思うし、顧客とシステムエンジニアのゴールも、設計や製造の役割を負うシステムエンジニアもゴールは同じです。


そうであるなら、設計はここまで、とか、言われても、「あぁ、そうですか。お宅のプロジェクトではそうなんですね。」と応える以上のリアクションはありません。そんなことより、−いや工程＝開発プロセスを決めることはDoneを決めることでもあるので大切です−、少しでも早く顧客に臨む価値を届けましょうよ、と言いたい。



設計と製造の工程を分離することと自ら選ぶキャリアは別の話
設計と製造の工程を分解するプロジェクトがあるなら、それはそのプロジェクト固有の事情があるからそのような開発手法を取っているだけであって、誰もが分かっているように、すべてのプロジェクトがそういった開発手法を取るわけではありません。


プロジェクトは、ウォーターフォールでもアジャイルでも役割があるもので、それは、プロジェクトを成立させるための必要な分掌の現れです。その役割をするエンジニアがいなければ、プロジェクトは想定し、計画したように進まないのですから、その役割を欠かすことはできません。


エンジニアが設計と製造の分離を嘆くのであれば、嘆くエンジニア自身が自分でキャリアを描き、そのキャリアを実現するために能動的に動いていないことが原因です。ただコードをエクセレントに書き出したいのであれば、製造の工程を黙々とやっていればいいのでしょうが、それではグローバル化が進む中、低価格のコンペティタに仕事を奪われるだけです。


若しくは、製造を担うエンジニアが仕様を設計するために顧客と話すことを見聞きする機会があって、仕様を設計するエンジニアの役割に魅力を感じ、それを自分がやりたいと憧れたのかもしれません。このケースでも、エンジニアは憧れるだけでは、その機会を手に入れることはできないもので、憧れを実現したいのであれば、自立して自分のキャリアを真剣に考え、行動に移さなければそれは実現しない夢もの語りで終わってしまうでしょう。


そう考えるとするならば、自分のキャリアをどうしていくか考えなくてはなりません。その考えた結果が、システム仕様を設計する役割まで広げたいなら、それに必要なスキルを今コーディングの作業をしながら横で学ぶことが必要です。その機会を得るために、次に必要になるスキルを机上で学び、実践する場を与えられないなら、エア設計をしたり、サンデー設計者をするなど、実践を自己研鑽として踏むのです。


経験のないエンジニアがその役割を担えるか
製造工程を経験していないエンジニアがシステムの仕様を設計することができるかどうか。それは今も動いているだろうシステムの多くは、そういった役割の分掌によって成立してきたのであるからなくなりはしないだろう、と思います。ただ、システム開発は、そのライフサイクルの波があって、その波がある程度の規模が維持されるなら生きていけるでしょう。しかし、ダウンサイジングやスマートアプリのようなアプリケーションのイノベーションが起きるたびに、選択できるシステム構成の手法が増えることから、パイが小さくなっているのも事実です。


そう考えるのであれば、システムの仕様を決定するだけのシステムエンジニアの生きる道は細るばかりで、その中を聞き残り指名されるための価値を上げ続ける必要があると思うのです。それは、他の役割を担うスキルを広げることとやることは同じであって、そう考え、行動するか否かはそのエンジニアの考えるキャリアパスに依るのだと思うのです。


結局、エンジニアになったときから、そのエンジニアのターニングポイントごとに自分のキャリアパスを考え、行動に移していくことを考えた方がいいのではないか、と思うのです。