パソコンの奴隷・アナログ回帰・適材適所

働き方改革や最近のコロナ騒動で在宅勤務・リモートワークが流行っています。

私自身は、在宅勤務・リモートワークは好きにすれば良いと思うのですが、
在宅勤務・リモートワークをしても生産性が下がらなく、オフィスの存在が不要だという意見もちらほら聞くようになりました。

この場合、『もともとオフィスでの仕事が、オフィスというものを効果的・効率的に活用できていないのではないか』という問いにつながると思います。
オフィスでの仕事のやり方を変えれば、これまでの数倍効果的・効率的にできると思います。

現在、ほとんどのホワイトカラーと呼ばれる人たちは、パソコンを使っています。WindowsかMacかUbuntuとかですね。

オフィスに行っても、ほとんどパソコン使ってるんじゃないですか。

打ち合わせ中もパソコンをずっと見てますよね。ノートパソコン・ラップトップの蓋を閉じることって移動中くらいでしょうか。

大切な書類も、パソコンやオンプレサーバ、クラウドにあるんじゃないですか。

仕事にパソコンを使うほど、生産性は下がります。

おそらくほとんど意味のない作業です。

特にソフトウェア開発をやっている方は、

・コードを書いて、ビルドする
・アプリをテストする

以外にパソコンを使わなくて良いと思います。

と言うBlogをパソコンを使っている自己矛盾ではあります（笑


何が言いたいかと言うと、

パソコンはあくまで、ツールなので、適材適所で使うべきということです。

もう本当に常識になってしまって、パソコンに記録しておくことが当たり前になりすぎています。

でもそれが生産性を下げます。

打ち合わせ中の議事録をその場でパソコンに書く。みんなパソコンを見てる。
共感できる議論ができるわけがない。


パソコンが得意なこと、パソコンにしか出来ないことって何でしょう。

・ソースコードをビルドする・デバックする
・アプリを動かす
・長期的に記憶しておきたいことを保存する
・スプレッドシートで計算を正確に素早く計算する
・インターネットを使って人に文章や絵を多くの人に読んでもらう・見てもらう。
・文章を書く


ぐらいかなー、私はこれぐらいしか思い浮かばないですね。

スプレッドシートに文章をすごい書いちゃったり、設計書書いたりしているところもありますよね。これも適材適所で、見極めが必要だと思います。
ほとんど制限がないぐらい、書けてしまいます。

これをA3の紙1枚しか使っちゃいけない、となったらものすごい頭をひねると思います。
そこから本当に大切なものが見えてくる。
制限がないと創造性が発揮しづらいのです。


今こそ、アナログに回帰しましょう。というのは言いすぎですが、適材適所の見極めですね。
とにかくパソコン、という思考停止をやめたほうがいいと思います。

あ、でも、紙を使うと、環境問題はあるなぁー。

Project ManagerとAgile Coach/Scrum Masterの考え方の違い

プロジェクトマネージャーの考え方	Agile Coach/Scrum Masterの考え方。
成果物は、プロジェクトのQCDの達成である。	成果物は、『学習する組織』であり、『自己組織化されたチーム』であり、そのような文化を持つ会社であり、人々である。
計画し、計画の通りに仕事をする。	”計画すること”は重要だが、計画自体は役に立たない。
人・モノ・カネはリソースである。	人はリソースではない。人は学び、成長する。 学び、成長するものはリソースと呼ばない。パソコンなどの成長しないものはリソースと呼んでも構わない。
要求（スコープ）・期限・コスト（予算）の３つの制約は互いにトレードオフの関係にあり、コントロールできる。	時間と予算（チームの人々）は一定を保つ。 要求（スコープ）のみが変動である。 自分自身以外の他者はコントロールできない。ましてやマーケットは。 如何に変化に迅速に対応できるかが鍵であり、変化に迅速に対応するために、意思決定は、一番現場に近い人（チームメンバー）が行うことが最も正確で最も速い。
計画は、アクティビティの段階（要件、設計、開発、テストなど）を通してプロジェクトを完成させるにつれ、時間の経過とともにより正確になる。	計画は常に変更され、チームの実際のパフォーマンスに合わせて調整される続けるため、計画は時間の経過とともに正確になる。
時間通り、予算以内、要求通りであることが成功。（QCDの達成が成功）	顧客が必要とするビジネスバリューを顧客が得ること、チームがどれだけ成長でき、楽しんで仕事ができたかが成功の目安です。 顧客とともにチームは成長しますし、顧客もまた、ともに成長します。ともに成長することを楽しみます。
要求（スコープ）の変更は受け付けません。プロジェクトの後半にそれが必要な場合は、変更要求として扱います。変更管理プロセスを厳密にまわし、 変更箇所を周知徹底します。	要求（スコープ）は柔軟なままです。どんな種類の変更も、プロジェクトの後期であっても、受け入れます。ウェルカムです。 そこには透明性が存在します。顧客・ステークホルダーは、チームのキャパシティがどれくらいで、この変更を受け入れたら何ができなくなるのかが、チームの部屋に行き、メンバーと話をすると瞬時に把握できます。
プロジェクト全体をコントロールすることが私の仕事です。	プロジェクト全体をコントロールすることは可能ではありません。そもそも自分自身以外はコントロールできません。コントロールという言葉自体使いません。だから、私はチームがより組織やチームがアジャイルになれるようにコーチします。絶対の結果など保証できません。
タスクの進捗が価値の提供を示します。（ガントチャートのパーセンテージ）	動くソフトウェアのみが進捗と価値を提供します。

