【翻訳＋意訳・要約】マイクロフロントエンドの進化

※本記事は、Geminiによる意訳+翻訳を活用し、レイアウト調整したものです。
※感想は、オリジナルです。

原文

意訳+要約

マイクロフロントエンドの進化

近年、マイクロサービスアーキテクチャはソフトウェア開発の世界で広く受け入れられています。このアーキテクチャは、アプリケーションを小さな独立したサービスに分割し、それぞれが独自のデータベースとロジックを持ちます。同様に、マイクロフロントエンドはフロントエンドの世界で同じ原則を適用しようとしています。この記事では、マイクロフロントエンドの進化について探っていきます。

従来のアーキテクチャの課題

• 従来のモノリシックなアーキテクチャでは、フロントエンドは一つの大きなアプリケーションにまとめられていた。
• モノリシックなアーキテクチャでは、アプリケーション全体をデプロイする必要があったため、スケーラビリティや柔軟性に課題があった。

マイクロフロントエンドの概要

• マイクロフロントエンドでは、フロントエンドを小さな部分（マイクロフロントエンド）に分割することができる。
• 各マイクロフロントエンドは独立しており、異なる技術スタックやフレームワークで開発することが可能。

マイクロフロントエンドの利点

• 独立性: 各マイクロフロントエンドは独立しているため、開発、テスト、デプロイが容易。
• 技術の選択肢: チームごとに最適な技術スタックやフレームワークを選択できる。
• スケーラビリティ: マイクロフロントエンドを独立してデプロイできるため、スケーラビリティが向上する。
• 保守性: コードベースが小さくなり、特定の機能に関連する変更を行いやすくなる。

結論

マイクロフロントエンドは、従来のモノリシックなアプローチからの進化を示している。新しいアーキテクチャパターンの導入により、フロントエンドの開発がより柔軟で効率的になり、スケーラビリティが向上している。将来的には、マイクロフロントエンドがさらに成熟し、より洗練されたアーキテクチャが登場することが期待される。

GeminiへのQA

Ｑ：マイクロフロントエンドについて概要を教えて下さい

マイクロフロントエンドは、近年ソフトウェア開発の世界で広く受け入れられているマイクロサービスアーキテクチャのフロントエンド版です。従来のモノリシックなアーキテクチャでは、フロントエンドは一つの大きなアプリケーションにまとめられていましたが、マイクロフロントエンドではフロントエンドを小さな部分（マイクロフロントエンド）に分割することができます。各マイクロフロントエンドは独立しており、異なる技術スタックやフレームワークで開発することが可能です。

Ｑ：モノリシックには利点がないのでしょうか？

モノリシックアーキテクチャにはいくつかの利点がありますが、その利点はマイクロサービスやマイクロフロントエンドのような分散アーキテクチャと比較すると相対的に少ないです。以下に、モノリシックアーキテクチャの利点をいくつか挙げてみます：

1. シンプルさと開発の速度:

   • モノリシックアーキテクチャは、一つのアプリケーションにすべての機能が統合されているため、開発が比較的容易で、新機能の追加もシンプルです。
   • アプリケーション全体が単一のコードベースに統合されているため、デプロイも単純化されます。
   • 開発チーム全体が同じ技術スタックやフレームワークを共有しているため、開発者同士のコミュニケーションが容易です。

2. デバッグとテスト:

   • モノリシックアーキテクチャでは、アプリケーション全体が単一のエンティティとしてデプロイされるため、バグのデバッグが比較的容易です。
   • テストもアプリケーション全体にわたって一貫して実行されるため、シナリオ全体のテストがより簡単に行えます。

3. 単一のデプロイメントユニット:

   • モノリシックアーキテクチャでは、アプリケーション全体が一つのデプロイメントユニットとしてデプロイされます。これにより、デプロイメントプロセスが簡略化されます。
   • また、複数のマイクロサービスやマイクロフロントエンドを管理する必要がないため、運用コストが低くなる場合があります。

4. 初期段階のシンプルさ:

   • 新しいプロジェクトや小規模なプロジェクトでは、モノリシックアーキテクチャが適している場合があります。シンプルでありながらも十分な機能を提供できるため、プロジェクトの初期段階では効果的です。

感想＋雑記

個人的に、いきなりマイクロ化するのは、難しい気がするんだよね。
早すぎたマイクロ化は、ただただ煩雑になるだけな気がする。

まずは、動かして、どこがネックになるのか分析してからだと思う。

マイクロサービスがあるのだから、いずれフロントエンドにも潮流が来るだろうとは思っていたが、やっと来たか。

