Picks
117フォロー
137フォロワー
運転免許データを不正削除か 男性職員を懲戒免職、警視庁
共同通信
戸ノ崎 学モビリティサービスのシステム屋
データアクセスにCRUD(Create・Read・Update・Delete)があるから、内部犯行には無防備に。 今回はDeleteの悪用。 情報アクセスは本来 CreateとReadだけあれば十分。 そもそも、時を戻すようなDeleteや、過去を無かったことにする Updateなんて概念は この宇宙には存在しません。 望まなくても思い出は蓄積されます。 例え記憶喪失になっても、宇宙の記憶から無くなる訳ではありません。 記憶違いや自分に嘘をついても、宇宙の記憶は変えられません。 ちゃんと見ていて忘れないこと、これが一番の優しさです。 なまじ何でもできるコンピュータ処理で、現実にはあり得ないアクセス手段、即ちUpdateやDeleteを発明してしまったのが、物事を難しくしている元凶だと定義してみるのが良いでしょう。 消しゴムで見えなくするというCreateは許しますが、DeleteやUpdateは許さない(存在しない)、その様に制限された蓄積・アクセス手段を 整えること、これが 今後DX基盤で求められてきそうです。 もしこの土台なら、この内部犯行も単なる 上司のPCでデータを見えなくするといったCreateを施しただけになります。 問題検知も容易ですし、Createで見えなくする為の作業を「全部却下」無視して取り扱うだけで、問題を無力化できます。何より犯罪の過程は全て明らかです。再発防止も検討できます。 誰がどこから何をしたのか。思い出のトレーサビリティが期待できるなら、組織活動の評価や反省もでき、反省できるならAIによるエンパワーも期待できます。 トレーサビリティが期待できるなら、とある世代断面からの別世界シミュレーションが面白くなります。 シミュレーターが鍛えられるので、加速シミュレーションで 多くの未来を垣間見る事ができ、現実世界だけは、厳選した好ましいパラメータで始めることができます。 さほど遠くはない未来で、このようなDXによるサービスや組織活動ができるようになるのは誰でしょうか。 Updateと、Deleteは過去の思い出として無力化させ、今後はCreateとReadだけのDX基盤を望むメリットは大きいと思います。
2Picks
標準ガイドライン群
cio.go.jp
戸ノ崎 学モビリティサービスのシステム屋
このコメントはアカウントを作成すると読むことができます。
5Picks
【JavaScript】if文やelse文で処理を分岐させる方法を詳しく解説
「傍楽」ブログ
戸ノ崎 学モビリティサービスのシステム屋
記事の最初の方にこうあります。 『if文は、プログラミングするなかで避けては通れない、分岐処理を実装するために用いられます。使用頻度も高い』 しかし、高可用(落ちにくい)システムのプログラムに熟達するには、if文を避けて通る設計ができるようにならなければなりません。 ifは「もしも」という仮定に過ぎず、 仮定は 単なる思い込みでも生まれるし、たとえ事実であっても簡単に覆るからです。想定外のif不足にも悩まされますね。 当然、ifが多いと、プログラムやプロセスの単体テストが複雑になり、同じ理由で品質保障がムリゲーになります。 拘束力が弱いバーチャルな世界の「if=仮定」に対しては、いつでもリアルが後出しジャンケンで襲いかかり、実装はバグだらけになります。 「創ったときはバグってないんですよ!? 多分」でも、後で必ずバグる。そして貴方が悪いと責められるでしょう。なんて世知辛い。 考えてもみてください。機器故障、ファームウェア更新、セキュリティパッチ、連携システム側の不具合、ユーザーの突拍子もない操作、技術革新、OSやミドルのバグ、オープンソースのIssue、軍事レベルのサイバー攻撃、全んっ〜部 想定したIF文、作りきれますか? という事です。 「非機能要件にありません」と言いますか? 責任は無くなるかも知れませんが、実装の問題が無くなるわけではありません。なんともやりきれない、無念さが込み上げてきます。自分だってイイモノ創りたい! 喜んで頂きたい! -- ifをどれだけ避けて実装できるか、ifゼロにできないか、それが難しければ開発チームに対して どれだけifを避けて貰えるような基盤を用意できるか、そういう観点をしっかり考え抜くのが肝要です。 実はifを避ける知恵は、製造に熟達した企業では当たり前になっています。その知恵をバーチャルなソフト開発に応用するアプローチに注目できそうです。
4Picks
明日発足の「デジタル庁」。重要プロジェクト「ガバメントクラウド」の意義と懸念
ニュースイッチ
戸ノ崎 学モビリティサービスのシステム屋
【小さく生んで大きく育てる為に】 ガバメントクラウドのイメージ(図)からしか分かりませんが、システムインフラ調達・メンテナンスコストの削減は期待できそうですが、将来への成長を目指して、もう少し汎化したアーキテクチャが良かったと思いました。少し残念です。 この図だけ診ると、成長のベクトルは集約方向ではなく発散方向。各自治体がITに習熟してきて、様々なトライアルがてんでバラバラに行われ、デジタル化した暗黙知が無秩序に蓄積されそうです。全体の一貫性は期待できなく、勘違いや混乱を招く例外・特例だらけ、条件分岐の増殖を抑える仕組みが見えてきません。逆にAIに乗っ取られる土壌づくりに見えてきます。規制てんこ盛りで楽しく改善できなくする環境破壊にも見えてきます。 SoRベースの概念が根強く残ってるかも知れません。 国や自治体の仕事はデーター蓄積と言えなくもないですが、別の見方では コミュニケーション管理とも言えそうです。後者に注目してオペレーションの汎化→再設計が見えてくると、カオスからコスモス、美しい秩序へと向き先を変えることができるかも知れません。 オペレーションの汎化、このキーワードは大切です。 柔軟なデーター蓄積と制御可能な意味付けも大切です。 トレーサビリティを確保する形のセキュリティ対策も。 当初、小さく生んで大きく育てる、と素晴らしコンセプトを掲げていたと思います。それには、システム構成がそれを促す形になってないと虚しいです。 日本には、ビジネスモデリングやジャストインタイム、全体最適化、ナレッジマネジメントに精通している組織が整っていると思います。その知恵をトップレベルの概念に置いてアーキテクチャを練り直すなら、小さく生んで大きく育てることを推進できる、シン・ガバメントクラウドに出来そうな気がしました。
323Picks
セキュリティ対策でよく使われる「孫子の兵法」の例えと活用法
ZDNet Japan
戸ノ崎 学モビリティサービスのシステム屋
「彼を知り己を知れば百戦して殆(あや)うからず」 己を知ることが大変困難。 経営サイドのメンバーだけでなく、予算取って発注するメンバーらも己の事を知るのは困難で、もしかしたら関心すらないかも知れません。 システムエンジニアや、プログラマなら分かってるか、と問いかけても 当然「否」。OSやミドルウェア、フレームワークやライブラリ全体を見渡して、完全に己のサイバーな肉体を把握することは困難です。 「己を知る」為には、アーキテクトの仕事が大切になります。それも、フィット&ギャップして落とし所を見出すタイプではなく、DXのロードマップを頭に描き続け最短を走るタイプのアーキテクトです。 現実は複雑で理解が難しいですが、 シンプルで本質的なDXからアーキテクチャを見出すなら、複雑なシステムやデータやオペレーションから、抑えるポイントを論理的に極所化できます。己の守る場所を少なくすると知り得て守りやすくなります。 データー蓄積とアクセス手段に対しても、汎化と層別で論理的にシンプルを狙うべきです。 更新や削除を許さない、QoSレベルを必要最小限にして実装過程全てで明確化、脱マスターでプロビジョニング型への変革など、色々知恵が沸いてきます。データは守るだけでなく、オペレーション正常復帰させやすい、という考え方も大切かだからです。腐ったデータ相手に数日間 苦闘するなんて状況は是非とも避けるべきでしょう。 丸投げ組織ではなく、内製DevOps組織をユーザー部門にまで広げて、総員当事者の仕掛けも 望まれます。セキュリティやクラウドのスペシャリストの知恵を借りるのは、DevOps体制の後です。 「己を知る」とは、サイバーな世界で言い換えると 「己を知り得る」こと。己を知り得る仕組みが肝要だと いち早く認知して、足早に仕掛けていく事だと、言えるかも知れません。 継続に己を知り得て、俊敏に対処できる組織で力を付けていくなら、「百戦して殆(あや)うからず」な状態に近づけるでしょう。
149Picks
プライバシーリスクを回避しながらDXを推進 参考になる国際規格まとめ
ITmedia ビジネスオンライン
戸ノ崎 学モビリティサービスのシステム屋
各地1000箇所から神輿を ワッショイ東京に運びますが、それは神聖なものだから誰であれ見てはいけないとし、様々な規格や施策を展開するのをイメージすると、ちょっと滑稽です。 風呂敷で隠すぞ!風で飛ぶだろ!喧喧囂囂! -- DXやそのずっと昔から 性別や、母の旧姓、最初のペットの名前、電話番号、2番目のメールアドレス、生年月日、家族、年収、小学校、ゥ〜まだまだ! そんなに個人情報を収集して、 例えば、駐車場の予約取るだけのサービスとか。 それで、会社が潰れたり、サイバー攻撃で盗まれたり、社員がコッソリ頂戴したり、ダークウェブで高く売れたり、リスクしかありません。 例えもし独りの有志が立ち上がり、リスクアセスメントのフレームワークを勉強して分厚い資料にまとめても、誰ひとり、経営者さえも無関心、そうなって終うのがオチです。無理なんです。 リスクアセスメント連合会作って相互監督。もう仕事の邪魔しか思いつきません。 -- よくよく話を聞いてみると、今回神輿を集めようとしたが、必要なのは神輿を担ぐ男達から1000人で、神輿はサービスに登場しないようです。 男達の魂に神輿の心が宿っている、経験談を熱く語れる、それだけで十分みたいです。 そうであれば、神聖な神輿の方は 各地に残したままにするのが、規約や施策を凝らすより安全ではないでしょうか。 プライバシーを語る前に、必要な時に、必要な種類の個人情報だけでサービスできる設計に留める。助平心は出さない もっと考えを進めて、サービスに必要なのは個人を特定するワンタイムIDのみとし、 個人の情報は、本人の端末にだけ保存して、必要に応じて端末から引き出し表示させる、こんな設計が 求められて来ると良いと思いませんか。 クラウドや自社サーバーに個人情報を渡すと ①データベースに蓄積され責任を負う ②ログに刻み込まれて通信で拡散・消せない ③時間と共に個人情報は陳腐化、リスクは高いまま残る ④入力ミスや意図的な誤情報でオペレーションが腐る ⑤目的以外に個人情報流用する誘惑に負ける ⑥サイバー攻撃が進化して追従コストが膨大 ロクな事がありません。 上記の端末にだけ保存する・端末からだけ参照する、この仕組みを拡張した考えで、クラウドに共同で個人情報銀行を作り、責任を一極に集中させリスクを共有・分散させる考え方もあります。
35Picks
ビジネスパーソンはPythonよりも「AI企画」を学ぼう--実践で使えるメソッドを伝授
CNET Japan
戸ノ崎 学モビリティサービスのシステム屋
分かりやすくまとめられて、面白い記事でした。 WhichやHowの層別も興味深いです。 AI活用の神髄は、ワンタイムの設備計画やPoCではなく、AIを使った継続成長に有りますので、この記事のフレームワークを体感したら、今度は継続成長のプロセスにフォーカスしたくなると思います。 成長過程においては、Whichの「代行」と「拡張」を畳み込む形でHowのレベルが 竜巻のようにスパイラルアップします。 何故なら、AIが住んでるサイバー空間には 質量や時空のような制約が少なく、そこで霊的に発達している人の知恵が働くからです。 サイバー空間の特性を一層活用する形の成長スパイラルが待っているので、その流れに乗る準備を進めるよう急かされます。早い者勝ちではなく、積み重ねて強い者勝ち。 ①DXでは古い資産がサイバー成長スパイラルの制約にならないように、中途半端に妥協しないで徹底的に(RPAとかイメージしていると、セキュリティに悩まされて進化が止まります。過去の質量資産は 一気に断捨離するくらいの潔さからスタートしてから資産活用を後付けで熟考) ②そのDXは顧客満足(CS)だけでなく、企画、開発、運用、改善、改革エコシステム全体を網羅するグランドデザインで仕掛ける ③試行錯誤の回転数を落とさないように、リソーセスが流れつづける改革も仕掛ける(予算など権限、人材・交流、開発・トライアル環境、速い合意形成と 健全な新陳代謝) ※未来像↓ AIで武装された人が、数多な未来を先取りし、リアルタイムの全体最適と、量にめげない個別カスタマイズで 整合取りながら現実をドライブし、精度高く反省・改善。 現実ドライブには、xRやロボットが合流しリアルとバーチャルの境界をシームレスに 低コストで乗り越える。 そんな人々が集まった次世代のチームで 幸福を量産する未来をイメージしています。
504Picks
中国人やインド人が、すぐにちゃぶ台返しをする理由
日経ビジネス
戸ノ崎 学モビリティサービスのシステム屋
中国人とかインド人に問題あるわけではなく、 工程設計、役割設計、業務設計が不完全で、丸投げ体質な日本人の方に問題があると考えるとどうでしょうか。 「ちゃぶ台返し」というより「後出しジャンケン」 こう表現するなら、 日本にいっぱい有りそうです。 人や組織に丸投げしておいて 「どうしてこれも、やってないんだ!常識でしょ?」 「ごめん、これも頼む!」 合意形成しなかったり、工程設計を適当に済ませると "常識"期待がはびこり、後出しジャンケンが好きになる 後出しジャンケン合戦を恐れて、形のないリスクとやらにお金がかかるようになる。 そのリスクとやらを怖れて、全体を見ず局所的な仕事を選り好みするようになる。 後出しジャンケンは、相互信頼を壊します... 同じ現場で、同じ課題を、同じ熱量で感じ合う。 当事者意識と、率先垂範、広く認められた権限で助け合う、感謝し合う。 こんなムードなら 後出しジャンケンも、ちゃぶ台は返しも無さそうです。 きちんと、ロバストな工程と役割を設計して、近未来までトレーサブル、成果が定量的に計測・永続化でき、合意形成のプロセスを重要視しているモダンな開発スタイルが運用できると、後出しジャンケンやちゃぶ台返しの報いが、ダイレクトにその人やチームに跳ね返るので、ズルは流行らなくなりそうです。
441Picks
製造現場のすべてを「見通す」、驚異のAIコーチング
NewsPicks編集部
戸ノ崎 学モビリティサービスのシステム屋
トヨタ生産方式を見ていると、リーンに「するのではなく」、リーンであり続け「理想や変化に追従して成長する」価値観を大切にしていると思います。注目してるのは、リーンは一つのフェーズではなく、将来に渡って追求する価値観、ということです。 お客様起点のニーズや需要の変化があります。 供給不足による 大幅な計画変更もあります 作業者や監督者の現場判断で、優先順変更もあります。 事故や緊急対応、病欠、作業ミス、新人教育に応じて、チームリーダーによる間欠的なフォローアップも日常的です。 小改善の横展や トライアルもあります。 技術革新があります。DXもあります。 記事で強調されていたAIは、「同じ事を続ける」前提に立って、その安定性向上のアプローチに見えてしまいました。もちろん、繰り返し 熟練を高めるメリットは計り知れませんが、リーンの次のフェーズというよりは、バラツキ低減で生産管理に貢献する 一つ前のフェーズなのかと、思いました。 日本の製造で強くあるために、優しさを発揮して変化に寄り添い、自らとチームを成長させ続ける、その実効性を高めるために、複雑やムダを削ぎ落としてリーンであるように、常にベターを追求する、こうした観点を壊さない形で新技術活用が大切かと思いました。 この観点で記事の技術を強調するのも面白いです。 このAIは、作業者のIoTを推進する技術になります。 工程のバラツキがモニタリング出来るようになります。ビッグデータとして蓄積できます。 人を糾弾するのではなく、工程設計の不完全さを追求する、クォリティ・コントロールの現状把握に役立ちます。 デジタル実績データを デジタル化したTPS工程に流すと、過去を再現できるようになります。パラメータを変えて同じ事を試行するとき、それは未来を垣間見るシミュレーションになり、改善案の良し悪しを知ることができます。 トライアル部署の改善を 既存部署に応用するとき、どのような成果が見られるか定量的把握できます。 事故や災害のシミュレーションで、サプライチェーン全体の予測精度が大幅に上がり、管理者や現場監督者の負担を大幅に下げられる期待が持てます。 AIの学習データにも使えますし、改革の成果のシミュレーションにも使いたくなります この技術は、未来を手の内にするリーンの価値観にフィットして、大いに貢献してくれそうです
486Picks
アップルは、マイクロソフトのWindows 365のような新OSを作るのか
Diamond Online
NORMAL
Premiumを無料で体験
登録・ログイン