読者です 読者をやめる 読者になる 読者になる

Murga

個人的に言いたいコト・主張・気持ち。

エンジニア必須スキル:名前を正しく付け、正確に区別する

エンジニア必須スキル

プログラムで必ず登場するのが、変数やメソッドと呼ばれるもので、変数やメソッドには名前を付ける。

名前を付けるという行為は、その名前が示す範囲を定義し、対象物とそれ以外を明確に区別するということだ。

クラス名であれば、それが「クラス」という括りで役割を持つことを表すし、例えば「登録ユーザを管理するクラス」なのであれば、そのクラスは「登録されたユーザにまつわる情報を保持するモノであり、それ以外には手を出さない」といったスコープ、責任範囲が見えてくる。よく「単一責務の法則」とか呼ぶあれは、名前を付けるということの意味を深く考えないと真に理解できない。

名前を付けるとはそういうことなので、名前を付けてからさて何をさせよう、ではなく、何かしたいことや表したいことがあって、それをまとめて他と区別する必要が出てきたときに、適切な名前を考えるのである。


変数名やメソッド名の名前の付け方が下手な人は、英語ができないという理由の他に、「自分が何をしたいのか言語化できていない」という状態が強く考えられる。恐らく日本語で変数名をつけてよいと言われたとしても、適切な名前が付けられないことだろう。

もっと言えば、何か説明文書を作ってほしいとか指示されたときに、ファイル名、文書全体のタイトル、章立てなどがグチャグチャだったり、全く出来ていない人は、母国語である日本語でも「物事を言語化する」「名前を付けて区別する」という習慣を付けてこないまま、もしくはその重要性や影響を無視したまま育ったものと思われる。

こういう人に「名前を付けるってのは大事で……」といくら説明したところで、「でも自分、国語苦手だし…」などと理由にならない言い訳をするだけで終わる。それが周りに混乱をもたらしていて迷惑であり、即刻改善しないと邪魔な存在だということに気付いていないのだ。

ただ、指摘したら直るものかというと、基礎的な言語能力は育ちの問題だと思うので、相当困難だと思う。親でもない仕事上の付き合いだけの他人が指導してやる義理もない。こういう日本語が不自由で変数名が意味不明な人間とは距離を置くしかない、というのがぼくの所感。


さて、じゃあ言って分かるレベルの人たちに何かアドバイスするとしたら、ぼくは先程挙げた「単一責務の法則」だけ守れればまずは良いと思っている。

そのクラスは何をするものなのか。単一責務の法則に則れば、一つしか責務がないのだから、「○○をするクラス」と一文になるはずだ。これをクラス名にする。そうしたら、そのクラスには他の仕事をさせない。他の仕事は他の名前を持つクラスを作ってやらせるのだ。

これなら一つの名前が指し示す物事は一つに限定でき、同じ言葉を使うことで他の物事と区別できるであろう。

そうそう、同じものを指すのに言葉を毎回変えるのも NG。名前は最初に定義して、同じ名前を繰り返し用いるのだ。長ったらしい文書に出てくる「(以下『Hoge』と呼称)」といった注釈は、実は名前の定義だ。

物事を区別して話すことが、相手に伝わる会話・文章になる。そして物事を区別するには名前を付けて特定の範囲を定義付けてやることが大事なのだ。

エンジニアが持つべき必須スキルを考える

エンジニア必須スキル

プログラマ、エンジニア、SE、この辺の肩書きが付く人間が持っておくべき必須スキルを考えていく。

もう世間的にも話し尽くされたものであることは承知の上で、現在4年目の新米 SE がとらばーゆするにあたって現職の不満をポジティブなあるべき論にすり替えて清々したいのが目的。

具体的な言語とかの技術的なスキルの他、持ち合わせていたい精神性とかも含んで、あえて「必須スキル」と呼ぼうと思う。これがない職場にいたストレスを発散したいからだ。多分に偏見を含んでいることであろう。うっかり視界に入れてしまった人は、どうぞ聞き流してもらいたい。

次回より随時書いていく。

ビルドツールに対する違和感、結構持たれていた

フロントエンド開発 所感

それまで Qiita なんかを見るだけで過ごしていた自分が、今年 Gulp の勉強を始めようという時、Grunt ってのはどうもオワコンになりつつあるらしいな、ということで Gulp を選んだのだけど、最近は「npm run で大体やれるし package.json に書いておけばいいじゃん」な流れがあるっぽい。

