orangeitems’s diary

40代ITエンジニアが毎日何か書くブログ

となりの職場を知ることができる良テックブログリンクまとめ

f:id:orangeitems:20210811170013j:plain

 

はじめに

技術者をやっていると自分の職場のやり方がスタンダードだと思い込みがちですが、いろんな職場でいろんな工夫が存在します。外に目を向けることで新しい発見がありますが、それだけの理由で何度も職場を変わるのは難しいですよね。

今は、技術部門が取り組んでいることを外部公開するテックブログがたくさん存在しています。一つ一つ読んでいくといろんな取り組みがありかなり刺激的です。

直近更新されているアクティブなブログを中心にご紹介します。

たくさんあるので、時間がいくらあっても足りないぐらいです!。

 

 

テックブログリンク集

BASE

devblog.thebase.in

 

Chatwork

creators-note.chatwork.com

 

DeNA

engineer.dena.com

 

DMM

inside.dmm.com

 

FIXER

tech-blog.cloud-config.jp

 

Google

developers-jp.googleblog.com

 

GREE

labs.gree.jp

 

GMOアドパートナーズ

techblog.gmo-ap.jp

 

GMOペパポ

tech.pepabo.com

 

 

LIFULL

www.lifull.blog

 

LINE

engineering.linecorp.com

 

mixi

mixi-developers.mixi.co.jp

 

PIXIV

inside.pixiv.blog

 

RACCOON

techblog.raccoon.ne.jp

 

Sansan

buildersbox.corp-sansan.com

 

SEGA

techblog.sega.jp

 

SMS

tech.bm-sms.co.jp

 

Yahoo! Japan

techblog.yahoo.co.jp

 

Wantedly

www.wantedly.com

 

 

ZOZO

techblog.zozo.com

 

エムスリー

www.m3tech.blog

 

カヤック

techblog.kayac.com

 

クックパッド

techlife.cookpad.com

 

グノシー

tech.gunosy.io

 

クラスメソッド

dev.classmethod.jp

 

サイボウズ

blog.cybozu.io

 

サイバーエージェント

developers.cyberagent.co.jp

  

さくらインターネット

knowledge.sakura.ad.jp

 

ハートビーツ

heartbeats.jp

 

はてな

developer.hatenastaff.com

 

マネーフォワード

moneyforward.com

 

メルカリ

engineering.mercari.com

 

モノタロウ

tech-blog.monotaro.com

 

ユーザベース

tech.uzabase.com

 

リクルート

engineer.recruit-lifestyle.co.jp

 

ローソン

techblog.ldi.co.jp

 

 

まとめ

調べてみたら、ほんとたくさんありますね。

各現場で、仕事に波があって、時間ができたときに更新する感じですかね。

しかし本当、会社によって取り組んでいることがバラエティに富んでいて、読んでいると自分のフィールドが狭いことを痛感してしまいます。

お時間あるときにたまに周回するのが良いかもしれません(日々更新されていますので)。

本ページは、適宜追加・更新していきたいと思います。

 

競争社会で埋没しないための考え方

  

f:id:orangeitems:20210810234555j:plain

 

能力が高い人。

社会で能力が高いと言われる人の人数は多すぎてもいけない。なぜならば、能力が高いイコール報酬が高い、という条件を満たさないといけないが、社会全体の富は有限なので人数も絞らなければいけないからである。だから競争は必ずあるし、その中から勝ち残った人が、能力の高い人とされる。

競争ありきなので、相対評価を基本とする。

 

中程度の能力の人。

学校教育とは実はこのゾーンの人を大量に生み出す制度である。学校教育は天才を生み出すためには特化されておらず、労働力になることができる中程度の能力の人々を安定的に生み出すことに特化している。

過去は受験戦争なので勝ち負けを気にする教育を進め過ぎたために、競争における負けとされる人を生み出すこととなった。その反省から絶対評価に代わり、たくさんの人々が負けない制度に変わった。これは、中程度の能力の人を傷つけないための配慮であり、今もって安定的に稼働していると思う。

