nDiki : 自己組織化

2004年6月11日 (金)

創発 蟻・脳・都市・ソフトウェア自己組織化ネットワーク

rimage:ISBN:4-7973-2107-5

以前からちょっと探していた本。 会社帰りに有楽町三省堂で発見。

ソフトバンクパブリッシングから出しているからてっきりコンピュータ関連のところにあると思っていたのだが見あたらず、端末で検索したら動物学・植物学関連のところにあるとでた。

創発というキーワードは「適応型ソフトウェア開発」でも何度も出てきているし、ちょっと押えておこう考えている。

それと自己組織化といえば大学時代、研究室に興味を示している友人がいたな。


[ コンピュータ書籍 ]

スポンサード リンク
[ 6月11日全て ]

2004年7月9日 (金)

創発 蟻・脳・都市・ソフトウェア自己組織化ネットワーク 読了

[ コンピュータ書籍 ]

rimage:ISBN:4-7973-2107-5

買ってから約1ヶ月。 本屋では動物学・植物学関連のところにあったのだが、やっぱり計算機科学関連の読み物。 創発に関していろいろ考えるきっかけとしてなかなか良かった。 スラッシュドットに対する考察なども興味深い。

本としては脚注が全て巻末にまとめられていて参照しづらい(結局見ていない)のと、日本語としてわかりにくい文が散見された(原文自体がわかりにくいのかもしれないが)のがマイナス。

フィードバックに関する話の途中で出てくる

スレッド型の討論掲示板は、イカレポンチと呼ばれる特殊な生き物にとって、理想的な生態環境となった。 イカレポンチは、ある特定の問題や解釈モデルに執着し、どんな議論であろうと自分の世界観を勝手に述べ立てて平気で、どうやら生業も家族生活もないので、ちょっとした挑発ですさまじいレスを返してよこす。(中略) あらゆる会話を自分の持つ特定の話題につなげないと気がすまず、自分のルールにしたがわない会話すべてに逆らう連中。(pp. 161-162)

という辛辣な表現は刺激的。ちなみにこの後、

ROMを考慮すると、スレッド型議論は実は伝統的な対面講義よりもインタラクティブ性が少なく、夕食のテーブルを囲んだ会話に比べればまるでインタラクティブではない。そこでならいちばん寡黙な参加者ですら、身振りや表情で参加する。(p.163)

と続く。


[ 読書ノート ]

[ 7月9日全て ]

2016年10月19日 (水)

チームのワーキングアグリーメントを作るの楽しい

スクラムマスターから「ワーキングアグリーメント(working agreements)を作ってみませんか?」と言われたのでチームでトライしてみました。これ、作るプロセス自体が楽しいですね。チームの一体感が高まるし、チームの自己組織化につながるなと感じました。

ワーキングアグリーメント

  • ワーキングアグリーメントはチームメンバで「合意した」ルールを書き出したもの。チームで合意したものであればどんな事を書いても OK。ミーティングの時刻だったり、ビルドのルールだったり。
  • ワーキングアグリーメントはチームメンバ全員で作る。上がってきたルール案に対して、例えば親指サイン(親指を上・横・下のどちらかに向ける)を使って全員に意思表明してもらい、全員が合意したものを採用する。
  • ワーキングアグリーメントは定期的に見るようにする。ふりかえりなどの際にアップデートしていく。

組織におけるルールは「誰かが作ってみんなが守るもの」というものが多いのですが、チームで合意して作るというのが自己組織化チームでは重要なんですね。

チームで作ったルールを書き出して明文化することでチームメンバ間の思い違いを無くすことができます。また暗黙的なルールは改善しにくいけれど、見える化すると改善の対象とすることができるというメリットもあるとのことです。なるほど。

アジャイルサムライでは「チームの約束」

ちなみにアジャイルサムライにワーキングアグリーメントなんてあったっけかなと思って調べてみたら、同書では「チームの約束 (working agreements)」として「チームが大事にすること (shared values)」とともに書かれていました。

[ スクラム ]

[ 10月19日全て ]

2017年1月31日 (火)

第13回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会13回目。今日は第13章 マネージャー

スクラムフレームワークではマネージャーという役割は取り上げられていませんが、組織を回すために必要な役割として1章割かれています。

ファンクショナルマネージャー

ファンクショナルマネージャー(あるいはリソースマネージャー。機能エリアごとのマネージャーのこと)の責務として本書では以下を上げています。

  • チームを編成する
  • チームを育てる
  • 環境を合わせてなじませる
  • 価値創造の流れを作る

