運用設計ラボ シニアアーキテクト。 日本MSP協会特別会員。 JAWS-UG事務局インフラ主担当。JAWS-UG CLI専門支部長。AWS Community Hero。AWS Samurai 2017/2020。AWS認定7冠。

Tokyo
Joined November 2007
【ちゃんと動いているシステムの更改について】 タイムズさんやSOURCENEXTさんの事例を見てすごく気持ち悪いなと思った方も少なく無いと思います。上原先生が指摘する「古いITシステムの見直し」は、多くの日本企業が抱える致命的な急所だと思う。 一般企業では、目に見えるITの「上物(UI等)」は見栄えや利便性の関係からそれなりに重視される。その一方で、IT基盤については「現に動いているからこれで良いんじゃない?」と投資する理由が無くそのままで運用されている場合も少なく無いですよね。 また、現場のエンジニアや運用側としても、せっかく安定してちゃんと動いている(そもそもブラックボックスだったりする)を、リスクを冒してまで弄りたくないという心理がどうしても働いてしまうものなんですよね。 しかし、その現状維持が通例化することによって、今となってはちょっと考えられないような古い仕様や設計のシステムが、誰にも気づかれず(あるいは見ぬふりをされて)取り残された結果がこれですね。 皮肉にも、そのような古い器のままで安定稼働していると誤解し「1000万件とかいう多大な個人情報を扱い続けた」その結果、今回のような甚大な情報漏えいへと繋がってしまったんだと思います。 このような見えない部分へのIT投資や運用を軽視する姿勢を続けていれば、「2038年問題」を迎えたとき、何の前触れもなくいきなりシステムが停止したり、深刻な誤作動を起こしたりすることになる。 2038年問題とは、2038年1月19日3時14分7秒(UTC)(日本時間では12時14分7秒)を過ぎると、コンピュータが日時を正しく処理できなくなるというもの。 2000年問題と同じ根っこの問題で、そんな昔話で笑い話みたいなのが今更本気で問題視されること自体がかなりイタいというのが本音です。 安易に「動いているから大丈夫と放置する」ツケは、残念なビジネス(IT運用を含む)の結果として、いつか破滅的な形で回ってくるんだと思います。 このタイムズさんやSOURCENEXTさんの例を見て、日本中が「総点検だー!」とやるくらいでもちょうどよいかなと思います。ブラックボックスの蓋を開けるのは早い方が良いです。
タイムズカーといいSOURCENEXTといい、10~20年前ではないかという古い基本設計のソフトウェアが使い続けられていたように見える。比較的システム更新が早いWebの世界で。インフラ系はもっと古いのが当たり前なので、脆弱性もどこに地雷があるかわからんし、2038年問題も対応できているか不明だよね…
33
5
60
15,347
AWS CLIを触りはじめた2014年から、AWSのAPIは、「ひとつのことを上手にやる」というUNIXの考え方に親和性が高いと個人的には感じています。 (20年以上経過してかなり肥大化していますが。端的にはEC2デカ過ぎ)
そうですね、私もそういう認識です。 ビルディングブロックはつまりはIaaS的(ただし、APIで組み立てられるレゴのような感じ)。故にAWSの場合は、同じようなことを実現する方法がいくつもある。 一方でGoogle CloudのSaaS感は、決め打ちの型があって、基本的にはその型に合わせることで最適化される。
2
225
今年の2月に発表した資料で、IT(数理論理学)は収斂的で、生成AI(数理統計学)は発散的という話をしたのですが、当時この切り口で対比する論は見掛けなかったので、割とオリジナリティがあると自分では思っている。
1
1
3
317
比較の図
131
勉強会の振り返りについてはこんな感じでまとめた。 ※あくまで私のインプットからのアウトプットです。勉強会の資料を直接のところもあれば私の解釈の個所もあります。
1
3
5
462
最初は @tcsh さんのお話 初っ端からIT運用のリアル聞いてて導入だけで面白い #福岡AIと運用のリアル
1
5
353
Replying to @east_takumi @tcsh
たまに思うんだけど、うちのチームで運用の話が難しいのってボトムアップというかみんなの合意形成を得ないとになってるのが一番きついのではって気がしてきた #福岡AIと運用のリアル
1
1
1
216
AI は運用の相棒になれるか? 実際の現場目線で語る、これからの運用のかたち fusic.connpass.com/event/401… #福岡AIと運用のリアル 今日はこれに参加した。 生の波多野さん初めてお会いした。 資料についての感謝を伝え損なって「不都合な運用自動化の真実」のお礼を先にしてしまった笑 私の中で言語化できない部分、会社の上層部や同僚にどう伝えるのか悩んでたところを思いっきり解消していただいた感じだった。
2
1
3
701
Replying to @east_takumi @tcsh
> 運用は再現性がないと評価されない いやそうなんよ 再現性ない作業を運用って呼びたくないんよ、、、 #福岡AIと運用のリアル
1
1
4
204
HATANO Hirokazu retweeted
次の JAWS DAYS 2027 は 3月13日(土)です! 間違えて 3月6日 あたりに宿を取っていた人お気をつけて! サイトもオープンしてます! ロゴはまだ内緒、とのこと #jawsdays2027 #jawsug
JAWS DAYS2027を池袋サンシャインシティで開催します!公式サイトもオープンしました。3/13土をSAVE THE DATE! #jawsug #jawsdays #jawsdays2027
9
42
1,441
@tss_ontap さんに無茶ぶりいただいて2018-03-30に発表した「技術導入とその運用設計を考える 〜 過去と未来と」以来の頭の使いっぷりだったので、結構大変でした。 (でも楽しかったです)
1
206
感覚的にかなりしっくり来る。 自分の生成AI理解にかなり近いので、時間見つけて整理していこう。
このAWSの方の発表はかなり面白い。Amazon内部のAI活用実績をだいぶ話してくれている。良かったので、メモ多め。 ・(前提)発表者は、AWSのシニアプリンシパルエンジニアであるクレア氏 ・初期のAIコーディング支援はコードの行補完やチャットベースの質問にとどまっており、生産性の向上は10〜20%程度にすぎなかった ・しかし現在、Amazon社内の一部のチームでは、生産性が中央値で4.5倍、時には10倍以上にも跳ね上がるという劇的な変化が起きている ・このような圧倒的な成果を出す開発者をフロンティア・デベロッパーと呼ぶ。 ・フロンティア・デベロッパーの第一の特徴は、自ら記述するコードを全体の1〜2%に抑え、残りのすべてをAIエージェントに任せていること ・第二の特徴は、彼らはエージェントと頻繁にやり取りせず、数時間単位で自律的にコードを書かせ続けること ・第三の特徴は、待機時間を最小限にするため、複数のAIエージェントを並行して稼働させ、タスクのバックログを次々と消化させている点 ・この飛躍的な生産性が最初に確認されたのは、BedrockのMantleチーム ・30人で18ヶ月かかると想定された新システムをわずか6人が76日間で構築した ・しかしこの成功例は、分散システムやAIの専門知識を持つ社内トップクラスのエンジニアが集められた特殊な事例 ・なので、一般的なチームでの再現性に疑問が残った ・次にPrime Videoのチームが6人で10日間のスプリントを実施すると、90週の工数がかかるとされたプロジェクトを24週にまで短縮する成果が出た ・だがこれも、ミーティングやオンコール業務を一切排した特殊な隔離環境 ・事前に3週間かけて詳細なタスク定義が行われていたという前提があった ・そこでAmazon Stores部門は、既存のシステムを扱うごく一般的な50のチームを対象に、より現実的な環境でのパイロットテストを実施 ・その結果、半数のチームは生産性の向上が3倍未満に留まったのに対し、残りの半数は4.5倍から10倍の生産性向上を達成した ・この劇的な違いを生んだのは、AIに合わせて働き方を意図的に変えたかどうかという点 ・高い成果を出したチームには、新しい働き方として共通する5つの習慣が根付いていた ・第一の習慣はエージェントのコンテキストへの投資 ・従来は口頭やチャットで共有されていた暗黙知を、AI向けの指示ファイルとして明文化した ・第二の習慣は、急ぐためにあえて減速したこと ・エージェントが動作しやすいように既存のコードベースやエラーメッセージを整理する準備期間を設けていた ・AIがコードを理解して自己検証しやすい環境を作るために、Pythonのような動的型付け言語から、コンパイラが優秀なTypeScriptやRustへ移行するチームさえ存在した ・第三の習慣はエージェントのお守りをしないこと ・少しずつコードを書かせて対話するのではなく、自己検証可能なまとまったタスクを与えて放置する ・第四の習慣は意図の明確化 ・事前に詳細な仕様書を作成して、AIとドキュメントの段階ですり合わせを行っていた ・第五の習慣はテストのシフトレフト ・リンターやローカルで動くモックサーバーを活用して、エージェントが素早く自己修正できる環境を構築していた ・これらの習慣を取り入れるプロセスは決して簡単ではなく、エンジニアが新しい働き方に適応する過程でバーンアウトするリスクもある ・完璧なプロンプトを求めて夜遅くまで作業してしまったり、複数のエージェントを並行管理することでエンジニアの認知負荷が劇的に高まったりする ・特に若手エンジニアにとっては、自らコードを書くよりも、AIが生成した大量のコードを読み解いてレビューする作業のほうが重い負担となっている ・AIを効果的に活用するためには組織側の変化も不可欠 ・リーダーは「AIがあるのだからすぐに開発が早くなるはずだ」という安易な期待を捨てなければならない ・事前準備やコードベースの整理には数ヶ月の時間を要する ・なので、経営陣は生産性が一時的に低下する減速の期間を許容する必要がある ・また、十分なノウハウが蓄積される前に組織全体へAI開発を急激にスケールさせると、チームが混乱に陥るリスクが高い ・AIによってコーディング自体が劇的に高速化された結果、プロダクトを作るかどうかの意思決定にかかる時間が新たなボトルネックとなっている ・コードが数週間で完成するようになった現在、承認プロセスや意思決定に何ヶ月もかけていてはAIのスピードを活かしきれない youtube.com/watch?v=pqlWNihg…
1
15
5,481
HATANO Hirokazu retweeted
分解と再構築をしたとき、同じ粒度に分解され、組み立て手段は違えど同じ形に再構築されるのはとても興味深かった #ssmjp
1
3
530
「よくわからない何かを扱う運用」でもきれいな方法をなんらかの形で適用することはできると考えていて、そのための「ゴール像」をいくつも考えるのが大事だと思っています。 その土台になっているのは自分の場合「UNIXの考え方」「オブジェクト指向」「演繹的指向法」の3つかなと思っています #ssmjp
正直なところ、よくわからない何かを取り扱う運用にはなかなかきれいな方法は適用できないので、疎外感半端ないという気持ちはあれど、それをなんとかするのが今の立場なので、愉快ではないが仕方がない、という感想になった。 #ssmjp
1
5
601
HATANO Hirokazu retweeted
何をもって確認完了とするかは書くようにしている(出力結果とか) #ssmjp 上記はJAWS-UG CLI専門支部のハンズオン手順書から学びました 昔は確認する、としか書いてなかった時もあったかも
1
5
322
HATANO Hirokazu retweeted
#ssmjp 倍速視聴完了☑️ライブに復帰 CRUDを分離するとか、明日から仕事に取り込みたいことだらけ!! ほんと、ドキュメント化もコミュニケーションも、大事。
1
3
227