ken1flanのブログ

自己紹介・最近やってることなどを書くつもりです。

情報セキュリティ対策自主研修 第22回 「ディスインフォメーション（偽情報）について知ろう」を開催しました

トロイの木馬

情報セキュリティ対策自主研修 第22回 「ディスインフォメーション（偽情報）について知ろう」を開催したので、簡単な感想を書きます。

題材

イベントページを作っていたときにちょうど台風・大雨などの自然災害が多かったせいか、「偽情報に注意してください」という注意をよく見かけました。IPA NEWS Vol.97で折よくやっていたので、チョイスしました。

感想

  • とにかく掲載されていた図の3つ分類がホントによかったです。
  • 古代から近代とずっとディスインフォメーションは使われていて…現代はディスインフォメーションとサイバー攻撃と組み合わされるようになって本当に大変な時代になったんだと思いました。
    • 古代ギリシャの「トロイの木馬」…トロイアに捕虜を使って偽情報を流して、アテネが退却したと思い込ませることで油断させて…。
    • 日本の中世の「桶狭間の戦い」…織田軍は少数という情報から今川軍が油断したところを、夜襲して…。
    • 近代イギリスMI15による「オペレーション・ミンスミート」…嘘の経歴を作り込んだ水死体に偽の極秘文書を持たせたものを敵方に拾わせる…。
    • 現代ウクライナで、政府と国営銀行をDDoSでダウンさせたところにATMが機能停止したという偽情報…ウクライナ国民が冷静だったので失敗したそうですが…。 ‐ 偽情報は感情を揺さぶって拡散させようとする…という、クラファンでシェアしてもらうときに感情を揺さぶるようにしてたので、びっくりした…という話が出ました。
    • 感情を揺さぶるのは、マーケティングの手法として普通ですよね…。
    • そうそう、これはずっと思っていて…ヒトラーの「我が闘争」を読んでみなければってずっと思ってます…。（いまだ読んでないんですが…。）
  • IPA NEWSの記事を読んだときも、今日この勉強会をやったときも、まさに「情報戦の戦場」に自分も立っていて、当事者なんだな…と思いました。
    • 結構のほほんと生きてきたので、ショックでした。

運営としてのふりかえり

KPT方式で。

前回のTry

  • 事前準備

Keep

  • 社外のひとが耳だけ参加者として来てくれました。
  • 今回の題材がよかったという感想をもらえてよかったです。
    • クラファンを拡散する際に、「感情を揺さぶる」ようにしているので、同じ手法なのかと驚いたとのことでした…。
      • ウチはちゃんとソースがあるので大丈夫なんですが…！
    • IPA NEWS Vol.97はおもしろかったので、よかったら読んでみてください…！

Problem

  • もうちょっと人がいたらなぁ…。

Try

  • 事前準備
  • 題材の決定

おわりに

参加してくれたみなさん、ありがとうございました！ あとでざっと見直しても、やっぱりひとりで読むより、圧倒的に気づくことが多いので、今後も継続してやっていきたいと思います！

メモ

  • 終わったあとにやること
    • [x] Google Meetのメッセージの保存
    • 謝辞と感想
      • [x] twitter
      • [x] facebook
      • [x] mastodon
      • [x] bluesky
      • [x] threads
      • [x] connpassのイベントメッセージ
      • [x] ブログ
  • 次回準備
    • [ ] Google Slides
    • [ ] カレンダー/Google Meet URL
    • [ ] connpassイベント
    • [ ] ネタぎめ
    • x] 告知
  • 直前
    • [ ] 告知
    • [ ] リマインドメール

プリンシプル オブ プログラミング 第2章のメモ

www.shuwasystem.co.jp

プリンシプル オブ プログラミングの読書メモです。

第２章 原則 ～プログラミングのガイドライン～

2.1 KISS

