システムエンジニアならパターン作ろう

学生さんがシステムエンジニアの仕事をテーマにして作ったパターンを試してみる機会があったので「どうやってこのパターンを作ったの」と聞いてみたんですね。


まず、どう作ったかを「訊こう」と思った自分に「おっ」と驚きましたが。いつもなら「そうなんだー」でスルーしそうなところを、学生さんのやっていることのプロセスに興味を保ちづけれたことに。


そんなことを内心思ったのは、方法論的にどうパターンを作っているかを知流ことができれば、自分が経験的にやっているやり方と違う手法を知ることができるから、と閃いたから。


その答えは「インタビューをして作った」と。そっか、そうだよね。システム開発の業務上の課題を設定して、体系化された方法がないからモデルを作って、そのモデルを検証する。学生さんだから、多分に論文を書かないといけないだろうから、そうすると、そうするのだろうねぇ。実務をインタビューして、先生の指導してもらって、とも言われていましたが。


その、作ったかを聞いたとき、そのとき思ったのは「じゃあ仕事の当事者のシステムエンジニアだって作れるじゃん」と思ったんですね。


いやですね、システムエンジニアに限らずお仕事とかは実務から汎化できるのですが、ことシステムエンジニアのお仕事についてはプロジェクトをいくつも経験するので複数の実務経験から共通要素を抽出することができる環境にあるんですよ。


でも、学生さんなら課題と思うところが日常になりすぎてしまっているために気づかないのかもしれない。プロジェクトにアサインされる形態だと望んだプロジェクト=仕事ではないわけで、そうした主体性がないところでアサインされた仕事に対する自らの関心を高めることをしている人は少ないだろうから。仕事だから割り切ってやる。でも、自分で楽しみを見つけることはしないから学生さんが見つけるようなシステム開発や維持管理の中にある普通のアクティビティがパターンになるとは気がつかない。


もったいないですね。プロジェクトが終わるたびに新しいプロジェクトという経験を積むことができる。それなのに、その経験した積み重ねを言葉に変え、知識に変えることをしないのだから。


システム開発なら、プロジェクト完了で1と数える。維持管理なら年次処理で1と数える。少なくとも1年に1回は経験を積み、体験に基づいた経験知に変換する機会を持っている。それを言葉でもパターンでも書き出すことで知に変え、それから共通項を見出すことで形式知に変換することができる。


だったら、それをやらない手はないじゃないですか。


例えば、プロジェクトマネージャの候補を選定するパターンを作るとします。5つの項目を書けるカードを用意し、それに普段やっていて汎化したい課題を小さくして書いていく。このとき、テーマをロール、マネージャ、リーダ、メンバのそれぞれの達がで考えることとするとカードをたくさん書き出すことができます。

タイトル プロジェクトマネージャ候補の選定
概要 次世代のプロジェクトマネージャを選定する
どういうときに ビジネースプランでプロジェクトマネージャを増員させる必要が出てきた
どういう問題に対し ビジネスを拡大する上でプロジェクトを増やす必要があり、プロジェクトマネージャを増やさないと案件のサイズを大きくせざるを得ないため
解決策 コミュニケーションスキル、作業を完了させることに対して明確な意思が強い特性を持っている中堅と若手のバンドから候補を絞る


こんな感じで課題と思っていることや普段、無理だとか面倒だと思っている仕事があればパターンを作る対象になるんです。こういったパターンを25枚くらい書くといいですよ。