「上の方から手助け/アドバイスしてあげる」っていう愚者が嫌いなのかも
起因は複数。
一つは「上の方から手助け/アドバイスしてあげる」と気軽にのたまう御仁を過去にちらりほらりと見かけた記憶と。
その記憶をほっくりかえしてきたのが、以下の記事
総務省、国民が悪性サイトにアクセスしようとしたら注意画面を表示
http://internet.watch.impress.co.jp/docs/news/20131002_617839.html
ん…本腰入れると猛毒化しそうなので、全力のオブラートでｗ*1
この手の「善意」があんまりおいちゃん的にお好まないのはおおよそ２つあって。
一つは「善意の裏側にあるもの」と、もう一つは「善意で行う意見行動のレベル品質クォリティが低い」ってあたり。
「善意の裏側にあるもの」ってのはまぁわりとちょこちょこあって、詐欺師の常套手段ではあります。
「右手を高々とかかげつつ左手でタネを仕込む」のは奇術の基本でもあります。
「あなたのためだから」とかいう発言のイヤミっぷりは、そういやCMでもあったなぁなんだっけ。
今回の総務省の話しで見てみると。
もちろん「、国内のインターネットユーザーがマルウェア配布サイトへアクセスするのを未然に防止する」ってのは、とてもありがたいことだと思うのです。便利だし。
ただ、ちょっと穿ってみると色々と妄想が妄想を呼んでしまうわけでして。
もちろん「莫妄想」とか言ってみるのはたやすいのですし「心配事の9割は起こらない」とか達観してみてもよいのですが、ろくでもないレベルが高いものに限って「予感的中」となるケースも多いわけでして。
そんな昨今を鑑みると「まぁお役所様だし大丈夫だよねぇ」と発言する根拠に今ひとつ強固な自信が持てず*2。
とりあえず、
http://www.active.go.jp/
こちらで「ACTIVE推進フォーラム」が動き出すらしいので一旦見守りつつ、必要に応じてツッコミを入れるのが現状の流れなのかなぁ、などと。
んで、この辺りに潜む「上の方から手助け/アドバイスしてあげる」の中身の「意見行動のレベル品質クォリティの低さ」の話に、少しお話を動かしてみようかなぁ、っと。
アドバイスってのは「忠告助言をすること」とあり。
忠告ってのは「まごころをこめて相手の欠点や過ちを、戒めさとすこと」、助言ってのは「助けになるような意見や言葉を、そばから言ってやること」と、あります。
この辺、おいちゃんの言葉に翻訳すると「ツッコミを入れる」となります。
さて。
「過ちを戒める」にしても「助けになるような言葉を述べる」にしても、そこには「適材適所」的なものが必要になる、とおいちゃんは考えています。
禅語だと「碎啄同時」とかってやつですね。
大体にして、お役所様系にしてもアドバイザー系にしても、見ている限り多く見るのが「状況をわきまえずにとりあえず一般論を自分の思い込みでエビデンスもなく」のたまうケース。
"コンテキストを踏まえていない"という時点で「ドレイファスの技能習得モデル http://d.hatena.ne.jp/gallu/20100118/p1 」を一度熟読すると、その御仁たちの熟練度も想像がつこうというものですが、どんなもんですかね？
まぁ多分「アドバイスには状況に応じた判断が必要である」事さえわからないから「こそ」、気軽に「アドバイスします」とか言えるんだなぁ、とか思うのですが、その辺りどんなもんなんでしょうか？
で、そのアドバイスの内容が「状況を踏まえていない、浅い一般論」だったりした日にゃ正直「邪魔」以上の初見が持てないわけですねぇぶっちゃけ。
お役所様及びアドバイサー各位におかれましては、是非「心に響くような、熟練の経験と深い知見とを感じさせる」発言をもうちょっとお願いしたいなぁとか思ってみたりするのですが、どんなもんなんでしょうか？
正のスパイラルと負のスパイラル
直接の考察のきっかけとしては…先日書いた「MACアドレスでの認証があずましくない理由 http://d.hatena.ne.jp/gallu/20130606/p1 」の元ネタになった事象が「実際に発生した(ギリギリ、辛うじて回避。厳密には"わずかに回避しきれていない可能性"があるのだけど、対応不能ではないレベル)」状況と、もしこれを「おいちゃんが突っ込まなかった」場合の惨事の予想とその時の彼らの行動と…その辺を一式シミュレートしたあたり。
その辺を起点にして、以前から思っていた事を、まとめてみようかなぁ、っと。
割と見かける負のスパイラルから。
基本的に「学習/勉強は、必要になるまでしない」で、よく発生します。以下、実際に「売るほど腐るほど」見ているケースから、要約。
その１：言われた
今まで知らない「これをやって」を言われて、慌ててググります。
とりあえず「深く根っこや原理までを噛み砕いて理解する」ほどの時間的余裕もないので、一旦、ググって出てきたソースをコピペして、最低限のテストだけして「通らばリーチ」で仕事を仕上げます。
何事もなければそのまま「忘却の彼方」に流して終了できるのですが、修正変更問題がある場合は「とりあえず場当たりで」修正をあてます。でもやっぱり「基本思想や原理の把握」までやってる時間はないので、理解は出来ないまま「なんとなく動いているような気がするからいいかなぁ」で納品、それ以上にはつながりません。
その２：気付かなかった/知らなかった
MACアドレスがまさに(途中まで)そのケースなのですが*1。
「知らないからとりあえず無知なままに実装」しますが、実際には問題がある実装なので、トラブルが露見します。
大体にして「露見したトラブル」ってのは落ち着いて修正できる時間的余裕とかないので、とにかく「対処療法考えてググって場当たりにパッチあてて」という作業に追われます。
どちらにも共通して言えるのは「時間がないので原理とか哲学とか根っことか根本とか考え方とか」っていう、本来「最も重要な」部分が、時間制約上「すっ飛ばさざるを得ない」状況で、故にすっ飛ばし、そのために時間がなくなり、時間がなくなるから学習せず、そのために場当たりの弥縫策で対処療法をせざるをえず、そのために「学習にならない」＆「問題が発生しやすい」状況で、そのために時間がなくなり、そのために以下LOOP。
同じ仕事が来ても「同じように」時間を使ってしまうので、わりといつも時間の余裕がとれない。
亜種として「同じ仕事に対して同じように駄目な実装をする」と、露見した時の対応コストが半端なく、隠して「言い訳する」「踏む」「逃げる」などといった、技術者的とは言いがたい解決策のスキルがたけていくようなケースってのも以下略。
上述、完全な「摩耗ルート」で。
まぁこの場合多分、30歳とか35歳とかで「エンジニア定年」とか騒ぎたくなる程度に、体力がついてこなくなります。
もちろん「とはいえつぶしが利かないので居座っている」タイプも存在して、その場合の問題の根の深さは言わずもがなでございます。
まぁ、こんな仕事している限り、エンジニア稼業ってあんまり「面白い」仕事じゃないですわな。
で、言及しておきたい正のスパイラル(ちょっと黒い目の技付きｗ)。
ポイントは「なんとなく、見たなぁ」程度に記憶をしていることです。知識へのポインタ、程度が把握できてりゃOK。
いきなり言われても「…あれ？ 確か、アレだよなぁ」とかなんとなく目見当つくんで、調査がそこそこ的確で、時間的余裕が少し発生します。
またコピペするにしてもコードを読む時間が取れるので、気になるところを「とりあえずマーキング」だけでも出来る ＆ 学習が習慣になっていると、納品後にしても「気になるところを確認してみる」とか色々できます。
ちなみに「納品後に気づいた」場合、相手にもよりますが、基本的には「一旦締め切りに間に合わせましたが、この辺に気づいたのでよかったら修正したいのですが」と申し出ると、多くの場合、そんなに邪険にされないというかわりと喜ばれます。
何よりも「一度ちゃんと噛み砕いている」ので大枠の基本やら考え方やらが身につくので、次に同じようなお仕事が来た場合応用が利くので、サラっといけるか、あるいは理解が深まるので、スキルが練られてきます。
まぁまぁこんな事があるので。
もちろん締め切り大切ですしそのために「一旦ググってコピペ」を、全面的には否定しないのですが。
「きちんと事後に噛み砕く」のと、それ以上になによりも「ある程度の感度であちこちにアンテナを張る」「直近直接に関係のない事についても、広く浅く学び続ける」ってのは、実利実務に直結する「重要事項」なんじゃないかなぁ、とか思うわけですが。
どんなもんなんですかね？
二種類の「書類」
書類には多分２種類ある。
「伝えるため」のものか「事後保身のため」のものか。
共存が必ずしも不可能ってわけじゃないので、理想としては「事後保身が出来るだけの情報を十全に掲載したうえで」「わかりやすい」もの、ってのがよりよろしいんだけど。
多くの場合「事後保身のため」だけに書かれていて、そのために「情報はあるけれどもわかりにくくて保守しにくい」ものがあふれておりまする。
…それすらないよりマシ、って話もありますが。
あとは、書類の質によっては(具体的には仕様書とか)、DRYがきちんと意識できていること、とか、重要。修正変更に耐えられることは、プログラム以外のものであっても「とても重要」です。
「必要最低限をMECEで、わかりやすく」というのは、とても大切だと思う。
UI(User Interface)ならぬ、SI(Staff Interface)とかいう単語、流行らないかしらん？
コンピュータシステムを「ビジネスとしての系(システム)の一部」として見ることが出来るかどうか
相変わらず「金の話とエンジニアの話の真ん中くらい」をふらりぶらりしているおいちゃんでございます。
ふと、偶然ではあるのですが。
ちょいとばっかり「壮絶な」ものを拝見したのと、そこに起因して随分といろいろ、考察できるネタがあったので。
その辺の考察の…途中経過、程度のものを、Blogにて。
とりあえず今回俎上に挙げるのは２タイプ。どちらにも共通しているのは「DRYなにそれ？ レッツコピペ駆動開発！！」な行動原理。
A)複数個所のテストだろうがどんだけ単純作業の連打だろうが「僕は」黙々と丁寧に根気よく続けます
B)テスト？ なにそれおいしい？ 理想論として耳にしたことはあるけど、現実、テストなんてやってらんないよ？
Aは、割と典型的な「無能で勤勉な人間」。
http://d.hatena.ne.jp/gallu/20081114/p1 の話を思い出すのであれば、彼らは速やかに[除隊 | 馘首 | 銃殺]されなければならない。
ちょいと真面目に考察すると。
「考えて」「改善すれば」できるコスト削減を彼らはず〜っと「やらない」ので、無駄なコストの発生源になりえるです
で、無駄なコストを生み続けるってのは、ビジネスのメイン目的の１つである「利益の創出」に真っ向から対立する概念なので(利益ってのが「売上 - 費用(コスト)」だ、っていう数式知ってりゃ誰にでもわかる話だ)。
従って彼らは極論としては「ビジネスの敵」になりえるわけです。
あぁ、少しだけ寄り道。
対局に「改善だけ考えて動かない」連中ってのがいて、これはこれで「邪魔なことこの上ない」です。「何もできていない」と比較するんなら「無駄なコストがかかり続けている」ほうが、まだ、極わずかに、１ミクロンくらいマシ。ついでに言うと「口先だけでできもしないことをわめいたりする」ので、ぶっちゃけうざい。
そうならないためには「まず動く」っていう部分と「常に考察を重ねる」っていう部分とをバランスよく保つのが、基本にしてコツ。
人によっては「まずｎ分間考察、しかる後に動く」って人もいるし、おいちゃんは「まず手を動かしながら、頭を並列処理化させて、現在データを分析して改善案を想定」するかな。
この辺「どうバランスをとるか」は、個人差ってか個性。
もう一つ…最近遭遇した怖いのが「テストをしない」という生き方(笑
えと…時系列を思い出しながら。
とあるところのソースコードが…なんていうか「ある意味革命的」で。
本番リリース直後とかなのに
・ソースコードがコピペの山
・使われていないメソッド多数
・使われていないクラスがちらほら
・使われていないテーブルがちらほら
・使われていないカラムがそこそこ
・謎のifやらforやらのネストの山
・意味のない共通化と密結合だけはそれなりに山盛り
というコード。
とりあえず思ったのは「テスト無茶(経路網羅はむろん、分岐網羅ですら、100%にするには手間がかかりすぎる)」「改修無理(コピペと密結合の嵐なので、どこから手を出したものやら…)」「追加困難(同左)」という三重苦。
どうやってこれでうまくやってるんだろう…っと思ってしばらく見ていたのですが。
結論からいうと「テストしてない」 orz
あとは「言われた事を狭い範囲で局所最適解的に額面通り、あるいは場合によっては曲解して理解して、かつその局所に対する修正しかしない」orz
あぁ「こういう理由があるから(根っこ)これを作って(実装)」ってお願いをしたら、根っこをドン無視したブツが上がってきたこともありましたな(遠目
どうも見ていると。
結局のところ「テストを全くしていない」かつ「テストをする必要性すら理解していない」ようなので(正常系の最小限をぎりぎり、それですらやっていないケースがあったっぽい)。
結果的に
・コピペ部分を「別途テストする」必要がないから、気にせずにコピペ
・分岐網羅率100%を満たすテストとか未考慮なので「似たような機能」を「あちこちに別々に書いて」も、手間はかからない
・データの確認とかしないので「似たようなカラム」「未使用のカラム」とかの存在も問題なし
という風になっているみたいざんす。
ついでに、基本的に「言われたことを実装してお金をもらえればよい」しか頭にないぽいので(そこさえもあるかどうか微妙なんだけど…)、相手の言ったことに対する「意図を知るための質問」とか、その辺が皆無。
ゆえに端的には「先方のビジネスに対して、全くコミットメントできない」ブツが仕上がってくる。
まぁ、納品されたほうとしてみればぶっちゃけい「いい迷惑」レベル*1。
上述AとBを見ていると「納品先のビジネスについてドン無視」ってところが、一致していると思うのですね。
Aは「どんだけコストをかけても無問題(ひどい言い方をすると、定期的にコストがかかったほうが、システム会社としては、短期的には大儲け)」。
Bは「押し付けるように納品してしまえば、あとは野となれ山となれ」。
むろん、発注元の担当者だって必ずしも「ちゃんとビジネスを意識している」とは限らない、ってのはあるのですが*2。
その辺をきちんと最低限踏まえていれば、たとえば「システムを作らない」というシステム会社の提案とかが、普通にあり得ると思うですし。
その中で「いかに運用コストをかけないつくりにするか」とか、そういう中から「よいもの」が生み出されてくると思うのですだよ。
その辺、相手の「ビジネス全体の系、の一部としてのコンピュータシステム」という認識に至れるかどうか。
システムってのは「発注者と受注者のコラボレーションである」というスタンスに至れるかどうか。
結構重要な考え方なんじゃなかろうか、って思うのですが、どうなんですかねぇ？
「愚行権」ってのを知っておくと楽なのかも
エンジニアさんのストレス周りの話で。
んと…まず先に、言葉の意味から。
http://ja.wikipedia.org/wiki/%E6%84%9A%E8%A1%8C%E6%A8%A9
愚行権（ぐこうけん、the right to do what is wrong/the right of(to) stupidity）とは、たとえ他の人から愚かでつむじ曲りの過ちだと評価･判断される行為であっても、個人の領域に関する限り邪魔されない自由のこと。
ポイントは「個人の領域に関する限り」。
ん…これ、割合にあちこちであって。
ちょいと変形させると「教えるのってやっぱり難しい…からいい勉強になる http://d.hatena.ne.jp/gallu/20120122/p2 」にもつながるかなぁ、と。
エンジニアさんのストレス溜める一箇所に「好みの違い」ってのがあるです。
いやまぁ実際「好み」って結構「質に直結している」可能性もあるので、「好みを持つこと」自体については全く否定をしないのですが。
ただ「考え方や捕らえ方、切り口の違い」を見て、「違う"から"否定する/ストレスをためる」と、ストレスがマッハでたまるです。
その辺はいわゆる「みんなちがって、みんないい ＠金子 みすず」ってあたりですね。
ここを許容できないと、貪瞋癡の三毒でいう瞋となるです。すなわち「我（自分）に背くことがあれば必ず怒るような心」。
このへんは、気合と修行と考察によって、消していくほうがよいです。
一方で…ここが多分、エンジニアとして困りやすいところだと思うのですが。
「瞋とかいう以前に純粋に被害がでて困るんだよ」って状況が、時々*1出てくるです。
この場合、それこそ「投石器使おうが石斧投げようが尿道結石の呪いをかけようが」やめさせる必要があるです。
ポイントは「自分にとって直接の実害が、明確に出てくる」場合。
で、重ねて書くポイントは「問題が発生することが明確である場合」ではなくて、「その発生した問題によって、自分に実害が及ぼされる」場合。
ちなみに「問題発生によって残業が増える」については「残業をしない」で跳ね返すことを前提に「問題は発生しない」っておいちゃんはみなします。
残業をしていないことで問題視されたらンな現場はとっとと辞めるし、実際過去に何度かそーゆー状況は発生しています B-p
この辺りの「適切に怒るべき箇所」と「他人ごととして、愚行権を認める箇所」を切り分けると。
少しだけ、気の持ち方が楽になるかなぁ、って、思うです。
まぁエンジニアに「あぁ愚行権を認めなきゃなぁ」って思われてるような現場に未来があるとは、あんまり思いませぬが B-p
*1:時々ってことにしておこうよ orz
認証、どうしようかねぇ？
自作しているBtoCのゲームサイトのauthentication、のお話し。
前提としては「スマフォ＆ガラケー用のゲームサイト」。現在絶賛作成中*1。
タブレットとPCはどうすっかねぇ、と。
排除はしない。デザイン的に想定するかしないか。
ガラケー以外は「レスポンシブWebデザイン」とかでいい感じにしてみるかしらん。
まぁ「画面サイズ」くらいしか見ないんだろうけどさ。
センス？ それなに？ 美味しい？
んでまぁ上述を作るのに当然ながら「認証」が必要になるわけですます。
一応セキュリティ意識して実装するけどさ、それでもやっぱり「馬の骨とも分からんところにパスワード入れられっかい！」という可能性も否定は出来ないわけで。
もわもわと考えてる実装を…どうしようかなぁ、っと。
- idとパスワードを登録。idは「@が入ってなければ」なんでもOK。パスワードが分からなくなったら終了。サルベージ手段なし。
- メールアドレスを登録していただいてパスワード。メールは存在確認あり。パスワードリマインダが利用可能。
- OAuthによる認証。twitter、facebook、github、mixiあたり、かしらん？
- idとかOAuthとかの認証のあと、メアドを「ヒモづけるように」登録、はあり。一応「メルマガを送る予定」だけど…実装、いつになるのかしらん？(最低でも年単位で未来だねぇ(苦笑))
こんな感じ？
これくらい豊富だと、登録もそんなに困らないかなぁ？って思ってるんだけど。
一端「idとパスワード」実装して、早めに「メアド」の実装。OAuthは後回しって思ってるんだけど…どうかなぁ？
ご意見求む！！ｗ
*1:停滞中とか言うな(号泣)
