2017年に映画館で観た映画2017年12月31日 23時14分08秒

2017年に映画館で観た映画は119本でした。

1月

  1. ファンタスティックビーストと魔法使いの旅
  2. 傷物語Ⅲ 冷血篇
  3. シン・ゴジラ(極上爆音)
  4. 劇場版 艦これ(寝た・全く面白くない)
  5. ぼくは明日、昨日のきみとデートする
  6. 僕らのごはんは明日で待ってる
  7. NERVE
  8. ドント・ブリーズ
  9. 本能寺ホテル
  10. 劇場版 黒執事 Book of the Atlantic
  11. 土竜の唄 香港狂騒曲
  12. 沈黙(寝た・面白くないのではなく疲れてた)
  13. 新宿スワンII
  14. ザ・コンサルタント
  15. ドクター・ストレンジ(少し寝た:疲れてた)
  16. スノーデン
  17. 破門 ふたりのヤクビョーガミ

2月

  1. マグニフィセント・セブン
  2. 君と100回目の恋
  3. 虐殺器官

4月

  1. パッセンジャー
  2. サクラダリセット 前篇
  3. チア☆ダン
  4. PとJK
  5. キングコング 髑髏島の巨神
  6. 一週間フレンズ。
  7. 今日のキラ君
  8. 3月のライオン 前編
  9. 彼らが本気で編むときは、
  10. ひるね姫
  11. LA LA LAND
  12. ゴースト・イン・ザ・シェル
  13. SING
  14. ひるなかの流星
  15. モアナと伝説の海(寝た)
  16. 夜は短し歩けよ乙女(寝た)
  17. 名探偵コナン から紅の恋歌(ラブレター)
  18. 3月のライオン 後編
  19. クレヨンしんちゃん 襲来!!宇宙人シリリ
  20. ワイルド・スピード ICE BREAK

5月

  1. 無限の住人
  2. 追憶
  3. 美女と野獣(吹替)
  4. ガーディアンズオブギャラクシー
  5. SPLIT
  6. 夜空はいつでも最高密度の青色だ
  7. メッセージ

6月

  1. 美しい星
  2. 帝一の國
  3. ちょっと今から会社やめてくる
  4. 22年目の告白-私が殺人犯です-
  5. パトリオット・ディ
  6. 夜明け告げるルーのうた

7月

  1. 花戦さ
  2. おとなの恋の測り方
  3. 忍びの国
  4. ハクソー・リッジ
  5. いつまた、君と ~何日君再来(ホーリージュンザイライ)~
  6. ライフ
  7. ジーサンズ はじめての強盗
  8. 君の膵臓をたべたい
  9. 東京喰種

8月

  1. ザ・マミー/呪われた砂漠の王女
  2. メアリと魔女の花(寝た:全く面白くない)
  3. 劇場版ポケットモンスター キミにきめた!
  4. 銀魂
  5. ジョン・ウィック:チャプター2
  6. エブリシング
  7. カーズ/クロスロード
  8. スパイダーマン:ホームカミング
  9. 打ち上げ花火、下から見るか?横から見るか?
  10. 怪盗グルーのミニオン大脱出(寝た)
  11. 心が叫びたがってるんだ。
  12. トランスフォーマー/最後の騎士王(寝た)
  13. きみの声をとどけたい
  14. 劇場版仮面ライダーエグゼイド トゥルー・エンディング/宇宙戦隊キュウレンジャー THE MOVIE
  15. ワンダーウーマン
  16. 関ケ原

9月

  1. トリガール!
  2. ジョジョの奇妙な冒険 ダイヤモンドは砕けない 第一章
  3. フェリシーと夢のトウシューズ
  4. エル
  5. 新感染 ファイナル・エクスプレス
  6. スキップ・トレース(寝た)
  7. スパイダーマン:ホームカミング(吹替版)
  8. ダンケルク(寝た)
  9. エイリアン コヴェナント
  10. 交響詩篇エウレカセブン ハイエボリューション1
  11. 奥田民生になりたいボーイと出会う男全て狂わせるガール
  12. 散歩する侵略者
  13. ダンケルク(前回寝たので2回目)
  14. 三度目の殺人
  15. ナミヤ雑貨店の奇蹟

