2020/09/19

More Effective Agileは良い本だ

「More Effective Agile ソフトウェアリーダーになるための28の道標」を一気に読んだ。
アジャイル開発の古い情報をアップデートできて良かった。
10年以上前のXPとかにハマっていた人にはお勧めと思う。
ラフなメモ書き。

【参考】
『More Effective Agile』を読んでみた感想 - 虎の穴開発室ブログ

More Effective Agile ソフトウェアリーダーになるための28の道標 読了 - nemorineのブログ

クネビンフレームワークについて講演してきました | サーバントワークス株式会社

半日かけて「More Effective Agile」をじっくり読んだ。
線を引いた箇所はかなり多数。
読むたびにインスピレーションが働いた。

この本のキーワードは「クネビンフレームワーク」「複雑系」「スクラム」「ブラックボックスなスクラムチーム」だ。

クネビンフレームワークでは、ソフトウェア開発は複雑系のドメインなので、従来のシーケンシャル開発では問題解決できない。
なぜなら、煩雑系のドメインの問題解決手法であり、複雑系では対応できない。
クネビンフレームワークでは、煩雑系では「把握→分析→対処」、複雑系は「調査→把握→対処」で問題解決の手法が異なる。
だから、アジャイル開発が必要とされる。
クネビンフレームワークは1990年代には概念があったのに、誰もそれを言ってなかったのが興味深い。

「More Effective Agile」では一貫して、クネビンフレームワークの話が出てくる。
クネビンフレームワークの概念のおかげで、ソフトウェア開発の本質は複雑性であることを常に認識させられるメリットがある。
人月の法則本の「ソフトウェア開発の本質は複雑性だ」を思い出す。

「More Effective Agile」では、アジャイル開発とはスクラムと同義だ。
XPなど他のアジャイル開発も紹介されているが、スクラムの「検査と適応」がOODAループと相性が良いことが強調されている。
僕は、調査→把握→対処という問題解決の手法を何度も高速に回すことと同じであり、その経験によって学習して判断能力を高めていくと理解している。

アジャイル開発では雨後の筍のように数多くのプラクティスが提唱されるが、最終的には、スクラムは複雑系の問題解決にいているから推奨されている。
一方、XPは技術プラクティスが残った。
カンバンは煩雑系の作業に向いていて、複雑系の仕事はスクラムの方が向いている、と言う。

この考え方を取り入れると、ソフトウェア開発だけでなく、企画提案系のプロジェクトの仕事は全てスクラムで実施した方が良いだろうと思う。
つまり、一般のビジネスマンもチームで仕事するのが普通だから、スラクムをマスターした方がいいのではないか。

「More Effective Agile」で良く出る言葉は、「スクラムチームはブラックボックスとして扱える」ことだ。
実際、スクラムチームというアジャイルチームは、自律的なチームであり、スプリント単位にアウトプットを必ず出してくれる。
つまり、外部のプロジェクトマネージャは、スクラムチームのマイクロマネジメントは必要ない。
スクラムチームのインプットとアウトプットさえ管理すればいい。
チームをブラックボックスとして扱うことは、チームを大人として扱うことと同じであり、技術の詳細や進捗を逐一管理すべきでないことを示唆している。
よって、プロジェクトマネージャは、スクラムチームにサーバント・リーダーシップで振る舞うようになる。

「スクラムチームはブラックボックスとして扱える」ことは、コンウェイの法則を良い方向に自然に従うことになる。
つまり、オブジェクト指向プログラミングのように、スクラムチームはコンポーネントと同一視すれば、疎結合なスクラムチームを構成すれば大規模なチームを構成して、大規模なソフトウェアを効率良く作れるようになるはずだ。
スクラムチームはコンポーネントのように疎結合であるならば、メッセージパッシングがスムーズであり、無駄なコミュニケーションがないはず。
でも、スクラムチームをオブジェクト指向設計のコンポーネントと同一視できても、チームである限り状態は持つし、副作用を起こすことで、チームは変化するから、不変なコンポーネントとは違うはず。
この比喩はどこまで使えるのか?
この辺りはまだ分かってない。

