« 2020年8月 | トップページ | 2020年10月 »

2020年9月

2020/09/28

課題は問題点をひっくり返す表現だけで良い場合もある

問題と課題の違いをメモ。

【参考】
リスクと問題と課題を再考: プログラマの思索

問題と課題の違い【改善活動の基礎講座-カイゼンの基本編:第3章】|カイゼンベース

「問題」と「課題」の違いとは?書き方や解決への対策も紹介 | TRANS.Biz

僕は、課題は問題解決のアクションと捉えていた。
問題は、現状とあるべき姿のギャップから発生した症状のこと。
問題はネガティブな表現、課題はポジティブな表現で書くべき、と考えていた。

しかし、課題は問題点を抽象化したもので書くべき、と言われた時があって混乱した。
その観点では、問題点と課題は同じ現象を少しだけ言い換えているに過ぎないので、問題と課題は同じ意味になってしまう。

そういう意図で聞かれた内容を色々考えあぐねた結果、課題は「問題点を改善すること」と言い換えれば良いと考えた。
つまり、課題は問題解決の具体的なアクションまで書く必要はなく、課題は悪い症状である○○を改善すること、とひっくり返した表現でいいみたいだった。

課題を具体的なアクションで書いてしまうと、レベル感が違うように受け取られるようだ。
あくまでも、抽象的なレベルで、課題は問題点をひっくり返す表現で十分であり、その後で具体的なアクションを書けばいい。


| | コメント (0)

2020/09/27

リーン製品開発はアジャイル開発に何となく似ている

「開発戦略は「意思決定」を遅らせろ! ─トヨタが発想し、HPで導入、ハーレーダビッドソンを伸ばした画期的メソッド「リーン製品開発」」を読んだ。
製造業の製品開発がメインなのだが、アジャイル開発に似ているなあ、でも違いは何だろう、と思いながら読んでみた。
ラフなメモ。

リーン製品開発の4つの礎石。
セットベース開発、チーフエンジニア制度、流れとリズムの確立、責任ある専門家チーム。

LAMDAサイクルとは、look, ask, model, discuss, act。
PDCAのうち、PとCはLAMDAサイクルで回す。
つまり、PDCAサイクルのうち、PlanとCheckに力点を置く。

セットベース開発は、多数の代替案を平行で評価しながら、徐々に絞り込んでいく。
代替案の収束の時系列図は、不確実性の時系列図に似ている。
たぶん、製品開発でも当初はどの案が自分たちが求めるものなのか分からない状態で、そこから複数の代替案を実験し、試行錯誤を繰り返していくうちに、あるべき姿が明確になってくるイメージなのだろう。
つまり、製品開発も当初はリスクが非常に高いが、経験値が増えるに従って、リスクを受容できるようになり、不確実性はコントロールできる範囲に落ち着く。

チーフエンジニア制度とは、トヨタを真似たもの。
スクラムのプロダクトオーナーに似ているし、スクラムマスターの役割も兼ねているように思える。

チーフエンジニアは、顧客を代表し顧客価値を最大化させることに注力する。
チーフエンジニアは、部品メーカーから工場、生産システムまでの生産バリューストリームを設計する。
チーフエンジニアは、機能別部門の開発者の対立を調停し、トレードオフを主導する。
チーフエンジニアは、インテグレーション・イベントで代替案を披露し、それに向かって開発のプロジェクト管理を行う。
チーフエンジニアは、ビジョンを提供し、開発資源を確保する。
チーフエンジニアは、製品ビジョンを実現するための技術の方向性を示す、技術的リーダーシップを発揮する。

インテグレーション・イベントとは、学習サイクルを管理するために一定期間で行う。
多数の視点から代替案を検討し絞り込む。
各チームが獲得した知識を共有し、将来のために記録する。
開発の計画と実績を対比し、開発ペースを管理し、開発にリズムと流れを導入する。
インテグレーション・イベントは、スクラムのスプリントに似ている。
ただし、インテグレーション・イベントでは、開発段階で得られた知識のレビューに力点が置かれる。

セットベース開発では、開発当初に詳細な仕様を厳密に決めるのではなく、複数の代替案を元に、開発しながら技術的知識が増えるにつれて、徐々に仕様をより細かく、具体的にする。

一方、ポイントベース開発のように、実際に製品の試作品を作り、それから試験して通過すればよいが、試験が通らなければ、出直し設計となり、量産開発に至るまでに膨大な開発コストがかかる。

開発上の技術的知識の多くは、トレードオフ曲線で表現される。
たとえば、ある部品の強度を強くしたら、大きくならざるを得ないとか。
つまり、2つの製品特性に対し、正や負の相関関係がある事実を実験で新たに見出す。

重要なのは、低コストで知識を獲得する工夫を行うことだ。
通常、必要な知識とは、設計パラメータ間の相関関係である事が多い。

製品開発の最大の無駄は、せっかく獲得した知識を捨てること。
蓄積した知識を次の製品開発に利用せず、同じ知識を得るために貴重な開発資源を浪費すること。

セットベース開発では、代替案が棄却されても、そこで得られた知識はチームに残り、A3文書に記録されて、後で再利用される。

あらゆる開発上の知識はA3報告書に1枚に記録する。
ナレッジはA3報告書で蓄積される。

