Workに関するhathewyのブックマーク (8)

  • 法とは「願い」。「ベンチャーだから」を理由にルールの逸脱や安易な変更を容認する会社に未来は無い|細田 薫|ファームノート CHRO

    新卒で住友商事に入り、ゴリゴリに尖ってイキっていた私は「信じられない分量の社内ルール・規則」に対して真っ向から、とてもしっかりと唾を吐いていました。 この頃は「其々のルールが価値を発揮しているかどうか」ではなく、単に「イミワカンナイ、マジムダ(だと思う)ルールに抗ってる俺カッケエ」といった独善的な"ノリ"での行動だったと思います。 今こんなやつが自分の組織にいたら、直ぐに宙吊りにすると思います笑 しかしその後、ブラジル、ウクライナ、上場ベンチャー、医療機関、未上場ベンチャー、、、と多様な会社の経営に携わり、「法(ルール・規則)の存在意義、そして経営陣はそれとどう向き合うべきなのか」について考えを巡らせてきました。 今回、東浩紀さんの「平和と愚かさ」を読み、自分の中で一つの言語化が結節したので、それを引用しつつ世の「ベンチャーなんだから、ルールルール言ってんじゃねえよ!」と宣う方々に対しての

    法とは「願い」。「ベンチャーだから」を理由にルールの逸脱や安易な変更を容認する会社に未来は無い|細田 薫|ファームノート CHRO
  • Symphony - OpenAIが発表したチケット駆動AI開発ツールについて

    こんにちは!ブロックチェーンエンジニアの山口夏生です。 ブロックチェーン×AI Agentで自律経済圏を創る開発組織Komlock labでCTOをしています。 コーディングエージェントを複数並列で自律的に回すマルチエージェント開発が、ここ数ヶ月でエンジニアの間に急速に広まっていますが、まだそれぞれ試行錯誤しているフェーズで、最適解はない認識です。 OpenAIが最近発表したSymphonyに注目しています。 自分もClaudeCodeとOpenClawのオーケストレーションを日常的に考えていて、複数エージェントのタスクやセッション管理に苦労していたので、とても気になりました。中身を読んでいきます。 これまでの試行錯誤 — 「エージェントチームの管理」は個人技だった Ralph Loop — エージェントの基的なフィードバックループ マルチエージェント開発の文脈で「Ralph Loop」

    Symphony - OpenAIが発表したチケット駆動AI開発ツールについて
  • なぜ、AIで生産性があがっていると錯覚してしまうのか

    1983年生まれ。筑波大学大学院を卒業後、2008年に新卒第1期として株式会社ミクシィに入社。アーキテクトとして、技術戦略から組織構築などに携わる。同社メディア開発部長、開発部部長、サービス部長執行役員を務めた後、2015年退社。現在は、株式会社レクターを創業し、技術と経営をつなぐ技術組織のアドバイザリーとして、多数の会社の経営支援を行っている。一般社団法人日CTO協会理事、朝日新聞社社外CTO。

    なぜ、AIで生産性があがっていると錯覚してしまうのか
  • 「指摘もどき」について考えてみた|柳川慶太

    BASE株式会社執行役員の柳川です。金融事業の事業責任者をしています。 私はエンジニアPdM→事業責任者というキャリアを歩んできました。 現在は事業戦略、プロダクト戦略、組織戦略全ての責任を持ちながら、事業責任者を務めさせていただいています。 こにふぁーさんの問題解決ブルドーザーの記事。問題解決ブルドーザーもいい表現なんだけど、指摘もどきもなかなかいい表現だなと思いまして、借ります。 この記事は指摘もどきをしてしまって上手く行かなかった、過去の自分の反省を振り返りながら書いています。 「言ったとおりにしろ、反発するな」と言う話ではなく、「建設的なやり取りをできたほうが良いよね、そのためには指摘する側にも、指摘を受ける側にも技術が必要なんだけど、構造的に負担が指摘を受ける側に偏りがちかも?」と言うのがこの文章のテーマです。 もう少し具体的に言うと、次のリーダーを育成する中での気づきになりま

    「指摘もどき」について考えてみた|柳川慶太
  • 問題解決ブルドーザー - Konifar's ZATSU

    視座の可視化というこの記事がめちゃくちゃ好きで、たまに読み返している。 note.com ここに書いてある、課題があった時のアクションのレベルみたいな話がわかる~~~って感じで好き。 具体的には何らかの課題があったときに下記のどのアクションをするか判断できそうです。 ・ そもそも気づいていない ・ 認知してる(けど言語化できない) ・ 問題指摘する ・ 解決策を提示する ・ 解決する 自分の経験だと、「問題指摘する」と「解決策を提示する」の間に結構隔たりがあって、指摘したら物事が前に進むと感じている人が意外と多い気がする。 また、問題を指摘してるつもりで、実は問題を把握できてなかったり適切に指摘できてないケースも多い。例えばあまり理にかなっていないと感じる制度に対して「これなんでずっとこうなってるのか謎」「こう変えればいいのに」とコメントしたとして、これは問題の指摘と言えるだろうか。これは

    問題解決ブルドーザー - Konifar's ZATSU
    hathewy
    hathewy 2026/02/22
  • Claude Codeと暮らす | DevelopersIO

    はじめに こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。 Claude Codeを使い始めたけれど、まだ「ちょっと賢いターミナル」くらいの付き合いになっている方はいませんか。あるいは、毎日使っているけれど「セッションが終わるたびに文脈がリセットされるのがもったいない」と感じている方もいるかもしれません。 AIコーディングツールは便利ですが、そのまま使っていると「賢いけど記憶喪失のペアプロ相手」になりがちです。昨日デバッグした問題の経緯も、先週の設計判断の理由も、新しいセッションでは白紙からのスタート。「……また同じ説明からか」と思ったことがある方、きっと少なくないはずです。プロジェクトが増えるほど、この「文脈の断絶」がじわじわ効いてきます。 Claude Code界隈ではClaude-Memをはじめ、記憶の永続化や開発効率化のためのソリューションが日々登場しています。アン

    Claude Codeと暮らす | DevelopersIO
  • コンサル新時代の幕開け:パランティアモデルの台頭、ファクトベースの終焉|Kozo Fukushima

    Executive Summary ファクトベースコンサルの終焉:賢さのコモディティ化Gemini 3 Pro と NotebookLM のアウトプットは、戦略コンサルティングに10年ほど身を置いた私には『衝撃』だった。将棋の名人がAIに敗れた時の、プロ棋士の心境かもしれない。賢さのコモディティ化が決定的になった ファクトベースは徹底的なリサーチと構造化や分析が価値の源泉Gemini 3 Pro と NotebookLMが思考とファクトベースを民主化新たな時代の幕開け:パランティアモデルの台頭常にコンサルモデルは進化してきた。ファクトベースの終焉は、コンサルの終焉ではなく、新たなモデルの始まり。代表するのがソフトウェアの高速稼働で、現場に埋め込み、Time-to-Valueを実現するパランティアモデル 価値創出のメカニズムは「高速実装」と「現場への埋め込み」質的な違いは爆発的なスピード「

    コンサル新時代の幕開け:パランティアモデルの台頭、ファクトベースの終焉|Kozo Fukushima
  • Real AI Agents and Real Work

    AIs have quietly crossed a threshold: they can now perform real, economically relevant work. Last week, OpenAI released a new test of AI ability, but this one differs from the usual benchmarks built around math or trivia. For this test, OpenAI gathered experts with an average of 14 years of experience in industries ranging from finance to law to retail and had them design realistic tasks that woul

    Real AI Agents and Real Work
  • 1