SAFeとLeSS

まず前提として、SAFeとLeSSは比較するようなものではありません。
SAFeの本質は、予算管理にあります。Lean Portfolio Managementを導入していないにも関わらずSAFeとは言えません。
Lean Portfolio Managementは、10週間（四半期）に一度、限られたバジェットの中での予算配分を動的に柔軟に変更する、ということです。これによりプロダクト毎の優先度を変化させていきます。
そのためにKanbanを使って、各Productの状態を把握したり、Program Backlogと呼ばれるProduct backlogのもっとEpicレベルのもののみを扱ったアイテムの優先順位を決めたりします。
また、開発チームはScrum、Kanban、XPなどどのような手法をとっても良いと書かれていますが、SAFeに出てくるScrumはScrumではありません。PO、SM、開発チームの役割がScrumと異なっています。 つまり、イテレーション開発です。Scrumではありません。

Remove References to Scrum from SAFe!

LeSSには、予算管理のような概念はありません。
これは明確に記載されている訳ではないので推測ですが、LeSSは、究極的に、1Productに予算権限・収支報告（P/L）まで割り当てることを見込んでいるからだと思います。各Productが一つ一つの会社のようなイメージでしょうか。
そこまでシンプルにすると、予算管理もシンプルになります。プロダクトバックログだけで予算・収支まで考えられるようになるぐらい、シンプルにする。
もちろん、Productとは何か、という定義は必要で、且つLeSSの場合は非常に、広いものになります。
LeSSは、Scrumと同じなので、PO、開発チーム、SMしかありません。CEOもCIOもCFOも登場しないのです。
LeSSは、”従来の考え方”に疑問を投げかけてくれています。
まとめる人、管理する人、整理する人って本当に専任で必要ですか？ということです。
究極的にはそうかもしれませんが、既存の企業は、この境地に辿り着けるのでしょうか。ボトムアップだと20年くらいかかりそう。

今現在、SAFeとLeSSは共存できないという見解です。なぜならLeSS = Scrumだから。
複数チームでScrumをやるとLeSSになる訳ではないのです。

ティール組織で言う、
オレンジ組織であれば、SAFe導入がしっくりくるでしょう。ヒエラルキーを保ったまま、大規模アジャイルを実践します。
グリーンからティール組織であれば、LeSSがしっくりくるかなと思います。ヒエラルキーがなくなりつつあります。マネージャーは残るかも知れませんが、役割は少なくなります。

SAFeは、Do agile
LeSSは、Be agile
SAFeは、ビジネスドリブン
LeSSは、現場、開発ドリブン
という感じがします。

	Essential SAFe(4.5)	Large Solution　SAFe(4.5)	Full　SAFe(4.5)	LeSS	LeSS Huge
