中土井僚氏の著書『ビジョンプロセシング』の出版を記念し、これからの時代の未来との向き合い方を探究するトークイベントが開催されました。『プロセスエコノミー』などの著者でIT批評家の尾原和啓氏、READYFOR創業者の米良はるか氏と中土井氏の3名がトークセッションを行い、「答えはないのに、ゴールを示すべき」というジレンマの乗り越え方について探りました。本記事では、中土井氏が提唱する「SOUNDメソッド」について解説します。 前回の記事はこちら 権限を渡すだけでは人は動かない 中土井僚氏（以下、中土井）：私の中で、未来との向き合い方が人間にとってすごく大事なんじゃないかって思ったきっかけが、書籍（『ビジョンプロセシング』）の中でも紹介している「タスク・アセスメント」という考え方なんですね。これはけっこう古くて、1980年代にトーマスさんとベルトハウスさんがエンパワーメントの研究の中で提唱していま

ネットで色々な記事を読んでると、自分の足元とか現在地がよくわからなくなるので、定期的に現在位置とかをチェックする仕組みが欲しいなぁ…というメモ。 1. チェックしたい思想を定義するまず自己診断したい思想やムーブメントを定義し、図のセンターにおく。 「リベラル」「新自由主義」「フェミニズム」とか抽象レベルでも、「地球温暖化」「中絶法」のような具体的な思索でもよい。 2. 上下左右の極端な思想を定義するその分野の思想の、一番極端なバージョンを定義し、図の上下左右に配置する。 超急進 vs 超保守 画面の左右を超急進（既存制度を根本からぶっ壊すレベルで進めたい）と、超保守（既存制度を1mmを変えたくない、可能なら巻き戻したい）。 規範遵守 vs 規範無視 画面の上下を、規範遵守（法律と倫理を完璧にコンプリートしたプロトコルで執行したい）と、規範無視（目的の達成のためなら、私刑、暴力、破壊行為など

大量の業務に追われ、気づけば目の前の仕事をこなすだけの日々……。より質の高い仕事を求めたり、斬新なアイデアを生み出したい気持ちはあっても、なかなか時間と心の余裕を持てない人も多いはず。 そんな人におすすめなのが、物事を一つの上の視点から考える「メタ思考」のフレームワーク。『具体や抽象』などの著書で「メタ思考」の有用性を提唱してきた、ビジネスコンサルタントの細谷功さんは「一つ上の視点から考えることで『気づき』を得られ、知的な成長のための第一歩を踏み出すことができたり、思い込みや思考の癖から脱することによって発想が広がります」と言います。 高難度の仕事をこなしてキャリアアップを実現させたいビジネスパーソンにとっても非常に重要なメタ思考の基本的な考え方と、日々の仕事にメタ思考を取り入れる方法論について、細谷さんに伺いました。 細谷功（ほそや・いさお）さん。ビジネスコンサルタント、著述家。1964

うれしかった。ので、メモ。 僕のいるチームのプロジェクトで、複数のチームにサポートしてもらいながら進める必要がある、ちょっと大きなものが始まりそうだったから、キックオフ前のキックオフやっとこかーってなって司会をした。オンラインミーティングね。 最初にこの会の目的を説明 今日のアジェンダのページのリンクは事前に共有もしていましたけど、いまSlackにもポストしておきましたー。 まだプロジェクトは始まってないんだけど、事前に調査とかをしたいから質問や相談をさせてもらいたいなと思っていて、そのときに「え？これなんの話？」って戸惑わせることがないように、プロジェクトの概要を共有しとこうと思ったー！だから、この会がうまくいったら、僕らが質問してもみなさんが戸惑わないようになっている！ Bさん、Slackにメモ残してってください。お願いしまーす！ からの、会の流れを説明 最初にPdMから10分くらいで

かねてより人間、とりわけ労働者や従業員をリソースと呼ぶことについて批判的な意見を聞くことがあった。 2018 Don't call people resources - Ben Linders 2021 社員を「リソース」と呼んではいけない――。 | d's JOURNAL（dsj）- 理想の人事へ、ショートカット 2022 人間をリソースと呼ばない方がいいと思う - ジムには乗りたい 加えて、これらの主張に対するカウンターを見たこともある。「問題の所在が不明瞭」「情緒的な意見のみで代替が示されない」「人材を人財と書くような言葉遊びでは」等々。俗っぽく言えばここにあるのは、「モノ扱いしないでほしい」vs「とは言っても経営管理上はヒト・モノ・カネ・情報はリソースでしょ」という対立である。 この件について「人間をリソースと呼ぶことの問題についてアカデミックな見解・理論はあるのか」「人間をリソー