この話で面白いと思ったのは、メーカーの製品開発でも、インテグレーション・イベント(スプリント)単位に設計し、そこで得られた知識はトレードオフ曲線で表現されているので、それらをA3報告書に記録してナレッジを共有する一連の流れがあることだ。
スクラムでも経験主義が強調されるが、リーン製品開発では、製品特性のトレードオフ曲線というナレッジがA3報告書1枚に記録され、失敗した経験から得られた知識も蓄積されていく。
それら技術的知識はチームメンバーに共有されて、インテグレーション・イベントを経るごとに、新製品のあるべき仕様が分かってきて、最終的に固まる。
そうすれば、試験も通過しやすいし、量産体制に入っても、蓄積された技術的知識を活用すれば生産プロセスを改善しやすい。

リーン製品開発を取り入れたハーレーダビッドソンは、リーン製品開発ではなく、知識ベース開発と呼んでいるらしいが、そちらの方が理解しやすい気がする。

リーン製品開発の効果は、競争力のある新製品を従来よりも短いリードタイムで開発できるだけではない。
実は、技術者の士気が大きく向上したらしい。

リーン製品開発に取り組んだ技術者の話が「開発戦略は「意思決定」を遅らせろ! ─トヨタが発想し、HPで導入、ハーレーダビッドソンを伸ばした画期的メソッド「リーン製品開発」」にあるが、その理由はこうだ。
従来の開発手法では、トップダウン式で製品企画が決まり、技術的に意味のないペーパーワークや会議に時間が取られていた。
一方、リーン製品開発では、試行錯誤しながら、問題を発見し、解決方法に関する仮設を立てて、それを実験により検証する、という技術者本来の仕事を中心に進められる。
実際、複数の代替案を作り、大まかな仕様を元に、問題を発見して解決して得られた技術的知識はトレードオフ曲線として表現され、それらはA3報告書に残る。
つまり、仮説検証による技術的問題解決を行っているわけであり、技術者本来の仕事なわけだから、モラールが向上するのは当たり前だ。

そして、できればそこで得られた技術的知識は、学術論文で投稿できたり、特許として認定できれば、技術者のモチベーションももっと上がるだろう。

クネビンフレームワークの複雑系の問題領域では、そもそも問題が何なのか分からない。
専門家が何度も調査して検証して、初めて因果関係が分かる。
その知識は経験として得られるものであり、トップダウンで分かるわけではない。
リーン製品開発も、クネビンフレームワークの複雑系ドメインの問題解決の手法の一つと捉えることはできる。

「開発戦略は「意思決定」を遅らせろ! ─トヨタが発想し、HPで導入、ハーレーダビッドソンを伸ばした画期的メソッド「リーン製品開発」」のあとがきの一節がとても気になった。
筆者は、TOCという生産改善手法を日本に初めて紹介したり、EMSを紹介したり(たとえば、台湾のフォックスコンなど)、トヨタ生産システムも翻訳したらしい。

いずれも、日本でそのアイデアが生まれて、アメリカ人が徹底的にその手法を分析評価して、フレームワークとして体系立てて、日本に逆輸入されている。
アジャイル開発も結局同じだ。

なぜ、日本人は、自らのアイデアを抽象化したフレームワークにまとめて、誰もが普遍的に扱えるような形にしなかったのだろうか?
なぜ、日本人は、自らのアイデアをアメリカ人にキレイな体系として理論化されたものを、ありがたがって受け入れざるを得なかったのだろうか?

| | コメント (0)

2020/09/24

スクラムは境界を生み出す

@sakaba37さんから言われてハッと気づいたこと。
スクラムはあえて境界を作り出している、と。

「More Effective Agile」で良く出る言葉は、「スクラムチームはブラックボックスとして扱える」ことだ。
チームをブラックボックスとして扱える利点は、2つある。
1つは、外部のプロジェクトマネージャはチームのマイクロマネジメントが不要で、インプットとアウトプットの評価だけでチームをコントロールできる点だ。
これはスクラムチームだからこそ実現できる。

もう一つは、疎結合なスクラムチームを組合せることで、大規模なソフトウェア開発にもスクラムを適用しやすくなる点だ。
スクラムチームは、コンウェイの法則「アーキテクチャは組織構造に従う」の呪縛から逃れられる。

実際、スクラムチームはチーム単体でアウトプットの増分を定期的にデリバリーできる能力を持ち、他のチームに依存する必要性はない。
よって、スクラムチームを一つのコンポーネントに対応付けることで、大規模なソフトウェアを組み立てることが出きる。
昨今、クラウド上の開発が主流になることで、マイクロサービスのアーキテクチャが流行しているが、その理由も、スクラムチームがマイクロサービスと相性がいいためだろう。

よくある駄目な例は、大規模なソフトウェアを開発するチーム構成を、データベースチーム、インフラチーム、アプリチーム、フロントチームのような機能別組織で分割してしまうことだ。
すると、1つの機能を作るために、数多くのチームに依存せざるを得ず、その分、複雑な組織構造を盛り込んだソフトウェアを作り込んでしまう。

これはオブジェクト指向設計と同じ発想で、疎結合なコンポーネントを組合せることで、各コンポーネントは互いにメッセージパッシングし合い、変な副作用を起こさずに大規模なソフトウェアを組み立てることができる。
同様に、疎結合なスクラムチームは、互いにコミュニケーションを取り合うが、変な副作用を起こさずに、大規模なソフトウェアを開発できる基盤をもたらす。

つまり、スクラムチームは専門性を発揮できるチームであり、チーム単体で諸問題を解決できる能力も持つので、そういうチーム設計が可能になるわけだ。
たぶん、Lessはそういう発想で組み立てられているのでは、と想像している。
だから、Lessは暗黙知を重んじる日本人好みなのだろう、と。


| | コメント (0)

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)

« 2020年8月 | トップページ | 2020年10月 »