学習塾は「能力が高い人」になるために学校教育の外で対応を行う制度であるが、最近聞いた話では、中国では営業目的の学習塾が禁止されてしまったらしい。それは、たくさんの中程度の能力の人が、「能力が高い人」になろうとして教育費が高くなりすぎ、少子化の原因になってしまったからだそうだ。思い切りのいい国だなという感想だが、一方で理にかなっているような気もする。教育費にお金をつぎ込むのは一種のチートに近いからだ。全体主義から考えると、チート行為は取り締まらなければいけない。全員同じ条件で競争させたほうが、より客観的に能力格差がわかる。

 

能力が低い人。

社会にとって「能力が低い人」というカテゴリーは少ない方がいい。

なぜならば、働くことが難しくなるからだ。

能力が低い、といってもある分野に関してであり、特定の分野については秀でるものがあるかもしれない。

だから、いろんな分野が存在し、どこかで受け入れられるような社会が望まれる。能力が低い人、というのは、見つけられなかった人である。でも探し方が悪いのかもしれない。今、社会が多様性、ダイバーシティーを広く叫んでいるのはオリンピックを見てもわかるが、裾野が広がれば広がるほど、たくさんの人が救われるはずだ。

学校教育のどの科目でも能力が低いと言われた人が、ある趣味の分野では日本、いや世界に通じてしまうと言うことだってあり得るのが世の中だ。だから、人間に対して、ある決まった尺度だけで評価するのではなく、たくさん挑戦するカテゴリーがあり、どこかで能力を発揮できる。そんな社会の仕掛けが必要であろうと考える。

 

と、能力の高中低によって人間を大まかにカテゴライズしたが、この考え方において、現代社会がずれ始めている。それは、仕事が多数の人間を必要としないケースが増えていることだ。昔は労働力=人数、という式がなりたった。今はITやロボティクスなど、人間を肩代わりする技術が大変向上した。いわゆる知識集約型と言われる働き方は、一部の能力の高い人間だけで、あとは機械化、IT化を進めればたくさんの労働力は不要にになる分野が育っている。

こうなったときに、もし「中程度の能力の人」にカテゴライズされ、単に会社の言うとおりにアサインされた部署で社会人生活を安泰に終えられるかは非常に危うい時代となった。自分の仕事を奪いに来るのは他人ではなく、ITかもしれない。

 

ちょっと前に業界で話題になった話がある。

 

xtech.nikkei.com

 東京高裁が特に問題視したのが、システムの仕様を策定するうえで重要な役割を担っていた野村証券のユーザー部門「X氏」の振る舞いだ。

 当時、投資顧問事業部(判決文では「投資顧問部」)の次長だったX氏は、パッケージソフトに合わせて業務を最適化するという会社の方針に反して自身の現行業務を維持することに固執。プロジェクト途中で追加要件を多発し、日本IBMの担当者らに対して「辛辣な他罰的、攻撃的発言」(判決文)を繰り返した。

 東京高裁は判決文でX氏について「自分の庭先(担当業務)をきれいにすることだけを考えている」と認定。断続的に変更要求を多発するX氏から、目標としていた2013年1月の稼働開始に間に合うのかについて「質問がなかったのが不思議なくらいであった」(判決文)などと指摘した。

 

この件、本文をよく読んで理解してもらいたいが、X氏は自身の業務をパッケージソフトにいわば奪われんとしていたのだ。

単にベンダー対ユーザーの係争ということより、まさに業務と人間の関係について考えさせられる一件となった。

この世の中は、ITの進化によって、大多数の人間が生きにくくなりつつあるのかもしれない。そうなると、プレーンで人数の多い「中程度の能力の人」は、かえって不利が生じやすくなっているのかもしれない。労働力がどんどん不要になっているのならば、だ。

 

この前、

 

 

とツイートしたが、この話にも通じるかもしれない。

多様性は認められる世の中になっているから、誰も挑戦していないようなマイノリティーの分野にどんどん挑戦したほうが、埋没しない存在になれるのかもしれない、と思った。オンリーワンはやっぱり強いのだ。

 

個人情報保護法の施行内容が2022年、大幅に変わる件まとめ

f:id:orangeitems:20210810164545j:plain

 

個人情報保護法が変わる

これは重要なお話。

日本の個人情報に関する決まりは、「個人情報保護法」で制定されているのは誰しも承知している話だとは思いますが、施行内容が2022年4月(令和4年4月)から大幅に変わります。