進化と言われると、やっぱりデジモンだな。
テイルモンからエンジェウーモンになったのが、衝撃的だった。あれで、目覚めた男子いるだろ。
あと、ウォーグレイモンのワープ進化とかカッコよかった思い出がある。

【翻訳＋意訳・要約】Webhooks と Websockets

※本記事は、ChatGPTによる意訳+翻訳を活用し、レイアウト調整したものです。
※感想は、オリジナルです。

原文

意訳+要約

Webhooks と Websockets

WebhooksとWebsocketsは、アプリケーションでリアルタイムな通信を実現するためのツールです。この記事では、それぞれの違いやどのように使用されるかを解説します。

Webhooksとは？

• Webhooksは、アプリケーション間でイベント駆動型のコミュニケーションを実現する方法です。
• 非同期のイベントを処理するのに役立ち、特定のアクションが発生したときに、自動的に他のアプリケーションに通知を送信します。
• 一般的な利用例は、ペイメントゲートウェイ、メッセージングアプリケーション、オンラインストレージサービスなどが挙げられます。

Websocketsとは？

• Websocketsは、クライアントとサーバー間で双方向の通信を確立する技術です。
• サーバーとクライアント間のリアルタイムでのデータ伝送が可能で、低レイテンシと高いパフォーマンスを提供します。
• Websocketsは、オンラインゲーム、チャットアプリ、株価のリアルタイム追跡など、リアルタイム性が重要なアプリケーションで一般的に使用されます。

WebhooksとWebsocketsの違い

1. Webhooks:

   • イベントが発生したときにHTTPリクエストを送信する。
   • イベントベースの通信を実現する。
   • 一方向の通信。
   • 遅延が発生することがある。
   • RESTfulなアプローチ。

2. Websockets:

   • サーバーとクライアント間での双方向通信を確立する。
   • 接続が確立されると、永続的な接続を保持する。
   • リアルタイムの双方向通信を実現する。
   • 高いパフォーマンスと低レイテンシを提供する。
   • 通信のためのプロトコルが異なる。

WebhooksとWebsocketsの利用場面

1. Webhooks:

   • ペイメントゲートウェイ
   • メッセージングアプリケーション
   • オンラインストレージサービス

2. Websockets:

   • オンラインゲーム
   • チャットアプリ
   • 株価のリアルタイム追跡

結論： WebhooksとWebsocketsは、アプリケーション間のリアルタイムな通信を実現するための重要なツールです。どちらを選択するかは、必要な機能とそのアプリケーションの要件に基づいて適切に選択することが重要です。一方向の通信が十分であればWebhooks、双方向通信が必要な場合はWebsocketsを選択すると良いでしょう。

ChatGPTへのQA

Ｑ：通信帯域は逼迫しないのでしょうか？

WebhooksとWebsocketsは、通信帯域においては異なる特性を持っています。以下にそれぞれの通信帯域に対する影響を説明します：

Webhooks:

• Webhooksは、イベントが発生したときにのみリクエストを送信します。
• 一度イベントが発生し、リクエストが送信されると、以降の通信は発生しません。
• そのため、通信帯域を逼迫させることはありません。

Websockets:

• Websocketsは、サーバーとクライアント間での双方向通信を確立し、通信チャネルを維持します。
• これにより、データの送受信にかかるオーバーヘッドは低減されます。
• しかしながら、常時接続を維持するため、長時間の使用の場合には帯域を消費する可能性があります。
• 適切なリソース管理と最適化が必要です。

通信帯域の逼迫を回避するために、以下のポイントに留意することが重要です：

1. Webhooks:

   • イベントが発生したときにのみリクエストを送信するため、通信帯域を効率的に利用できます。
   • レスポンスがない場合でも、通信チャネルを維持する必要がないため、効率的です。

2. Websockets:

   • 適切なリソース管理と最適化が必要です。
   • 長時間の接続を維持するため、帯域を消費する可能性があります。
   • 不要なデータの送信を避け、データの最小化を行います。

総括すると、適切に実装されたWebhooksは、通信帯域を逼迫させることはありませんが、Websocketsの場合は常時接続を維持するため、長時間の使用の際には注意が必要です。帯域を効率的に管理するためには、データの最適化と不要なデータの送信を避けることが重要です。

Ｑ：WebhooksとWebsocketsにセキュリティ上の懸念はありますか？

WebhooksとWebsocketsにはセキュリティ上の懸念が存在します。以下に、それぞれの技術における主なセキュリティ上の懸念を説明します：

Webhooksにおけるセキュリティ上の懸念:

