経験年数をヒューマンスキルの実務適用年数として考えてみる

(「エンジニアの価値は経験年数じゃなくて開発手法とか能力に求められる」と考えたいので、ITサブコン系エンジニアでもやりたい仕事があるならやれる可能性を考えてみるのだ...)

ヒューマンスキルはオープン(セミオープン)な世界でトレーニングすることで「エンジニアの価値は経験年数じゃなくて開発手法とか能力に求められる」と考えたい。

テクニカルスキルに比べてトレーニングが難しいのがヒューマンスキルだろう。

(「目的指向」「読み手(聞き手)指向」アプローチのヒューマンスキル系のコンサルタントの曰くなのだが)
ヒューマンスキルは「フィードバックがないと身につきにくい」からだ。

これは、例えば、実際に書き手と読み手に分かれてドキュメントのレビューとフィードバックを繰り返すというワークですぐ実感できる。

今の世の中、オープンソースのコミュニティに関与してコミットしていたり、コミュニケーションしたり、ライトニングトークなどの機会は誰でもある。
アウトプットとフィードバックはオープンソースコミュニティやブログなどで可能になるだろう。
実際、オープンなコミュニティのほうが特定少数ではない分、フィードバックの量自体は多くなる可能性がある。

ただ、ITサブコン系エンジニアが相手にするのは、殆どの場合クローズ系だ。
クローズ系のドキュメンテーションスキルがないことはディスアドバンテージだといえるだろう。
オープンソースプロダクトでウォーターフォールモデルによる開発などまずないからだ。

だから、逆手にとることを考えよう。

「一人ウォーターフォールやってみた」っていうエントリ...

あえてやってみる。
仮に完全なウォーターフォールモデルの実務経験がないとしても、これはそれなりのフィードバックがあるだろう。

...だから、ヒューマンスキルはオープン(セミオープン)な世界でトレーニングすることで「エンジニアの価値は経験年数じゃなくて開発手法とか能力に求められる」と考えたい。