dotkuwaの日記: ソフトウェア開発に於いて「技能」とは何か 3
ソフトウェア開発を仕事とする場合、そうではない場合と異なり、
「技能」が必要になると思います。
ただし「技能」のみ(ワーカーと蔑まれる)で仕事と出来る訳では
当然無く、十全な知識が前提です。
---------------------
自分は自転車で遠乗りをするのが(「ぽたぽた」というやつ?)趣味で
すが、自転車で街乗りをする際にも、「技能」が要ると思います。
それは、
・大きな音から、即危険としない。
・すべての交錯点であらかじめ確認し、対処する。
のを、頭で判断する前にやり遂げる事だと(自分は)思います。
前者は、
・大きな音は非常に高い確率で「危険」なのは事実だが、大きな音から
は、自分が危険に近づいているのか遠ざかっているのか判断できない
為、即視認をし、その後、対処すべき。
だからで、
後者は、
・自転車は音楽の技能や、陶芸の技能より、緩急がきつい(大抵は安全な
楽しいサイクリングだが、交錯点に差し掛かると、途端に命のやり取り
になる)。
からです。
昔、クロスバイクの納車後、ワクワクしながら家に帰っていた所、走って
いた道の新道と旧道の別れのY字路で、後ろから来た自転車にY字路の真ん中の
コンクリート柱にこすり付けられる様に追い越しをされた事が有ります。
前に原付バイクで、246と小田原のY字路で同じ目に合っていたので、
急ブレーキをかけ、安全地帯と同化して何を逃れましたが、本当に晴天の
(その日は晴れでした)霹靂でした。
#いくら、かわいい折り畳みからロードに乗り換え、峠を登れる脚力を身に
#つけても、それが即、街乗りで何百キロも走れる技能にはつながらない
#様にも思えます。
#早い自転車はバイクの上位免許でもいいと思ってなりません。
後、この「技能」は自転車の分野では最強でも、別の分野では百発百中
ドツボにハマる「間抜けな癖」となるだろうという事も申し添えます。
---------------------
ひるがえって、ソフトウェア開発の「技能」ですが、
やはり、自転車と同じで、
・緩急がきつい
・危険が見えない・見えても分からない
面が有り、
・その危険を察知し、乗り越える
ことと第一に関連していると思います。そして、その危険を乗り越えれば、
後は楽しいプログラミングライフしか残らないと思います。
では危険とは何でしょうか? 第一には、
・元データを消す
事だと思います。これは出会いがしらノーブレーキ並みの危険だと
思います。ただし、
・元データを消すかどうか、見えません。
これを見る為にはソフト・ハードの一人前の知識が要ると思いますし、それを
肌で得心している必要が有ります。兎に角、何が何でも、交錯点の前で踏みと
どまらないといけません。
知識は(発達障害の方以外の)すべての方が身に着ける事が出来るとは
思いますが、「肌で得心」出来るかどうかは「技能」のレベルだと思います。
誰にでも出来るとは(自分には)思えません。
もちろん、ソフトウェア開発で有利な「技能」が、別の分野では百発百中ドツボに
ハマる「間抜けな癖」と、ほぼ間違いなく成り得るだろう事も申し添えます。
嫌な先輩 (スコア:1)
昔、プログラミング技術を実地で覚えようという意欲を持った初心者が
脱落していく(1つの)主な原因として、
・温厚だと思っていた先輩が、なにかのきっかけで、キチ●イの様に
怒り出し、理由を言われても何のことかさっぱり分からない。
もうついて行けない。
という事が有ったと思います。(「昔」で無く、今も散々有るようです。)
実地で白紙から虚心坦懐に学ぼうとすると起きる事だと思います。
緩急のきつい(ボラティリティの大きい、リスクの高い)分野では、
もしそれを職業としてやるとしたら、さらに緩急をきつくする
ふるまいは厳に避けるべきなのに、そこに踏み込んで「チャレンジ」
であるとうそぶくと、だれであろうと(仏さまであろうと)怒って
当然だと思います。
自動車を運転する人も、電車を運転する本職の人も、時々刻々と
規則が変わったら激怒すると思いますし、それを「チャレンジ」であると
評価したりはしないと思います。
---------------------
これも昔、自分が(COBOLの)プロジェクトに配属されて思った事は、
・プロジェクトとは1つ1つ、小さな学会の様なものでは無いか?
という事です。
もちろん、そう思ったのは、
・縛りがものすごくきつかったから
です。
学会とは、特定の分野の学問に対して、
・人間が思考可能な様に、ボラティリティを小さくする。
・ボラティリティを小さくする為に、分野に縛りを設ける。
・実際に指向可能であると価値づける事により資金を得やすくする。
組織だと思います。
もちろん、構想段階、設計段階では、最大限にボラティリティを
度外視し、見える限りの選択肢を否定すべきでは無いと思いますが、
(「プログラミング」と言った)実現段階以降では、それをするのは、
・リスクの他人へのなすりつけ
にしかなりません。
「実地で白紙から虚心坦懐に学ぼうとする」と、リスクの他人への
なすりつけになるかどうかが見えません。学校などで先に、
・制限された失敗しやすい縛り
(「関数呼び出し」に過剰にこだわる手法など。これは、
せっかく存在する、なけなしのプログラミングの自由度の1つを
殺し、緩急のきつさへの備えを妨げ、かえってボラティリティを
必要以上に大きくするという、実地では忌むべき手法です。)
の元で、実際にリスクに直面してから実地に臨むべきでしょう。
---------------------
管理職と言われている人や、運用担当者と言われている人は、
緩急のきつさを他人に押し付ける事が可能な職種です。
もちろん、押し付ける事が可能ならばの話です。
その様な事は無理に近くなっている今日、せめて、
・ボラティリティをより小さくする方向に(実現可能性を上げる
方向に)
意識を向ける事で、少しでも押し付け可能となる状況に持って
行くことが必須だと思います。
その為には、プログラミングを学ぶ事が重要だと思います。
ボラタイルはそこに書いて在り、顕現していないボラタイルも
そこから生まれるからです。
お金やPingの可否などの固定の指標からでは、絶対無いと、
自分は断言いたします。
Re: (スコア:0)
「関数呼び出し」に過剰にこだわっている時点で、『実地で白紙から虚心坦懐に学ぼうとする』態度では無いのではと疑問に感じたのですが…。
上司の方針で不適切な手法を強制されているのなら、『初心者』の問題ではなく『実地』そのものの問題である気もします…。
Re:嫌な先輩 (スコア:1)
コメントありがとうございます。
自分も、「『初心者』の問題ではなく『実地』そのものの問題」と
いう意見で、ずっと多数決で押し切られて来たので、良く解りますが、
やはり、「実地で白紙から虚心坦懐に」というのが致命的に悪いと
思います。
もと日記でくだくだ述べました通り、
・ソフトウェアは緩急がきつい(ボラティリティが大きい)
と思います。
そして、その様なきつさは、学校教育でも学生の日常でも類例が無い
と思います。
すると「実地で白紙から虚心坦懐に」で何が起きるかと言うと、
・緩急のゆるい(ボラティリティが小さい)他の分野でうまくいった
やり方でやろうとする。
事に絶対になると思います。
国語算数理科社会でも、政治経済法律人文でも、かなりボラティリティは
小さいと思います。(人間どおしの競争の上でなっている以上、最終的に
小さくなって当然。)
だから、それを(戦争にならない範囲で)大きくして利を得るのが
(利を取られる人間以外からは)妥当だとされているのだと思います。
ソフトウェア開発はそれとは違い、さらに理系の電気電子土木建築物理化学
に比べても、緩急がきつい(ボラティリティが大きい)と思います。
その中で先輩と並んで何かを成し遂げるには、極度の忖度、まねっこが
必要になるでしょう。
車に乗るなら、前車などを忖度して、動作をまねっこしないと危ないと
思いますが、ソフトウェア開発でそれをしない事が
「『初心者』の問題ではなく『実地』そのものの問題」というのは不当だと
思います。
緩急の緩いと所でのやり方を虚心坦懐にやられるのは危険です。