「More Effective Agile」では、アジャイル開発をいかに大規模ソフトウェア開発に適用するか、というテーマを後半で詳しく説明してくれている。
意外だったのは、大規模アジャイル開発のフレームワークは、LeSSよりもSAFeの方を推奨していたことだ。
僕の身近のスクラム関係者は、LeSSを高く評価し、SAFeを低く評価していたので、どちらが正しいのか、まだ分かってない。

@sakaba37さんのアドバイスでは、プロセス志向がSAFe。
SAFeでは、アーキテクチャ管理、プロセス管理のレイヤが別にあり、基本テンプレートもある。
RUPに似ている。
一方、情報共有がLess。スクラムチームをベースに細胞のように階層化していくイメージ。
Lessの方が状況共有や暗黙知を重視するから日本人向きで、日本人好みだろうね、と。
すぐに作るために暗黙知を重視しているわけであり、暗黙知はチーム内で認識できていればいい、と。

つまり、スクラムチームがブラックボックスならば、チーム内で問題解決できる専門能力を持つだけでなく、暗黙知もチーム内で共有できているから、スクラムチームは強いわけだ。

アジャイル開発がこれだけソフトウェア開発に浸透して使えるならば、ビジネスの観点で計測したくなる。
実際、スクラムは「検査と適応」のサイクルをこなすことで、スクラムチームは経験を深めて、予測可能な振る舞いを行うようになる。
つまり、スクラムチームは計測可能な状態になる。
たとえば、ベロシティのように。
すると、コストやスケジュールが予測可能になってくるので、ビジネスで計画を立てたり、意思決定するのにその予測を使えるメリットが出てくる。

「More Effective Agile」では、最後に規制産業にアジャイル開発をいかに適用するか、というテーマがある。
たとえば、製薬業や医療業界、航空機メーカー、金融機関、政府など、法律による規制が前提にある産業だ。
では、アジャイルやスクラムは規制産業でどうやって支援するのか?
アジャイルの境界を引いて、文書作りやソフトウェア要求やソフトウェアアーキテクチャ設計はシーケンシャル、実装スプリントはアジャイルと分けることを提案している。
よく見れば、これはウォーター・スクラム・フォールじゃないの、と思ってしまうが、たぶんこれが現実的な解決法なのだろう。

最後に、スクラムの導入と社内展開は、キャズム理論に従うという指摘は参考になる。
実際、社内のイノベーターはすぐに飛びついてくれるし、アーリーアダプターは色んな意見を出してくれる。
その後のアーリーマジョリティへの展開が一番大変なのだ。

「More Effective Agile」はまだまだ読み直してみたい。

| | コメント (0)

2020/09/18

RedmineJapan2020が無事に終わりました #RedmineJapan

本日、RedmineJapan2020が無事に終わりました。
講演者と参加者の皆さん、スタッフの皆さん、ありがとうございました。
今日は本当に疲れたので、まずはメモしておく。

【参考】
タイムテーブル | Redmine Japan

REDMINE JAPAN 2020 オンライン開催 - connpass

今日は朝9時から19時半まで、自宅の机とPCに張り付いて、気づいたら外は真っ暗。
基調講演から最後まで、どの講演も素晴らしくて、興味を引いて、気が抜けなかった。

Matzさんの話は、Rubyのリモート開発と、開発をリードする立場の事情話。
自分の意見と自分が書いたソースコードは違う。
エゴレス。

みうら(あに)さんはTwitterを使っています 「(自分思い出し用)1) OSS→コミュニティベース開発→PdM:「よい」とは?⇒同じ方向見れるか?⇒求心力/哲学 2) ツールの支援:円滑な意思決定⇒分散SCMのよさ⇒Issueベース⇒フロー/ストック⇒Wikiの使い方 3) コンフリクト解決:コードより知見大事、エゴレス、ゆるやかにつながる #RedmineJapan」 / Twitter

