i_amaiの雑記

お金稼ぎが目的のブログです

ポートフォリオ

今の会社に入ってから作った社内向けアプリの一部を公開します。

2018年11月 作業時間計測アプリ

f:id:i_amai:20190610000631p:plain
app
f:id:i_amai:20190610000637p:plain
app2

従来、

  1. ストップウォッチを使用し、作業ごとに作業時間を計測
  2. 紙の記録表に作業時間を記入
  3. Excelの表に記録表の作業時間を入力
  4. 管理者が集計、グラフ化

と手間のかかっていた作業時間の計測作業を半自動化。

作業者がWebページにログインし、Web上のストップウォッチを使用して計測を行うことで、上画像のようなグラフがすぐに、誰でも見られるようにした他、

  • 誰が
  • いつ
  • どんな作業を行ったか
  • どんなトラブルがあったか

などが下画像のようなカレンダー形式で表示されることで、簡易的な日報としても使用できるようにした。

使用技術

住み込みエンジニア

会社に住みたい。

最近自覚しつつあるが、私はたぶんかなりの面倒くさがりで、通勤が面倒くさいし、勉強をするのに場所探しから始めるのが面倒くさいし、自分が何を食べたいか考えるのも面倒くさいし、モノを色々持つのが面倒くさい。

もういっそのこと会社に住みたい。会社にシャワーと洗濯機があって、布団があって、死なないだけの食べ物があればそれで良い。最近求人広告とか眺めていると眩いほどオシャンティを前面に押し出した会社が増えているけど、私が求めている「働きたい会社」というのはオシャンティな会社ではないんだよな。てかコンクリの内壁にツル植物とか間接照明とか中庭とか、よくあんなキラキラしたところで働けるな。寝ぐせと全身ユニクロと無精ひげとアトピーと毛玉は絶対許さんみたいな清潔な空気。そこで働く自分の姿を想像すると滑稽すぎて吐き気を催す。

閑話休題、会社に住みたい。唐突に告白すると、私は元陸上自衛官である。独身の下っ端は問答無用で駐屯地内に住むことになるのだが、働く環境として個人的に駐屯地以上の環境はない。何せ通勤徒歩30秒。衣食住完全無料。体育館と銭湯とコンビニと居酒屋と(駐屯地によっては温水の)プールが徒歩1分圏内。自衛隊はほかに嫌なところが多すぎて辞めたのだけど、あの環境はもっと民間企業も真似すべきだ。

会社に住みたい、と言う人のことを社畜と呼ぶ人もいるかもしれない。私はそれには異を唱えたい。私はなにも、衣食住以外の時間の全てを会社に捧げたいわけではない。むしろ逆で、働く以外の時間をもっと有効活用したいのだ。なぜみんな毎日毎日、満員電車に揺られてまで、渋滞に巻き込まれてまで、そんな苦労をして家に帰るのだ?家族がいる人ならいざ知らず、そうやってまで死守するほどプライベートって重要なもんだろうか?

福利厚生でオシャンティとかストックオプションとか住宅手当とか確定拠出年金とか畳にこたつとか、そういうのと並んで「会社に住めます!」があってもいいと思うんだけど、どうだろうか。

住み込みエンジニア。良い響きじゃないか。

辛い

大型連休中、自宅に缶詰で仕事してたら辛くなってきた。

まあだいたいこういう大型連休って、宿題なんかほっぽり出したままだらけきって過ごして、休み明けが近づいてくると宿題のこと思い出して「あー仕事行きたくねえ」ってなって辛くなるものだ。以前の私はそうだった。

そういう辛さとはベクトルが違う。私は連休中ずっと宿題のことばかり考えている。そして、それでもなおその宿題はまったく終わりそうにない。

そもそもなんで私はこんなことしてるんだ?

決まってる、「連休明けまでに今作ってる社内用業務アプリの大枠を完成させます」、そう約束してしまったからだ。

先月頭に部署を転属になったのだが、転属先の部署で当初の予想より仕事を振られまくって、業務中にそのアプリの開発がほとんどできなかった。それで持ち帰ってこうして自ら宿題を課して、缶詰めになっている。

もう無理!疲れた!と駆け込むようにネットサーフィンしていたら、下の記事が目に留まった。

tech.tabechoku.com

ほとんど小見出ししか読んでないが、今の私にぐさぐさ刺さる。ごめんなさいと言う他ない。