‐ Keep It Simple, Stupid. ‐ 口が悪いなぁ…。UNIXらしいともいう…？ - シンプルに、は常に気をつけてます。 - 「こんなこともあろうかと…」の誘惑と日々戦ってるともいいますが…。 - シンプルに保とうとして結構大変なのは…要求が増えてメソッドの扱う機能が増えそうになるときかも。ちゃんと分割したりしなきゃいけませんが…サボりたくなりますね…。 - …結構頭イタイ>< - ウチは頑張ってテスト増やしたから、ちゃんと分割しよーぜ…！と自分に言い聞かせよう…。 - シンプルを保つのに役立っているのは…テストを書くことかも。 - 複雑なことをすると…テスト書きたくねぇ！って思いますもん。 - そういうときには機能をバラしたりして、シンプルなテストを書いて…その後にパーツを組み合わせて作ったもとのメソッドには、主たるケースのテストだけ書くみたいなことをしてます。 - 自分は自社システムの開発をやっているので、そもそも要求が無駄でないかとかも気にしていたりします。 - The Art of UNIX Programming - アスキードワンゴは読んでないです。気になる…。 - 達人プログラマー（第2版） 熟達に向けたあなたの旅 | Ohmsha…また出てきました。読まないとなあ。

2.2 DRY

  • これは結構気にしてます。
  • その場でゴニャっと書いちゃうとラクっちゃラクなので、いつも誘惑と戦っているというか…。
  • マジックナンバーも含まれるのは知りませんでしたφ(･･
  • どうしてのところ、キツイなぁ…わかりすぎて><
    • 読むのが大変、あちこちにコピペコードが散らばってて修正が大変、そういうのに限ってテストがない…詰んでる…。
    • もはや、バグってもしゃーない、とやるしかないけども。
  • DRYはテクニックというか、方針かしら。実践しようとすると実にいろんな手を使うことになるし。
  • 間違ったDRYはあとから結構大変なことも…。
    • 今（あんまり内容を考えていないがために）形が似ているからとまとめた処理が、あとから全然違うものだとわかって涙することは結構ありました。（今もある…どうしよう(T_T)）
  • テストのないコードはよくないコード…それは間違いないと思います。
    • なにかするたんびに「エイヤッ！」と気合が必要なのはイヤすぎます…。
  • 達人プログラマー（第2版） 熟達に向けたあなたの旅 | Ohmsha…また出てきました。読まないとなあ。

2.3 YAGNI

  • KISSと似てる…。大事だからですかねえ…。
  • 必要なだけ、極力シンプルに、はいつも気をつけてます。
    • 誘惑が多いですが…。
  • O'Reilly Japan - プロダクティブ・プログラマ
    • これはノーマークで読んでませんでした。

2.4 PIE

  • コードの意図を伝える ‐ Rubyに慣れてきたころから、超気をつけるようになりました。
    • RSpec、Cucumbarが衝撃的でした…。これをできるようにしているRubyもまた衝撃的でしたね…。
  • 「書かれる」より「読まれる」ほうが回数多いでしょ？…は超納得…。
    • 長い期間同じ現場で働くことが多かったから、何度も実感しました…。
  • 読めないコードは……つまり、レビューのときに読みたくないコードも同じかも…。

2.5 SLAP

‐ コードのレベルを合わせる……。気にしているけど、うまくいってるかいつも自信のないヤツですね…。 - 本の目次、内容のように…？なるほど、そういうふうに考えたことはなかったです。 - 並べ方はどうしたらいいんでしょう……？ - このサンプルのようにしているつもりですが、あとから書き足したりするとぐちゃぐちゃになりがちで…。 ‐ 「要約」はよく使います。 - これもプロダクティブプログラマー。

2.6 OCP

‐ オープン・クローズドの法則 ‐ あんまりインターフェイスって作ったことないなぁ…と思ったら、過度の適用が起きやすいのか…。 - 2度目から本格対応、は確かに自分もそうしてます。 - 適用のポイントは…これもよく考えることかも…。 - 読み進めたら、ポリモーフィズムもここに入るのか…。じゃあ、結構適用を考えているかも。 - バリエーション防護壁…大小さまざま使っているかも。 - アジャイルソフトウェア開発の奥義 第2版 | SBクリエイティブ…うーん、読んでません><

2.7 名前重要

  • 最重要！
    • なるほど、名前をつける行為と名前そのもので、それぞれ別に価値があるとは…その通りだと思います！
  • コードを読むひとへのUI…たしかに。
    • 逆に変な名前がついていると、途中でわかんなくなります><
    • テキトーな名前は、それ以降読むひとへの負荷をあげちゃうって…確かに…。
      • とっとと変えよう…。
        • 前の読書会を思い出して、開発ベンダーとして入っているときはこういう気軽なムーブが禁止されているようで…ツラそうでした。
  • 短い名前をつけると、頭の中でその名前と実際のイメージを紐づけるから、メンタルマッピングという…と。
    • 誤解しやすい名前だと…もっとツライのはイメージの取り消しが最初に入るから…？
      • キツすぎる><
  • 名前からちゃんと機能が復元できるように、というのは無意識に大事にしてました。ループバックチェックという言葉を知っておけば、意識的にできそうです。
  • まつもとゆきひろ コードの世界 | 日経BOOKプラス…うーん、読んでなかったです。

この章を読んで

  • 大事なことしか書いてない…。当たり前かあ…。
  • KISS、DRY、YAGNI、PIE、名前重要 はいつも気にかけてて、やってるなぁという感じです。
  • SLAP、OCP は…気をつけてるけど、ちょっと自信ないです。
  • いろいろ思い出せてよかったです。

プリンシプル オブ プログラミング 第１章のメモ

www.shuwasystem.co.jp

プリンシプル オブ プログラミングの読書メモです。

第１章 前提 ～プログラミングの変わらぬ真実～

1.1 プログラミングに銀の弾丸はない

  • 困難性
    • 同調性
      • 開発者も見落としがち…。
      • 単独ではなく外部と接続されて存在しているから…というのは最近ようやく他のひとへの説明にできるようになってきました…。
    • 可変性
      • さらなる要求を思いつく、のは普段から身に沁みてますね。
      • 早い段階で見せながら、仕様と工数の調整を繰り返して完成に向かうのが、アジャイルってことかしら。
  • 偶有
    • ぐうゆう…パッと読めませんでした><
    • 本質的なところには銀の弾丸はないけど、周辺はツールや技法で大きく改善…されますね。
      • 普段から幅広く情報を得るようにしたいと思っています…。 ‐ 人月の神話は読まねば…と思いつつ、読めてません><
    • CODE COMPLETEは読みました！

1.2 コードは設計書である

  • わかる！大事にしてる！
  • そりゃ、昔のコンピュータで処理速度が足りないから一部アセンブリとか…今はほとんどないでしょ…。
    • まぁ、Rubyだけでライブラリを書くと遅いから、C言語使うとかはありますけど…。
  • CASEツールとかUMLは昔夢見てましたね…。今は全くできる気がしてません><
  • 仕様をコード化するだけの仕事と思ってるひとがいる…？
    • そんなちゃんとした仕様書を書けるひとなんかおるんかいな…。
    • これも、動くのを見たら、うーむってなって結構変えたり…しません？
  • 全員が全工程をやるのが一番…まったく同意です。
  • ロゼッタストーン……めっちゃほしいけど、うまく書けない……。
    • アジャイルでドキュメントを書かないなんて言ってない、書こうって言ってるひとは多いけど…。
    • こんなこと書くといいよ、的なものがほしい…。
      • README.mdをちゃんと書くところからかなぁ…。
  • コードにはWhyがない……必要なときにはコメントかコミットログか、プルリクエストに書くようにしてます…！
  • アジャイルソフトウェア開発の奥義

1.3 コードは必ず変更される

‐ せやせや。 ‐ 「コードは無常である」…なんかかっこいいなw - 無常は仏教からなんですね…。 - 絶対変更が必要になる→変更に強いコード→ …ときて、たしかに「読みやすいコード」は変更しやすいに直結してますね…。 - 達人プログラマー（第2版） 熟達に向けたあなたの旅 | Ohmsha - 読みたいと思いつつ、まだ読んでません。 - 2版も評判いいんですよねえ。 - プログラマが知るべき97のこと - Wikisourceにも記述があるみたいですが…どれだろう :eyes:

この章を読んで

  • 大した文章量じゃないので、時間はかからないと思ったのに…思い出すことが多くって、それなりに時間がかかりました。
  • 「前提」としているだけあって、大事に思っていることばかりでした。
  • プリンシプルをカードにしておいて無作為に引いて…それについてガヤガヤ話すって…飲み会のネタとかにいいかもしれない…？

プリンシプル オブ プログラミング プロローグのメモ

www.shuwasystem.co.jp

プリンシプル オブ プログラミングの読書メモです。

プロローグ 本書の読み方

  • プリンシプルがこのあとに列挙されていくスタイルなので…読み方についてざっと書かれていると確かに読みやすそうです。

0.1 プリンシプルのカテゴリ

  • あとの章の簡単な概要でした。章の頭にちらっと見返すとよさそうかも？

0.2 プリンシプルの説明のフォーマット

  • 2ページくらいなのかな。本当に情報のインデックスっぽいですね。

0.3 プリンシプルの説明における用語法

  • ふむふむ…。読んでてあれこれ混乱しそうになったら、見直しても。

0.4 プリンシプルの説明の注意点

  • あくまでもプリンシプルのインデックスなので、興味を持ったら自分で深堀っていきましょう、ですね。

(WIP)プリンシプル オブ プログラミング のメモ

www.shuwasystem.co.jp

プリンシプル オブ プログラミングの読書メモです。

動機とまえがきと期待

同僚が読書会で読みたい！と言ったから。

自分から言ってきたというところから、興味を持ちました。

さらっとまえがきを読んだら…その通りかも…。コードレビューをしていて、「どうしてそうするのかな？」「この間説明したんだけど…忘れちゃったかな？」みたいなことは結構あって…。当然昔自分もそういうコードを書いてはいましたが、長い時間をかけて、自分のコードで失敗したり、ひとのコードを読んだり、いろんな本を読んだりしてきて変わってきたような気がします。この長い時間でゆっくり吸収してきたことが、目次をみたらインデックス化されていそうですし、あらためて自分や参加者の経験などを読書会で共有できたら、なんか、とてもよさそうな感じになりそうです。

‐ プロローグ 本書の読み方 - 第１章 前提 ～プログラミングの変わらぬ真実～

第２章 原則 ～プログラミングのガイドライン～

2.1 KISS

2.2 DRY

2.3 YAGNI

2.4 PIE

2.5 SLAP

2.6 OCP

2.7 名前重要

第３章 思想 ～プログラミングのイデオロギー～

3.1 プログラミングセオリー

3.2 【プログラミングセオリーを支える3つの価値1】コミュニケーション

3.3 【プログラミングセオリーを支える3つの価値2】シンプル

3.4 【プログラミングセオリーを支える3つの価値3】柔軟性

3.5 【プログラミングセオリーを実現する6つの原則1】結果の局所化

3.6 【プログラミングセオリーを実現する6つの原則2】繰り返しの最小化

3.7 【プログラミングセオリーを実現する6つの原則3】ロジックとデータの一体化

3.8 【プログラミングセオリーを実現する6つの原則4】対称性

3.9 【プログラミングセオリーを実現する6つの原則5】宣言型の表現

3.10 【プログラミングセオリーを実現する6つの原則6】変更頻度

3.11 アーキテクチャ根底技法

3.12 【アーキテクチャ根底技法1】抽象

3.13 【アーキテクチャ根底技法2】カプセル化

3.14 【アーキテクチャ根底技法3】情報隠蔽

3.15 【アーキテクチャ根底技法4】パッケージ化

3.16 【アーキテクチャ根底技法5】関心の分離

3.17 【アーキテクチャ根底技法6】充足性、完全性、プリミティブ性

3.18 【アーキテクチャ根底技法7】ポリシーと実装の分離

3.19 【アーキテクチャ根底技法8】インタフェースと実装の分離

3.20 【アーキテクチャ根底技法9】参照の一点性

3.21 【アーキテクチャ根底技法10】分割統治

3.22 アーキテクチャ非機能要件

3.23 【アーキテクチャ非機能要件1】変更容易性

3.24 【アーキテクチャ非機能要件2】相互運用性

3.25 【アーキテクチャ非機能要件3】効率性

3.26 【アーキテクチャ非機能要件4】信頼性

3.27 【アーキテクチャ非機能要件5】テスト容易性

3.28 【アーキテクチャ非機能要件6】再利用性

3.29 7つの設計原理

3.30 【7つの設計原理1】単純原理

3.31 【7つの設計原理2】同型原理

3.32 【7つの設計原理3】対称原理

3.33 【7つの設計原理4】階層原理

3.34 【7つの設計原理5】線形原理

3.35 【7つの設計原理6】明証原理

3.36 【7つの設計原理7】安全原理

3.37 UNIX思想

3.38 【UNIX思想1】モジュール化の原則

3.39 【UNIX思想2】明確性の原則

3.40 【UNIX思想3】組み立て部品の原則

3.41 【UNIX思想4】分離の原則

3.42 【UNIX思想5】単純性の原則

3.43 【UNIX思想6】倹約の原則

3.44 【UNIX思想7】透明性の原則

3.45 【UNIX思想8】安定性の原則

3.46 【UNIX思想9】表現性の原則

3.47 【UNIX思想10】驚き最小の原則

3.48 【UNIX思想11】沈黙の原則

3.49 【UNIX思想12】修復の原則

3.50 【UNIX思想13】経済性の原則

3.51 【UNIX思想14】生成の原則

3.52 【UNIX思想15】最適化の原則

3.53 【UNIX思想16】多様性の原則

3.54 【UNIX思想17】拡張性の原則

3.55 UNIX哲学

3.56 【UNIX哲学1】小は美なり

3.57 【UNIX哲学2】1つ1仕事

3.58 【UNIX哲学3】即行プロトタイプ

3.59 【UNIX哲学4】効率性より移植性

3.60 【UNIX哲学5】データはテキスト

3.61 【UNIX哲学6】レバレッジ・ソフトウェア

3.62 【UNIX哲学7】シェルスクリプト活用

3.63 【UNIX哲学8】対話インタフェース回避

3.64 【UNIX哲学9】フィルタ化

第４章 視点 ～プログラマの観る角度～

4.1 凝集度

4.2 結合度

4.3 直交性

4.4 可逆性

4.5 コードの臭い

4.6 技術的負債

第５章 習慣 ～プログラマのルーティーン～

5.1 プログラマの3大美徳

5.2 ボーイスカウトの規則

5.3 パフォーマンスチューニングの箴言

5.4 エゴレスプログラミング

5.5 1歩ずつ少しずつ

5.6 TMTOWTDI

第６章 手法 ～プログラマの道具箱～

6.1 曳光弾

6.2 契約による設計

6.3 防御的プログラミング

6.4 ドッグフーディング

6.5 ラバーダッキング

6.6 コンテキスト

第７章 法則 ～プログラミングのアンチパターン～

7.1 ブルックスの法則

7.2 コンウェイの法則

7.3 割れた窓の法則

7.4 エントロピーの法則

7.5 80-10-10の法則

7.6 ジョシュアツリーの法則

7.7 セカンドシステム症候群

7.8 車輪の再発明

7.9 ヤクの毛刈り

2024年08月

8月何したっけ…？というまとめ。

全体で

  • 良いコード悪いコード〜の読書会が終わって、気が抜けている感じと、暑かったこともあって、活動が控えめでした。
  • 9月も準備がイマイチで次の読書会が始められなかったので…10月に向けてがんばっていきます…。

以前のまとめ

Special Thanks

IPA NEWS Vol.68（2024年9月号）のメモ

IPA NEWS Vol.68（2024年9月号）を読んだときのメモです。

www.ipa.go.jp

いろんなものが特集されていそうなので、もしかしてセキュリティ対策自主研修の資料にもしかして…と思って、目を通してみます。

「デジタルスキル標準」の賢い使い方を徹底解剖！ DX先進企業のデジタル人材育成法

「デジタルスキル標準」の賢い使い方を徹底解剖！ DX先進企業のデジタル人材育成法

ビジネスとデジタルをけん引する人材を育成

  • これかしら…？
    • www.ipa.go.jp
    • …読むのに時間がかかる><
    • ざっと見た感じ、スキルの項目が分類されて挙げられていて…とりあえず見て点数つけるだけでも役に立つかもしれません。
    • 細かく見れば説明もありますし…結構よさそうです。
  • 双日 - Wikipedia
    • この会社での事例のインタビューだそうです。
    • …めちゃくちゃデカいですね、この会社…。
    • 普段見かけなくって知らなかったです…。商社って、そうやって言われるとよく知らないですね><

人材育成プログラムにスキル標準を組み込む

  • レベル1にITパスポート…。昔にシラバス読んで、その位置づけだと思って、勉強会やったりしたのを思い出しました。
  • スキルレベルを定義するのは、給与にも反映しやすいし、なるほどです。

デジタルスキル標準の要素を “いいとこ取り

教材に魂を込め育成の質と速度を向上

  • DX推進スキル標準を人材類型をバラして、会社で必要なデータ分析とビジネスデザインに当てはめ直しているみたい…。なるほどです…。
  • 研修コンテンツは自社で作っているそうで…ここまでできるのは理想ですね…。

「DX認定」のほか「DX銘柄」にも選定

  • デジタルトランスフォーメーション銘柄（DX銘柄） （METI/経済産業省）
  • こんなこともやってたんですね…。全く知りませんでした…。どうやって選定しているんでしょう…？
    • 大企業がやる気になれば、そのうちに中小もついてくるだろう、みたいなところなのかしら…。
  • この記事を見ると、実際によさそうな活用をしているので、その選ばれた事自体は正しそう…って思いました。
  • 活用事例として公開されたのも、ありがたいです。

デジタル活用による価値創造で “Digital-in-All” の実現へ

人事部としても全社目線で人材の活躍を後押し

  • 自社に合わせた研修があれば、確かに各所に人材が配置されそうです。ここまでやれば、結果出そうですねぇ…。
  • この会社、ちょっと気にかけてみます…！

特集 【ウェブ限定記事】

「デジタルスキル標準」改訂。生成AIをDXに生かすヒントに

  • 章のタイトルは生成AIだけですが…プロダクトマネージャーも入った、と。
  • 今まで注目されてなかったけど、めっちゃ大事な役割だと思います…。

ビジネスアーキテクトの類似職種・プロダクトマネージャーを補記

生成AIの効果とリスクを理解したうえで使いこなす

‐ 効用、リスク以外にも、ビジネスへの組み込んでいくところにも触れているのは、ちょっとよさそうです。

デジタルスキル標準は、DX推進に取り組む企業・組織のより所

  • ちょっと読んでみたい気持ちもありますが……デカいんですよね……。
  • www.ipa.go.jp

セキュリティのすゝめ Webサービス認証のセキュリティ強化 不正ログインを招くパスワード認証から脱却 「パスキー」で多要素認証をより安全＆スマートに

公開鍵暗号方式でパスワードが不要に

‐ パスキーの認証のイメージの図 - スマホのときはこうですが…PCのときは…？ - 同期パスキーというみたい。 - AppleやGoogle、1Passwordなどがユーザアカウントに紐づけて、管理しているそう。 - 普段は同期パスキーを使ってるので、この図だとちょっとわかりにくかったかも。 - パスキー - Wikipedia

防犯性の高い鍵へ早めの切り替えを

  • パスワードが要らなくなるのは、めちゃくちゃいいので…早く移行したい…。
  • 移行するときの進め方がなぁ…どうしたもんか…。

対策のポイント

  • パスキーは…多要素認証を便利に利用できるようにできる仕組…というのは発見でした。その言い方が一番しっくりきました。

セキュリティのすゝめ 【ウェブ限定記事】 不正ログイン被害が多発！より安全な認証方式へ移行を

パスワードが破られると、なりすましが容易に

  • IDとパスワードの組み合わせがわかっちゃうと…なりすませちゃいますよね…。
  • 多要素認証のないところにはカード情報は入れてなかったりしてます…。

ネットショッピングで300万円以上の不正注文も

‐ サービスの運営をしていると、怖くて仕方がないです…。 - 国を跨ぐと、法律が及びにくいのもなんとかしてほしい…。

ひととおり読んで

  • 今回はスキル標準の話で、うまいこと利用するとよさそうな気がしました。
  • 続けて読んでいこうと思います。