城谷 信一郎

私も業務柄様々なデータを利用しますが、プライバシーポリシーの第三者提供先にNEVER社が入っていないのにも関わらず、個人関連情報である位置情報を送ったのが問題かと思います。 多分これですかね。 https://privacy.yahoo.co.jp/acquisition/thirdparties.html どういう意思決定プロセスが踏まれたかは不明ですが、検証目的だったとのことなので、現場サイドが仕込んでしまったのか。。 ただ、エンジニア、現場もこういった個人情報保護法・GDPR・CCPAなどの法律や自社サービスのプライバシーポリシーを理解しどういう影響があるか。把握しておくべきだと考えています。知っていれば防げた。

流石の朝日 専門家批判も具体的な指摘は無く、印象論に終始

これでも擁護している人が居るのは驚きですね。 開発API終わらせてたり、開発者振り回しておいて今度スクレイピングが来たから、一般ユーザーの閲覧含めて締め出す。 その場、その場の対応で悪化させている。。

いくら個人を特定、推定する情報が無くても移動履歴や行動ログは個人関連情報で、個人情報ですからね

こういうインシデントが起きると、過剰に怖がる方や経営者がいるかもしれませんが、これらのデジタル化は不可逆で乗り越えなければならない事です。 システムを厳格にした所で、人間というバックドアがあるので一重にも二重にも対策と監査が必要です。また、厳しさだけではなく、運用性、効率性の考慮を行わないと、今回のケースや尼崎市のケースなどを引き起こしかねません。 確かに閉域網にすれば安心と言う、ある種のスキルやシステム自身を堅牢にする機会を奪っていった側面もあると思うので、ゼロトラストの考え方にアップデートが必要です。

出島形式で待遇を上げるのは良いのですが、 * 事業課題に向かう際に、ビジネスとの距離が生まれる * 相互理解が生まれなかったり、無用な軋轢（待遇差）が生まれて業務進捗に影響を与える * 上手くいくと、様々な事業・プロジェクトに投入されてしまし、コンテクストSwitchによりパフォーマンスが大幅に低下する。 といった事から、基本的には事業会社・事業部門の中に所属して、一緒に開発を進める事を私はおすすめします。 とは言え、孤立しがちなのでギルド的な活動も同様に計画する必要があります。

この人数で回ってる事は、自動化、仕組み化ができている事の表れでしか無いと思います。 SREチームは、チームごと解雇みたいな話もあるので、複雑な分散処理システムについて、何かトラブルが起こった際にどうなるか。。 もう少し見守る必要はあるかと思います。

データ基盤を開発、運用するデータエンジニアは、かなり不足しています。 バックエンド、インフラのスキルを持ちつつも、データモデリングやコンサルティング、課題定義などマルチに貢献する必要があり、エンジニアの2次職。 AI,MLもデータ活用の一つの出口にすぎません。全ては、ガバナンスが効いたデータプラットフォームの存在が必要です。 この辺りの理解と人材が広がることを願います。

Grammarly…. 使ってますよ！！

日本はイーロン好きが多いので相性良さそう。 主要エンジニアは辞めていったと言う話があるが、 今後Twitterはどうなっていくか。。

よくある話。 ソースコードに鍵情報を記載するのは絶対にダメという、エンジニアにとっては当たり前の知識が浸透してほしいですね。 ソースコードが公開リポジトリで漏れてしまったとしても、鍵が無ければ、アクセス出来ないわけですし。 こう言う事があると、とりあえずIP制限。棚卸し業務。チェックリストと本質では無い業務が増えていく。。