『段ボール読み』集合知山手線ゲームをふりかえる - 余白
この記事は ゆる言語学ラジオ非公式 Advent Calendar 2022 - Adventar の7日目の記事です。 adventar.org アドベントカレンダーの発起人ではあるものの他の参加者みたいなコンテンツは持ち合わせてないので、ゆサD（ゆる言語学ラジオサポーターDiscordサーバー）の中で今年楽しかった集合知山手線ゲーム（あるルールに合致するワードを集めたい人が山手線ゲーム形式で集合知を募る遊び）のひとつ、『段ボール読み』スレッドについて振り返りながら、こういう遊びをサポーターコミュニティでは楽しくやってるよ、という雰囲気を紹介したい。こんな遊びが好きならあなたもぜひゆサDへ！ yurugengo.com 専門用語が多くて語釈がめんどくさいなこれ。 集合知山手線ゲームチャンネルの様子 『段ボール読み』の誕生 ことの発端は2022年2月4日、ゆサDのゆるい雑談チャンネルでのひ
コンウェイの法則の反転現象 - 余白
発見したつもりだが、すでに周知のことかもしれない。が、少なくとも私には知られていなかった。全文はScrapboxに。 scrapbox.io TL;DR システムの構造を変更するほうが組織の構造を変更するよりも困難である場合、組織の構造はむしろシステムの構造から優越的に影響を受ける 「コンウェイの法則の反転現象」と呼ぶものについて システムの構造と組織の構造がミスマッチしたとき、システムの構造を変化することが容易でなければ、組織の構造のほうが適応してしまう システム開発能力の養成が不十分なまま内製化を進める組織においては、この反転現象が起こりやすい また、ソフトウェア開発現場のアジャイル化はこの現象をさらに促進するだろう アジャイルな組織とは変更容易性の高い組織であるため、相対的に必然的に組織の構造のほうが適応しやすい この現象によって、逆コンウェイ戦略を狙ってシステム構造の改善をめがけた
ギバーのジレンマ - 余白
他者に対して惜しみなく何かを与えるギバーがもてはやされる昨今、しかし与える者はそれを受け取る者がいてはじめて成り立つ。 自身がギバーでありたいと望むならば、他者がそれを受け取ってくれることを望まずにはいられない。 そのとき、利他的でありたいという欲望は、他者の利己的な姿勢を求めるという意味において利己的な欲望として現れる。 多くのビジネス書などでは、成功する確率が高いのはテイカーよりもギバーであると言われている。 そのような状況でみずからテイカーになろうという者のほうがむしろ自己犠牲的とも言えるのではないだろうか？ つまり、利他的であろうとすればするほど他者の自己犠牲を求める利己的な姿勢として現れてくるのではないだろうか？ ヒーローであるためには世界に悪がいなければならないヒーローのジレンマのように、ギバーでいるためにはテイカーにいてもらわなければならないギバーのジレンマがそこにあるのでは
ふりかえりの本質・事象評価の4象限・KPTの矯正効果 - 余白
ふりかえりの本質 まずはじめに、ふりかえりの本質は「ある特定の時間・空間的範囲において発生した事象に対する評価」であるということから説明する。 時間的範囲は過去のある時点から現在までの範囲が典型的だが、場合によっては未来の時点も含む。いわゆる事前検死（プレモーテム）は未来の失敗を終点とするふりかえりである。また、空間的範囲はふりかえりの対象となる個人や集団が知覚可能な範囲だ。離れたチームや地球の裏側の事象まで対象にすることはない。 ふりかえりの対象は必ずしもふりかえりを行う当人とは限らない。他人の活動を外部からふりかえることもできる。 だが、ふりかえりという活動から評価とそれを行う評価者の存在は除外できない。 もっとも根本的な評価は事象の選別である。ふりかえりの中でどの事象を取り上げ、どの事象を取り上げないかという選別がすでに事象に対する評価である。 その上でさまざまな基準によって個々の事
ソフトウェア設計を学びたい人々にまず教えるべきことはテスト技法ではないか - 余白
根本の問題意識 ソフトウェアの設計スキルはどのように獲得する（させる）ことが効果的であるのか ソフトウェアアーキテクチャの目的 そもそもソフトウェアアーキテクチャはどのような欲望を満たすための方法か ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するための必要な人材を最小限に抑えること である。 (CLEAN ARCHITECTURE) 「求められるシステムを構築・保守するための必要な人材を最小限に抑えたい」 => 構築容易性 と 保守容易性 を確保したい 構築容易性 「構築しやすさ」とは？ ソフトウェアを構築するとはどういうことか ソフトウェアの2つの価値: 「振る舞い」と「構造」 振る舞い: 要件を満たすこと => いわゆる機能 構造: 振る舞いを簡単に変更できること => いわゆるアーキテクチャ 構築しやすさ=価値の生み出しやすさ 要件を満たしながら振る舞いを変更
情報ではなく経験をアウトプットすること - 余白
調べれば大抵の情報は誰でも手に入る今日このごろ。特に技術的な情報はオープンソースで一次情報へのアクセスは容易になった。 それと同時に繰り返し言われるアウトプットの重要性。 しかし、ブログやLTなどでアウトプットしても、「もっと質のいい情報があるのに自分がアウトプットする必要があるのか」「逆にノイズになるだけじゃないか」というような考えになってしまう人もいるのではないか。 そんな架空の声にお応えして、それでもなおあえて、一次情報ではない「あなたのアウトプット」の重要性を伝えてみようと思う。 実際にやる人は多くない 定量的なデータがあるわけではないが、直感的に共感してもらえるだろう。 ある技術や手法が話題になったとして、それを情報として知っている人はこの時代いくらでもいる。 だが、それを実際にその手でやったことがあるというだけでかなり群衆からは抜きん出た経験を持つことになる。 ましてやそれをや
謙遜しないと決めている話 - 余白
僕は誰かに褒められたとき、謙遜しないようにしている。 褒められたら「ありがとうございます」「嬉しいです」「照れます」と、はっきり言葉で喜びを示す。 これを心がけはじめた最初のころは意識的だったけど、最近では意識しなくても自然にそう振る舞えるようになった。 これまで何人かに、「それいいですね」と言われることがあって、そういえばこの自分ルールについてちゃんと言葉にしたことがなかったなと思ってこの記事を書いている。 褒めたいと思ったあなたを否定しない 「謙遜しない」というルールの根幹は、「褒めたいと思ったあなたを否定しない」ということ。 褒めてもらったことが、自分が本当に認められたいことではないときもある。あるいは、何気なくやったことで自分ではそれほど価値を感じていないことのときもある。 それでも、相手が自分を褒めたいと思ったそのことはその人にとって疑いようのない事実である。「そう思った」という
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