具体的には二本柱です。

①令和2年改正→2020年4月に改正。施行は2022年4月からとなる。

②令和3年改正→2021年5月に改正。施行は1年以内とされている。

大きな変更が①の方に含まれていますが、この際①も②も両方踏まえておけば、時代の変化についていけます。

今回の変更に関しては国民にもあまり周知がされておらず、IT業界に属していてもあまり話題になっていないので、ここでまとめておきたいと思います。

 

要点をまとめた良い資料

法令の変更を原文で読んでもなかなかわかりにくいので、よくまとまっている資料をご紹介します。

 

www.mhlw.go.jp

 

こちらの「資料3-2 個人情報保護法 令和2年改正及び令和3年改正案について」という資料がとてもとても学習に最適な資料となっています。

この資料、「個人情報保護委員会(PPC)」自体が作った資料ですから当然ですね。

さらにこの資料から、重要なポイントをまとめていきます。

 

令和2年改正まとめ

1. 個人の権利の在り方

利用停止・消去を利用企業に請求できる権利が拡充される。法違反の場合に加え、個人の権利や利益が害されるときにも可能になる。

・これまで書面での開示だったが、個人が、デジタルでの開示を利用企業に指示することも可能になる。

第三者に提供したかどうかを、個人が開示請求できるようになる。

6カ月以内に消去するデータも、個人データに含めることにする。

・オプトアウト規制の強化。これは分かりにくいので下記をご紹介します。つまり、第三者に個人データを使わせることに対して規制を強くしたということです。

 

business.best-legal.jp

⑤ オプトアウト規制の強化
2019年4月に、個人情報保護委員会がオプトアウト届出事業者に対して、実態調査を行ったところ、本人が提供した覚えのない形で名簿が商品として流通していること等が判明しました。

この結果等を踏まえ、オプトアウト規定(※本人の求めがあれば事後的に停止することを前提に、提供する個人データの項目等を公表等した上で、本人の同意なく第三者に個人データを提供できる制度)により第三者に提供できる個人データの範囲を限定することとしました。

 

2. 事業者の守るべき責務の在り方

① 漏えい等報告の義務化

漏えい等が発生し、個人の権利利益を害するおそれが大きい場合に、委員会への報告及び本人への通知を義務化する。

⇒これまでは義務ではなかった。

 

② 不適正な方法による利用の禁止

違法又は不当な行為を助長する等の不適正な方法により個人情報を利用してはならない旨を明確化する。

⇒何が不適正なの?という問いに対して下記の例が挙げられています。

・ 違法行為を営む第三者に個人情報を提供すること。

・ 裁判所による公告等により散在的に公開されている個人情報について、差別が誘発されるおそれがあることが十分に予見できるにもかかわらず、それを集約してデータベース化し、インターネット上で公開すること。

 

3.事業者による自主的な取組を促す仕組みの在り方

○ 認定個人情報保護団体の充実

認定団体制度について、個人情報を用いた業務実態の多様化やIT技術の進展を踏まえ、企業の特定分野(部門)を対象とする団体を認定できるようにする。

 

4.データ利活用の在り方

① データ利活用に関する施策の在り方

イノベーションを促進する観点から、氏名等を削除した「仮名加工情報」を創設し、内部分析に限定する等を条件に、開示・利用停止請求への対応等の義務を緩和する。

⇒ここ、すごく重要です。テストに出ます。3つの区分をおぼえましょう。

・個人情報

仮名加工情報(新設)

・匿名加工情報

これらは、下記の扱いとなるそうです。

f:id:orangeitems:20210810160656p:plain

⇒これまでは個人情報と、「本人が一切わからないよう加工した」匿名加工情報の、二択でした。この中間が生まれたのです。

「他の情報と照合すれば本人とわかる」というのがポイントです。

そして、「漏えい等報告等」に×がある通り、報告義務がないというのもポイントです。完全に匿名化してしまうとデータ分析に使えず、一方で個人情報の形で使うと扱いが難しくなる。この中間の存在である「仮名加工情報」を生み出すことにより、データの活用を活発にする反面、制限するところはしておこうという内容のように読めます。また、匿名加工情報と違って、第三者提供も原則禁止されています。

 