規模	50～125人　　1トレイン	2トレイン以上	2トレイン以上	LeSS:2Team-8Team	LeSS Huge:9Team
役割	RTE/System Arch/Product Mgmt PO/SM/D-Team	Essentialに加えて、 Solution Arch/Solution Mgmt/STE	Large Solutionに加えて、 Epic Owners, Enterprise Architect	PO 1人 SM 1人で3チームくらいまで見れる D-Team	LeSSに加えて、APOが入る場合がある。 1エリアは4チーム以上。
バックログ	Program Backlog Team Backlog or Kanban	Essentialに加えて、 Solution Backlog	Large Solutionに加えて、 Portfolio Backlog	Product Backlog1本	LeSSと同じだが、エリア属性が加わる。
導入の考え方 （清水主観）	教育・研修によるトップダウンアプローチ マネージャーやCEOを先に教育する	←に同じ	←に同じ	ボトムアップ（チーム中心）を重視 本質的なマインドセット変革	←に同じ
際立った特徴	10sprintに1回、PIPlannningがある。10Sprint分の計画を事前に建てる。 ScrumMasterやProductOwnerがScrumはできない。=SAFeでも、スプリントという言葉は禁止されていて、イテレーションと呼ぶことになっている。 SAFe内で表現されているイテレーション開発は、Scrumではない。TOOになっている。仕組み上仕方ない。 SAFeの中からScrumという言葉を消してくれムーブメントが起こっている。　http://remove-scrum-from-safe.tilda.ws/	←に同じ	←に同じ	Scrumにいくつかのイベントを足しただけでシンプル	←に同じ
チーム	75％はFeature/25%はComponent	←に同じ	←に同じ	Featureを強く推奨	←に同じ
働く場所	同じ場所は必須ではない	←に同じ	←に同じ	同じ場所を強く推奨	←に同じ

スクラムと経済学・社会学・心理学

あるCSTの方と話をしていて、スクラムは組織論と心理学に基づくと言われました。 もっとスクラムマスター極めたいと思ったら組織論と心理学を学べと言われ、ちょっと調べていたのですが、そもそも組織論ってどのような学問なのか調べていたら、社会学と心理学だという。 組織行動のマネジメントに載ってた。

【新版】組織行動のマネジメント―入門から実践へ

また違うCSTの方と話をしたら、おそらくJeffとKen（スクラムの創始者）は、偶然スクラムのやり方を発見し後から理論を紐付けているのだろう、と。

でもそんな文献どこにもないから、自分で考えようと思った矢先、めっちゃいい本出た。

世界標準の経営理論

あやうく通信制の大学入り直すところだったよ。危ない危ない。

これで、スクラムと理論を結び付けられるかも。 スクラムすべて、つまりプロダクトオーナー、スクラムマスター、開発チームにも関連すると思ったら印をつけている。
ということで、概要レベルでの紐付けは以下。今後深堀りしていこう。2020年のテーマができた（笑　

○=直接的に関係がありそう
△=間接的に関係がありそう

こうみてみると、意外にも社会学の繋がりは弱い。LeSSで考えるとまた違うのかも。
リアルオプションは不確実性という文脈で、どちらかというとアジャイルに馴染む。

SCP理論

SCP理論をベースにした戦略フレームワーク

リソース・ベースト・ビュー（RBV)

SCP対RBV、および競争の型

情報の経済学(information economic)

情報の経済学(エージェンシー理論)(agency theory)

取引費用理論(TCE)

ゲーム理論(Game theory)

リアル・オプション理論

カーネギー学派の企業行動理論(BTF)

知の探索・知の深化の理論(exploration and exploitation)

組織の記憶の理論(SMM&TMS)

組織の知識創造理論(SECIモデル)

認知心理学ベースの進化理論(evolutionary theory)

ダイナミック・ケイパビリティ理論(dynamic capabilities)

リーダーシップの理論(leadership theories)

モチベーションの理論(motivation theories)

認知バイアスの理論(cognitive bias)

意思決定の理論(decision making)

感情の理論(emotion theories)

センスメイキング理論(sensemaking)

エンベデッドネス理論(embeddedness)

『弱いつながりの強さ』理論(weak ties)

ストラクチャル・ホール理論(structural holes)

ソーシャル・キャピタル理論(social capital)

社会学ベースの制度理論(institutional theory)

資源依存理論(resource dependence theory)

組織エコロジー理論(organizational ecology)

エコロジーベースの進化理論(evolutionary theory)

レッドクイーン理論(red queen theory)

2019年振り返り

2019年もお疲れさまでした。2019年の印象に残った本をご紹介します。だいたい2019年は、漫画を除くと100冊くらい読みました。進撃の巨人はクライマックス、ワンピースもあと数年で終わりそうですね。

「影響言語」で人を動かす

Coachとしての資質の一つに必要かも知れない、Profiling。この本では、LABプロファイリングとして人を１４種類の特性に分けて、どのように分類していくかが語られている。

【新版】組織行動のマネジメント―入門から実践へ