マネージャーの役割は「戦略的な方向性を定めること」「戦略目標を達成するための組織的リソースを採算を考慮して揃えること」とのこと(スクラムの環境において)。

チーム編成のところで権限の7つのレベルの話が出てきます。自己組織化されたチームであるためにはメンバが権限(と信頼)が必要で、マネージャーはアクティビティや意思決定の種類ごとに適切なレベルで移譲すべきとしています。

本書ではマネージャーが分野・コミュニティ別にいる組織をメインに説明されていましたが、マネージャーが複数のチームを抱えるような組織についても説明を聞きたいなと思いました。

チーム編成のところは今の自分の立場での大きなトピックとして意識していきたいです。

プロジェクトマネージャー

後半はプロジェクトマネージャーの話。スクラムチーム数が多くて、さらに立場が異なってスクラムオブスクラムでの話し合いでもうまくいかないような場合に、他チームとの調整を効率的にする役割としてのプロジェクトマネージャーを置く場合もあるという説明がされていました。多くの組織ではいらないのかなと感じました。

[ 1月31日全て ]

2017年8月2日 (水)

今日のさえずり: 承認の場作りよりも学習の場作りの方を優先したい

2017年08月02日

  • 09:43 セミの声がしみわたるオフィス。
  • 13:12 また「自己組織化」が出てきた。
  • 15:27 承認の場作りよりも学習の場作りの方を優先したい。
  • 21:44 夜のおやつとして、井村屋のあずきぼっちゃんクローンを食べてる。
[ 8月2日全て ]

2018年3月29日 (木)

チームがグループになりつつあるのを見守っている

あるマネージャーの方針で自己組織化チーム型から共同作業グループ型に少しずつ変えていこうとしているのを見守っています。

状況がクネビンフレームワークでいうところの Complicated な(煩雑な/込み入った)領域であると考えれば適切なアプローチかもしれません。

どちらにせよやってみて検査と適応をしていけば良いだけです。

[ 3月29日全て ]

2018年12月3日 (月)

複雑な領域なのでスクラムがいいと思ったけれど自己組織化するほどメンバがコミットできなさそう

とある複雑な領域のプロジェクトについてスクラムがいいのではと思って準備したんだけれど、メンバがコミットできるエネルギーを考えると失敗する可能性が高いと思えてきた。

事業全体での WIP を下げた方がいいなと。

[ 12月3日全て ]

2019年2月14日 (木)

Developers Summit 2019 1日目 #devsumi

image:/nDiki/2019/02/14/2019-02-14-145351-nDiki-800x1200.jpg

2015年2016年2017年以来、2年ぶり4回目の Developers Summit 参加。一昨年には無かった Wi-Fi のスポンサー提供があってとても快適になった。素晴らしー。

朝1番のセッションの冒頭で今回の事前登録が4000人超という話があった。大盛況。会場の混み具合からするともうキャパオーバーも近いのではと思えてくる。各セッション会場でのバーコードチェックがステージ近くで、まだセッションが終わる前に次のセッションの人が誘導されて入ってきたりして、待機列の問題からだろうけれど、ちょっと発表者に失礼なんじゃないかなーとは思ってみてた。

以下セッションタイトルは2月13日時点の公式サイトより。

10:00~10:45 【14-D-1】 Scrum@Scale入門

株式会社アトラクタ 原田騎郎(@haradakiro)氏

メモ
  • スケール
    • 全く同じチームを複製してくことはできない。違いのあるチームを増やしていく。まずうまく行っているスクラムチームを2つ育ててから、スケールさせる(そうでないと悪いものがスケールする)。
  • Scrum @ Scale フレームワーク
    • スクラムだけでもスケールする。
    • スクラムマスター(SM)
      • デイリースクラム階層。チームで解決できない課題を上位のデイリースクラムに伝えて解決していく(チームのデイリースクラムの方を1日の先にやる)。トップレベルは役員によるエグゼクティブアクションチーム(EAT)。 EAT もスクラムチームなのでスクラムの全てのアクティビティをやる。
      • SM で寄ってたかって協力。
      • マネージャーの仕事。
    • プロダクトオーナー (PO)
      • チームに1 PO。PO チーフ PO。チーフチーフ PO。
      • PO は上位のオーナーが絶対。
    • 各チームに常に PO と SM がいる。そうするとチーム単位で動かせる。ニーズの変化でチームごと動かせる。チームを立ち上げる時間よりも、チームが新しい担当を覚える方が早い。チームを壊さない。
  • PO
    • 「調査してから…」ではなく「今間違えろ」(辛いけど……)

思ったこと