近年はマネージャー業務の負荷が増大したことによって、ミドルマネジメントの限界問題が叫ばれています。そんな課題を解決するために株式会社Momentorの坂井風太さんが「マネジメント民主化モデル」を提唱しているということを知りました。 私たちチームメンバーはマネージャーをどう支えていくと良いのか、「マネジメント民主化モデル」とはどのようなものなのか、お話をお聞きしました。 株式会社Momentor 代表取締役。組織効力感などの理論を元に、様々な企業の人材育成/組織基盤の構築を支援をしている。 早稲田大学法学部卒業後、DeNAに入社。6年目で子会社の代表取締役に就任。同時にDeNAの人材育成責任者として、暗黙知化・属人化されやすい人材育成・ピープルマネジメント領域の体系化を行い、独自の人材育成プログラムを開発。2022年に株式会社Momentorを設立。

カケハシでエンジニアリングマネージャーを担当しているいくおです。 今回は、私たちのチームで中規模以上（複数スプリントにまたがるもの）の機能開発を行うときに作成している「全体マップ」について紹介します。 全体マップを考案したのはチームメンバーの椎葉さんなのですが、「いくおさん言語化うまいからブログにしてください！」とおだてられたので、それを真に受けて私がブログに書きます。 全体マップを作るようになってから、中規模の開発で自分たちの状況を把握しやすくなりました。また、全体マップを通して関係者全員がコミュニケーションすることで、なめらかな協働関係を築けるようになりました。こういった実体験からも、ぜひ多くの現場で全体マップを試してみたいと思っています。 では、全体マップとは一体なんなのか、どうやって活用するとよいのか、解説します。 この記事は秋の技術特集 2024の6記事目です。 ユーザーストーリ

以下の記事などで既にかなり話題になっていますが、ぼくも触ってみました(使い方などの詳細はこちらの記事を参照してください)。 結論としては、マジすごくてかなり衝撃的です。すべてのホワイトカラーワーカーにとって、かなりディスラプティブなツールになるのではないでしょうか。 自分はコンサルタントでして、これまでにたくさんの資料を作ってきてスキルを磨いてきたつもりだったので、AIポン出しでここまでのものが出てきてしまうと、正直、人生について考えさせられちゃいますね。 この記事では、Napkinを使ってどういう資料ができたのか共有したいと思います。 ポストモーテムの勉強会をしたいなと思っていたので、まずはChatGPTで資料の骨子を出力し、それをNapkinに入力してみました。それで得られたのが、以下の資料です。 スライド1: タイトルスライド タイトル: ポストモーテムの教科書 副題: SREにおけ

これはなに ども、レバテック開発部のもりたです。 今回はMySQLでのスロークエリログについて調査してまとめました。 スロークエリログといえば古くからパフォーマンスチューニングの力強い味方といったふうに語られることも多いですが、最近はクラウドで使える便利なツールも生まれています。この記事ではスロークエリログの一般的な使い方を紹介するとともに、他のツールとの比較や、どんな場面でスロークエリログが役に立つのか、また役に立たない場合はどんなツールを利用することができるのかについてまとめました。 足りないところなどあればおおいにマサカリ投げていただけると幸いです。 記事の流れ 記事の流れ この記事はそこそこ長いので、初めに記事の流れを解説します。適宜読み飛ばしてください。 なぜスロークエリログなのか ここではそもそもスロークエリログをなぜ確認したいのかみたいなところを説明します スロークエリログの

ChatGPTを利用するときに漫然とプロンプトを入力するだけでは、その能力を十分に引き出せない。ChatGPTの達人である深津貴之氏が、プロンプトの極意を伝授する。 第5回 深津氏に学ぶChatGPTプロンプトの極意、必要な行動を考えさせてから尋ねる ChatGPTの達人である深津貴之氏にプロンプトの書き方を整理して教えてもらう。今回取り上げるのは「ReAct（Reasoning + Acting）」だ。 2024.09.06 第4回 深津氏に学ぶChatGPTプロンプトの極意、段階ごとやアプローチ別に考えさせる ChatGPTの達人である深津貴之氏にプロンプトの書き方を整理して教えてもらう。今回取り上げるのは「Chain of Thought」と「Tree of Thought」だ。 2024.09.05 第3回 深津氏に学ぶChatGPTプロンプトの極意、資料そのものをAIに作ってもら

2024/9/2 LayerX 全社週次定例 LayerX 部門執行役員 AI・LLM事業部長 中村龍矢 https://x.com/nrryuya_jp

スクラムガイドの目的 スクラムは複雑なプロダクトを開発、提供、保守する為のフレームワークである。このガイドではスクラムを定義している。定義には役割、イベント、作成物とそれらをまとめるルールが含まれている。フレームワークの各要素は特定の目的を有し、スクラムによって実現される価値と成果にとって不可欠な要素となる。スクラムの考え方や構造を変えたり、要素を省いたり、ルールを無視する事は問題を隠し、スクラムから得られる価値を限定したり、無意味な物にしてしまうのである。 Ken Schwaber と Jeff Sutherlandはスクラムのフレームワークを作る事に重要な役割を担った。 LeSS（大規模スクラム）は複数のチームでプロダクト開発をする際にスクラムを適応し、組織のシステムが変化した結果として形作られ、LeSSはLeSSルールにて定義をされている。LeSSルールは、各チームのレベルではスクラ

