がるの健忘録

エンジニアでゲーマーで講師で占い師なおいちゃんのブログです。

なぜ「質問」をしないんだろう? 或いは「コード絶対領域」に対する考察

比較的「古い」御仁やら現場やら、に多いように思われるタイプなのですが。
現象としては
・似たような関数やメソッド、下手したら定数までも、をあちこちにcopyして書き散らかす
というのがありまして。
端的に「物凄く、反DRYな感じ」で、おいちゃんとしては「お好まない最たるモノ」の一つ、でございます。

そういったコードをつぶさに観察していくと見てとれるのが
・とにかく、自分の手の届く所に、コピペを含めて全部持ってくる
という行為であることが多くて。
言い方を変えると「他の人とライブラリを共有する」って事を、一切、やらないんですね。

その辺を「コード絶対領域*1」とか呼称してみようか、と思います。
絶対領域、という単語については、「スカートとニーソックスの間の領域」のほうではなくて、「何人にも侵されざる聖なる領域(心の壁)」のほう、を意図しております。

自分の書いたコードは「自分のコード絶対領域」な一方で、他人の書いたコードは「他人のコード絶対領域」なので。
「他人のコード絶対領域のライブラリは使わない」。面倒なんでコピペとかはするんだけど、「自分のコード絶対領域」に持ち込んでからじゃないと、使わないし使えない。
大体、そんな感じでコードをくみ上げて行きます。

そうするとどうなるかってぇと
・同じ機能を持つ、似たような関数があちこちに散らかる
ので、そりゃもぉ大騒ぎ。メンテとか、夢のまた夢でございます。

いやまぁ、そういう風になってしまう背景が、見てとれなくもないんですが。
具体的には、以下のあたりがAND条件で一通りそろったりすると、やむを得ないケースが、無くもないです。

まず「複数社が混在している」か、或いは少なくとも「複数のエンジニアが混在している」環境で。
かつ、その複数に対して「質問が出来る空気でもなく」「質問を投げても返ってこない(か、下手したら怒られる)」環境で。
かつ、全体仕切りがまともに動いていないために「俯瞰した視点を持っている人」がいなくて。
かつ、そのプロジェクトに対する「権限」は全く所持していなくて。
かつ、「責任だけは十全に背負わされる」ので、「防御的開発」をせざるを得なくて。

この辺が揃うと。
他の人が作ったライブラリに下手に依存するコードを書いて「そのライブラリがいつの間にか仕様変更があった」時に、「仕様変更を言ってこなかった相手」ではなく「勝手に使ったこっちが悪い」になってしまうので。
そーゆー環境下で「その現場に限って"コード絶対領域"を発動する」事については、一定の配慮とか理解とか、が、必要だと思うのです。

っつか「責任も権限もないのにカイゼンをしろ」とか、どんだけブラックなんだよ、的な。

ただ。
「そーゆー環境に長いこと居る」とか「"そーゆー環境に長いこと居る"人から教わった」とかで、「コード絶対領域を"普通の事だ"」とか認識されてしまうと、色々と困ったり困ったり殺意が沸いたりするんですねぇ。
っつかそれ、基本的に「防御的開発」に属する技法なので、端的に「プロジェクトがまともに終わらないことを前提にした技法」だよ?。

一方で「そんだけ、闇の深い現場があちこちにあるんだろうなぁ」とか思いつつ。
「闇落ちした開発者」って、その闇をあちこちに散らかしたりしてくるので、それはそれで、浄化したり聖別したり昇華させたり、なんらかの「ナニカ」が必要なんだろうなぁ、とか思ってみたりするですよ。

とりあえずおいちゃんが推奨するのは「まず、質問をちゃんとしようよ」とか言っていたりするのですが。
まぁそもそも「学問とは問い方を学ぶことである」とか、一時期は「質問力」なんて言葉が出てるくらい、「的確に質問をする」ってのは、それなりに難しいもんだと思うんですが。
その辺はやっぱり「鍛えないと」どうにもならないので、まずは「沢山質問をしてみる」からstartして、問い方を学んでいくしかないと思うんですよねぇ。