東芝やNTTコムウェアの開発プロセス標準とRedmineをベースとした開発基盤の紹介。
大企業の内部事情が分かった感じ。

@akiko_pusuさんのLTは、朗読のようなナレーションで聞き入ってしまって、聴衆の皆さんも思わず泣きたくなったのではないか。

平鍋さんの話は、リモート時代でのアジャイル開発のコミュニケーションの取り方。

akipiiさんはTwitterを使っています 「#RedmineJapan 平鍋さんが最初に作ったastahも、平鍋さんが書いたソースコードはもうない。インターフェイスだけ残っている。そういう意味では、設計思想が優れていた、ということなんでしょうね。」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan 平鍋さんは工学部出身だから、場と言えば、電磁気学や量子力学を連想されたのかな?」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan 古典力学はコマンドコントロール。場の理論は、チームの空間から力が生まれる。なるほど。」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan ティール組織は場がない。スクラムは場がある」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan リモートワークの場作り。リモートワークの基本の最初は、速いインターネット回線」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan デジタルでは表現者が優位。過剰な表現で十分」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan ネットワークの7層モデルと、コミュニケーションモデルの比較。物理層は、信頼関係に対応するのでは、という仮説」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan タックマンモデルも、最初の混乱期までは合宿して、それからリモートに移行する。でも、コロナ時代はどうする?」 / Twitter

akipiiさんはTwitterを使っています 「#RedmineJapan これからのチームビルディングは、合宿無しの継続的なチームビルディングへ。」 / Twitter

(1) kabukawaさんはTwitterを使っています 「#RedmineJapanA いまここ性 here-now-ness」 / Twitter

リモートワークの時代では、チームビルディングの手法はオフラインとは変わってくる。
五感のうち、見る・聞くしかチャネルがない。
だから、自己表現を派手にするぐらいでないと伝わらない。

すると、チームビルディングでは、タックマンモデルの形成期・混乱期がリモートワークでは難しくなる。
いかにそういう場をオンライン上で実現するか?

パターン言語を用いて、アジャイル開発の秘密基地のパターンを作っていた。
同様に、リモートワークのアジャイル開発のパターンが作れないか?
そのパターン言語を作ることで、リモート時代の特徴や本質が見えてこないか?

同時並行で見れなかったB会場では、RedmineのDBアーキテクチャの説明、RedmineのDockerのお話、ファーエンドさんのAWSでRedmineサービスを作った裏話、なども聞きたかった。
動画を準備しているので、ゆっくり見てみたい。

Redmineというテーマで、オンライン参加者が300人もいるイベントを実現できて本当に良かった。
Redmineは、開発プロセスの構築とそれを支えるPJ管理ツールの話と、実際にPJ管理ツールの開発基盤を構築するためのインフラ環境やRedmine本体の改善の話を同時に議論できて面白い。
そういう話をコミュニティで10年も継続できたことがすごいな、と思う。

| | コメント (0)

2020/09/13

RedmineJapan2020の見所 #RedmineJapan

9/18金に予定するRedmineJapan2020の見所について、スタッフの一人としてメモ。

【参考】
タイムテーブル | Redmine Japan

REDMINE JAPAN 2020 オンライン開催 - connpass

RedmineJapan2020の見所は3つある。

一つ目は、Redmineに関する日本最大のイベントになったこと。
発端は、@agilekawabataさんの発起により、Redmineに関するイベントを開催しよう、という話。
そこから、いつの間にか、参加者500名を超える大規模なイベントになった。
大阪や東京のRedmineコミュニティでも、50~100人前後がせいぜいなので、参加者だけでも、オンラインとはいえ、経験したことのない規模になった。
それだけ、Redmineに興味のある日本人が実は一定の層だけいることを示しているのだろう。