10月

  1. あさひなぐ
  2. ユリゴコロ
  3. 僕のワンダフル・ライフ
  4. 亜人
  5. 猿の惑星:聖戦記
  6. Fate/stay night Heavens Feel 第一章
  7. 劇場版Fate/kaleid liner プリズマ☆イリヤ 雪下の誓い

11月

  1. 恋と嘘
  2. アトミック・ブロンド
  3. ザ・サークル
  4. バリー・シール
  5. 氷菓
  6. ラストレシピ
  7. ミックス。
  8. ナラタージュ
  9. 先生!
  10. マイティ・ソー バトルロイヤル
  11. ブレードランナー2049(ちょっと寝た)
  12. ゲット・アウト

12月

  1. 火花
  2. ジャスティス・リーグ
  3. 鋼の錬金術師
  4. GODGILLA怪獣惑星
  5. IT
  6. gifted
  7. 探偵はBARにいる3
  8. スター・ウォーズ 最後のジェダイ(吹替版)

公正の意味をはき違えた会社2017年12月23日 23時50分33秒

■横並びの評価は行わない。努力・成果に応じた公正な評価を行う。

設立から7年程度の会社の採用情報での言葉。
現在社長含めて6人の会社で、一人は事務の女性なので開発ができるエンジニアとしては社長含めて5人です。
そもそも事業においての「公正な評価」ってなんだ?

(1) 売り上げへの貢献度
(2) 研究開発でのアウトプット量
(3) リリース後の不具合量の少なさ
(4) 作業効率の高さ(いわゆる生産性)
(5) 業務改善提案の量(いわゆるカイゼン)
(6) 勤怠
(7) コミュニケーション能力
(8) 従順さ(社畜度)

というようなところでしょうか。
そんなこんなを点数化して係数にして売り上げ計画を上回った分を配分するってことか?

さて、この会社の「こたえ」は概ね以下のような感じ。

(a) 毎月の給与では残業代は払わない。そもそも時間なんか管理しない。
(b) 評価は賞与で還元する
(c) 各自の評価は創業メンバーエンジニアAが「公正」に行う
(d) 賞与の額、できる人は120万円、できない人は5万円程度の場合も。

そのA氏の評価も聞いている範囲ではプログラミングの能力的なことのように感じた。
正直呆れて何も言えない。

■ソフトウェアエンジニアの「腕」と事業に対する貢献は違うということを知らない

プログラミングにおいてはコードの美しさ、実行速度の速さ、バグを回避するような記述、適切なコメントなどの最低限のこだわりは必要。
プロのエンジニアとしての誇りの部分でもある。
そうはいっても一方ではそこに全く関心がなく、「動けばいい」、冗長で速度も出ない結果だけど、このシステムでは問題にはなっていない、コメントなんてなくてもコード見ればわかるだろ、などなどの考え方を持ったエンジニアも存在します。
私も個人的にはそんなエンジニアは尊敬できないけど「コイツはコードが美しくないから5万円」なんて言えない。そんな権利もないと思う。

例えていうならば、「字がキレイなCさんは120万円で字が汚いDさんは5万円」って言ってるのと同じ。

会社としてプログラミングの質を上げたいのであればコーディング規約をきちんと作ってそれを遵守させて「教育していく」ことしかない。
年齢の割にとか経験年数の割にってフィルターが入っているのであればそれこそ「公正」ではない。

顧客との契約形態によっても違う。

準委任契約で時間単価で時間がかかればかかる程売り上げが上がる契約内容の場合、ヘタクソで効率の悪いプログラマが「稼げる」ことになる。

請負契約(いわゆる受託開発)や自社のプロダクト開発ならば短期間に質の良い成果物を上げれば評価は高いでしょう。この場合の「質の良い」はコードの美しさではなくブラックボックスでの性能や機能に問題がないことなどの基準での判断であるべきです。
もちろん、長期的にはコードが美しい方が将来的なメンテナンス性は上がるので生産性も高くなることになります。

■評価されるのは創業メンバー以外

創業メンバーA氏の評価はどうするのかは不明だった。
そもそも、「公正な評価」は特定の個人がやったらだめ。
技術を売る会社なら仮想的な第三者が客観的に評価できるような仕組みを構築できなければならないでしょうね。
「公正な評価」を公言するのであれば、例えばこういうことですよね。

