2021総括 ＜新しいことと変わらないこと＞

2021年4月にIT業界に舞い戻り「ほぼ1人情シス」を始めた。
Windows95+UNIXのころ情シスの経験はあるのだが、すっかり景色は変わっていて、日々雲の中でAzureとM365の森を探検している。

今年できるようになったことは、

• AzureADでのユーザ管理
• ノーコード・ローコードプログラミング
• PoweShellのスクリプト

昔から変わらず重要なことは、

• 現状を分析して課題を設定できる
• 業務フローを再構築できる
• なぜ、業務を合理化・効率化するのか考える

ことだ。

ロートル技術者でもこの辺りに需要がありそうだ。

一方で、
読書量と駄文のアウトプットが減った。
プログラムのアウトプットが増えたので仕方がない。
プログラムを書き始めると、プログラムのことで頭の中が一杯になる癖は若い頃と変わらない。

総括
クラウドの知識・技能は必須、その技術を活かす「考え方」は昔から変わらない。
図らずもクラウドの知識・技能が得られたのは良かった。

---

最近の投稿
【Yoshiのよしなしごと】【Yoshiのブログ】【よしなしごと】

物事が出来るようになるための思考法 ＜唯一の方法ではない＞

プログラミングというより物事が出来るようになる思考法　牛尾 剛　(2021/11/22)

牛尾剛氏は、

皮肉なことに「早く出来るように頑張る」ということが最終的な生産性を圧倒的に下げていたのだ。理解が十分でないから、努力しても空回りになるし、身につかないし、忘れやすくなるので頭にのこらないのだ。

とおっしゃる。

働いていると、知っているだけでは仕事に使えないことはわかってくるものだ。
理解(分かる)していてしかも仕事に使える(できる)状態になるのが理想だけど、時間がかかる。
例えばエンジニアとテクニシャン、技術と技能のように「分かる」と「できる」は分業できるのだが、今時は「わかって、できる」テクノロジストが求められる。

知っている状態からわかってできるようになるためには、理解してできるようになる、できるようになって理解するという2つのアプローチがある。
できると分かるは明確に分離しているわけではなく、できると分かるは並列に進むのだが、どちらかが優勢になるようだ。

「分かるが」優勢のアプローチは、できるようになるまで時間がかかる。
一方、「できる」が優勢のアプローチは、早く使えるようになる。

「できる」が優勢のアプローチは、できるようになると、わかることを止めてしまいがちだ。
一方で、「わかる」が優勢のアプローチは、高いレベルに達することができる。

牛尾剛氏は「できる」が優勢のアプローチだったのだろう。
経験則だが、牛尾剛氏に限らず「できる」が優勢のアプローチの人は多い。
わかる前にまず覚えるという日本の人材育成方法が少なからず影響しているのではないかと思う。

投稿に登場する、できる人たちは分かるが優勢のようだが、ビデオを何十回見るよりも、ざっくり理解したところで、やってみることで効率的に理解できることもあるだろう。と「できる」が優勢の凡人は考えてしまう。

よく考えると
物事が出来るようになるための唯一の方法はなくて、人それぞれではないかと思う。

牛尾剛氏の素晴らしいところは、自発的に、能力が高い人の行動を観察して、自分に足りないことを分析して、言語化し、それを補うための行動ができるところだ。

だから
物事ができるようになる普遍的な方法は、牛尾剛氏が発見した方法ではなく、発見までの行動そのものだろう。

ところで、前々職で若い人の研修に携わっていたときに分からなかったことは、若い人たちが知っているのにやろうとしないことだった。
彼らが投稿を読んだらどう行動するのだろうか？
周りのできる人の観察と自己分析から始めるのか、単純に牛尾剛氏の手法を真似るのか、興味がある。

---

【最近の投稿】【よしなしごと】【2019の投稿】【2018の投稿】【2017の投稿】【2016の投稿】【2015の投稿】

「仕事ができる」とはどういうことか？

「仕事ができる」とはどういうことか？  楠木　建　山口　周　株式会社 宝島社

「仕事ができる」は個別の職場、職種ではなんとなくイメージできるけれど、抽象的に捉えようとするとかなり難しい。

楠 木建氏の言う「仕事ができる」は「スキルがある」とは似て非なるもので、簡単に言えば「成果を出せる」ことらしい。
具体的には「頼りになる」「安心して任せられる」「この人ならなんとかしてくれる」、極論すると「この人じゃないとダメだ」と思わせる人らしい。

「仕事ができる」ためには「スキル」だけでなく「センス」が必要とおっしゃる。しかし、「センスを磨く」という言葉は知っているが、具体的な方法論が明文化できないように「センス」は言語化しにくい。

そこで、センスがある人を多く語ることで、捉えどころのない「センス」を理解しようという内容。
つまり「要するにこういうことだよな」という抽象化が重要だとおっしゃる。

他人や他業種の成功例を自分や自分の仕事にそのまま使えることはない。
だから、この本に登場する、著名な人の手法をそのままパクれない。
そもそも、経営者の問題と現場で働いている読者の問題は違うから、経営者の手法ではなく、考え方を自分の行動に反映できるまで抽象化しなくてはならない。

「〇〇技術」や「〇〇の方法」のようなハウツー本は、抽象化しなくても、自分の行動に反映することができる。
ところが「スキル」をいくら重ねても「センス」にはならない、「センス」は抽象化から得られる。

技能職の場合はどうだろうか？

若い頃は、抽象化ができなかったから、技術書ばかり読んでいた。
技能職の命は「スキル」だから仕事ができるためには「スキル」高めなければならない。
技術書は「スキル」を得るためのものだから、自分の仕事に使える。

「スキル」を高めようとすると具体化、先鋭化してくるから、抽象化が必要な「センス」とは相容れない。
ある程度「スキル」が高くなると、思うように高くならなくなってくる。
いわゆる伸び悩みだ。経験では、そこで一旦、抽象化すると、壁を破ることができる。

プログラムを作ることはできるけれど、特定の言語でしかプログラミンでできないと言う人がいる。
特定のプログラミング言語を扱う「スキル」は高いが、プログラミングの「センス」が無いいから、異なる言語の習得が困難なのだ。

プログラミング言語は流行りすたりがあるから、流行らないプログラミング言語の「スキル」はいくら高くても、市場価値は低い。

そこで、抽象化してプログラミング言語に依存しないプログラミングを理解すると、どのようなプログラミング言語でも比較的簡単に習得できるようになる。

具体化と抽象化を行きつ戻りつしながら「スキル」と「センス」両方を習得することで、仕事ができるようになるのだと思う。

---

最近の投稿
【Yoshiのよしなしごと】【雑誌・書籍】 【Yoshiのブログ】