私はタスク管理ができない。より正確には、ちょっと無理めなタスクを自分に設定しがちなところがある。

ここ2年ほど、そういう生活を続けていた。ふつうに仕事しているだけではこなせないような業務タスクを、プライベートを使って消化していた。

ただ任された仕事をしているだけという状況が不安だった。この日記で何度か言及しているように、私は本職のエンジニアではなく工場の組立作業員であり、いつ仕事が機械に奪われるか分からない。それでプログラミングの勉強を始めた。

身の回りの作業が自分の作ったプログラムで自動化されたり見える化されるにつれ、上司は私を当てにするようになった。悪い気はしなかった。その期待に応えなければと思った。幸いやるべきことは多かった。私はどんどんタスクを自らに課して、それをこなしていった。

なんか違うなと思ったのはつい最近だ。

自動化だったり見える化だったりするプログラムは、ほとんどすべてプライベートで拵えたものだった。そうして作業の効率化が進めば、余った時間でもっと複雑なプログラムを書く時間が得られる。そう思っていたのだ。

しかし実際はそうはならなかった。定年だったり正社員になりたくてもなれないなど、色々な理由があって辞めた人員の補充を、会社が渋っているのだ。

会社の業績は思わしくなかった。辞めてしまったベテランでパートのおばちゃんがこなしていた同じ作業を、課長や次長や副工場長が手順書を眺めながら2倍の時間を費やしてやるような、そんなありさまだった。

業務中の私は組立作業に追われた。課長や次長や副工場長がそう頻繁に現場に入れるはずもないので、適宜彼らのケアもしなければならなかった。

結局、作業の効率化で待っていたのは、作業だった。

そんななかでも、私はずっと、ちょっと無理をしていた。やるべきことは多かったから、それを「自分が」やるべきこととして設定し、社内で宣言した。冒頭の宿題もそれだ。

でもなんとなく、そのループが限界に差し掛かっているような、そんな気がする。

私はなんでこんな頑張ってるんだ?


もちろん、この2年間色々あった。たとえば、上司からさらなる作業の効率化を求められたとき、アラートも出したのだ。

「そう言いますけど、あのアプリもそのアプリも、全部プライベートで作ったやつですからね?それをずっとやってくのは辛いから、業務中にやらせてください」

そう言っただけでは上司がうんうん頷くだけで何一つ変わらなかったから、社内規定の書式で提案書も書いた。それが効いたのかは分からないが、この春に転属することになった。

しかし転属先で待っていたのは、やはり作業だった。そこは会社で一番売上の大きい部署で、その分課員に対する要求も厳しくて、どんどん人が辞めていて作業員が不足していた。私はその作業に追われた。

先ほどの記事に、一つだけ気になる点があるとすれば、「仕事を任せる側」の責任が曖昧になっている点だ。

アラートを出してもダメな場合はどうすればいい?せっかくタスクを管理していても、それをぶち壊すようなタスクを上から振られた場合はどうすればいい?

適切な見積もりができるかどうかは、そりゃあ個人に任される部分もあるだろうが、「適切な組織運用ができているか」がより大きな割合を占めていると思うのだ。

件の記事を読んだ世の上司たちが天狗になってしまわないことを祈るばかりだ。


私はなんでこんなに頑張っているのか?

この間転職はしないという記事を上げたばかりだけど、私は自身のへたくそなタスク管理と、上司からの要求との間に挟まれて、見かけはホワイトな企業にいながら、潰れそうになっている。

ほとんど自業自得だよな、という思いと、でも会社のせいでもあるよな、という思いがないまぜになって、誰に文句を言うこともできず、なんとなく、辛い。

変数に対する関数の代入

こんにちは!皆さん、JavaScript書いてますか。初心者プログラマのi_amaiです。

もともとN予備校のプログラミング入門講座経由でNode.jsをちょこちょこ書いていたんですが、少し規模の大きなアプリを作ろうとしたときに現在の理解レベルでは不安があったため、再度入門というかたちでjsPrimerを読んでいるところです。

今回の日記はJavaScriptの勉強中にその仕様で一日ほどハマってしまったため、その備忘録となります。

問題

下記のJavaScriptコードを御覧ください。

function f () {
  return 0;
}

const a = f();

const b = f;

2つの変数abの違いを簡潔に説明してください。

解答

function f () {
  return 0;
}

const a = f();

const b = f;

console.log(typeof a);  // => number
console.log(typeof b);  // => function

変数aには関数fの実行された返り値である0が代入されます。