組織行動学が学問的にどのように派生されてきたかも記載されている良書。心理学や組織論を体系的に学びたい方にはおすすめ。

すぐれた意思決定―判断と選択の心理学 (中公文庫)

意思決定の方法が様々記載されている。

ビジュアル・ミーティング 予想外のアイデアと成果を生む「チーム会議」術

ファシリテーション・グラフィックの元祖らしい。ミーティングのススメ方や結束力の高め方などが記載されていて、何回も読み返したくなる。

Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing (English Edition)

ビジネス部門と開発部門のコキュニケーションのギャップを無くしたい、そのために・・・という本。 ATDDやBDD、Specification by Exampleの先にある本。Kindleだとすごい安いので、電子版がおすすめ。

GREAT BOSS(グレートボス): シリコンバレー式ずけずけ言う力

一兆ドルコーチ内に参照されていた本。まぁ、そうなんですよ。本音で語ることの重要性。めっちゃ重要。でもできないのよ。日本人。

1兆ドルコーチ シリコンバレーのレジェンド ビル・キャンベルの成功の教え

一兆ドルコーチ。最高。

偉大な組織の最小抵抗経路 リーダーのための組織デザイン法則

個人的には何も学ぶことがなかった本。１回読んでお蔵入り。学習する組織のピーター・センゲの友達が書いてるって書いてあったから読んでみたけど、微妙。

Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum (English Edition)

大規模スクラム（LeSS）の誕生前２００８年ごろ同じ著者、グレイグとBassに書かれた良書。でもScaling Leanのほうが響いたな。 Avoid ... Try... で記載されているのは、あくまでガイドだからかな。

新インナーゲーム (インナーシリーズ)

個々人に対してどうやったら良いコーチングができるのかな、というところで読み進めた。良書。 なんというか、例えば、テニスプレーヤーをコーチするときに、『ボールをよく見ろ』ではだめで。 『ボールがネットを超すときに、ボールの縫い目はどの方向を向いていたか？』という問いが、本当の集中力を必要とさせる問いであると。 確かに。
それをビジネスの現場ではどうするのか、考えをくれた一冊。

グループ・コーチング入門 (日経文庫)

グループコーチングという単語では、ではおそらくこの一冊しか日本で出てないのではないか。集団に対するコーチングのハウツーが記載されている。 システムコーチング（ORSC/CRR) とも違う流派ではなる。ここからインナーゲームにたどり着いた。

INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント

新版だったのだが、魅力が薄れた。初版のほうが好き。

システム・シンキング入門 (日経文庫)

システム思考の練習問題がたくさん載っている良書。ループ図の前提として、時間軸を考慮したグラフを考えろ、とか、ループ図のパターンを理解するにはこの本が一番良い。

LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear)

DevOps関連の本ではこの一冊が一番良いのでは。定量的にどんな指標がいいのか指南されている。

The Ten-Minute Trainer: 150 Ways to Teach it Quick and Make it Stick! (English Edition)

半端ねぇ。シャロンさんすげぇ。

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

これまでの設計論とかコーディングとかをまとめたような感じでそんな新しい発見はなかった。。。まとめとしては良いかな。逆にこれまで設計やプログラミングであまり本を読んでこなかった人は最初に読むとまとまってていいのかも。

Release It！ 本番用ソフトウェア製品の設計とデプロイのために

生々しくて大好き。古くからの現場ってこうゆう感じだよね。

米海軍で屈指の潜水艦艦長による「最強組織」の作り方

基本は、権限を委譲するって話。

DVD付き カラダをリセット+体幹力UPのコアトレーニング

半年間ぐらい週末はこれをやっているけど結構いい。とくにエキスパート体幹は結構利く。

本を読む本 (講談社学術文庫)

ものすごい良かったけど、体系だってない。からまとめ書こうかと思ったけど、まとめられず。

経営戦略としての異文化適応力 ホフステードの6次元モデル実践的活用法

その国に住む人は、XXX（例えば、主体性とか、危険回避性とか）の傾向が強いとか弱いとかそうゆうのが研究されていたみたい。まぁ、なんとなくわかる部分もあるけど、 一概にそのくくりに当てはめちゃうのは危険だとは思う。参考にはなる。

完全教祖マニュアル (ちくま新書)

達人のサイエンス―真の自己成長のために

奇跡の経営 一週間毎日が週末発想のススメ

エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド

花粉じゃばらサプリ：奇跡の柑橘ジャバラに青ミカン成分を凝縮 1本: 1か月分270粒