チームのパフォーマンスを高めるために、日々試行錯誤している方も多いと思います。私自身も、プロセス改善にこだわり続け、うまくいった部分もあれば、失敗を経験した部分もあります。今回は私のチームリーダーとしての失敗談と学びを共有したいと思います。 チームリーダーとしての責任Tebiki株式会社 エンジニアの二瓶と申します。私は Tebiki株式会社の Web アプリケーションエンジニアとして入社し、現在は tebiki現場分析 の開発を担当しています。また、チーム内では「チームリーダー」という役割 を担っています。弊社のチームリーダーのミッションはざっくりいうと「生産性とプロダクトの品質を最高の状態に保ち、プロダクトの価値を最大化できるような『チームの状態』をつくること」です。ここでいうチームとはプロダクトマネージャー、デザイナー、エンジニアを含む開発チームことです。これまで一人の開発者として手

こんにちは。AWS Container Hero の新井です。 Amazon ECS の登場から間もなく 10 年が経ちますが、その間、ECS ⾃体の進化に加えて、さまざまな AWS マネージドサービスとの連携が可能になりました。 現在では、コンテナベースのワークロードを活⽤することで実現できないことを探す⽅が難しいほど、柔軟なアーキテクチャが構築できるようになっています。 しかし、⾃由度が⾼い分、要件に合ったアーキテクチャを模索する際には、迷うことも多いでしょう。 AWS上でシステムを適切に構築するためには、あらかじめサービス間のつなぎ⽅やパターン、その特徴を把握しておくことが重要です。 これにより、フィージビリティを迅速に確認でき、その後のトライアンドエラーのサイクルを加速させることができます。 今回は、最新の AWS サービスアップデートを踏まえつつ、Amazon ECS / AWS

フィーチャーフラグの標準規格 OpenFeature の React SDK を試してみる 2024.08.31 OpenFeature はフィーチャーフラグのオープンな規格です。特定のベンダーに依存しない API や SDK が提供されています。フィーチャーフラグの API の標準化により、ベンダーロックインを回避し、フィーチャーフラグのツールを自由に選択できるようになります。この記事では OpenFeature の React SDK を使ってフィーチャーフラグを評価する方法を紹介します。

はじめに こんにちは。calloc134 です。 バックエンド開発において、DB にデータを保存することはよくあることです。 DB と接続してデータのやり取りを行う必要がありますが、皆さんはどのようにしてデータを取得していますか？ ORM やクエリビルダを利用したり、逆に SQL を記述してコード生成を行ったりと、様々な方法があります。 今回はこれらのアプローチについて比較し、比較的斬新な方針を取っているものとして SafeQL を紹介します。 注意点 ここでは、TypeScript のバックエンド開発と、そこで利用されるライブラリを前提として話を進めます。 Go や Python など他の言語での利用方法については、別途調査が必要です。 SQL に対するアプローチ まず、SQL に対するアプローチには大きく分けて 2 つの方法があります。 それぞれのライブラリの使い方を、簡単に見ていきま

エンジニアの未来と生成AIについて質問させて頂きたいです。情報系の学部に所属している者なのですが、自分が何時間もかけてやった課題をChatGPTに投げるとほんの数秒でサンプルコードが提示されます。自分の課題のレベルが低く、上のレベルでは自力でプログラミングをすることが必要なのは理解しているのですが、何時間もかけたものが一瞬にして解決される様にAI発展の喜びより冷酷さを感じてしまいます。エンジニアとして働きたい者としてどのようにこの事実と向き合うべきでしょうか？ ソフトウェアエンジニアの仕事について誤解があるようです。 確かに書けと言われた題材を動くまで持っていく力は大切ですが、それよりもっと大切なのは動いている物を思い通りにする力です。ソフトウェアエンジニアの仕事の9割以上は既に書かれているコードに対して何らかの変更を加える事であって、どこをどう書き換えるべきかという疑問に対して生成AIが

Prisma界隈で話題沸騰中（自分調べ）のTypedSQLだが、自分の中ではかなりアツいと思っているので、その理由を語ろう。なおTypedSQLの機能とか仕組みについては記述しないのでドキュメントや以下の記事を参照するとよい。 Prismaの難しさ 複雑なクエリを組み立てるのが特に難しい。複雑といっても何10行もあるようなクエリとかではなく、joinとか集計関数がいくつかあるくらいで十分複雑になる。たとえば特定のユーザーに紐づく記事をコメントの数を含めて取得したいとする。クエリは雰囲気こんな感じ。SQLとしては全然難しくない。 SELECT posts.id, count(comments.id) AS cnt FROM posts INNER JOIN users ON posts.author_id = users.id LEFT JOIN comments ON posts.id =