1. 不正なイベントの受信:

   • Webhooksでは、イベントが発生したときにリクエストが送信されます。しかし、これらのリクエストが信頼できない送信元から来る場合、悪意のあるアクションを引き起こす可能性があります。
   • セキュリティ上の懸念に対処するためには、送信元の認証を行い、受信後のデータを検証することが重要です。

2. データの信頼性:

   • Webhooksでは、受信したデータの信頼性が問題となります。偽造されたリクエストが送信される可能性があり、これによりアプリケーションの安全性が脅かされる可能性があります。
   • 受信後のデータの検証を行うことで、信頼性の確保が重要です。

Websocketsにおけるセキュリティ上の懸念:

1. 接続の安全性:

   • Websocketsでは、常時接続が維持されます。接続が安全でない場合、第三者によって接続が盗聴される可能性があります。
   • エンドポイント間の通信を暗号化し、データの送受信中にセキュアなプロトコル（例：TLS/SSL）を使用することで、接続の安全性を確保する必要があります。

2. データのプライバシー:

   • Websocketsを使用して送受信されるデータは、安全である必要があります。データが傍受または改ざんされると、重大なセキュリティリスクが発生します。
   • エンドポイントの認証を行い、セキュリティを強化することが重要です。

これらのセキュリティ上の懸念を軽減するために、以下の対策を実施することが重要です：

Webhooks:

• 送信元の認証を行う。
• 受信後のデータの検証を行う。

Websockets:

• エンドポイント間の通信を暗号化する。
• データの送受信中にセキュアなプロトコル（例：TLS/SSL）を使用する。
• エンドポイントの認証を行う。

これらのセキュリティ対策を実施することで、WebhooksとWebsocketsのセキュリティを強化し、懸念を軽減することができます。

感想＋雑記

概念は知ってるけど、使ったことはないな。
いや、websocketsは、チャットアプリを業務で作った時に利用したことがある。
webhooksだけないが、githubActionがこれ使ってるんだっけ？

webhooksは、イベントを偽装できれば、攻撃に利用されそうだな。。。
websocketは、性質上、常に接続されているから、攻撃し放題ってことか。
どこに重きをおいているからで、セキュリティ対策方法が微妙に変わってくるわけか。

利用する技術によって、対策方法が変わるのは、頭の片隅に入れておく必要がある、

【翻訳＋意訳・要約】ソフトウェアインシデント管理15年の経験から得た教訓

※本記事は、Geminiによる意訳+翻訳を活用し、レイアウト調整したものです。
※感想は、オリジナルです。

原文

A dozen (or so) learnings from 15 years of software incident management - DEV Community

意訳+要約

ソフトウェアインシデント管理15年の経験から得た教訓

このブログ記事では、著者が15年間のソフトウェアインシデント管理経験から得た教訓を共有しています。特に重要な部分は以下のとおりです。

1. インシデント対応チームを構築する

• 明確な役割と責任を持つチームを構築する
• チームメンバーは、インシデント対応プロセスに精通している必要がある
• チームは、定期的に訓練および演習を行う必要がある

2. コミュニケーションが重要

• 関係者全員と明確かつ簡潔にコミュニケーションをとる
• インシデントの状況を定期的に更新する
• 誤解を避けるために、専門用語の使用を避ける

3. 文書化が重要

• インシデントのすべての詳細を文書化する
• 文書は、将来のインシデントの参考資料として使用できる
• 文書は、監査目的で使用できる

4. 自動化を活用する

• インシデント対応プロセスを自動化できるタスクを特定する
• 自動化ツールを使用して、効率と精度を向上させる
• 自動化ツールは、チームメンバーをより重要なタスクに集中させることができる

5. 振り返りと学習

• すべてのインシデントから学び、プロセスを改善する
• 振り返りセッションを使用して、何がうまくいったのか、何がうまくいかなかったのかを特定する
• 改善点を特定し、将来のインシデントを防止するために措置を講じる

その他の重要な教訓

• 顧客に焦点を当てる
• 予防策を講じる
• テストと監視を徹底する
• 謙虚さを保ち、常に学び続ける

これらの教訓は、ソフトウェアインシデント管理を成功させるために役立ちます。

このブログ記事は、ソフトウェアインシデント管理に関心のあるすべての人にとって貴重なリソースです。

GeminiへのQA

Ｑ：インシデント防止のために、どんな活動をしているのでしょうか？

インシデント防止のために、以下の活動を行っているとのことです。