やはり適切な人数の自己組織化されたチームで構成される体制を作っていきたいな。エッセンシャル スクラムだとプロダクトバックログは唯一なものと書かれていたと思うんだけれど*1、現実的なところ抽象度の違う階層化されたバックログとチーム毎にそれぞれあるバックログという感じでいいんだな多分(エッセンシャル スクラムでも階層化バックログ自体は紹介されている)。

*1 どんなプロダクトバックログをいくつ用意すべきかを考えるにあたっては、基本原則がある。プロダクトごとに、プロダクトバックログをひとつ用意するというルールだ。-- エッセンシャル スクラム 6.7

11:05~11:50 【14-A-2】 GitHub Actionsはどのような未来を描くのか : コンテナ技術が開くワークフローOSS

GitHub 池田尚史(@ikeike443)氏

GitHub Actions で Docker イメージを作成して、デプロイまで実行できるようになるという話。デプロイ以外にも GitHub 内での様々な処理も。

12:10~12:40 【14-A-3】 GCPに恋してHashiCorpを愛して起業したエンジニアのお話

株式会社grasys 長谷川祐介氏

サンドイッチ。HashiCorp 製品Google Cloud の紹介。それから企業の話についての自分語りを伺えた。

13:05~13:50 【14-D-4】 大学におけるイマドキのエンジニア教育

ワイクル株式会社 角征典(@kdmsnr)氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏

前半永瀬氏による enPiT 事例紹介。

後半角征典氏のエンジニアリングデザインプロジェクト(EDP)を通じた知見紹介。参加者の多様性とモチベーションのばらつきを意識した取り組みが素晴らしい。

こちらでもやはり最適なチームについて(人数・多様性)が取り上げられていた。メンバの多様性によるデメリット(ここではモノづくり工程ではデザイナーができることが少ない)もきちんと示されていて、その上でそうしているという話で説得力があった。

ただ「やってみているという話」ではなく、裏打ちされた方法論を押さえた上での取り組みで学びのある話だった。

東工大生イジりが嫌味がないのも素敵。

14:10~14:55 【14-D-5】 新技術導入を成功させる組織のつくりかた ~spanner、GKE導入の実体験から得たこと~

株式会社コロプラ 廣本洋一氏

  • コロプラでのマネージメント事例。2年前に事業部制から機能別組織に。
  • コピーベースで新しいアプリケーションを作ることによる課題があった。
  • ノーメンテナンス時間というポリシーを前提とした技術選択。
  • オーバーエンジニアリングとの戦い。

機能別組織だからこそ、事業部とは別のロードマップで優先度判断ができる部分があるのだなと感じた。

15:15~16:00 【14-A-6】 レガシーとのいい感じの付き合い方 〜15年続くウェブサービスのシステム改善パターン〜

株式会社VOYAGE GROUP 福田剛広氏 小林徹也氏 駒崎大輔氏

ECナビについて2年弱かけて AWS 移行した話。

サービスの長期運用で技術が古くなり、エンジニアから見た魅力がなくなり新規採用で苦戦したり、在籍エンジニアのモチベーションがダウンしたりというのはあるある話だ。

別だったインフラとアプリの管轄を分けないようにする・オンプレから AWS に移行する・いったんそのままの構成で移すなどは、そうだよねというかそうするよねというかそうしているよねとかそういう感じ。現実的・保守的な判断かなと。

発表者の1人が年末退職済みということで、嗚呼となった。

16:20~17:05 【14-A-7】 ZOZOTOWNのDWHをRedshiftからBigQueryにお引越しした話

株式会社ZOZOテクノロジーズ 塩崎健弘氏

BigQuery 移行事例についての、味わいのある発表。

今日はシャッター音少なめだなと思っていたのだけれど、このセッションは賑やか。聴講者の層が違うのかな。

17:25~18:45 【14-A-8】 「ITエンジニアに読んでほしい!技術書・ビジネス書大賞 2019」プレゼン大会

高柳謙氏 株式会社丸善ジュンク堂書店 平木啓太氏 株式会社スマートニュース 瀬尾傑氏 株式会社アトラクタ 永瀬美穂(@miholovesq)氏

技術書・ビジネス書のそれぞれトップ3人の著者(や関係者)によるプレゼンテーション投票・発表のセッション。

[ 2月14日全て ]

About Me

Naney Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。ちょっとしたノートは nNote にあります。

※内容は個人的見解であり所属組織とは関係ありません。

follow us in feedly

月別インデックス
Process Time: 0.057692s / load averages: 0.30, 0.37, 0.59
nDiki by WATANABE Yoshimasa (Naney, Google profile)
Powered by DiKicker