作業プロセスを設計できないエンジニアのカップ麺は美味しくない
ここのところ、プロジェクトマネジメントの話題を振ると返ってくるのがプロジェクトでのプロセス設計ができないという愚痴なのです。現場のエンジニア、リーダになるようなエンジニアやなって欲しいエンジニアが悉く作業プロセスを設計できないのだそうです。
こうした愚痴もサンプル数１とか特定業種ばかりではなくて、製造業でもそうなんだそうです。超大手でも。
ちょっと昔を思い出して
よく思うことは、今できるエンジニアが少ないというのは、じゃあ、昔は多かったのかといえば、できる人たちはできていただろうと思い込んでいるだけじゃないかと思うのですよ。
昔といっても20年くらい前のことを思い出しているのですが、口を開けて待っているエンジニアがいれば、何をいっても文句が先に出てくるエンジニアもいたし、技術ネタばかり話しているエンジニアもいれば、エンジニアの仕事が好きなのかどうか怪しい人だってそこそこいたし。
記憶は美化するというけれど、あまり人の習性というか特性は変わらないのではないかと。
実体験からもそう思うので、昔はーというのは何いっているんだか、と。
どうしてプロセス設計ができるようになって欲しいのか
まあ、これに尽きます。じゃあ、どうなったらできる方のおじさんエンジニアたちは満足するのか、と。別に満足してもらわなくてもいいのですけれど。言われるエンジニアの立場になれば。
とは言え、何かができるようになるのはいいことです。武器を増やすことになるし、エンジニア的にはプロセス設計ができるようになって、実践できるということはリーダのロールが担える可能性が出てくるのですから。
プロセス設計で何ができるようになって欲しいのか
じゃあ何ができるようになるといいのかと。
例えで話をすると、カップラーメンを作る手順、そう、カップ入りのラーメンならカップの側面に書いてある手順をシステム開発の工程単位で作れるようになって欲しいのです。
どんなプロセス設計ができるようになって欲しいのか
例えのカップ麺を作る手順の話で進めます。カップ麺を作るのは要求があってその解決策、ソリューションとしてカップ麺を提供することを提案するわけです。受け入れられれば、商談成立です。
商談が成立したので履行しなければなりません。そこでカップ麺を実現する手順を確立しなければなりません。
既知の、経験知があれば、それに基づいて手順を構成すればいいのです。まとめるとこんな感じですね。
要求 ：お腹すいた
解決策：カップ麺でいかがでしょうか
手順 ：材料を用意する→お湯を沸かす→注ぐ→3分待つ→提供する
でも、こうした手順をスラスラと書き出す＝具体化できるのは経験があるからで、完成イメージを持っているからです。
カップ麺はお腹をいっぱいできる＝要求を満たすことができることを知っている
逆に言えば、知らないことは具現化できないのです。
まあ、そうはいっても、上記の手順をシステム開発の工程内の作業プロセスとして表現できれば、それはそれで、ベースのプロセスとしてはいいのです。及第点はあげられるかと。
実現したい完成イメージを持てる＝手順を知っている
ただ、カップ麺は割と手順が標準化されているので－－割とと書いたのは、かやくやスープの素を入れるタイミングがまちまちであることや待つ時間が3−5分といくつかの種類があるので、3分だと思い込んでいると固い麺で出来上がることになってそれを検査もしないで給仕すると要求を出した人からクレームになるわけです。
手順を知っている＝材料や要求の性質から調整できる
つまり、標準的だと思っている作業プロセスは、プロジェクトのソリューションでテラーリングが必要ですよ、ということです。
それはさておき、まずはカップ麺の作り方と同じレベルで作業プロセスを作れるエンジニアになって欲しいのです。
