タグ

2023年6月21日のブックマーク (5件)

  • 「誰が何をしているか」がわからない組織がうまく回らない理由 “考えなくても動けるチーム”をつくる、2つの認知モデル

    イノベーションを起こすために欠かせない要素として注目が集まる「心理的安全性」。今回は、心理的安全性をテーマに各界の専門家・実践企業が集まった「Unipos心理的安全性サミット2022」より、早稲田大学商学部准教授の村瀬俊朗氏の講演の模様をお届けします。イノベーションが生まれやすい多様性のあるチーム作りにおいて「信頼」が重要な理由や、「リーダーシップ」の捉え方について語られました。 言語化コストのかかる「暗黙知」は、信頼がないと共有されない 村瀬俊朗氏(以下、村瀬):ここで「信頼が重要である」という話をします。我々は、ネットでぱっと情報を見ると思いますが、それは誰にでもわかりやすいように「形式化された情報」なんですね。 しかし、人々が専門的になっていったり、いろんな経験を積んでいくと、言語化できる情報はほんの一部になってくるんです。来、新しいことをやる時には、薄い情報の共有・提供ではなく、

    「誰が何をしているか」がわからない組織がうまく回らない理由 “考えなくても動けるチーム”をつくる、2つの認知モデル
  • プロダクトが大きくなると、なぜ生産性は下がるのか? 『Team Topologies』から読み解く、「認知負荷」という考え方

    株式会社overflowによって開催された、開発組織のあり方について考える1ヶ月「CTOWeek 2023 by Offers」。Week2に登壇したのは、株式会社LayerX 執行役員の名村卓氏。開発スピードを落とさないために必要な、イネーブルメント組織について話しました。全3回。1回目は、開発の生産性に大きく影響する、「チームの認知負荷(Team Cognitive Load)」について。 名村卓氏のキャリア変遷 大谷旅人氏(以下、大谷):それでは日のメインの名村さんのお話に入りたいと思います。LayerX 名村さん、ご登壇よろしくお願いします。 名村卓氏(以下、名村):はい、よろしくお願いします。LayerXの名村と申します。今、LayerXでEnabling Teamという、Enablementをやっている組織にいるのですが、今日はそこでの経験と諸々含めてお話できればと思っていま

    プロダクトが大きくなると、なぜ生産性は下がるのか? 『Team Topologies』から読み解く、「認知負荷」という考え方
  • https://twitter.com/TakumiTonosaki/status/1668585590072426497

    tanaka_shi
    tanaka_shi 2023/06/21
    “・プロジェクトについて説明・概要 ・課題:このプロジェクトで何の課題を解決するか? ・Why:どのようにしてそれが解決する意味ある課題だと判断するか? ・成功:どのようにしてその課題が解決されたかを測定する
  • Webサイトのワイヤーフレームの作り方 ― FigmaやXDを開く前の3ステップ|重松佑 / Shhh inc.

    先日1500ページくらいのやや大きめなコーポレートサイトのワイヤーフレームをディレクター、デザイナー、テクニカル担当、アシスタントという職能や経験もバラバラのチームで共同作成しました。みなが足並みを揃えて進めていけるようにワイヤーフレームの作り方を要素分解して、共通理解を持って作業をできるようにしました。どのような手順や考え方で進めていったのかをnoteにも記しておきます。 0. 情報設計とトンマナ設計を分けて考える Webサイト制作ではデザイン着手前の工程でワイヤーフレームと呼ばれるWebサイトの設計図のようなものを多くの場合で作ります。デザインとの違いは何かというと、上図のようにワイヤーフレームでは「情報設計」を主として扱います。そのためトンマナ(トーン&マナー)と呼ばれるWebサイトの印象や雰囲気を形作る要素については考えず、Webサイトに掲載する情報について決定することが目的となり

    Webサイトのワイヤーフレームの作り方 ― FigmaやXDを開く前の3ステップ|重松佑 / Shhh inc.
  • ITプロジェクトの失敗原因、追究する5つのステップ

    作業はグループで進めるのが望ましい。1人でもできるが、プロジェクトに参画した複数のキーパーソンで議論したほうが、より客観的かつ網羅的に原因を究明できる可能性が高い。 ステップ1:全ての失敗原因を抽出 ステップ1では「ITプロジェクト版失敗原因マンダラ図」から全ての失敗原因を抽出する。図に示した第1レベル・第2レベルの原因全てについて、今回のプロジェクトの失敗原因として当てはまるかを確認。当てはまる全ての原因に丸印を付けていく。 作業は左下の「無知」から始めて「未知」で終わるよう、時計回りに進める。この段階では参加メンバーが個別に確認・記入していく。 メンバーは丸印を付けた項目について、具体的な事象を書き出す。「重要性の認識誤り」に丸印を付けたのであれば、「システムダウンが引き起こす社会的な影響を経営層は軽視していた」などと書く。 これは「抽象化と具体化」という技法に基づいている。具体的な事

    ITプロジェクトの失敗原因、追究する5つのステップ