なので、まずは「とにかく"質問しろ"」と。
「どのように質問するか」の前に「思い込みで答えを出してしまって"質問すること"をしない」ってのを、割とよく見かけるので。

………それを考えると「ある程度丁寧に、しっかりと質問が出来ること」ってのは、開発者のレベルの高低を図る、よい指針の一つなのかもしれないなぁ、などと、思ってみたり。

「頭でわかってる」から「身体で覚えた」までにある距離

元ネタはこちら。
12時間円柱を描きつづけてはじめてわかったこと。「気づく」までにはたくさんの時間がかかるのに、みんな先に教わってしまうんだね。
http://izoomi-momo.jugem.jp/?eid=1243701
https://megalodon.jp/2016-0425-0921-07/izoomi-momo.jugem.jp/?eid=1243701 (魚拓)
いやあんまりにも素晴らしくて消えて欲しくないので、魚拓まで取ってます(苦笑

似たようなお話は何度も書いてるような気がするのですが、まぁこの手のは「何度書いてもよいかなぁ」とか思っているレベルで大事な事なので、何度も。

さすがにもうわかんねーよ
ってかもう7時間も描いてるのに、指導なしかよ。
ほったらかしかよ、と、その場にいる人たちの
気持ちの中がざわざわとしてきた。
(中略)

「教えてもらわなくっちゃ、わからないじゃんよー」

なんてことを隣の人と話していた。

うんまぁ「教わる側」からしたら、そうだろうなぁ。
で、教える側の視線を加味すると、 https://gallu.hatenadiary.jp/entry/2018/11/15/174146 であったり https://gallu.hatenadiary.jp/entry/20121115/p2 であったり。
「全てを教える丁寧な言葉」って、どうしても、軽くなっちゃうんだよなぁ、的な。

「ちょっと左に傾いてますね」という。

嘘だ。絶対平行だ。私の目にはそう見える。
なので、定規で測ってやった。

曲がってた。3mm。

これも「教える側の実力」って側面から大事なんだけど。

「形は一カ所だけ直しても意味がないんです。何かがおかしいなと思うときは、たいてい全体が
 どこか違っています。違っている場所をすべて、少しづつ修正する。それが基本です」

この辺、含蓄が深いなぁ、と。

「描き方を教えるのは簡単だ。でも、大事なのは自分で気づくことだ。教えられることに慣れた人間は、自分だけの力で同じことができなくなっていく。気づく目を持つには、対象物と徹底的に向き合う時間が必要なんだ」

この辺もステキですねぇ。
言い方を変えると「気づき方を学習しないと、いつまでも"気づけない"人、が育ってしまう」。

いや勿論「巨人の肩の上に乗る」事は大事で、だから潤沢に教えたいなぁ、ってのも、随所にあるんだけど。
ただ、「口を開けて餌をねだる雛」になった瞬間に、多分「伸びないんだろうなぁ」って思ってしまったりもするのですだす。

「真っ当なもの」をこさえるのには、「真っ当なだけの時間」がかかって、そこには多分「近道」とか、ないので。
急ぐべき時は急ぐべきだし、無駄な時間を費やすのは、もしかしたら本当に無駄かもしれないけど*1

「必要な時間」もあるんだよ、ってのは、頭に入れておきたいものでございます。

*1:無駄じゃないかもしれない、あたりが、難しいなぁ

どこにリソースを突っ込むのか? って選択は大事だよねぇ

元ネタは、これ。
https://twitter.com/rootport/status/781680038844309504

ピクサーでは必要以上に丁寧な仕事を、「完璧な陰影をつけた1セント硬貨」と呼ぶらしい。非の打ち所のない1セント硬貨の3Dモデルを作ることに熱中しても、映画全体の品質が高まるとは限らない。むしろ、貴重なリソースを浪費しているだけかもしれない。仕事は丁寧なほうがいいが、過剰ではダメだ。

………「2016年9月30日」とか、もう2年も暖めてたネタだったのかwww
ググると色々出てくるので、そこそこ有名なんだろうなぁ、と思うのです。

さて。
いやまぁ単純なお話で。
手元に「無限のリソースが潤沢にあふれていて、かつ締め切りが広大なる彼方にある」のであれば、どこまでもどれだけでもリソースを潤沢にぶち込んで、思うさまにクォリティを上げりゃいいと思うのですだす。

ただ、大抵の場合は
・リソースは限られていて
・締め切りは、さほど彼方ではないどこかに決まっている
ので*1

そうするとどうしても
・ナニを優先して
・そのために結果としてナニを「捨てる」のか
を、はっきりさせにゃならんですし、着手する中でも
・ナニは丁寧にしっかりと作成し
・ナニは「場合によっては後でリファクタ」前提でざっくり組むのか
を選択せにゃならんです。

トリアージってのは、別に「こいつ死んでもいいや」じゃないんですよ。
「限られたリソース」をどうやって回すかを考えた、苦肉の策なのですよ。

ちなみにプロジェクトで「トリアージに失敗」すると「全滅して死屍累々」とかなったりするので。
ロッコ問題とか、なんかモラルとか良識とかを考慮しつつ年単位で思案してもよいのですが。現実にアレで思案できるのってせいぜいが分足らず程度の時間で、かつ「選べなかったら全員死亡」とかなので、「決断する権限を持っている人間が決断しない」のは、罪悪なのですよ。

おいといて。

基本的に「限られたリソース」なのであれば。
それを「まんべんなく平均的に」使うと、大体において「どれも駄目な駄作」ができあがるので。
そこはどうしても「ここには集中、結果としてここは(一端)切り捨て」って現実路線での考察と決断が必要となると思うのです。

勿論「ナニを大事だとするか」ってのは、とても大切で。かつ、それは必ずしも「外から見て合理的に見える」モノばかり、ではない、と思うので。
結果的に、一見「………なんでそこにそんなコスト突っ込むの? それって"完璧な陰影をつけた1セント硬貨"じゃない?」とか見える瞬間があり、かつ、当事者にとっては「ココにコスト突っ込まないでどこに突っ込むの?」とか思うシーンもあると思うのですが。
まぁその辺は、好き好きですよねぇ、と。
自身の裁量の範囲内において、お好きにやってみたら良いんじゃないかなぁ、とは思うわけなのですが。

ってな訳で。
「どこに突っ込むか」はともかくとして「突っ込む所と突っ込まない所の取捨選択」は、しっかりと考えておきたいなぁ、とか思ってみたりするのです。

………いや一生に一度くらい「あらゆるリソースの心配が全くないプロジェクト」とか関わってみたいなぁとか思うのですが(笑

*1:………えぇまぁついでに「スコープが増大し続ける」とかありそうなのですがそこは永久封印とかぶちかまして寝かせておくとしまして

パスワード文字数の超おおざっぱな最小長の計算

ふと軽く気になったので、おおざっぱに。
前提として「パスワード 定期的 変更」というキーワードがありまして。
個人的に

パスワードの最適変更間隔とその定量的効果の評価
https://docs.google.com/document/d/1RWDerFjLc24nr_lDhF8s0vEOJ8DPKhEnEAYG9qr_oBY/pub

ここが非常に気にっております(笑*1

さて。
パスワードの「最低文字数」をどれくらいにするか……の前提として「空間の広さ」を検討付けておきたいかなぁ、と。

どっかで「5万語の英単語からランダムで5つ」ってのを記憶してたのですが……微妙に記憶違いしていましたな。
https://twitter.com/HiromitsuTakagi/status/978648962449129473

私の推奨は「5万語の語彙の辞書(広辞苑など)をランダムに開いて3つの語を選んで繋げる」(オフライン攻撃想定の「暗号の鍵」の場合は5つの語を選んでつなぐ)という提案。(NISCは採用していない。)

まぁおいちゃんの専門エリアは「オンライン」なのですが、せっかくですので(なにが)。

「5万語から5つ」の場合
50000 * 50000 * 50000 * 50000 * 50000 = 312,500,000,000,000,000,000,000
………単位がもはやよぉわからん(苦笑*2

一応「5万語から4つ」の場合も。
50000 * 50000 * 50000 * 50000 = 6,250,000,000,000,000,000
これもごいすー(笑

当初のお話の「5万語から3つ」だと
50000 * 50000 * 50000 * 50000 = 125,000,000,000,000
いやまぁ十分以下略。

もう一つ、こちらは「パスワードの最適変更間隔とその定量的効果の評価」にある「辞書に載っている10万語を2語組み合わせてパスワード」。
100,000 * 100,000 = 10,000,000,000
………なんだろうこの数値が穏当に見えるw

………うん、一旦、目安として「5万語から4つ」を採用してみましょう。なんとなく。
区切りを抜いて数値だけにすると
6250000000000000000
となります(625京………こんな単位、まぁ滅多に使わんなぁw)。
ので、これと同じくらいの空間をゲットしてみたいなぁ、と。

まずは「英大小文字+数字」。文字種類は26+26+10 = 62となります。
計算をしますと
10文字 → 839299365868340224
11文字 → 52036560683837093888
なので、まぁ「11文字以上」で十分な広さが確保できそう。

次に「英大小文字+数字+記号」。記号は一旦<>!\"#'$%&()=-@;:,.?*[]{}
の25種類と仮定します。
文字種類は26+26+10+25 = 87パターン。

9文字 → 285544154243029527
10文字 → 24842341419143568849
こちらは「10文字」でいけました。1文字の差を、大きいとみるか小さいとみるか。

で、まぁ、せっかくなので「5万語5文字」への対応も。

記号無し
13文字 → 200028539268669788905472
14文字 → 12401769434657526912139264

記号あり
12文字 → 188031682201497672618081
13文字 → 16358756351530297517773047

なので。
全体的に「14文字以上くらいあればよいかなぁ」と言えそうな感じですねぇ。
「ナニを基準にしてるんだよナニを」とか言われそうですが、あんまり気にしない方向で。

………どっかに「英単語5万語とか10万語とかの辞書データ」落ちてないかしらん?
とかたまに思うんですが、どうなんですかねぇ???

*1: 最近うまくググって見つけられなかったので、検索用に上述のメモを取りたかっただけ、って話も以下略

*2:3125垓、とか、ど~ゆ~www

歴史………

この世界は、数万年という長い歴史を持っている。
それに間違いはない。
なぜなら、記録にも文献にも、或いは痕跡にも遺跡にも、若しくは記憶にも語り部にも残っている「事実」だから、だ。

とある異端の、狂った学者は言う。
「"数万年"の痕跡がおかしい。これは"本当に数万年を閲している"とは思えない。わずか、10年足らずの、未熟な考察によって"捏造された"歴史なのではないのだろうか?」
そんな狂気にも等しいお話は、人々の物笑いの種にすらならず、虚空へと消え去っていく。

いったい、なんびとが「数万年の歴史を、その記録と文献と痕跡と遺跡と人々の記憶と語り部と、に残せる」ほどの奇跡を使えるというのだろう?

ありえない。それは、どう考えてもありえない。







ありえない。
それはつまり………………………

PMの必要条件に「技術力」は含まれるのか?

インスパイア元は、直近としてはこの2つのツイート。

https://twitter.com/toukatsujin/status/1063208694123393024

いまだに「システム開発プロマネは技術者でないと務まらない」と主張する人がいて愕然とした。ナンセンスな話で技術者ならやりやすいだけ。技術を知っているしメンバーからの承認も得やすいからね。でもそれに安住して大炎上のパターンもあり。逆に技術者でないとプロマネのコアスキルが鍛えられる。

https://twitter.com/toukatsujin/status/1063212787587903488

この人に「多分そうだろうな」と思って聞いたら、やはりそうだった。「プロジェクトが炎上したらプロマネであっても例えばコードを書いたりするの」に「当然でしょ」の返事。それって戦争で指揮官が職務放棄して最前線で銃をぶっ放すのと同じ。部隊は全滅、開発チームには地獄のデスマが待っている。

先においちゃんの手元を明かすと
・PMは「やってる」けど「特に得手分野ではない」
くらい。
なのでまぁ「1現場の意見」程度に、という前提で。

んと……まず「PMがコードを書くか?」という問いについては
・おいちゃんは基本的に「自分がコードを書く」ために自分でPMをやる(事が多い)
ので(自分で仕切ってたら「自分がコードを書く時間」を自分でひねり出せるでしょ?)。
「指揮官が最前線で銃をぶっ放す」については、普通に肯定的。

ただ「炎上したらコードを書く」「職務放棄して最前線で銃をぶっ放す」だとすると、「炎上しなくても書いてる」し「職務は放棄せずに前線で銃をぶっ放している」ので。
「炎上したからやむなく」とかその結果として「PMとしての職務を放棄して」とかだと、まぁ確かに「それは崩壊の、序曲ってよりもうちょっと先のほうだねぇ」とは思う。
コードは書いても良いけど「職務の一端として"PM"を握ってるんだからね」ってのは、まぁ、肝に銘じていたいところ。

…………いやまぁ「がっつりPMやった上で数人分のコーディング」とか、やると色々死ねるので*1、その辺は適宜、自制したり自重したり自愛したりしてください。

んで。、本題。
システム開発プロマネは技術者でないと務まらない」のか? ってお話。

んと……「技術者」の定義が、不明ではあるんだけど。
一端「相応(以上)の技術力がある」或いは「前線で一級レベルの技術力がある」人、と仮定。

あと。PMのお仕事については。大まかに

・(主にステークホルダーと)利害の調整をして
 →げとれるリソース(主にお金)とスコープの調整をして
・リソース(お金、人員、時間 等)を確保して
・計画を立てて
・タスクを人員に割り振って
 →品質管理して
 →必要に応じて計画のリスケをして
 →スコープ、リソースなどを再調整して
 →人員間の(コミュニケーション)調整をして
・最終的に納品をする

ってあたりだと一端仮定します@大体PMBOK参照。

………いやまぁ大概「どんだけ上級職業だよ」とか思うわけなのですが。
上述のうち
・リソース(お金、時間)確保
ステークホルダーとの利害調整
・人員間のコミュニケーション調整
あたりは、技術力は「あってもなくても」なんですが。

一方で
・リソース(人員)確保
・計画を立てる
・品質の管理(のための手法の選定など)
・「計画のリスケ」のために必要な諸々(と、人員への(技術的)フォロー)
・「スコープ、リソースなどの再調整」に必要な前提知識など
については、基本「結構がっつりした技術力が必要」なんじゃないかなぁ? と、個人的には思うです。

いやまぁ勿論「PMには技術力がなくて、でも人員で技術力が高い人を入れておく」でもいいのですが。
単純に質問なんですが「そのエンジニアが"本当に"技術力が高いかどうか」って、どうやって判断するんでしょ???
その辺の物差しって、せいぜいが「本人のスキルレベルの2倍程度」までしかはかれないと思うんですよ経験上。かつ「スキルポイント割り振ってない方向のスキルの判定は出来ない」ってのが、これは恐らく、ガチ。
ちなみに経験上「しゃべらせたら弁が立つんだけどコードを書かせたらさっぱり妖精が団体でお越しになる」ケースも散見されるので、最近は「まずコードを見せろ。話はそこからだ」って感じになったりしてますねぇ、的余談。

そうすると。
結局の所「PMさんに、相応のスキルレベルがある」事が求められる可能性が高くて。
そうでない場合は「ランダムながちゃ引いて"いいエンジニアさんが当たったらいいなぁ"」な、博打にしかならないと思うんですよねぇ。

いやまぁ「技術力なくてもしっかりとPMが出来ていて、それが運任せじゃなくてちゃんと理論背景に基づいている」ケースが、あるのかもしれないんですが。
知っている限りでは
・技術力のないPMが計画とかそれ以前の「ステークホルダーとの調整」の時点で「できねぇ事を出来るとかほざいて」「あり得ない線を引いて」から現場に持ってきて初手から燃えまくり
なケースを大量に見ているので。
次点で
・いわゆる「リーダー格のエンジニア」が、びっくりするほど「駄目くさい」
ケース。
んで、それって「ちゃんと"技術力"があって、考えればわかる話ですよね?」で一通り以下略した後は敗戦処理、ってなケースが多いので。

ぶっちゃけると「技術力低いPMとか、ないわ~」って思っちゃうんですよねぇ。
経験的には。

いやまぁ「技術力なくてもイけるPMのやり方」とか興味あるんで、なんかコメントとかで「よい」感じのお話とか聞けると興味深いんですけどねぇ。
実際、どうなんだろ??

*1:比喩的にも現実的にも実体験………

「目で盗め」もきついけど「懇切丁寧」が良いってわけでもなくてねぇ………

直接の発端は、こちらのツイート。

https://twitter.com/tatamin_ttmn/status/1062271330895056896

そういうことやるからあらゆる職人業界の技術継承が廃れていくんだろ…

はっつけてある画像は、確か「将太の寿司」だったかな(うろ覚え)。

「この店では誰も技術を教えてはくれない
 仕事のやり方は自分で覚えるしかないんだ」
「えっ……」
「親方の考えじゃ
 楽に教わった技術は決して身につかない
 苦労して人から盗みとった技術が長くその職人の技術になるんだって

 「目で盗め」
 って言われてるんだ」

こんな台詞のやりとり。
うん………まぁ「技術継承が廃れる」の文脈が、わからないでもない。

ないんだけど、一方で………例えば「法演の四戒」という禅語には「好語不可説尽(こうご ときつくすべからず)」って言葉がある。
もうちょっと続けると

好語説き尽くすべからず。
好語説き尽くせば人かならずこれを易(あな)どる。

って感じ(あと三つの戒があるんだけど、ここでは省略)。

なので。
技術を「全部、自分で盗め。一切教えない」はアウトなんだけど、一方で「懇切丁寧に全部教える」のも結局は「アウトになりやすい」ので。
どうしても「身体で覚えていく」しかないフェーズ、ってのは、あると思うんだよねぇ。

この辺は、どっち側に「極端に」倒しても、あんまりお互いに幸せになれないんじゃないかなぁ、って、割と常々、思ってたりするです。

「じゃぁどの辺が適当なのさ?」ってお話になるんだけど。
多分、この辺は結局、山本 五十六さんの、この言葉に集約されるのかもしれない。
「やってみせ、言って聞かせて、させてみせ、ほめてやらねば、人は動かじ。」

ちと、かみ砕いて。

「やってみせ」ないと、そもそも「それ、本当に出来るんですか?」とかって疑念がわいたら、守破離どころの騒ぎじゃないので、まず「出来る事を見せる」のは、信頼を得る意味でも、必要だと思う。
で、それに対して「そら学べ」ではいささか突き放し感が強いので、「言って聞かせて」理論背景の説明をする。
説明を聞いてわかった"つもり"になったところで、じっさいに「させてみせ」て、「つもり」の部分を洗い出してあぶり出して。
あとは出来ているところを「ほめてや」りつつ、出来てないところを「やってみて 言って聞かせて させてみて」の、loop。

……いやまぁこんな丁寧な教育がどこまで出来るか? ってのは、色々と難しいところではあるのですが。
できるだけ、その辺を目標に「見て学べ」でもなく「好語を説き尽くす」でもなく、良い感じのバランスを追い求めていけたらなぁ、とか、思ってみたり。

「そんな教育をすることが出来るビジネスとスキーム」を作るのが、もしかしたら、喫緊の課題なのかもしれないんだけどね(苦笑