モダンサッカーの教科書 イタリア新世代コーチが教える未来のサッカー

大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法

LeSSを実践するなら読んでおかないといけないけど、実践しながら読むとまた色々と噛み締められる。バイブルですね。でも 個人的には、↓のほうがおすすめ。

Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum (Agile Software Development Series)

Be Agileって言葉が出てきた最初の本なのかな？とにかくAgile謳ってるなら必読。後のLeSSに繋がる。
Be agile rather than do agile.

アジャイルコーチのコーチパフォーマンス計測

単純なメモです。
Coaching Agile Teamのp281よりGoogle翻訳で抜粋しただけ。

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn))

以下の考え方から離れます	以下の考え方に向かいます
チームを駆動すると、結果を取得します 他人の作品を演出	チームは自然に、誰もが「ドライブ」できる環境。それらを考えることなく、素晴らしい結果を提供する環境を作り出すことを暗黙的にリードします
予測可能性を達成するために、チームの仕事を制御します	彼らは選択して、彼らが約束した結果を得るために、彼らが責任を持って仕事を成し遂げるためにチームを解放します
会社のルールに従います	都度、彼らが価値の提供を制限する会社のルールに出会ったら、それを変えていくことに挑戦します。
すぐに管理に問題をエスカレート	完全に関わる人たちの中に問題を通じて働くことは、それらを解決し、上に移動します
実績のある安全で有利なオプション	チームのために安全性を作成すると、実験失敗し、学ぶために
計画によると製品を提供	その変化に応じた製品をお届けするためにチームを有効にし、ビジネス価値をまかせ、ますます正確な計画が唯一のメトリックその事項も配信
定番の戦略と手順に従って	創造性とでもおなじみの領土に改めてそれぞれの状況を確認し、ゲームを変える結果のためのチャンスを高めるために、チームの能力を育成
本を読んでアジャイルを実装します	「本を読んで」行くとき知ることが最善であると不完全な環境では、少なくともいくつかの改善を得るためにアジャイルの最も強力な表現を犠牲にするとき

コンポーネントチームとフィーチャーチーム

コンポーネントチームとフィーチャーチーム

フィーチャーチームの定義

そのチームがフィーチャーチームかどうかは以下で判断できる。
・そのチームだけで最終出荷製品が作れるかどうか。

リーン思考では、手渡し作業、待ち状態、仕掛り作業の制限、情報散財、未活用の人々、これらは致命的となる。
クロスファンクショナル、クロスコンポーネントフィーチャチームはそれらの無駄を減らすためのパワフルな解決策となる。

理想的なフィーチャーチーム

• 長期間存続。
• クロスファンクショナルでありクロスコンポーネントである。
• 一緒に同じ場所で働く。
• 要求分析、デザイン、プログラミング、テスト・・・顧客中心の機能をすべてのコンポーネントにまたがって実現する
• 多能工で構成される
• スクラムにおいては、7±2人で構成される。

フィーチャーチームのメリット

価値のスループットが増加する

顧客もしくは市場にプロダクトを届けることに焦点をあてる。

学びの増加

個人とチームの学びは、広い責任と様々なエリアのスペシャリストが集まり協働することによって増加する。

よりシンプルな計画をすることになる

組織的に計画がより簡単になる。例えば、コンポーネントチームが複数あった場合、それぞれのコンポーネントチームと調整が必要になるが、
フィーチャーチームの場合、このフィーチャーチームだけで調整は閉じている。

手渡し作業の無駄を減らせる

要求分析、デザイン、プログラミング、テスト・・・などのすべての作業において手渡し作業の無駄を減らせる。

待ち時間の無駄を減らせる

複数のコンポーネントチームでの協働の場合、そのコンポーネントができるまで自チームに待ちが発生する。その無駄を減らせる。

自己組織化、効率的にコストを改善できる

フィーチャーチームはプロジェクトマネージャまたはフィーチャーを市場または顧客の届けるためのマトリックスマネジメントを必要としない。
なぜなら、フィーチャーチームにすると、調整はささいなことになるかである。チームは顧客に届ける価値を自分達自身で調整し、彼らの仕事を仕上げる責任がある。
データはマネージャーの数と開発生産性に逆の相関があること、また、内部と外部の両方に焦点を当てたチームが成功する可能性が高いことをも示している。[AB07]
フィーチャーチームは出費を抑え、プロジェクトマネージャのようなオーバーヘッドを必要としない。