確かに、Gulp や Grunt といったビルドツールは流行り廃りが早い割に、個々の学習コストが高いのだ。コマンドラインbrowserify を呼ぶ時は幾つかのオプション指定でよかったものが、やれ vinyl-source-stream かませろだの plumber で失敗時の制御しろだの、watch は別に書かないといけないとか、なんだかめんどくさいのだ。大枠は同じ作りであるにしろ、プロジェクト毎に書き換えが必要な部分も出てきて管理が面倒臭い。

こういうフロントエンド開発のためのツールに初めて触れていたので、「面倒臭いけどこれがベターなものなのかなぁ」と思ってある程度勉強していたのだけど、いかんせん面倒臭い。

…という思いはどうやら世間的にも持たれているようで、「make と何が違うの」とか「シェルスクリプトでおk」とか言われていて、最終的に「npm run で全部動かせばいいじゃん」感もある。

フロントエンド覚えること多すぎ問題

以下の記事あたり。

気になった言葉を引用。意図的に前後の文脈無視。

  • フロントエンドは複雑化してると思ってるし、それは「目的の複雑化に対して必要なもの」だったと思っている
  • 採用例これだけ増えてて、用途に向かないって理由で採用しないのはわかるけど、知見ないから使えないですね〜って理由で落とす人みるとあ〜ってなる
  • フロントエンドを名乗るエンジニアの平均的な技術力が低いことは僕も認めるところではあるんだけど、これはJSが元々「サーバーサイドもしくはデザイナが片手間にやる」時代の変遷から仕方なくて
  • プログラミングが好きではない職業エンジニアが増えている
  • 英語の能力が高ければ、英語の文献や一次資料に触れる機会が増え、そこで得た知識を模倣することで、プログラミングにおける問題解決の再生産能力を高めることができる
  • 変化は良いかもしれないが無駄が多すぎる

何の設定も要らないビルドツールが夢なのは理解しているけど、

Web制作のフロントエンド界隈では、「考えている暇があるなら、四の五の言わずにやっちまえ!」方式みたいです。

この気が強すぎて、自分としては「もっと理屈や思想・哲学から入って欲しい…」と思ってしまう。

なんだか退化しているように思えるんですが、過去のビルドツールの使いにくさから考えると、「何も考えない」という割り切りも理解はできます。

gulpのウォッチは、やっぱり「知性を持たない」方法ですね。

各々が欲しいように書けばいいっていう自由度は魅力がある一方、車輪の再発明に近いことがあちこちで行われている感覚に違和感がある。

できることなら学習コストが低くて決まりきったことは書かなくてよくなる方法を取りたいじゃないの。

「まだ若いからコーディングしたいんだねぇ」とかいう勘違い SE

日本の SE

キャリアプランなんかを話す時にコーディングをしていたいというと、「まだまだ若いうちはコーディングしたいものだよねぇ」みたいなことをよく言われる。

あれは何なの?

歳を取るとコーディングしたくなくなるの?歳を取るとマネジメントしたくなるものなの?

ぼくはそうは思わない。

こういうセリフは、コーディングができなかった能力の低いヤツの僻み・言い訳としか聞こえない。あなたは英語が読めなくて技術に興味もなくて、でもウッカリ SE になってしまったしロクに勉強もしなかったから転職もできなくて、それじゃあプログラミングしなくて済む職種に変わるしかないやって流れで人材派遣と政治活動してるだけでしょ?違うの?

いや、そういう自分ができないことをやろうとしてる人を見て、できなかった自分を正当化したい意識がなかったとしたら、「キミは技術力を高めていきたいんだね」で終わるはずでしょ。コーディングのスキルがなかった言い訳をしたいから、わざわざ「若いうちはコーディングしたいものだよねぇ~ (でも歳取ると違うんだよねぇ~マネジメントの道があるからさぁ~)」みたいなこと言うワケでしょ。

ぼくは客と直接打合せして要件定義もしてきたし、問合せを受け付けるような仕事もしてる。後輩の OJT もやったし、何人かのメンバをまとめて開発案件を回したこともある。見積もやるしスケジュール管理もする。でも「マネージャ」という肩書に落ち着いて、コーディングをしない SE には絶対ならない。

プログラミング・コーディングは、直接の成果物を作る仕事だ。ぼくは直接の成果物を作らない限り、「エンジニア」なんて名乗れないと思ってる。ニホンノエスイーの PL だとか PM だとか、あんなのは「エンジニア」でもなんでもない。俺はああいう職業には就かないぞと言っているのに、「歳を取ったらやるもの」になっていることが我慢ならない。

ニホンノエスイーにおける実装以外の工程は、証拠作りのための不必要な業務でしかない。形だけの設計書に、コード化せず手動で打鍵するクソみたいなテスト。コードが全てなのに、コードを誰も見ようとしない。バカだからだ。