■違法な裁量労働制

「公正な評価」の主張には「残業時間ではなく公正な評価で還元」という文脈でも表現されていた。
この会社は裁量労働制で勤怠管理をせず、実労働時間の把握もできていない状況。
実労働時間すら把握せずに「公正な評価」もあったものではないだろう。

それ以前に裁量労働制自体が違法。
この会社には就業規則がなく労使協定も未締結。
労使協定が締結されて労働基準監督署に届け出られていない場合は裁量労働制そのものが無効。
そもそも、専門型裁量労働制の要件に当てはまらないので労使協定を無理やり締結しても無効。

システムエンジニアやコンサルタントは裁量労働制の適用対象ではあるけどプログラマは適用対象ではないのでコードの美しさで評価している事実からそもそも裁量労働制にはできない。
時間で推し量れない創造的な仕事内容のみを担っている人物以外は裁量労働制にはできないのだ。
これが法の下での公正さであって、それすらできない会社に「公正な評価」を公言する資格はない。

■やりがい搾取

「逃げ恥」のみくりさんの言葉を借りればまさに「やりがいの搾取」状態の会社だと思われる。

確かに技術的に面白い、技術力も高い、人月商売をやっていないので業界的には外側からみれば良い会社だろう。
やりがいもあるし、技術者としては携わりたいテーマがたくさんあった。
そのエンジニアの「やりがい」を餌にして結果的に労働力を搾取して、客観的な評価をせず非公正な評価をしていることに気付きもしないでいるのだ。
実はそういう意味では昨今多くなっているスタートアップのベンチャー企業にも同様のことが言える。
起業のハードルは確かに下がっているけど従業員は必ず必要になるわけで、労働基準法や関連法令は避けては通れないはず。
にもかかわらず、無関心なのは無能であるのと同義。
高い技術力を公言するのなら労働基準法遵守なんて簡単なお仕事のはず。
優秀なんだからさらっと解決して見せなさいよ。

■自信過剰な世間知らず

ある程度の違法状態は指摘させてもらって今後対応していくようなことを社長は話していたが信用できない。
この社長は大手電機メーカであるH社の出身。
労働組合もあっただろう。組合員の経験だってあるはずだ。
それが全く身についていないのは「労働問題に全く関心がない」証拠。
設立から7年も放置していたのにこれから対応するなんて言葉には全く説得力がない。

「公正な評価」は客観的な事実の積み上げで行うべきだと思っているので主観的な評価を公正と思い込んでいて、法律違反を7年もやり続けているという客観的な事実からこの社長を「公正な評価」で判断すると「自信過剰な世間知らず」ということになる。

コピペ記事が技術をダメにする2017年09月28日 06時25分30秒

■きっかけ
最近IoT関連の技術開発のスタートアップの会社を取材しました。増資もして勢いがあるように見えます。若いけど優秀なエンジニアも揃っていて、と自信満々。いわゆる、はんだ付けカフェやレーザーカッター、3Dプリンタもそろえた「工作室」も一般に開放しました。
ところが、この会社のホームページのエンジニアが書いたArduinoでの温度センサーを使う記事が他のサイトのコピペ記事で、しかも、他の記事よりも質が悪い始末。
この記事は公開されてから4ヶ月以上放置されており、書いた当人以外のエンジニアもお粗末さを指摘していないということになります。
私はこの会社の技術力には疑問を持たざるを得ず、社長の資質にも疑問を感じる次第となりました。
社長に指摘の連絡をしましたが、「本人に伝えておきます」程度の反応でした。

■コピペ記事の弊害
コピペ記事の弊害はいわゆる検索エンジンに引っかかる複数の記事が「同じ」だということです。正しい内容ならもちろん問題ありません。
いくつかの主張のうちの一つを自分の考えで選択しているのならまだしも、無理解、無思想でコピペしてあたかもそれが正解かのような印象を持たせる。
間違っているのに数多くの記事で同じことを言っているのでそれを正しいと鵜呑みにする。
そこが問題です。