変数bには関数fそのものが(実行されずに)代入されます。

私がハマったのは以下のコード。

function f () {
  let x = 0;
  console.log(x);
  return function i () {
    return x += 1;
  }
}

const a = f();  // 0 undefined
a();            // 1
a();            // 2

クロージャの学習で、jsPrimerを参考に「関数を返す関数」を書きました。

変数aに関数fを代入したときに、初回のlet x = 0;console.log(x);が処理されるのは、まあ分かります。

その次の行で変数aを関数として呼び出した時、let x = 0;console.log(x);が処理されず、xがインクリメントされるのはなぜかが分かりませんでした。

なんのことはなくて、fの後の()の効果により、変数aには関数fを実行した返り値である関数iが代入されているのです。

関数f自体は変数aへの代入時の1回しか実行されません。

これを防ぐ、つまり関数f自体を変数に代入したい場合は、

const a = f;

とする必要があります。

このように、JavaScriptでは関数に対する()のある/なしが処理の違いを生むのです。

言語による違い

さてこの仕様、他の言語ではどうなのでしょう? 自分のPCに入っているいくつかの言語で試してみました(間違っていたら教えてください)。

JavaScriptと同じ仕様

()あり:関数を実行し、その返り値を代入する

()なし:関数そのものを代入

括弧のあるなしに関わらず関数を実行し、その返り値を代入

その他

VB.NETについては、Visual Studio上で関数を代入する際に()が自動補完され、()なしを試すことができませんでした。()ありの場合は当然、JavaScriptの仕様と同様でした。

まとめ

言語によって処理に違いがあるのは面白いですね。もうちょっと研究すると色々捗るかもしれません。

私はもう疲れました…

それでは今日はこの辺で。

しばらく転職はしない

下の日記から、早いものでもう半年近く経った。

www.vonyaridgement.com

最近色々考えすぎて頭の中がごちゃごちゃしてきたので、整理のために書く。

結論から言うと、転職するべきと感じていた動機はひとまず無くなったので、しばらく転職はしない。以下はそこに至るまでのごちゃごちゃ。

世間では転職・退職しました系エントリが耳目を集めているけど、こういう「転職するのをやめました」というエントリがあっても良いのではないかと個人的には思う。


昨年秋、転職するかもしれないと上長に告げると、すぐにその上長(と、兼務先の上長)と面談をすることになった。そういった面談は、ここ1年以上していなかった。

面談ではもう既に「辞めてもなんとかなる」という気持ちでいたので、ここぞとばかりに洗いざらいぶちまけた。「ここ1年で従業員の1割近くが転職やら定年やらで辞めたけど、ほとんど補充してないよね」だの、「もっと人を教育する機会を設けてほしい、毎年同じことの繰り返しでは人は成長しない」だの、「中間管理職にマネジメントスキルが感じられない。年功序列の消去法で成り上がってしまったから仕方なくその職をやっているように見える。てかなんで次長やら部長が現場に入って作業やってんの?そんなんだからコスト管理できないんだよ」だの、偉そうなことをずいぶんと言った。いや、もちろん実際はですます調だけれども。

だけどそもそも、私が働いていて気づくようなことは上長たちもだいたい気づいているのだ。彼らは彼らなりに状況を変えようと努力している。だからこそ面談の場は定期的に設けた方が良い。現場で毎日似たような作業を続けていると、どうしても視野が狭くなってくる。視野が狭くなった結果、業務に対する作業員どうしの認識にずれが生じて、足並みが揃わなくなってくる。認識のずれを修正し足並みを揃えるために、面談という場は必要なのだ。

そういったことも話すと、上長たちは快く頷いてくれた。ただ、頷いてくれたからといって、上長たちがその後具体的な対策を練り、実行に移してくれたかというと、微妙なところだ。少なくともこの半年間は、彼らが関わった事柄については、ほとんど変わっていない。

繁忙期だから今は仕方ない、と人は言うが、私はそれが嫌だった。この先人材不足が長引けば、繁忙期であろうがなかろうが、可処分時間が足りないことを言い訳にし続けるだろう。いつまで経っても「これは仕方ない、これも仕方ない」と宣うことになるだろう。私は色んな言い訳を考えて「仕方ない」という思考に至るまでに消費する時間や、そう言う風に互いに愚痴を言い合うだけで浪費する時間を、状況を打破するための行動に充てたかった。ある人には焦りすぎだとも言われたが、むしろ私はもっと焦りたかった。