2つ目は、多種多様なスピーカーによる講演が目玉であること。
Redmineをテーマにするので、講演の数が集まるか、スタッフとしては不安だった。
しかし、蓋を開けてみれば、あっという間に応募枠は埋まったので、とても嬉しい。
理由を推測すると、大阪と東京のRedmineコミュニティが10年以上も継続的に存続してきたので、熱心なユーザが常に存在していたのだろうと思う。
また、ソフトウェア開発のプロジェクト管理だけでなく、製造業の業務部門や情報システム部門で、当初想定されていなかった使い方をする事例も増えてきたこともあるだろう。

RubyのパパであるMatzさんや、日本のアジャイル開発の第1人者である平鍋さんの基調講演が聞けるのも楽しみ。
そして、そういう日本のIT業界を代表する人たちと、僕も講演者としてタイムテーブルにプロフィール公開されているのも、ちょっぴり嬉しい。

講演内容は、A会場はPJ管理系・事例系、B会場は技術系・ツール系に分けた2トラックになる。
タイムテーブルを見ての通り、正直どちらの講演も聞きたいぐらいだ。
そんな声も踏まえて、後日、参加者には聞けなかった講演を動画で視聴できるようにしたい準備も進めている。

3つ目は、今後のRedmineの発展に貢献したいこと。
コロナ感染騒動でオフラインの開催自体も怪しくなったが、オンライン開催できる運びとなった。

実は、コロナ感染騒動がなければ、フランスのJPLさんもお呼びする予定だった。
しかし、コロナ感染騒動のため沙汰止みとなった。
周知の通り、Redmine本家の開発体制はJPLさん、@g_maedaさん、@matsuorijpさんの3人だけだ。
競合となるJiraやBacklogに比べれば、非常にリソースが薄い開発体制である弱みはある。
だからこそ、ユーザによるこういうイベントやコミュニティの盛り上がりで、オープンソースであるRedmineが今後も永続的になっていけるように支援できれば、とスタッフの1人として思っている。

まだ、当日まで参加可能なので、是非応募してみてください。

最後に、注意点を1つだけ。
RedmineJapan2020のオンライン配信は、Remoというツールを使う。
ほとんどの人が使ったことがないはずなので、下記のガイドは必ず読み込んでおいて下さい。
RemoはZoomとは全く違って、仮想的なイベント会場を用意している。

日本コミュニティでの活用 - Remo.co Virtual Events and Office space

Remo参加者用ガイド

当日までに、Remoにアカウントを作って事前にログインして動作確認することをお勧めします。
ちなみにRemoの環境は、PCのChrome、Firefoxが推奨です。
iPhoneなどのスマホでは、ブラウザ表示がベータ版になっています。


当日はスタッフは公演準備に忙しいのでフォローできない可能性が高い為です。

では、皆さんのお越しをお待ちしてます。

| | コメント (0)

2020/09/02

問題解決アプローチを見極める『クネビンフレームワーク』のメモ

問題解決アプローチを見極める『クネビンフレームワーク』を知ったのでメモ。
結論のないメモ。

【参考1】
akipiiさんはTwitterを使っています 「クネビンフレームワークの説明が参考になった。問題のドメインが時代で変化しているからソフトウェア開発プロセスも変化する。非開発者のためのアジャイル開発入門 by @haradakiro #agile #complex https://t.co/2iCYVDeddY」 / Twitter

More Effective Agile ? “ソフトウェアリーダー”になるための28の道標|かず|note

複雑な世界を捉えるためのカネヴィンフレームワーク(Cynefin Framework) ? ゲームを用いた企業研修なら| 株式会社HEART QUAKE

(引用開始)
カネヴィンフレームワークは1999年にIBM Global Servicesのデイブ・スノーデン(Dave Snowden)らが提唱したもので、状況・問題を大きく4つのドメインに分類するフレームワークです。(上画像)

1.Simple(シンプル):単純
⇒問題の因果関係・構造が明確

2.Complicated(コンプリケーティッド):煩雑
⇒少し分析すれば、因果関係・構造が明確

