がるの健忘録 このページをアンテナに追加 RSSフィード

2018-03-21

[]業務にシステムを合わせるのか? システムに業務を合わせるのか?

ふと何気につぶやいた程度の話だったのですが、思ったより膨らみそうなので、膨らませてみる(笑

いやまぁ結論は「程度問題」なんだろうなぁ、とは思いつつ。じゃぁ「どの程度」が「よい程度」なのか? ってのもあるので、このあたりは論考してみても面白いんじゃないかなぁ、と。


いつも以上に、っていうか多分今までになく「とっちらかったまま」書いてるので、文章に不安定なところや毒やその他諸々が含まれますので。

容量用法を適切にまもってお読みくださいませ。


直接的なネタとしては「Webアプリケーションフレームワーク」回り。まぁおいちゃんなんで、PHPの。

ただそこから少し「経営回り」のお話が絡んでくるので、そんな感じで色々なレイヤーをまぜこぜにしつつ。


直接的には、直近使ってるLaravel(5.5)が、そうで。

Ruby on Railsなんかでも聞こえてきて、それ以外のフレームワークだとFuelPHPなんかで感じて。………cakePHPは、がっぷり四つに組む前に魔改造してたから不明(笑

なにかってぇと「フレームワーク特有の縛りと固有のノウハウが結構面倒」。

もちろんこの辺はトレードオフなので、ってのはあるんだけど。


ん……少し暴言を吐くと「0からがっちょり(セキュリティ回り含めて)組める面子でそろえられるんなら、フレームワークを使わない」って選択肢が、脳内によぎる程度。

ちなみにその辺の観点からSlimが最近わりと気になっていて、今度がっぷりやってみる予定……ってのは、余談。

あと「テンプレートエンジン」は、なにか、は、大概使う。「シンプルな機能」だけなら、どのテンプレートエンジンでも「大体同じような機能を提供している」から、学習コスト低いし。

Twigが結構気になってるんだよなぁ、その辺としては。

もちろん「素のPHPテンプレートエンジンに使う」でもよいんだけど、いくつかの観点から、テンプレートエンジンは使いたい事が多いかなぁ。「中にPHPコードが書けないようにする」的なギミックがあると個人的にはすげぇ嬉しかったりするんだが*1


話を戻すと。

上述は「0からがっちょり組める面子でそろえられるんなら」って前提なので、「そんなメンバーばかりではない」場合は、もちろんフレームワークを使って「提供された機能を使う」ほうが楽なケースも多々。

あと、「0からがっちょり組める面子でそろえられる」場合でも、認識合わせのルールはしっかり決めないとえらいこっちゃになるケースが多いように思われるので*2

事前にその辺の「取決め」は、大枠から細かい所まで意識合わせしないとひどい目に合う感じなので、その辺は注意。


ただまぁじゃぁ「フレームワークつかったらそんなことがなくなるのか」といえばそんなことは全然ないので。

フレームワークによって強制できる取決め」は、全体からみると割と控えめだったりするので、その辺も注意が必要ではあったりする。細かい見た目からもうちょっと致命的な記述方法まで、色々と問題が起きるしねぇ。

んでまぁこれがまた「フレームワーク使ってる"から"誰が書いてもコードが均一になる」とかいう信仰を持っている方も一定数いらっしゃるので、どっちがより深刻な事態になるのかなぁ? とか、思うところは色々。


個人的には「仕事で書いてるんならちゃんと人と足並みそろえようよ」と。

「好き勝手にコード書くのは、プライベートな趣味か、でなきゃせめて"自分が頭張ってる"時にして」って思うざます。


次。

んじゃまぁ「ある程度のルールが均一化できた」として。

次に立ちふさがるのが「フレームワーク的な制約」の諸々。端的には「素組みならさほど困らない実装」のいくつかが、フレームワークを使ったりすると「えらい事面倒」になったりする感じ。

この辺も「8割くらい*3フレームワークに従って楽が出来て浮いた工数」を「残り2割の奇異な要求で、がっつりと工数が食われる」とかいう状況になったりして、全体的なバランスがですね、えぇ。


もちろん「フレームワークのお作法をドン無視して」ってやり口もあるのですが、その場合大体は、割れ窓の法則に従って「全部が壊れていく」ので、フレームワーク使う旨味が減っていくので。

結果として「フレームワーク、使わなかったほうがよかったんぢゃね?」とかいう状況になって、それはそれでど〜なのかなぁ? と。多分選択肢としては「劣悪」な部類だと思う。


で、この辺になってくると気になる一つ目が「そのフレームワークの作り」と、次が「そのフレームワークに対する習熟度」。

ちなみにその観点で、Laravelは、作りとしては面白いんじゃないかなぁ、と思ったです。

「知らないと出来ない」の塊ではあるにしても、「知ってたら、ある程度介入出来る箇所も多い」ような印象は受けたので。

Zend Frameworkは「そもそも縛りがほぼない」から、この辺については楽だったなぁ………それ以前の問題が山積み過ぎて困ったけど。

CodeIgniterもその辺の縛りはシンプルだったような気がする……ただそれならSlimまでそぎ落としてほしいとか思うので、色々と難しいなぁ、とか思うのですが。


閑話休題


………こう考えてみると「フレームワークの縛りがギチギチで介入が難しい」ってのは、昔はあったんだけど、今は減ってきてるのかなぁ? って気は、する。気がするだけかもしれないけど。

ただ、上述のように「フレームワークそのものの処理に介入」できるようになるためには、フレームワークのつくりまでをある程度「熟知している」必要があると思われて。

端的には「新しい案件で使うからキャッチアップしませう」のレベルだと、ちょっと、そこまで踏み込むのは難しいんじゃないかなぁ、とか思ってみたり。


なんてのを色々と脳内で繰り広げていくと。

一つの疑問がふと脳内に横切るわけなんですね。


「どのフレームワークを使う?」以前に「フレームワーク、使う?」


いやまぁもちろん「対象フレームワークを熟知してから使う」ってのは、一つの真っ当な正解だとは思うのですが。

とはいえ、割とコロッコロ移り変わるフレームワークを、どこまで追いかけていくのかなぁ? と考えると、色々と思案のしどころ、ってのが一つ。

もう一つが「じゃぁ熟知するフレームワークにはどれを選択する?」って話にもなって。もちろん「今のトレンド」に合わせてもいいのですが、多分それ、5年持たないんじゃないかなぁ? と。

その辺を考えると「いずれにしても(フレームワークよりは)長期間使える知識としての"PHPそのもの"や"SQLそのもの"や"サーバ知識そのもの"を学習する」とかなんとか。まぁそこから先に踏み込むと「PHPよりは長期間使える知識としての"プログラミングそのもの"」とかになってきて玉ねぎの皮のようになっていくわけなのですが。


で……そこからさらに考えて。

おいちゃんの場合は「実案件」ベースなので。つまり実案件が「フレームワークの諸々の縛りに、何一つとしてはむかわないニーズのみ」であれば、問題の大半は解消できるんですよ*4

ただ、現実問題として、見ている案件は、大なり小なり「フレームワークのこの部分の縛りをど〜にかして業務に合わせてほしい」っていうニーズがあって。

「素直にフレームワークを使う」と迂回路を作るのに工数がめっさかかって、でなきゃ「フレームワークを熟知する」か「フレームワークを使ってる意味をなくすレベルで壊す」か、「フレームワークを使わない」か。

んで、もう一つ出てくるのが、「顧客の要求捻じ曲げてご理解いただいてねじ伏せる説得する」っていうルートです。


ようやっとここで出てくるわけなんですね「業務にシステムを合わせるのか? システムに業務を合わせるのか?」ってお題。

Google検索で「業務にシステムを合わせる システムに業務を合わせる」なんかでも色々と出てくるんですが。

おいちゃんが見聞きしている論調としては「アメリカではシステムに業務を合わせるが、日本では業務にシステムを合わせようとするから失敗する」的なお話。


個人的には「ケースバイケース」だと思うですし、もうちょっと突っ込むと、根本的にまずいのは「業務フローを定期的に見直すルートが存在しない」事なんじゃないかなぁ? とは思うです。

一見無駄に見えるフローが「予想以上に無駄」な事もありますし B-p 、一方で「実はちゃんと意味があった」事象もあるので。正確には「ある事象を懸念してルールを策定して連絡して伝えたのにルールが無駄だと軽視された結果、懸念した事故が起きて面倒をこうむった」事とか、ま〜ま〜あります。

なので「無駄な業務」が「本当に無駄なの?」ってのは、しっかりと理由込みで継承していかにゃならんのではないかなぁ、と。

その上で「昔は重要だったけど今は無駄になった」なんてのもあると思うので、定期的に検証のループを回す、と。


んで、ちょうど大垣さんが、Facebookのほうで、ど真ん中な書き込みをしてくださってます。

https://www.facebook.com/michiaki.furusho/posts/1840530206021119?comment_id=1840546786019461&reply_comment_id=1841203432620463&notif_id=1521601974590136&notif_t=feed_comment&ref=notif

パッケージを入れると今の業務に合わなくなるので、どうでも良いことは全てパッケージに合わせる、が良いのは確かです。

問題はどうでも良くないことで、一言で言えば「競争力を維持するための業務」についてはカスタマイズも検討する方が良いと思います。でもそれ本当に競争力??という検証は常に必要だと思います。

多分、ここに尽きるんですよね。

おいちゃん的にポイントだと思っているのは

・どうでも良いことは全てパッケージに合わせる

・「競争力を維持するための業務」についてはカスタマイズも検討する

・でもそれ本当に競争力??という検証は常に必要

この辺。


んで……こっからは経営素人なおいちゃんの考え方、として。

「これ本当に競争力?」って、どうやって検証するのか、ってのが、おいちゃんには正直、よぉわからんです。

「KPI回せばいいじゃん」とか言われそうな気もするのですが、KPI界隈もいろいろあるっぽいですしねぇ。

施策を打ったらKPIが上がった!」だけで満足するのは危険( https://tjo.hatenablog.com/entry/2013/06/17/190319 )」とか、こーゆー話、なんか割とありそうな気がして、色々。


………確か、どこかで「2要素が、相関なのか因果なのかを(ある程度)判断できる」方法とか、あったような記憶がかすかにうすぼんやりと。


話をシステムに戻しつつ。

システムを組むのって「業務を組む」事でもありつつ、「システム自身」のお話にもなるので、二重に出てくるお話なんですが。

フレームワークが持つ縛り」を、どれくらい許容してどれくらい許容しないのか? ってのは、まぁ、少なくともしばらくは、ず〜〜っと付きまとってくるお話なのかなぁ、と。

その辺も結局のところ

・どうでもよい事か?

・重要な箇所か?

ってあたりの考察が、定期的に必要なんだろうなぁ。

あとは「重要な箇所」が「なぜ重要なのか?」を、最低限、言語化できる事と、可能であれば、必要な人に伝える事。


んで。

個人的には、どちらかというと「フレームワークの縛りが業務と相反する、或いは露骨にリソースを食う」なら、フレームワークをカスタマイズするなり改修するなり改造するなり部分的に置き換えるなり使わないなり、って選択肢を選ぶことが多かったんだけど。

その辺を、今後、ど〜しようかねぇ? っという感じで。

フレームワークの縛りが業務と相反する」についてはお客様と要相談。問題は「露骨にリソースを食う」場合で、「許容できる業務」もあれば「許容が不可能な業務」もあるかなぁ、と思うので。

その辺も「業務の性質を考えながら」になるんだろうなぁ、とかとか。


まぁおそらく最終的には「プレタポルテにも対応できる、普段はレディ・メイド」になるんだろうなぁ、とは思いつつ、まぁまだ色々と煩悶している時期なので。

とりあえず、その煩悶をそのまま文章にしてみましたww


……多分、フレームワークを「がっつり熟知する」には、端的には「そのフレームワークに好意以上のものを持つ」あたりが一番のモチベーションになりそうなんだけど……今の所、あんま、ないしなぁ。

そーゆー意味で、Slimがちょっと気になってる感じ。次点は、現状だと割とCodeIgniter。案件で一度「壮絶なコード」を見たけど、あの壮絶さに、逆に可能性を感じたのでwww


なんて駄文を、つらつら。

広い世界で、なんか一人くらい、この文章が参考になってくれればよいかなぁ。

*1テンプレートの中で「DBに接続してSQL発行する処理」とか、あんまり見たくない

*2Zend Framework案件でいくつか「壮絶なの」を見てるしなぁ……伝聞も実体験も込みで

*3:なんとない印象値。根拠なし

*4:いやまぁそれでも最後「なんか色々と無駄メモリ使ってるなぁ」とか思うところもなくはないのですが、その辺も「クラウドインスタンス増やす」で片付くしねぇ

2018-02-19

[]それは「やらなきゃいけない」事?

「誰が」やるのか?( http://d.hatena.ne.jp/gallu/20180130/p1 )ってエントリーをえらい事のんびりと書いて、割とすぐに出てきた、気になる記事。


「誰がやってもつまらなくて、苦痛なこと」を愚直に継続すると、ものすごく信用される。

http://blog.tinect.jp/?p=49073


ちょいと色々と端折って、結論部分を引用。

「つまらなくて、苦痛なことを地味に続けなさい、その一歩が掃除、ということなんだろう。でも、そういうオーナーはたいてい、掃除も続けられないそうだ。人生がかかっているのにね。」

「「掃除すりゃいい」ということではないとおもいますが、「つまらないこと」を継続できる人は、絶対的に信用されます。そのアドバンテージは、会社の中ではかなり大きいのではないかと。」


色々と興味深く、思う事も色々あるような内容でした。

なので、メモ。

2018-01-30

[]「誰が」やるのか?

元ネタの一つはこちらから。……もう大分古いなぁどれくらい古いのか記憶から抜けるくらいw

「新人時代の雑用」意味ある? 20代と30代で意見逆転

http://r25.jp/career/00051998/ (サイトがcloseしちゃったみたい… http://www.news-postseven.com/archives/20160803_435798.html で読めるです)。


まぁ以前から考えていたネタではあるので、ちょうどよいからくらいの感触。

いわゆる「雑用とか下積み」とかのお話。

細かい話をすると「雑用」と「下積み」は全然違う話なんだけど、似たようなラインで語られる事が多いし一部分重なる部分もあるので、適宜、重ねながら。


端的においちゃんの見解としては

・下積みには基本、意味がある(事が多い)

・雑用の意味&意義は不明だが「誰かがやる必要がある」んなら「一番下っ端がやらされる可能性が高い」(でなきゃ、コストメリットに応じて自動化されていく)

ってあたり。


かみ砕いて。

雑用は…正直おいちゃんの経歴だとあんまりないのだが。いわゆる「掃除」とか「お茶くみ」とか「コピー」とかの類だと仮定。

食い物系だと、皿洗いとか野菜の下ごしらえとか…こないだ「老舗のすし屋では、10年修行を積むと、たまごを焼かせてもらえる」とかいう話もあったなぁこの辺が雑用なのか下積みなのかは微妙なところだけど、一端現時点での切り口では「雑用」と仮定(相反するもんでもないし)。

果たして「野菜の下ごしらえ」が「本当に雑用なのか?」ってのはあるんだけど、一旦おいといて。


お茶なんかは「ティーサーバあれば各個でどうぞ」とかしみじみ思うのですが。

ごみ箱のごみ捨てとかが微妙になってきて(この辺までは各個かしらん?)、掃除とかはおそらく「誰かがやる必要がある」ってあたりまでは、割と合意が取れるところなんじゃないかなぁ、と。

だとするとじゃぁ「誰がやるのか?」。


一つの見解としては「みんなで当番制」なんだろうけど、ぶっちゃけこれは悪平等な部分があって。

端的には「バリバリの稼ぎ頭でかつスケジュール的にタイトな人間に雑用やらせるとか、費用対効果が問題ありまくりすぎ」。

だとすると、端的には「一番"時間単価稼げないヤツが雑用をする"」って方向に流れる可能性は十分にあって、それがそのまま「じゃぁ新人に」って流れになるんだと思う。


先に、上に上げたサイトの意見のうち「意味がない派」に少し突っ込んでおくと。


「まったく意味がない、新人の能力を活かしていないから」

「自分の能力を他人に生かしてもらわないと活躍できない」時点で未熟。

或いは「あなたを活かすよりも、ほかの人を活かしたほうが効率が良い」って考察の結果の可能性もある。


「誰にでもできる仕事はアウトソーシングするべき」

その費用の捻出はどこから?

或いは「その費用を捻出してでもアウトソーシングしたい、って思わせる程度にあなたは稼げてるの?」

まぁつまりこの辺については「自動化等が可能で、自動化のためのコスト+自動化を維持するためのコストが"新人がやる未満"に収まる」んなら、自動化のほうがメリットがあるし。

つまり「自動化のためのコスト+自動化を維持するためのコスト > 新人がやるコスト」なら、新人がやる雑用になる可能性が高い。


まぁ「意味がある派」にも突っ込みどころはあって。


「忍耐力が増す」

忍耐力が増してもなぁ(苦笑

基本、単純に「忍耐"だけ"」が増しても、あんまり嬉しくない事のほうが多い。


「上司の命令を忠実に聞くという縦社会で生きていく意味で勉強になったと思う」

社蓄養性ギプス?w

これも、衰退していく方向性なんじゃないかなぁ? っと。


別口で見ている限りの突っ込みと反論としては…

意味はあるかもしれませんが、非効率であることは間違いありません。

「新人にとっての効率の良さ」なんて局所最適を、会社はそう簡単に受け入れてくれるのかしら?


この変化の早い時代、1億総中流でなくなった時代、20代での遅れは致命的だと思いますよ

否定はしないけど「雑用程度で遅れる」んだとすると、そもそもの資質に問題が以下略。


なので。

全体として

・他によい方法がある

んなら「雑用を新人にやらせない」って方法はとりうる方策だと思うんだけど。

現実問題として「じゃぁ(たいして何もできない)新人に何をやらせるのさ?」って話になると「………雑用?」って話になる可能性は、ぶっちゃけ、高い。

で、必ず出てくるのが「お前は新人を活かせてない!」って話なんだけど、本気で話をすると「中途半端な人間をそれなりに役に立つように"使う"」ってのは、使う側に結構な高レベルスキルと高コストがかかるざますぶっちゃけ。「高レベル」はまぁ「上司が身につけろ」、にしても「高コスト」はあんまり見逃せないよねぇ、的な。

で、その「高コストを支払ってまで"新人を活かす"メリットは?」ってお話。

多少スタートラインが不利なのかもとは思うんだけど、結局のところ「(基本)自力で成果を出しました!」ってのを数字なりで出さないと、次につながらないざんす。


で…ここからが「雑用なんだか下積みなんだか」ってお話と、おいちゃん関連の「いっと業界」の頭の痛いあたり。


料理のじゃぁ「素材の下ごしらえ」とかは。

うん大変なんだろうっていうか間違いなく大変なんだけど、じゃぁこれが「雑用」なのか? と問われると色々と疑問。

現実問題として「包丁一つまともに使えないでなにが料理人?」って話になるし、結局のところある程度までは「質量転換」なんて話にもなるので、とりあえず「大量の下ごしらえ」は、雑用消化の観点からも訓練の観点からも、それなりに「理にかなってる」んだよねぇ、的な可能性が。

……料理学校とか卒業した人間が「キウイを湯むきした」とか、なかなかに笑えないんだけど、それが「事実」ってのが、多分、一番笑えない。

おそらく「次に下が入ってくるまでに一定のレベルに達してない」と色々と困ったりするんだろうから「気ぃ抜かずにがんばれ」としか思わないし思えないのだが。

恐らく「雑用と下積みすらこなせない」んなら、「早いタイミングで転職したほうがよいんじゃなかろうか?」ってのも、割と本気で、選択肢なんじゃなかろうか、と。


で…この辺を前提に、おいちゃんの関連「いっと業界」で、些か頭の痛いお話が。

雑用って結局のところ「誰かが手を動かさなきゃいけなくて」かつ「ある程度、誰がやっても程度問題はあれどなんとかなるんじゃないかなぁ」タスクなのですが。

いっと業界が「きっちり」回っていると、そーゆー「誰がやってもある程度何とかなるもの」ってのは速やかに「自動化」されて「こんぴぅた様がこなすタスク」になるので。

…気が付くと「新人にやらせる雑用が………ない!!」なんて事になったりして、大変に痛し痒し。


https://twitter.com/hayakogoto/status/767527674436685825

しかし友人とも話してたのですが、最近はデジタルのおかげで、ベタ塗ったり消しゴムかけたり、簡単なトーン貼りとかの人手がいらなくなってアシさんに求められるスキルが跳ね上がってるよなあ…。アシさんは本来そういう楽な仕事からじわじわ育てていくものだけど…。

なんてあたりを聞くと「いっと業界以外も似たようなもんなんかなぁ」とか思ったりはするのですが。


いやこの辺割と本気で困る事があるので、色々と悩みます。

ふた昔くらい前なら「テストでもやらせるか」ってなってたような気がするのももうずいぶんと昔のお話でいまどき「テストくらい自動化してるよねぇ」で片付いちゃうあたりが色々と切ない限り。

かといって「技術と技能と知識と経験が必要」なあたりをいきなりやらせても無理があるしねぇ…的な。


さてはて。


なので、おいちゃん的には「雑用でもやれることがあるうちはやる」&「雑用だから、とかヌルい事言わずに速やかにそこから吸収できるものを吸収して這い上がってよじ登っていく」くらいの気力があったほうがいいんじゃないかなぁ、とおもうですだす。

いっと業界は、幸いにして「公の舞台に出る」方法が比較的あちこちにあるので、例えば「仕事では色々と耐えつつ」「プライベートでちょっとはじけてみる」とかでもよいだろうし。


で「それでも老害が頑張ってバリケードはってる」んなら、その時点で辞めることを考えても遅くはないんじゃないかなぁ、と。

まぁこの辺は「育てる」タイミングで色々と思案が始まるところなのですが……いや実際、よい「銀の弾丸」が見当たらないので……結構困ってる。


ど〜したもんかねぇいや割とマジで。

2017-10-19

[][]基礎を学びたい時の書籍草案

発端としては。

うちの子(というか元生徒さん)が「内部的な仕組みとかハードとかやってなかったなぁ」というお話があったので。

おいちゃんなりに、多少「お勧め可能な書籍」とかを勧められればなぁ、ってのが発端でございます。


……なんか記憶にあると思ったら、以前にも http://d.hatena.ne.jp/gallu/20170119/p1 でつぶやいてございましたw

書籍にかぶりがあるのはまぁ「そんなもん」だとおもっていただければ。


注意事項

比較的ノンブレーキ(アクセルフルスロットルではない。ブレーキをかけてないだけだ)なので、書籍には偏りもあれば、濃度もあります。

適宜自分で選びなおしつつ、適量を少量づつ、用法容量を守ってお使いください*1


さて。

何はさておきまずはここからでしょう。


UNIXという考え方―その設計思想と哲学

UNIXという考え方―その設計思想と哲学

鉄板中の鉄板でございます。

まずはここから。これは必読。


この後ですが


は割とお勧め。ただ、ちと「訳が悪い」というお話もあり、確かに微妙なところもあるので。

もう一つとしては

コンピュータシステムの理論と実装

あたりもよろしいのではないかなぁ、と。

併読ももちろんありで。


プログラム自体、の話をすると、まずはなんといってもこちら。

これはやはりほぼ「必読」。


ここから先ですが……幾分深くに潜り込むのであれば

熱血!アセンブラ入門

熱血!アセンブラ入門

大熱血! アセンブラ入門

大熱血! アセンブラ入門

あたり。

ちなみに「大熱血! アセンブラ入門」は「購入したけどまだ読んでません」ので、厳密な是非は不明。

ただ、以前の内容とざっと斜め読みの雰囲気からして「面白い」のは確定であろうか、と(笑


ここから一瞬寄り道をするのであれば

新装版 達人プログラマー 職人から名匠への道

新装版 達人プログラマー 職人から名匠への道

も面白い。「プログラミングを深く学ぶ」上では非常によいげなので。

この系の「少し古いけど興味深い書籍」はまだストックがあるので、興味が向いたら適宜、突っついてくださいませw


さらに深く掘り下げていくと

30日でできる! OS自作入門

30日でできる! OS自作入門

経由で

CPUの創りかた

CPUの創りかた

って方向も、存在は、する(笑


さて深堀繋がりで。

インフラの場合、深い根っこのあたりとしては

なんてのがあって、起動プロセスが理解できる、という、割合と稀有な書籍。

そこまでいかんにしても

ルーター自作でわかるパケットの流れ

ルーター自作でわかるパケットの流れ

くらいを押させておくと「パケットがどのように流れるのか」が理解できるので、なにかよい基礎が築ける可能性、が、ある。


インフラ繋がりとしては

インターネットのカタチ―もろさが織り成す粘り強い世界―

インターネットのカタチ―もろさが織り成す粘り強い世界―

を抑えておくと、今度は「インターネット」ってもん(の濃いところ)が見えてくるかもしれない。


余談だけど、あきみちさんの「IPv6本」、楽しみだよねぇ(笑


さて。

プログラム、インフラときたら、次はDB

データベースシステム概論

データベースシステム概論

は面白いんだけど、絶版だし、そもそもお値が張る。古いし。

An Introduction to Database Systems

An Introduction to Database Systems

のほうにしてもお値段が以下略。


なので、とりあえず

あたりが穏当にお勧め。

あと、実務ベースだけど

SQLアンチパターン

SQLアンチパターン

は合わせて読んでおいたほうが安全な感じ。


あとは、プロジェクトぶん回し的な意味で

人月の神話【新装版】

人月の神話【新装版】

はほぼ必読。

トム・デマルコさん、って方も色々書籍だしてるんで、検索してみるとおもしろげ。

https://www.amazon.co.jp/%E3%83%88%E3%83%A0-%E3%83%87%E3%83%9E%E3%83%AB%E3%82%B3/e/B000AP7OPO/ref=pd_sim_14_bl_19?_encoding=UTF8&refRID=HG973H4YBVAFDDH1BSF1


余談だけど

暗号技術入門 第3版

暗号技術入門 第3版

もわりと「知らないと痛い」内容が多いので、一読をお勧め。


以上駆け足でなんか色々抜けてそうな気がするんだけど、今「ふと思いつく」程度の、手元にある書籍の群れからのチョイス、でした。

何かの役にでも、立つとよいなぁ。

*1:PL法対策

2017-05-21

[]教わる側の意見

元ネタ

エンジニアを指導する立場の人こそ読んでほしい、新卒エンジニアが1年間で上司に感じた5つのこと

http://qiita.com/H_Crane/items/22ea96300dda82ec5b02


どちらかというと「教える」事が多くなった立場のおいちゃん的に「下はどう感じてるのか」ってのは、色々と興味深いのだよねぇ。


1、「本当にそれググった?」って聞き返さないで欲しい

まぁ本文に書いてあるんだけど、おいちゃんが聞くとしたら「どんな風にググった?」かなぁ。

「本当にググった?」って聞かれても、聞かれた相手「ググったにきまってるやん」くらいにしか思わないだろうし。

ただ「ググリ方」があるから、その辺をレクチャーしていく感じかなぁ。


2、やたら「同じミスはするな」って言わないで欲しい

言わない。言ったらブーメランになるからwww

大体「癖(くせ)的なミス」はしょっちゅうやるもんなので、そこが見えた時点で「こーゆー癖があるよねぇ」から始まって「こーゆーやり方をすると防止しやすいよ」と、あとは「自分には"こーゆミスをしやすい癖がある"って覚えておくと、チェックしやすいよ」って教えるくらいかなぁ。


3、意見やツールの押し付けをしないで欲しい

基本はしない。

聞かれたらおいちゃんの好みは伝えるけど……基本「補助輪を外しまくった」ツールを使う事が多いので、止めはしないが勧めもしないw

ただまぁ現場によっては「ツールはこれ」って決まっちゃってるのもあるので、その場合は「あきらめろ」とは言うかなぁw


"上司の考える効率"というものが、「俺の方が経験あるし正しいに決まってる」という個人の行き過ぎた考え方なのか、「客観的見ても」そうであるかどうかが重要ではないかと思います。

この辺については、正直「そのツールに対する慣れとか好みの方向とか」色々あるしなぁ。

とりあえず「お勧め」はするけど、それ以上のものではないかなぁ。

そのツールを使って「明らかにはまりそうな沼」があるなら、それは伝えるが「それでも使う」ってんなら、止めるほどのもんでもないしなぁ。


4、もっと褒めて!

割と大事ではあるのよねぇマジなところ。


5、「わからないことはすぐ聞いて」という人ほど聞くと怒る

別所でも(定期的に)書いているような気がするんだけど。

おいちゃんは「一定時間(1時間とかが多い)調べて、1時間したら、解決してようがしてなかろうが、報告して」って話をするかな。

んで、聞かれて怒ることはないから、「すぐ怒る」のあたりは、ぶっちゃけ理解不能かなぁ(苦笑

「質問したら怒る人」は、多分「そんな事聞かれても自分のスキルと知識が低いからわからないんだけどわからないっていうにはプライドが邪魔をするから怒る」んじゃないかしらん? くらいにしか見ていないしw


……ふむ。

特段に違和感もなにもない感じかなぁ。普段やっている事についても、違和感がある感じではないし。


僕自身ここまでの反響が(炎上が?笑)起こったことに驚いております。

ってあるから、もうちょっと色々とアレがナニな感じなのか、と思ったんだけど、さほど違和感なく読めました。まる。