■技術の基本は考察と実験による実証
コピペ記事は書いてあることを鵜呑みにしてそれがソフトウェアであればコピーして実行して試しますが、それが正しい結果なのかの検証をしません。
なぜ、そのような計算をして、そのような結果が得られているのか。
それらを自分自身の頭で考えて検証してこその技術です。



温度センサーLM35DZを移動平均で処理する2017年09月26日 11時12分50秒


ADCからのセンサーデータをそのまま使うと様々な要因により値がふらつきます。
それを平滑化させるために移動平均という手法があります。

■移動平均の考え方
同じセンサーデータをある程度の数だけ格納してその数の平均値を求めるのですが、次々に新しい観測データを採用して古いデータを捨てていくという処理が移動平均です。

■移動平均に必要な処理構造
(1) センサーデータを一定数配列に保管します
(2) 一定数のセンサーデータの合計値を求めます
(3) センサーデータの合計値を格納数で割ると平均が求められます
(4) 配列に新しいデータを格納する時には一番古いデータを捨てます
(5) 一番古いデータを捨てる前にそのデータを合計値から引きます
(6) 合計値に新しいデータを加えます
(7) センサーデータ単体で平均値を求める代わりに最終的な換算時に加味することもできます

■サンプルプログラム
以前の記事のプログラムをベースに修正しています。
以下の部分が変わっています。
(1) 換算用のマクロの変更
(2) 配列へのADCデータ格納と合計処理の追加
(3) 配列インデックスをLED点滅に流用
(4) シリアル出力に合計値出力を追加
(5) 温度換算時に使うデータはADC出力の合計値を使う
移動平均版LM35DZ処理スケッチ

出力結果は以下のようになります。

移動平均版でのLM35DZ処理出力

■注意点
今回のサンプルではサンプリング周期と表示周期を同じ1秒としていますので室温測定には問題ありませんが、もっと早い応答性が必要な場合にはサンプリング周期をもっと短い間隔にして、表示や出力間隔とは分ける必要があります。

ADCの出力値をアナログ値に換算する考え方2017年09月25日 15時11分05秒

■ADC出力値からアナログ値を求めるやり方の問題
ADCから量子化されて出力されるデジタル値をアナログ値への換算を行う時に2^nで割るのか、2^n - 1で割るのかの問題ですが、ADCの内部の仕組みとしては以下図の左側で示したような配列とその要素のインデックスだと考えると問題が整理しやすくなります。
2^nとか2^n-1の代わりにここでは10bitADCを前提として1024と1023という数値でどちらかを表すことにします。

ADC出力値の換算方式の比較図


この図の左側で示した配列の条件は以下です。
(1) メモリ上の通常の配置とは逆のイメージ
(2) 10bitADC
(3) 基準電圧(VREF)は5.0V
(4) 1LSB = 5.0/1024.0 = 0.004882813V
(5) 上限(n) = 下限(n+1)未満の値

■1024で割る派の問題
ADCから出力されたデジタル値からアナログ値に換算するやり方で、1024で割る派の人たちは上記の「仕組み」を前提に話をしているわけですが、常に配列インデックスに対応したアナログ値の範囲の下限のデータを拾ってくることになります。
理屈から言えば上限を拾ってきても良いはずだし、下限と上限の中間の値を採用しても良いはずです。
この点が1024で割る派の人たちのおかしなところです。
現実的には下限であることは非常にまれでしょう。
シフト演算して処理を高速化するために1024で割るという主張の方がよっぽど説得力があります。

■1023で割る派には問題はありません
あえて問題があるとすればシフト演算での高速化はできません。
あくまでもブラックボックスとしてのADCを扱うため、出力値が0なら0Vだし、1023なら5Vとして係数を求めて度量換算する算数の問題として計算するだけです。
結果的に中間値を採用することになり、フルスケールに達すると確実に5Vになります。
もちろん、中間値とはいっても0の時は下限値を採用し、1023の時は上限値を採用するような変則的な対応付けが自動で行われることになります。
図の右側で示した通り左側の配列の下限値から上限値の間に換算値は収まっていることが分かります。
無思想でコピペ増殖で1024で割る派が多い中、数少ない1023で割る派の書籍はこちら

とは言え、実験してみるのは筋なので、実際のセンサーでの実験結果はこちら