• システムを可能な限り自動化する。これにより、人為的ミスによるインシデントの発生を減らすことができます。
• 先行指標を追跡する。先行指標は、インシデントが発生する前に予測するのに役立つメトリックです。これらのメトリックを追跡することで、インシデントの発生を防ぐことができます。
• 明確なコールチェーンとエスカレーションパスを持つ。これにより、インシデントが発生した場合に誰に連絡すればよいか、インシデントをできるだけ早く解決できるようになります。
• 最前線の人員に大きな決定を下す権限を与える。これにより、インシデントの初動対応者が、上級管理者の承認を待たずに、インシデントを解決するために必要な措置を講じることができます。
• 非難のない事後検証を行う。これにより、インシデントの根本原因を特定し、将来再発しないようにすることができます。

これらの活動は、インシデントの発生を減らし、インシデントが発生した場合の被害を最小限に抑えるのに役立ちます。

Ｑ：指標として何を見ていたのでしょうか？

記事によると、最も重要な指標は、コンポーネントシステムが期待どおりに機能しなくなったときに、通常と異なる値になるものです。これは、eコマース、金融、または$ベースのプラットフォームの場合は、プラットフォームを流れる収益を追跡すること、ソーシャルメディアプラットフォームの場合は、現在のアクティブユーザー数を追跡することです。

具体的には、以下の指標が考えられます。

• システムのパフォーマンス指標（CPU使用率、メモリ使用率、ネットワーク帯域幅など）
• ユーザーエクスペリエンス指標（応答時間、エラー率など）
• ビジネス指標（収益、顧客満足度など）

これらの指標を定期的に監視することで、インシデントの発生を早期に検知し、被害を最小限に抑えることができます。

また、インシデントが発生した場合は、これらの指標を分析することで、インシデントの原因を特定し、再発を防止するための対策を講じることができます。

感想＋雑記

インシデント管理ってだけで、対応はしてなかったのかな？
インシデントで一番つらいのは、対応する側な気がするけど、顧客に説明するのが管理側がしてたら、それも辛そうだな。。。

個人的には、インシデントがエンジニアを成長させると思ってる。
インシデント対応から逃げずに対処してきた奴らは、やっぱり強いと思う。
メンタルや物事の捉え方が違う。なぁなぁで対応してきたら、成長できんから、成長する機械だと思って、真剣に取り組むべきだと思う。
まぁ、俺がやれてるかと言うと、やれてない気がするが。

【翻訳＋意訳・要約】AI面接がもたらすディストピア：AI面接システムへの批判

※本記事は、Geminiによる意訳+翻訳を活用し、レイアウト調整したものです。
※感想は、オリジナルです。

原文

AI "interviewer"...I rarely want companies to fail but... - DEV Community

意訳+要約

AI面接がもたらすディストピア：AI面接システムへの批判

この記事は、AI面接システムへの批判を展開しています。著者は、AI面接システムが非人間的で非効率的であり、採用プロセスを悪化させる可能性があると主張しています。

主な批判点

• 非人間性: AI面接システムは、人間による面接の暖かみや共感を欠いています。候補者は、無機質な機械に対して緊張し、本来の能力を発揮できない可能性があります。
• 非効率性: AI面接システムは、候補者の真の能力を評価するのに十分な精度を持っていません。AIは、偏見や誤解に基づいて判断を下してしまう可能性があります。
• 採用プロセスの悪化: AI面接システムは、優秀な候補者を見逃してしまう可能性があります。また、AIによる判断が不透明なため、採用プロセスに偏見が生じる可能性があります。

重要な部分

• AI面接システムは、候補者と企業双方にとって非人間的で非効率的なものです。
• AI面接システムは、採用プロセスを悪化させ、優秀な候補者を見逃してしまう可能性があります。
• 企業は、AI面接システムの使用を慎重に検討し、その潜在的なリスクを認識する必要があります。

代替案

著者は、AI面接システムの代わりに、以下のような代替案を提案しています。

• 人間による面接: 従来の人間による面接は、候補者の能力と潜在能力をより深く評価することができます。
• ビデオ面接: ビデオ面接は、候補者と面接官が直接顔を合わせることができるため、AI面接システムよりも人間的なやり取りが可能になります。
• スキルテスト: スキルテストは、候補者の特定のスキルを評価するのに役立ちます。

結論

AI面接システムは、まだ発展途上にあり、多くの課題を抱えています。企業は、AI面接システムの使用を慎重に検討し、その潜在的なリスクを認識する必要があります。

まとめ

AI面接システムは、採用プロセスを効率化するためのツールとして期待されていますが、多くの課題も存在します。企業は、AI面接システムのメリットとデメリットを慎重に検討し、その利用を決定する必要があります。