3.Complex(コンプレックス);複雑
⇒因果関係が複雑、調査・探索が必要

4.Chaotic(カオス):混乱
⇒因果関係が不明確で、状況や問題を理解することも難しい

その他.Disorder(ディスオーダー):無秩序
⇒直面する問題に適切な解決策がない

さらに、1のSimpleと、2のComplicatedを予測可能な問題、3のComplexと、Chaoticを予測不可能な問題と分類することもできます。
(引用終了)

製造業における製品製造の大量生産方式のビジネスと、エンジニアやコンサルタントなどの知的労働者がプロジェクトで仕事するビジネスは、本質的に何かが違うといつも思っていた。
その理由の一つは、問題解決アプローチが全く違う、という指摘を、クネビンフレームワークは教えてくれる。

クネビンについて講演してきました | サーバントワークス株式会社

(引用開始)
(クネビンフレームワークが必要とされる)背景としては、「正解がない」多様化した問題と現実解に対しての理解を深めることが第一義です。第二儀としては、アジャイルの必然性の腹落ち感があります。
(引用終了)

アジャイル開発が昨今必要とされる背景には、従来の問題解決の手法が通用しなくなってきていて、新しいフレームワークや考え方による問題解決手法が必要とされているのだろう。
「More Effective Agile ~“ソフトウェアリーダー"になるための28の道標」では、アジャイル開発による問題解決の観点はクネビンフレームワークの「複雑(Complex)」に当たるのではないか、という内容があるらしいので、今度読んでみたい。

【参考2】
複雑な世界を捉えるためのカネヴィンフレームワーク(Cynefin Framework) ? ゲームを用いた企業研修なら| 株式会社HEART QUAKE

クネビンフレームワーク Cynefin Framework :臨機応変の意思決定手法 ? I & COMPANY / アイ&カンパニー

カネビン・フレームワークで問題解決策を見極める

クネビンフレームワークを使ったテクニカルサポートチームの行動指針の立案 | Developers.IO

問題の解決アプローチを見極める『クネビンフレームワーク』をざっくりまとめる - コード日進月歩

(引用開始)
これをエンジニアのロールに置き換える広木さんのツイートはすごいなと思ったので参考まで
(引用終了)

広木 大地/ エンジニアリング組織論への招待さんはTwitterを使っています 「CTO/VPoE/TechLead(スペシャリスト)の仕事って一体どう言う役割分担なの?みたいなことを聞かれる。 これはクネビンフレームワークで捉えるとわかりやすい CTO は Chaoticな問題 -> Complex VPoE/EMは Complexな問題 -> Complicated TechLeadは Complicatedな問題 -> Simple 不確実性が減っていく https://t.co/un1FX3QQ53」 / Twitter

akipiiさんはTwitterを使っています 「クネビンフレームワークでカオスで複雑・複合的な問題を分類する。CTO/VPoE/TechLeadというエンジニアのロールはクネビンフレームワークで整理すると分かりやすいという指摘。 問題の解決アプローチを見極める『クネビンフレームワーク』をざっくりまとめる - コード日進月歩 https://t.co/exz3rCJnfw」 / Twitter


| | コメント (0)

2020/09/01

OODAループはScrumにどんな考え方を注入し、影響させたのか

スクラム 仕事が4倍速くなる“世界標準”のチーム戦術」では、OODAループが紹介されていた。
ラフなメモ書き。
考えがまとまっていない。

【参考】
アジャイルの源泉、OODAループとは何か? - Qiita

米空軍パイロット撃墜王の研究 「OODA ループ」 は、ビジネスにも示唆があり興味深い|多田 翼 - #ビジネスセンスを磨くノート|note

OODAループの歴史:世界の軍事戦略を全面転換 ? I & COMPANY / アイ&カンパニー

OODA について講演してきました | サーバントワークス株式会社

【1】OODAループの本質は何だろうか?
OODAループはScrumにどんな考え方を注入し、影響させたのか?

