組織はツリーではない - Jim Coplien さんのスケールフリーネットワーク論 - kawaguti’s diary
RSGT2020の基調講演をやっていただく Jim Coplien さんによる、大規模組織のお話がありました。 この話を聞くのは実は三回目(飲み屋、ウィーンでのScrum Gathering、今回)ですし、ありがたいことに、色んな人に日本語で説明することもあるので、周りの人とも話しながら自分なりの認識がまとまってきました。 いや、お前のまとめなんていらないんだよ、とは思いますが、全体をちゃんと書くのは難しいので(ビデオとっとくべきでした)、ざざっと書いておきます。 人々は組織をツリー構造*1で考えがちで、実際に公式な組織アサインはそのように運営されがちだが、末端のノード間やたすき掛けのようなつながりは自然に起きていて、それによって情報流通の効率性が維持されている。これは、兼務をつけて複数部署にマネージャーを頭出しさせるのとも違うし、マトリックス型組織でプロジェクト運営するのともちょっと違う
業務知識を持たないリーダーで大丈夫か？ - kawaguti’s diary
2017年1月に米Microsoftに遊びにいって感じたことを、そのあといろんな人に伝えてきたのですけど、ブログには書いていなかった気がしますので、年頭にあたり書いておきます。 機動警察パトレイバー アーリーデイズ | Netflix (ネットフリックス) ツアーの際に現地で講演してくれた方の1人が河野さんで、ありがたいことに翌年のRSGTで基調講演していただきました。(もう1人Chap AlexはDevIpsDaysでお呼びできました。) 米Microsoftで働く日本人エンジニアが語る、“楽しく開発”するために必要なこと - Part1 - ログミーTech ここで痛感したのは、ビジネスに必要な業務知識を経営層・マネジメント層が持っていないと、もう儲からないんじゃないか？ということです。ソフトウェアに関する業務知識というと、コンピュータサイエンスだったり、もうちょっと基本的なレベルで、
経営者がITを学ぶインパクトは、プログラマが経営を学ぶより大きいかもしれない - kawaguti’s diary
前回のエントリもずいぶん多くの方に読んでいただいたようで、大変驚いております。 kawaguti.hateblo.jp さらに、いただいたフィードバックから、もう一点補足した方がよいかなと思いまして、このエントリを書き始めました。補足の補足ですみません。 リーダーがITを学ぶのが早いか、IT技術者が経営を学ぶのが早いか 前回、IT技術者ではないキャリアを歩んでいる方々がプログラミングを学んだ事例としてジャパンタクシーの川鍋社長のエピソードと、若手向けプログラミング研修の例を出しました。 ビジネスマンがプログラミングを学ぶ価値 アジャイルジャパン2018で、ジャパンタクシーの川鍋社長が話していたことが印象に残っています。川鍋さんは正月休みを利用して、１週間詰め込み型のプログラミングスクールに行き、Railsを使ったプログラミングを学んだそうです。そこで発見したのは、「一文字間違えただけでも動
業務知識とIT知識を分けて考える時代は終わったんじゃないか - kawaguti’s diary
昨日のエントリは思いがけずアクセスをいただきまして、はてブのホッテントリにものったようで、驚いております。ありがとうございます。ここのところお腹の中にぐるぐるしている思いを新年にかこつけて吐き出した記事で、切れない「なまくら刀」のような後味で申し訳なく思っております。 kawaguti.hateblo.jp この記事の中で、業務知識という言葉の定義を曖昧なままに使ってしまって、ブクマコメントで「業務知識とはだな...」というご教示をいくつかいただきました。ご指摘ありがとうございます。 SIerで業務知識といえばお客さんの業務に関する知識 システムインテグレーター(SIer)方面の方は「(自分たちはIT知識を持っている前提で)、ユーザー企業の人が持っているべき知識のことを業務知識と呼ぶ」という認識なのだろうと認識します。そういえば、10年以上前になってしまいますが、業務知識はSIerに必要か
非アジャイルマニフェスト - kawaguti’s diary
「アジャイルやってないんですよね」「うちアジャイルじゃなくって」っていう話をたまに聞くんですけど、「アジャイルじゃない」って、どういうことかなぁ、と思ったりします。 アジャイルはアジャイルマニフェストで定義された言葉なので、その内容をみて、そうなっていない、というのが「アジャイルやってない」ということなのかな？ agilemanifesto.org 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 これをひっく
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