GeminiへのQA

Ｑ：意思決定を全面的に信じることの弊害はないのでしょうか？

意思決定を全面的に信じることの弊害

意思決定を全面的に信じることは、一見すると良いことのように思えますが、実はいくつかの弊害があります。以下、3つの主要な弊害と、それぞれの対策について説明します。

1. 思い込みや偏見による誤った判断

人間は誰でも、無意識のうちに思い込みや偏見を持っています。意思決定を全面的に信じてしまうと、これらの思い込みや偏見に基づいて判断してしまう可能性があり、それが誤った判断につながる可能性があります。

対策:

• 自分の思い込みや偏見を認識する。
• 多様な意見を取り入れる。
• 複数の選択肢を比較検討する。
• 十分な情報収集を行う。

2. 変化への対応力の低下

意思決定を全面的に信じてしまうと、状況の変化に対応するのが難しくなります。なぜなら、一度決定したことを覆すのは心理的に抵抗があるからです。

対策:

• 常に新しい情報にアンテナを張る。
• 状況の変化に柔軟に対応できるマインドセットを持つ。
• 定期的に意思決定を見直す。

3. リスクへの無頓着

意思決定を全面的に信じてしまうと、リスクを過小評価してしまう可能性があります。なぜなら、自分の判断を信じているからです。

対策:

• リスクを常に意識する。
• 最悪のケースシナリオを想定する。
• リスク対策を講じる。

その他

上記以外にも、意思決定を全面的に信じることによって、責任逃れや固定観念の助長などの弊害が生じる可能性があります。

感想＋雑記

漫画やアニメのキャラが面接してくれるなら、別にいいやって思って最後まで見てたら、コメントでも同じこと言っているやつが。。。
海外でも同じことを考えるんだな。

AIの判断が正しいとは言えないからな。
結局は、AIと言われるものは確率論を高めてるだけで、ギャンブルと変わらんからな。
判断は、やっぱり人間がくださねば。
そうじゃないと、責任転嫁してばかりで、発展は出来ない気がする。

2024/04/15週 気づきと振り返りなどなど

業務こなして学んだこと

Javaでパフォーマンス測定

eclipse4.24でパフォーマンス検証することになって色々調べた結果、MissonControlleってのができるっぽいので、使おうと思ったが、使い方が分からねぇ。。。
いろいろ調べてたけど、時間だけがすぎるので、VisualVMに変更。
思ったより簡単に調べられた。

VisualVMなのか、VirturalVMなのか、最初わからんかったわ。。。
ずっとVirtualVMかと思って調べてたけど、ちゃんとVisualVMが検索結果に出て聞いて、気づくのが遅れた。
検索が優秀になって、自分がバカになってしまったような感覚を感じた。

VisualVMとeclipseに連携するには、VMの引数に -Xverify:none が必要になる。
ただし、JDK13から非推奨。実行時に警告でるけど、機能はするみたい。

JavaのStreamでlist生成するときは、toListを使え

他人が書いてたコード見てたんだけど、foreach(v -> list.add(v)) みたいな実装をしていた。
Lambdaが登場して結構たつけど、まだそういう実装する人がいるんだなぁと感じた。

mybatisのxmlでforeachは使うべきではない

mybatisのxmlで、foreachは使うべきではない。

そう思う理由は、以下。
- SQLの長文化によるエラーを誘発しやすい - 生成されるSQLが分かりづらく、思わぬSQLが投げられる - SQL１本化して高速化しても、だいたい間違っている。(orでの連携は、インデックスが効かない過リスクがある) - パラメータがないと、意図せぬSQLが発行される可能性がある

これ何回か遭遇したことがあって、大体は長文化でエラーになった。
その尻拭いを、毎回やっていた記憶しかない。

マジで辞めろ。
普通にシンプルなSQL発行する方が、改修しやすいから、SQLにロジックを入れるべきではないと思う。

SQLplusでカラムごとの末尾の空白は取れない

Oracle10g使ってるんだけど、ツールとしてSQLplusでデータ取ってくるものを作ったが、カラムの末尾が取れねぇ。。。
いろいろ調べたら、取得した文字列の末尾の空白を消してくれるらしい。。。
結果は、全部連結した文字列だから、末尾のカラムしか、空白取れない。。。
12c以降は、Markup指定で、カラムごとに末尾の空白を消してくれるらしい。。。
12c使いたかった人生だった。

その他雑記

ショッカーおじたん