俺はコーダー、プログラマ、技術者、エンジニアになりたいのであって、人材派遣も社内政治も興味ない。マネージャがしたい人はしていればいいし、彼らが担う役割があるのも分かってはいる。そうではなくて「プログラマは下、マネージャが上」「歳を重ねてスキルを付けたらマネージャになるもの」というキャリアプランに反対しているのだ。

お前らは何にもモノ作ってねえじゃねえか。俺より下だろ。ふざけんなや。

作業効率を改善させようとしない人

日本の SE 効率化

ニホンノエスイーな人たちの話。

テキストのコピペを毎回メニューバーの「編集」→「コピー」とマウスで選んでたり、毎回同じようなことを手作業してたりする人が意外といる。

「その操作、このショートカットキーがありますよ」とか「こういう数行のスクリプト組めば手作業無くせますよ」とか教えはするんだが、それを定着させようとしない。

パソコンに命令を出すまでの操作が多い人、パソコンに効率的に作業させる工夫ができない人は、いつまで経っても仕事がトロい。

命令を出すスピードは人に依存する

サッサと動いてほしいのに、パソコンというものは、「さっきのアレ、やっといて」なんて曖昧な言葉がけじゃ動かない。

しかし、人間がパソコンに対して命令を送る方法は、今のところキーボードとマウスが一般的だ。これは恐ろしく非効率で、スピード感のない伝達方法だ。

一回頭の中で考えたことを、一文字も間違えず正確にプログラミング言語に翻訳して、それを両手の指から一文字ずつ指定して打ち込む。「あ、ココだ!」と思ったところを選択するにも、マウスを掴んで、画面を見ながらポインタを重ねようとする。パソコンの操作は実は間に結構面倒臭いことが挟まっていて、操作する人間自身が素早く操作する以外では、「より速く仕事をする」方法がないのだ。

んで、人間がそうやって速く命令を出すための近道 = ショートカットが、パソコンの方に用意されている。その名のとおり「ショートカットキー」だったりするわけだが、同じやりたいことでも、人の命令をより手短に伝える方法は常にある。

Excel など、少し機能の多いアプリになるとその差は顕著で、罫線、計算処理、図形配置、入力規則、色んな操作のショートカットをどれだけ知っているか、どれだけ使いこなせるかが、仕事のスピードに繋がる。

繰り返し作業は自動化できる

同じことの繰り返しを厭わないのは、エンジニアにとってはマイナス要素だと思う。パソコンが得意なのは同じことを繰り返すことであって、そのスピードは人間じゃ敵わない。

もちろん、パソコンが勝手にしたいことをしてくれることはないので、最初にスクリプトを書いたりする時間はかかるが、一回書けばそのあとずっと楽になるワケで、そこに投資しない理由はない。

また、パソコンは疲れもしないから、繰り返し作業を間違えたりしない。人間は「うっかりやらかす」ものだから、繰り返す回数が少なかったとしても、マクロやスクリプトを使っておいて、「間違いがないこと」「抜け漏れが起こり得ないこと」を重視させた方が、結局は質の高い仕事が出来ると思う。

また、自身の作業に対して、「自分が頑張って手動かして解決させる」という姿勢では、顧客が業務の中で何を面倒臭がっているか読み取る力が乏しくなると思う。

「紙資料を毎回手打ちされてますけど、うちのこの機械入れれば一気に電子化できますよ」とか、「集計・統計も自動でやれるようにしますよ」とか提案できなかったら、システム屋としてはイマイチじゃない?

それでも慣れた不便な方法を選ぶ人たち

「これさえ覚えれば凄く楽になるのに」なんて思うことを目にして、方法を教えても定着しない人は、慣れ親しんだ自分のやり方があり、それを変えようとする気がないようである。その自分のやり方がどれだけ不便であろうと、変化というものを極端に恐れているように見える。

もしくは、こちらが「これさえ覚えれば」と思っていることでも、その人にとっては受験勉強ばりに時間と労力をかけないと覚えられないらしい。もはや基礎学力がないというか、「自分が今の生き方をしていて損している」という感覚をどうやっても持てないみたい。

それともパソコンに興味が持てないのだろうか。だったらなおさら、好きじゃないことはサッサと終わらせられるように、素早く済ませられる方法を覚えようとしそうな気がするが。

そもそも何にも考えていない、何にも感じていないのかもしれない。周りからいくら効率化だ時短だって言われても、聞こえていないのかもしれない。

自分にはそうだった瞬間がないので、そういう人がなぜ学習しないのか本当に理解ができないのだが、いずれにしても、馬鹿な人は勝手に不幸になっていればいい、と思う。