だから、私はとりあえず行動してみることにした。


まず、コスト管理を徹底するために、作業時間を計測するWebアプリをNode.jsで作った。

今までは月に一度、ストップウォッチで作業時間を計測して、紙に記入した後提出してもらい、管理職がわざわざExcelに入力しなおしていた。これのストップウォッチでの計測に当たる部分以外を自動化することで作業者の負担を減らし、その代わり月一ではなく日常的に使ってもらうことにした。集計とグラフもDBから自動で出力されるようにした。

とりあえず自部署の人に使ってもらって、使用感をレビューしてもらった。ある程度運用してデータが集まってきた段階で、社内全体に公表した。今はレビューや他部署からの要望を踏まえて、他部署や間接部門、IoTでも広範に使えるようリビルドしている最中だ。

次に、頭の中で思うだけで言わずにいたことを、稟議書に似た社内規定の書類で上層部に数回提案した。具体的な内容はここで明かせないが、たとえば、従来管理者の経験と直感が頼りだった日々の業務量の調整を数字で計画・把握できるようになるために、組織として対応してほしいことなどを書いた。

書類で提出することで、上層部とのコミュニケーションの増加に繋がる。私はあまりコミュニケーションが得意な方ではないが、こうすると交流せざるを得ない状況に自らを追い込むことができる。また、他人が読んでも分かるような文章を考えてわざわざ書くことで、今の私がそうであるように、自分の意見を整理することもできる。

続けて、私は自分のやりたいことを、きちんと周りに伝えるようにした。何もWebエンジニアがエンジニアの全てではなく、Webだけが私のやりたい全てでもない。なぜか上の日記では「エンジニア言うたらWebエンジニアや!ワイはWebエンジニアになるんや!」みたいになってしまったが(ごめんなさい)、IoT、機械、電気など、勉強したい分野はたくさんある。

周りにそれを伝えてみると、社内でもできることはいろいろとあることが分かった。うちは中規模メーカーの子会社なのだが、設計開発を担当している親会社が製品を設計するための研修を定期で行っているらしい。私は行動してみるまで、そんなことも知らなかったのである。


こういった行動が功を奏してか、少しずつ社内で自分の立ち位置が認められてきていると感じる。

今までの私は、上の日記にあるように、「田舎の工業団地に勤める30代前半の現場作業者」だった。会社がそうあるように求めるから、私はそういう役割を嫌々ながらこなしているのだ、勝手にそう考えていた。しかし実態はそうではなく、社内でのコミュニケーション不足ゆえに、私が私自身を縛っていたのではないか。

そう思い至った時点で、自分が転職すべきだと感じていた動機は無くなってしまった。独学が嫌なら、社内で勤務時間中にそれができるように自ら動けばいいのだ。そしてその土壌は(少なくともしばらくの間は)整う予感がしている。

すべては自分次第だ。私は努力が足りなかった。

おわりに

上の日記がきっかけで、ここ半年で、いろいろな方から叱咤激励を受けました。上の日記を書いたときは、ほんともうボロクソのけちょんけちょんにけなされるんじゃないかと思っていたんですが、そんな人は一人もいませんでした。感謝しかありません。

ここまでポエティックなことを書いておきながら、すぐ考えが変わる可能性もありますんで、生暖かく見守っていただければ幸いです。

頑張ります。

Temporal Dead Zoneってなんぞや

最近個人的に「何それよく分からん」となったJavaScriptについてのメモ。

間違ってたら教えてください。

hoist と TDZ

なんか厨二センスあふれるこのフレーズは、You Don't Know JSの著者、Kyle Simpson氏のツイートから。

hoistしてなかったら2回目のconsole.log(x)では2が出力されんだろ?って言ってるんだけど、まずhoistの意味が分からんかった。

で、調べた。

console.log(x); // undefined
var x = 2;
{
  console.log(x); // ReferenceError: x is not defined
  let x = 3;
}

前者のconsole.log(x)はエラーにならない。後者のconsole.log(x)はエラーになる。

letが宣言されたブロックの中では、ブロックの最初にlet宣言された変数を走査し、それらをundefinedとしてインスタンス化する。これを巻き上げ(hoist)と呼ぶ。

letの場合は巻き上げた時点(ブロックの最初)から実際に変数が初期化されるまでの間を特にTemporal Dead Zoneと呼んでいる。Temporal Dead Zone中にその変数を参照しようとするとエラーになる。