電車に乗ってたんだが、「イー」という奇声をたまに発するおじたんがいた。
なんなんだ？って思ったけど、ショッカーが好きなのかな？ぐらいで思考するのをやめた。

【翻訳＋意訳・要約】IoTセキュリティの脆弱性とオペレーションテクノロジーにおけるリスク

※本記事は、Geminiによる意訳+翻訳を活用し、レイアウト調整したものです。
※感想は、オリジナルです。

原文

IoT Security Vulnerabilities in Operational Technology: Addressing the Risks - DEV Community

意訳+要約

IoTセキュリティの脆弱性とオペレーションテクノロジーにおけるリスク

IoTデバイスの普及に伴い、オペレーションテクノロジー（OT）システムへのIoTデバイスの統合が進んでいます。しかし、IoTデバイスはセキュリティの脆弱性が多く、OTシステムへの統合によって新たなリスクが生じる可能性があります。

本記事では、IoTセキュリティの脆弱性とOTにおけるリスクについて解説します。また、これらのリスクを軽減するための対策についても紹介します。

IoTセキュリティの脆弱性

IoTデバイスは、以下の脆弱性が多く存在します。

• 標準化の欠如：IoTデバイスは、さまざまなメーカーやベンダーから提供されており、セキュリティ対策が統一されていない。
• レガシーシステム：OTシステムは、古いシステムを継続して使用している場合が多く、セキュリティ対策が不十分である。
• 不安全な通信プロトコル：IoTデバイスは、不安全な通信プロトコルを使用している場合が多く、攻撃者に傍受される可能性がある。
• 物理的なアクセス：IoTデバイスは、物理的なアクセスによって攻撃される可能性がある。
• サプライチェーンのリスク：IoTデバイスは、サプライチェーン攻撃によって悪意のあるコードが埋め込まれる可能性がある。
• リソースの制限：OTシステムは、リソースが限られているため、セキュリティ対策を十分に実施できない場合がある。
• 認証とアクセス制御の不備：IoTデバイスの認証とアクセス制御が不十分な場合、攻撃者が不正にアクセスする可能性がある。
• データプライバシーの懸念：IoTデバイスは、個人情報や機密情報を収集する可能性があるため、データプライバシーの懸念がある。

OTにおけるリスク

IoTデバイスをOTシステムに統合することで、以下のリスクが生じる可能性があります。

• システムの可用性への影響：IoTデバイスが攻撃されると、OTシステムの可用性に影響を与える可能性がある。
• データの改ざん：IoTデバイスが攻撃されると、OTシステムのデータが改ざんされる可能性がある。
• 制御の奪取：IoTデバイスが攻撃されると、OTシステムの制御が奪われる可能性がある。
• 物理的な損害：IoTデバイスが攻撃されると、OTシステムを制御する機器や設備に物理的な損害を与える可能性がある。

対策

IoTセキュリティの脆弱性とOTにおけるリスクを軽減するためには、以下の対策を実施することが重要です。

• セキュリティ対策の標準化：IoTデバイスのセキュリティ対策を標準化することで、脆弱性を軽減できる。
• レガシーシステムのセキュリティ対策の強化：OTシステムのセキュリティ対策を強化することで、脆弱性を軽減できる。
• 安全な通信プロトコルの使用：IoTデバイスは、安全な通信プロトコルを使用することで、攻撃者の傍受を防ぐことができる。
• 物理的なアクセスの制限：IoTデバイスへの物理的なアクセスを制限することで、攻撃者の侵入を防ぐことができる。
• サプライチェーンのセキュリティ対策の強化：IoTデバイスのサプライチェーンのセキュリティ対策を強化することで、サプライチェーン攻撃を防ぐことができる。
• リソースの確保：OTシステムのセキュリティ対策を十分に実施するためには、リソースを確保する必要がある。
• 認証とアクセス制御の強化：IoTデバイスの認証とアクセス制御を強化することで、不正なアクセスを防ぐことができる。
• データプライバシーの保護：IoTデバイスから収集されるデータのプライバシーを保護する必要がある。

まとめ

IoTデバイスの普及に伴い、OTシステムへのIoTデバイスの統合が進んでいます。しかし、IoTデバイスはセキュリティの脆弱性が多く、OTシステムへの統合によって新たなリスクが生じる可能性があります。

組織は、IoTセキュリティの脆弱性とOTにおけるリスクを理解し、適切な対策を実施することで、IoTデバイスの安全な導入と運用を実現する必要があります。

重要なポイント