OODAループは、従来のPDCAサイクルと何が本質的に異なるのか?

【2】「スクラム 仕事が4倍速くなる“世界標準”のチーム戦術」では、Scrumを生んだサザーランドがベトナム戦争のパイロット経歴を持ち、こういう軍事経験を元にScrumを編み出した、という歴史の方が興味深かった。
生死の境にいる現場で、生き抜くために、どんな考え方や意思決定が必要なのか?
いくら軍事戦略や戦術が優れていても、戦場は刻一刻と変化して、今までの経験を多用できない。

米空軍パイロット撃墜王の研究 「OODA ループ」 は、ビジネスにも示唆があり興味深い|多田 翼 - #ビジネスセンスを磨くノート|note

(引用開始)
空軍の空中戦では、いかなる状況でも必ず敵機を撃ち落とす「撃墜王」と呼ばれるようなパイロットが現れます。
アメリカ空軍の研究目的は、空中戦での撃墜王は他の一般的なパイロット比べて何が違うのかを知ることでした。
研究結果から、パイロットが敵機を見つけてから攻撃、または回避行動をするプロセスで、優秀なパイロットとそうではないパイロットを比較すると、3つのことがわかりました。

研究結果
・敵機の観察段階 (Observe) で統計的に有意な差はない
・状況判断 (Orient) と意思決定 (Decide) の速さに有意な差がある
・行動 (Action) では有意差はない
つまり、状況判断と意思決定で、パイロットの優秀さが決まるという研究結果です。
(引用終了)

敵の意思決定より早い意思決定を行い、そこから行動することで、相手の意思決定を鈍らせる。
つまり、動く的に対し、優れた観察眼で、状況判断と意思決定を素早く行い、行動に移す。

OODA について講演してきました | サーバントワークス株式会社

(引用開始)
プロダクト開発では、正解がわかっていない状況下で推進することが多く、アジャイルに代表される実証により、経験的に推進していくことが多くなってきています。
そこでは、反復的かつ漸進的なアプローチとなるのでOODAループがそれに似ているとも言えます。
スティーブ・マコネルは著書の中で、スクラムの「検査と適応」はOODAループととても関連があると述べています。
(引用終了)

【3】PDCAサイクルとScrumの違いは、計画駆動なのか、観察駆動なのか、という違いもあるだろう。
PDCAサイクルでは、計画にすごく時間をかけて、計画と実績の予実管理によって、リスクを測定し、判断を下す。

一方、スクラムは「経験主義」と言われる。
つまり、スクラムは実践で得られた経験を元に、あるべき方向を見極めて、意思決定を下し、そのフィードバックを経ながら軌道修正していく。
スクラムでは、最初からベストプラクティスがあるわけではない。
観察して経験していきながら、より良い対処を探していく。

スクラムガイドをきちんと読もう - Qiita

(引用開始)
スクラムは、経験的プロセス制御の理論(経験主義)を基本にしている。経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。
スクラムでは、反復的かつ漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う。
経験的プロセス制御の実現は、透明性・検査・適応の 3 本柱に支えられている。

透明性
経験的プロセスで重要なのは、結果責任を持つ者に対して見える化されていることである。透明性とは、こうしたことが標準化され、見ている人が共通理解を持つことである。
(中略)
検査
スクラムのユーザーは、スクラムの作成物やスプリントゴールの進捗を頻繁に検査し、好ましくない変化を検知する。ただし、頻繁にやりすぎて作業の妨げになってはいけない。スキルの高い検査担当者が念入りに行えば、検査は最大の効果をもたらす。

適応
プロセスの不備が許容値を超え、成果となるプロダクトを受け入れられないと検査担当者が判断した場合は、プロセスやその構成要素を調整する必要がある。調整はできるだけ早く行い、これ以上の逸脱を防がなければいけない。
(引用終了)

| | コメント (0)

«Redmine4.2に2要素認証機能が導入された