コードとデザインの品質がより良くなる

複数のフィーチャーチームで開発をすると、シェアすべきコンポーネントは、否が応でもクリーンなコードにせざるを得ないプレッシャーにさらされる。複数のフィーチャーチームで扱うのだから
コードフォーマットは標準化され、維持される。コンスタントにリファクタされ、たくさんのユニットテストで囲まれる。そうでなければ、仕事をすることが不可能になるからだ。
一方で、コンポーネントチームが長い間維持されると、彼らはそのコンポーネントに対する理解しか持たなくなり、似たようなスキルの人で固まり、よりコードをわかりやすくするという必要性に迫られない。

モチベーションをより維持できる

フィーチャーチームは、顧客と直接対話し、必要なものを作っているという実感を得られるとモチベーションが高まるという研究結果がでている[HO80, Hackman02]。
仕事満足度もあがる。これは、生産性と成功に重要なファクターとなる。

変更がより簡単になる

要求やデザイン、設計の変更により柔軟に対応できる。マルチコンポーネントチームとの相談や調整が不要になるし、コードがクリーンだから当然だ。

コンポーネントチームのデメリット

• 順次開発サイクルとマインドセットを助長する
• 同じコンポーネントを長期間開発し人々の学習を制限する
• 最も価値のある仕事よりも、簡単にできる仕事をすることを助長してしまう
• 人工的な仕事（仕事のための仕事）を助長してしまう
• 手渡し作業の無駄と長い待ち時間による大きな遅延の原因となる
• コードの重複を助長する
• 増え続ける開発者を不必要に促進する（どんどん人を増やす原因となり、遅れが遅れを呼ぶ）
• チーム間の計画と同期を複雑にする
• ボトルネックを増加させる -あるコンポーネントチームが単一障害点となる-
• より貧弱なコード・設計を育成することになる

よくある質問

例えば、デザイナーや要求仕様をまとめる人(Analyst)がフィーチャーチームでチームに加わっていたとして、その人の作業が終わるまでプログラマは作業ができないのではないか？

なぜプログラマはその人の作業が終わるまで待っているのですか？同じチームなのに。デザインが必要ならば、一緒にデザインをすればいい。要求分析が必要なら、一緒にやればいいのです。
忘れないでください。あなたたちはチームであり、共通の目的を持っている。そして短いイテレーションの中でその目的を達成し続ける必要があります。
プログラマがデザインの仕事を一緒にやることによって、より効率的な方法が見つかるかも知れません。逆のことも考えられます。
デザイナーやアナリストもプログラムを一緒に書きましょう。チームの一員なのです。これの繰り返しにより、メンバー全員のスキルが多能工になっていきます。よりよい世界が見れますよ。きっと。

営業やマーケティングもフィーチャーチームに加わるべきでしょうか？

原則はリーン思考になります。リーン思考を考えると、Time to Market。つまり、いかに迅速に市場や顧客にプロダクトを提供できるか、提供後に学び続けられるかが重要になります。
営業やマーケティングのメンバーがチームに加わることで、それが達成できますか？答えがYesなら、そうすべきですし、Noであれば、そうすべきではないでしょう。
必ず加わらなければならないということではありません。結局は、Time to Marketがより迅速になるかどうかだけです。フィーチャーチームになることが目的ではありません。
コンテキストに依存するので、一概にYesとは言い切れない場合もあるでしょう。

意欲に満ちていない人々を集めてフィーチャーチームはできますか？

アジャイルの12原則に少し違反しているようですね（笑
意欲は非常に重要です。ただ、フィーチャーチームはより顧客に近いところで仕事をすることになります。
人間は社会性を持つ動物ですので、他者の役に立ちたいと思う動機は、どのような人であり、多少はあるようなのです。
フィーチャーチームは、その動機を刺激することはできると思います。
でも、刺激をしたからといって、本当に人と接したくない方もいらっしゃるでしょう。
無理強いはよくないですので、それでも、もしモチベーションが全然上がらない方、それが２ヶ月以上続いたら、フィーチャーチームから『優しい言葉』をかけて去っていってもらうようにしましょう。

結論

どちらを選ぶべきか目指すべきかは、もう明らかですよね。
大切なのは、目指すべきということ。
いきなりフィーチャーチームは難しいですが、組織・チームの壁を超えてフィーチャーチームを目指すと、とてもいいことがある。徐々に攻めていきましょう。

参考文献

Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum (Agile Software Development Series)