• 組織は、IoTデバイスの統合に伴うOTにおけるリスクを理解する必要がある。
• セキュリティ対策は、IoTデバイスのライフサイクル全体にわたって実施する必要がある。
• セキュリティ対策は、組織のニーズに合わせてカスタマイズする必要がある。

本記事が、IoTセキュリティの脆弱性とOTにおけるリスクについて理解する上で、お役に立てば幸いです。

GeminiへのQA

Ｑ：OTシステムとは何ですか？

OTシステムとは、産業環境における物理デバイス、プロセス、インフラストラクチャを監視および制御するために使用されるハードウェアとソフトウェアのことです。これには、監視制御およびデータ取得（SCADA）システム、産業用制御システム（ICS）、その他の特殊アプリケーションなどが含まれます。

Ｑ：ベンダーロックインされそうな気がしますが

OTシステムにおいて、特定のベンダーに依存しすぎることによる「ベンダーロックイン」は、深刻な課題となりえます。ベンダーロックインが発生すると、以下のような問題が生じます。

コスト増加

• ベンダー独自の規格や技術に依存するため、他社製品への切り替えが困難になり、コストがかさみます。
• ベンダーの言い値で購入せざるを得ない状況になり、価格交渉力が弱くなります。

柔軟性の低下

• ベンダーの都合に振り回され、システムの改修や拡張が困難になります。
• 最新技術を取り入れることができなくなり、システムの陳腐化を招きます。

セキュリティリスク

• ベンダーが脆弱性を放置した場合、システム全体が攻撃を受けやすくなります。
• ベンダーが事業停止した場合、システムの保守・運用が困難になります。

対策

ベンダーロックインを回避するためには、以下の対策が有効です。

オープンな規格を採用する

• ベンダーに依存しないオープンな規格を採用することで、他社製品への切り替えを容易にします。
• 将来的にもシステムを拡張しやすくなります。

複数のベンダーを組み合わせる

• すべての機能を単一のベンダーに任せるのではなく、複数のベンダーの製品を組み合わせることで、ロックインのリスクを分散します。
• システムの柔軟性を高め、最新技術を取り入れやすくなります。

自社でノウハウを蓄積する

• システムの設計、開発、運用に関するノウハウを自社内に蓄積することで、ベンダーに依存する度合いを減らすことができます。
• ベンダーとの交渉力も高くなります。

クラウドサービスを活用する

• オンプレミス型のシステムではなく、クラウドサービスを活用することで、ベンダーロックインのリスクを低減できます。
• スケーラビリティやセキュリティを向上させることもできます。

ベンダーと契約を締結する前に

• ベンダーロックインのリスクを認識し、契約内容を慎重に検討する必要があります。
• ベンダーのサポート体制や過去のトラブル事例なども確認することが重要です。

ベンダーロックインは、OTシステム導入において慎重に対処すべき重要な課題です。上記のような対策を講じることで、ベンダーロックインのリスクを低減し、システムの安定稼働と将来性を確保することができます。

感想＋雑記

IoTの課題は、セキュリティと連携方法だな。
IF部分をプログラミング可にしておいて、結合部分をプログラミングで対応可能にしておけばいいのでは？って思ったけど、ハードル高いんかな？
物理的なものにするよりは、ソフトウェア的に連携できるもののほうがいい。
そうなると、クラウド連携か、bluetooth連携が楽そうな気がする。

たぶん、ベンダーが好き勝手するから、標準化は難しいと思う。
やるとしたら、誰かが圧倒的にシェアを独占しないと、無理な気がする。

【翻訳＋意訳・要約】プログラミングの「アート」：単なるプログラミング技術ではなく、問題解決能力を養う

※本記事は、Geminiによる意訳+翻訳を活用し、レイアウト調整したものです。
※感想は、オリジナルです。

原文

El Arte de Programar: No se Enseña Programación, Sino a Programar - DEV Community

意訳+要約

プログラミングの「アート」：単なるプログラミング技術ではなく、問題解決能力を養う

本ブログ記事では、プログラミングを単なる技術習得ではなく、問題解決能力を養う「アート」として捉えるべきであると主張されています。

重要なポイント：

• プログラミングは単なるツール: プログラミング言語やフレームワークは、問題解決のためのツールであり、目的ではありません。
• 論理的思考と創造性の融合: プログラミングは、論理的思考力と創造性を駆使して、最適な解決策を導き出すプロセスです。
• 問題解決能力の重要性: プログラミングスキルは、問題を分析し、解決策を設計・実装・テストする能力を養います。
• 継続的な学習: 技術は常に進化するため、プログラマーは新しい知識やスキルを習得し続ける必要があります。
• 協調性とコミュニケーション: チーム開発においては、効果的なコミュニケーションと協調性が不可欠です。
• 哲学との類似点: プログラミングと哲学は、どちらも論理的思考、問題解決、創造性を重視する点で共通しています。