② 個人関連情報の第三者提供規制

提供元では個人データに該当しないものの、提供先において個人データとなることが想定される情報の第三者提供について、本人同意が得られていること等の確認を義務付ける。

⇒ひどい話ですが、たくさんのデータを集める会社があって、その会社では個人まで特定できない。それぞれデータはID番号で管理しているから。でもそのデータを別の会社に転売。そこではID番号と個人名を紐づける表を持っていて、個人を特定できる。そんなやり口が横行しているそうです。

今後は、最終的に利用する場合に個人データとなるのであれば、収集時に本人の同意が必要になるとのことです。

 

5.ペナルティの在り方

① 法定刑の引き上げ等

・委員会による命令違反・委員会に対する虚偽報告等の法定刑を引き上げる。

・命令違反等の罰金について、法人と個人の資力格差等を勘案して、法人に対しては行為者よりも罰金刑の最高額を引き上げる(法人重科)。

 

⇒下記の通りです。特に罰金については法人で1億円以下まで引き上げられていて、なかなか重たい科料となっています。

f:id:orangeitems:20210810162143p:plain

 

6.法の域外適用・越境移転の在り方

① 域外適用の強化

日本国内にある者に対する物品又は役務の提供に関連して個人情報等を取り扱う外国事業者を、罰則によって担保された報告徴収・命令の対象とする。

⇒日本でビジネスをするなら、外国事業者であっても日本企業と同様に取り締まるよ、ということです。

 

② 越境移転に係る情報提供の充実

外国にある第三者への個人データの提供時に、移転先事業者における個人情報の取扱いに関する本人への情報提供の充実等を求める。

⇒同意したから自由だよねではなく、同意する際にどこの国に移転するかもしれないということを本人の情報提供すること。

⇒移転先事業者の取り扱いを定期的に確認すること。本人にも求めに応じ情報提供すること。

 

令和3年改正まとめ

① 個人情報保護法、行政機関個人情報保護法、独立行政法人等個人情報保護法の3本の法律を1本の法律に統合するとともに、地方公共団体の個人情報保護制度についても統合後の法律において全国的な共通ルールを規定し、全体の所管を個人情報保護委員会に一元化。

医療分野・学術分野の規制を統一するため、国公立の病院、大学等には原則として民間の病院、大学等と同等の規律を適用。

③ 学術研究分野を含めたGDPRの十分性認定への対応を目指し、学術研究に係る適用除外規定について、一律の適用除外ではなく、義務ごとの例外規定として精緻化。

個人情報の定義等を国・民間・地方で統一するとともに、行政機関等での匿名加工情報の取扱いに関する規律を明確化。

 

⇒下記の絵がわかりやすいでしょう。行政機関や学術機関については、これまで縦割りで法律が分かれていて、何やらわからなくなっていたので、とにかく統一できるものは一つにする、と言う考え方が貫かれています。

f:id:orangeitems:20210810163208p:plain

 

⇒また、学術研究はこれまで何がなんでも適用除外だったものが、何が除外されるのか細かく書かれました。学術研究の自由を守りながらも、安全面を強調しているように見えます。

f:id:orangeitems:20210810163632p:plain

 

全体まとめ

これらの変更を読めば読むほど、ここ最近でネットを騒がせたいろいろなニュースが反映されていると思いませんか。データの外国企業への移転や利用、法のすり抜け、本人が認識していない形でのデータ利用・・、それらに対応しつつ、仮名加工情報なる概念を生み出し、企業のデータ活用自体はむしろポジティブに整備しています。制限でがんじがらめにすると経済活動が委縮してしまうので、バランスを取っているように見えます。

昨今のDXにおいては、データを利用しないシーンはほぼありませんので、今回の変更はよく理解しておくべきでしょう。

 

※補記

今回引用した図は、

「資料3-2 個人情報保護法 令和2年改正及び令和3年改正案について(個人情報保護委員会作成)」

を利用しています。

 

システム運用における何もしないことの尊さ

f:id:orangeitems:20210809232051j:plain

 

夏期休暇のある会社も多いと思いますがそういった休暇期間の前は、大きなシステム変更はできるだけ行わないのが鉄則です。