ちなみに、

let u = undefined;
console.log(u); // undefined

この場合は同じundefinedでもエラーにならない。つまり、変数の初期化フラグをJavaScript Engineが内部的に管理しているということなのかな?

varの場合も巻き上げは行われるが、その宣言がブロックの中だろうが、すべてがプログラム実行の最初に走査されて、undefinedとしてインスタンス化される。これは適当なIDE等で変数を色んな場所で宣言したコードを用意し、1行目にブレークポイントをおいてデバッグしてみればすぐ分かる。

f:id:i_amai:20190302231236p:plain
VS Codeデバッグ

その他、TDZに関する動作のあれこれは以下のページを参照した。まだ全部読んでないけど。

jsrocks.org

初心者プログラマとして思う

どうも、こんにちは。ふだんはタンポポを乗せた刺身パックの出来栄えをチェックする仕事をしているi_amaiです。

下の記事を読みました。

note.mu

blog.3qe.us

初心者プログラマの一人として思うことがあったので、ちょっとだけ書きます。


プログラミング言語って、基本英語じゃないですか。

母語じゃないから、「やりたいこと」を言語化するときに、

  1. 日本語でまず考えて、
  2. それを英語に翻訳して、
  3. さらにそれが単語として文法として正しいか検証する

って作業がどうしても必要になってくる。だから急に問われると答えに窮するんです。

implicitlyとかsyntaxとかoperandとか、あんまり学校でなじみのなかった単語もしょっちゅう出てくるし、signedとかdirectiveとか、意味はなんとなく知ってるけどパッと見でなんのことか分からない単語も出てくる。

私たちはトライを繰り返して、上記作業の応答性を高めていきます。算数の問題を繰り返し解くように、身体に染み込ませていきます。日本語でコレと言ったら英語でアレ!といった感じです。

これって、一朝一夕で身につくようなもんではないと思うんですよね。

初心者が中級者になるには相当時間がかかります。シグモイド曲線みたいな。

初心者が中級者になること、それは「何が分からないかが分からない」という段階から脱することでもあります。「何が分からないか」が言語化できれば、あとは勝手に成長するんです。

これって、誰もが通る道ではないでしょうか。


初心者にとっても、熟練プログラマにとっても、今って辛い時期だと思うんですよね。

なにせ人手不足で、未経験歓迎!とか謳って大量に人雇ってビジネスマナー()とhtmlをちょろっと叩き込んだだけで適当に現場へぶち込むみたいな、誰も幸せにならない商法が確立されてしまっています。

初心者と熟練者の間にギャップがある。

私たちはお互いに辛抱強く、歩み寄る必要があるんだと思います。

これは受け売りで、初心者に向けた言葉なのですが、「一冊だけでもその言語の入門書を購入して手を動かしながら学ぶ」ことをお勧めします。

私もいろいろと教材を試してきましたが、結局体系的に学ぶなら本が一番手っ取り早い気がしました。

情報の網羅性と信憑性だけでおつりが出るくらいで、「やりたいこと」を言語化する、及びその応答性を高めるのに一役買ってくれます。

頑張りましょう!


あとプログラミング教育については、少し古いんですが、文科省有識者会議が発表した下記の記事が参考になると思います。 http://www.mext.go.jp/b_menu/shingi/chousa/shotou/122/attach/1372525.htmwww.mext.go.jp

私たちは現在でも、自動販売機やロボット掃除機など、身近な生活の中で意識せずとも、様々なものに内蔵されたコンピュータとプログラミングの働きの恩恵を受けている。このような人間とコンピュータとの関係は、人工知能の急速な進化等に伴い、今後ますます身近なものとなってくると考えられる。

そうした生活の在り方を考えれば、子供たちが、便利さの裏側でどのような仕組みが機能しているのかについて思いを巡らせ、便利な機械が「魔法の箱」ではなく、プログラミングを通じて人間の意図した処理を行わせることができるものであり、人間の叡智が生み出したものであることを理解できるようにすることは、時代の要請として受け止めていく必要がある。

どうでしょう?そこまで変なことは言っていないと思うんですよね。こういう思想が全小学校教諭にまで浸透するかどうかは未知数ですけど、少なくともトップはきちんと考えているんじゃないかってことをお伝えしたかった。

結論

なでしこ良いよなでしこ。日本語でコードが書けます。

ブラウザだけでも開発できるよ!みんなやろう!