まとめ

プログラミングは、単なる技術習得ではなく、問題解決能力を養う「アート」です。論理的思考と創造性を融合させ、継続的に学習することで、様々な課題を克服できる人材へと成長することができます。

GeminiへのQA

Ｑ：正解ではなく自立の方法を教えるということでしょうか？

はい、その通りです。ブログ記事では、プログラミングを単なる正解を導き出す作業ではなく、問題解決能力を養うための「アート」として捉えています。

従来のプログラミング教育では、特定の言語やフレームワークの使い方を習得することに重点が置かれていました。しかし、真のプログラミングスキルとは、与えられた問題を分析し、創造性と論理的思考力を駆使して最適な解決策を導き出す能力です。

ブログ記事では、以下の点を強調しています。

• プログラミングは単なるツール: プログラミング言語やフレームワークは、問題解決のためのツールであり、目的ではありません。目的を達成するために、適切なツールを選択し、使いこなすことが重要です。
• 継続的な学習: 技術は常に進化するため、プログラマーは新しい知識やスキルを習得し続ける必要があります。変化に対応し、常に新しいことに挑戦する姿勢が求められます。
• 問題解決能力の重要性: プログラミングスキルは、問題を分析し、解決策を設計・実装・テストする能力を養います。問題の本質を見抜き、論理的に解決策を導き出すことが重要です。
• 哲学との類似点: プログラミングと哲学は、どちらも論理的思考、問題解決、創造性を重視する点で共通しています。プログラミングを通して、哲学的な思考を身につけることもできます。

このように、ブログ記事はプログラミング学習の目的を単なる正解導出から、問題解決能力の向上へとシフトさせています。

自立の方法とは、まさにこの問題解決能力を養い、自ら考え、行動できる人材へと成長することです。

ブログ記事では、そのためのヒントとして、以下のような点を挙げています。

• 独学と実践: 教科書やチュートリアルだけでなく、実際に自分でコードを書いて試行錯誤することで、より深く学ぶことができます。
• オープンソースプロジェクトへの参加: オープンソースプロジェクトに参加することで、他のプログラマーと協力し、実務経験を積むことができます。
• 多様なプログラミング言語に触れる: 異なるプログラミング言語に触れることで、それぞれの特徴や強みを理解することができます。
• 問題解決コンテストへの挑戦: 問題解決コンテストに挑戦することで、問題分析能力とプログラミングスキルを磨くことができます。

これらの方法を通して、正解を導き出すだけでなく、自ら考え、問題を解決できる自立したプログラマーへと成長することができます。

Ｑ：この記事では、なぜアートに例えたのでしょうか？

ブログ記事でプログラミングがアートに例えられている理由は、以下の3点が挙げられます。

1. 創造性と論理的思考の融合

プログラミングは、単なる技術ではなく、創造性と論理的思考を融合させて問題を解決するものです。

画家がキャンバスに絵を描くように、プログラマーはコードを使ってソフトウェアを作り上げます。独創的なアイデアを生み出し、論理的にそれを形にするためには、創造性と論理的思考の両方が必要不可欠です。

2. 型にはまらない自由な表現

プログラミングには、正解が一つというわけではありません。与えられた問題に対して、様々なアプローチで解決することができます。

画家が様々な技法を使って絵を描くように、プログラマーも様々なプログラミング言語やフレームワークを使ってソフトウェアを作ることができます。型にはまらず、自由な発想で問題を解決することが求められます。

3. 終わりなき探求

プログラミングは、常に新しい技術が生まれてくる分野です。

画家が生涯をかけて新しい表現技法を探求するように、プログラマーも常に新しい知識やスキルを学び続ける必要があります。終わりなき探求こそが、プログラミングの魅力の一つです。

感想＋雑記

そうか、俺は画家だったか。。。
俺が変人だと言われるのは、きっと画家だからだろう。

結局、言いたいことは、老子の「飢えている人がいるときに、魚を与えるか、魚の釣り方を教えるか。」ということだろうな。
プログラミングの考え方を教えるのが本質で、プログラミングの仕方ではないのだろう。
自分で考えてプログラミングできるようにさせるのが大事。いちいち聞きに来られたら、鬱陶しいからな。

昔の人の格言は、たまにぶっ刺さることがあるから、格言は覚えておいたほうがいいと思いました。