なぜかと言うと、システム障害の発生率はシステム変更後に高くなるからです。何も変更しない場合は本当に大きな障害は少ない。システム変更と言ったってアプリケーションの変更から、再起動を伴うメンテナンスまでいろいろです。とにかく、大きな休みの前には変更はするな、と。一週間で言えば金曜日は土日の前なので作業はあまり入れません。翌日休みの日に何か起こると対応が遅れるからです。

システム変更を行った際にそれらが全て想定通りに行われたらよいのですが、実は作業内容に勘違いが含まれていて誤作動の原因となったりもします。しかも修正した直後は気づかなくて少し時間が経ってからその間違いが何らかの障害を引き起こします。ところがそのときに休暇がはまっていると、休暇中であれ誰かが修正しないといけないのですが、直接の担当者はつかまらないかもしれません。誰か別の担当者がアサインできたとしても、問題の原因にたどり着くかと言えば、着くかもしれませんが時間がかかります。直近で行った作業も詳しくは知らないので、中身を確認しなければいけません。しかもその作業が別の部門からの依頼だった場合には、その部門の関係者まで連絡し、調整しなければいけないかもしれません。もし顧客向けのシステムだった場合は、顧客に連絡するために営業部門との調整しなければいけません。休み中にリスクを負うのを避けるために、作業はできるだけ凍結します。

昨今は、変更を短期間にできるようにしようと、Kubernetesなどコンテナを使ったCI/CDと呼ばれる開発サイクルの高速化は良く話題に上ります。リリースした後何か問題があったらすぐに戻す(ロールバック)ことでリリース時の問題の戻しも自動化する。一見良いことなのですが、冒頭のシステム変更直後に障害リスク確率が上がることを考えると、あまり真に受けられるものではないのではないかと思う次第です。

CI/CDであっても、リリース期間を短くすることは避け、テストやリリースに対する手間が楽になった部分はもっと品質の向上に時間を使ってほしい、ということです。ソフトウェアはテストに合格すれば必ず正しく動くというのは言い切れません。テストの考慮ミスや、そもそもの仕様変更がユーザーフレンドリーではなく、批判にさらされ戻さなければいけなくなるということもあり得ます。どんどん変更していくというCI/CDのイメージの方が先行していますが、これまでのシステム運用の経験から考えると、たくさんの変更は、想定外の状況を引き起こしやすいです。また、ロールバックしたときに、本当に前の状態に戻るかも100%とは言い切れません。なぜならシステム変更後にデータ構造を変える場合があり、戻したら戻したで不具合が出る場合もあるからです。

元々アジャイルやCI/CDが指示された理由としては、ウォーターフォールではビジネスのスピードに追随できない。ビジネス環境の激変の速度に追いつけない、というものがありました。

ではアジャイルでは追いつけるのかというと、少し単純化し過ぎて現場を見ていないと思います。リリースのスピードを上げると言っても月に一度程度。そして不具合によるロールバックはおそらくユーザーにはほとんど許されません。例えば何かのスマホゲームでリリース作業がありメンテナンスでプレー中止を十時間行い、何かその後不具合が見つかって緊急メンテナンスに入ったとしたら、ユーザーが不満を覚えますよね。だから、簡単に戻せるからCI/CDがいいというのは短絡的です。リリース作業に対する負荷を減らしたのなら、リリース感覚を短くするのではなく、品質の高いリリースを行うことに空いた時間を使うべきです。

私もいくつかのシステムの運用を預かっていて、たくさんの変更を行うシステムとそうでないシステムの間で、どう見てもシステム障害とは言わないまでも手間が増えることについて、明らかな差があると感じています。ぜひ、変更はリスクを伴うことは、どんなにシステム基盤が変わっても、頭の中に入れておきたいものです。

 

人間が不要になるぐらい全部システムで自動化できればいいんじゃないか、に対する解答

f:id:orangeitems:20210808002945j:plain

 

全部自動化すれば・・

システム運用の仕事をしていると思うのだけど、基本的にはいろんな自動化の塊で動いている。それなら、もう人間が不要になるぐらい全部システムで自動化できればいいんじゃないかと思わないだろうか。なぜコンピューターが全部自動でやってくれるのに、そこに、人がいなければいけないのか。それすらも自動化できないものか。

自動化ができないケースをいくつか経験しているので書いていきたい。

 

 

自動化できないケース

障害対応

監視は24時間人が張り付いてチェックするわけには行かないので、監視サーバーを立てて一定期間ごとにチェックさせる。その上で問題が発生するレベルを事前定義し、それを超えたらメールなどで人間に知らせる。そこまでは自動化されている。

そこで人間に知らせるまではいいけれど、そのアラートを消しこむのは人間の仕事になる。傾向を確認し、すぐに対処しなければいけないのか。それともすぐには対処しなくてもシステムには影響なく、調査に時間が与えられるのか。人間が判断し、優先順位や緊急性を定義し、解決に向かって進めていく。

この解決プロセスに対して、ある決まった条件においては、ソフトウェアの再起動をすぐに行うなど、単純なことであれば自動化は可能だ。ただ、問題はほとんどの場合、そんな簡単な話では終わらない。

いや、もし問題が発生した時に、何も確認しないでいきなり処置を自動でされると、かえって症状が拡大する場合もある。本当は再起動などする必要もないのに強制的に再起動してしまい、人間の手を入れないと再起不能になる場合だってある。

スプリンクラーが火気を検知し水を出すという仕組みだって、例えばデータセンターの中で簡単に水をまき散らしていたら、機械は壊れてしまう。問題を検知するということと、それに対して自動的に対処を行うというのは、全然レベル感の違う話なのだ。

 

正常性確認

また、障害対応以外にも自動化しにくい部分もある。システムの正常性確認だ。毎朝、システムが正常に動いているか確認を行うが、結構多岐にわたるので、この確認を自動化できないか考えたことがある。システムの動作レポートを毎日出力しているが、これを出力する際に自動的に人間が確認している項目をプログラムで確認し、問題があればメールを送るようにしたらどうか。そうすれば、毎朝、動作レポートをチェックする必要はなくなり、アラートが来た時だけ動けばよいではないか。

しかしこの考え方には穴がある。レポートを送ることができないくらいシステムに異常があったとき、何もアラートが届かないので以上に気づけなくなる、ということだ。

つまり、システムが正しく動いてますよ!というレポートを毎日確認することが、「問題があるときだけアラートメールを送る」という工夫に変えてしまうとどうなるか。

・システムが正しく動いているのでアラートメールが来ない

・アラートメールを送る機構自体が動いていないのでアラートメールが来ない

この2つが見分けがつかないのだ。

 

履歴管理

運用の中でいろいろ雑多な情報処理を実施するのだけど、実際に何をやったのか、についてまとめるのはやっぱり人間しかできない。

毎日仕事の終わりの時間に、今日何やったっけ・・と思い出すとそれはもういろんなことをしていて、まとまりはない。

課題管理システムなどで自動的にやり取りのログは残るので、読み返せば一目瞭然にはしているのだが、これらを定期的に表にまとめ、履歴の管理をするようにしている。じゃないと、全部のやりとりを課題管理システムを開き読み込むわけにはいかないからだ。

この、人間がいろいろと手を動かしたことについて、自動的に状況をまとめるためには、秘書でも雇えばいいのかと思うこともあるが、その秘書も情報処理の知識がないと務まらないだろう。人間であればいいというものでもなく、ある程度知識のある人が状況をまとめないと務まらない。

将来AIがこの分野をやってくれるようになるのだろうか。ユーザーの気持ちがわかり、文面の行間を読み、端的にまとめることができるというのだろうか。

自動化の道は険しいと思う。

 

たまに不思議になること

システムエンジニアというのは、とにかく自動化することには前向きな種類の人間だと思っている。武器としてはプログラミングや各種ソフトウェアがある。うまく設定したり構築したら、人間がわざわざ作業をしなくて済むようになる。

そして、考え付く限り自動化に取り組み、ひと段落して思うことがある。なぜそれでも、人間(自分)がここにいて、今日も何か仕事をしなければいけないのか。

自分自身すら自動化できないのか、と思うのだけど、それは少し哲学的な領域に入るのではないかと思われる。

AIは、これに対する解、となる予定だけどどうにもまだ私の近くには来ていない(気づいてないだけかもしれないけど)。