沈黙のパレード

 つまらないわけではないが、ちょっと拍子抜けという感じであった。

容疑者Xの献身と比べると、登場人物の切実さにかける行動が目立つ。

トリックありきで、人間模様には薄さを感じた。

リーンソフトウェア開発

 リーン開発の本質の一つ前の本にあたる。

良い本である。順番的にはリーン開発の本質を先に読んで正解だったかもしれない。

こちらの本のほうが具体的で細かいことが書いてあるので。

２２のツールについて話をしてくれている。しかし、本質的には

1. ムダを排除する
2. 学習効果を高める
3. 決定をできるだけ遅らせる
4. できるだけ速く提供する
5. チームに権限を与える
6. 統一性を作りこむ
7. 全体を見る

について書かれている。いわゆる７つの原則であるが、リーン開発の本質に書いてあることと少し違う。リーン開発の本質のほうが後で書かれた本みたいなので、そっちを見たほうがいいかも。

１．ムダを排除するについて

ここだけでもかなり良い内容だと思う。

バリューストリームマップを作成して、とにかくムダを排除すること。

待ち行列が無駄になるので、余裕をもたせて渋滞が発生しないようにすることなどが書かれている。

２．学習効果を高める

品質の作り込みと決定を遅らせるということに関連している。

最初から完璧なものを一発で提供することを目指すのではなく、可能な限り初期の頃から品質チェックを行うということだ。最後の工程で品質チェックをして差し戻されるとムダが多いからである。

ユニットテストも自動化のうちの一つだと言える。可能な限り自動化することで品質の作り込みが前倒しできる。

また、開発の方針決定であるが、いきなり決めるのではなく、広く調べるべきで、段々と選択肢を狭めていく方向が良いと言える。

いきなり決めて、後戻りをせざるを得なくなると無駄になるので、できるだけ広く調べて少しづつ選択肢を狭めていったほうが良い。

ちょっと指摘が足りないと思ったところは２つある。

セキュリティについてだ。セキュリティチェックも可能な限り早期にかつ繰り返し行うほうが良い。

また、いつまで広く調べるべきだろうか？という点については言及がなかった。ただ、スケジュール感覚に優れた人の意見を聞いて決断していくべきだということが書いてあったと思う。

３，決定をできるだけ遅らせる

決めないことではない。

コンカレント開発は、仕様が固まりきらない段階から開発をはじめて、それぞれの工程での制限をフィードバックすることで、無理のない仕様や設計にして製品を作っていくということ。制限を伝えるというのが味噌。

できるだけ決定を送らあせたほうが、情報が揃っているので、良いわけだが、ただ決めずに遅らせるのは良くない。決めるべきタイミングではきちんと責任のある人間が決めて前進させる必要がある。

４．できるだけ早く提供する

早く作れるならギリギリまで決定を遅らせることが出来るから。フィードバックを与えられるから。当然メリットは多い。

５．チームに権限をあたえる

命令して動かすのではなくて、ボランティアの集団を動かすようにマネージメントするのが良い。

６．統一性をつくりこむ

ちょっと次の本では消えた要素では？とか思ってしまう。

リファクタリングは、やり直しではないし、設計コンセプトを保つための方法になるので、最初から工数に積んでおかないとだめだ。

そうしないと全体での統一性が取れなくなる。

実際に、そうなっているプロダクトを見ているので、まったくそのとおりだと思う。

７．全体をみる

局所最適しないように全体を見たほうがよい。

ここでは、リーン開発と協力会社との契約に関して記述されていて、非常に興味深い。

リーン開発の本質と微妙に違う構成になってはいあるが、非常に良い本であったし２２のツールは見直していきたい。

リーン開発の本質

 名著だと思う。

全編にわたって参考になることばかりが書いてあるので、繰り返し読んだほうがいいかもしれない。特別に抜粋すべきところがあるというよりは全体がすごく良い。

トヨタ生産方式とソフトウェアの関連がいまいちついていなかった面があったが、腑に落ちた。

だいぶ昔の本であるのに、日本にリーン開発が根付いていないのが非常に気になりはした。

原則1:ムダをなくす

原則2:品質を作り込む

原則3:知識を作り出す

原則4:決定を遅らせる

原則 5: 速く提供する

原則6:人を尊重する

原則7 : 全体を最適化する

が原則として挙げられており、それらについて細かく説明がされている。

基本的なコンセプトはサイクルタイムをいかにして短くしていくのかという点だ。

ムダをなくしていくのも、その手段となっている。

ムダには大きく７つがある

• 未完成の作業のムダ
• 余分な機能のムダ
• 再学習のムダ
• 引き継ぎのムダ
• タスク切り替えのムダ
• 遅れのムダ
• 欠陥のムダ

バリューストリームマップの作成をしてムダを排除していく。

スピードを上げるために、可能な限り作業を詰め込むのではなく、少し余裕をもたせることで、スループットがあがり、最終的なスピードがあがる。

あまり詰め込みすぎると渋滞が起きるのと同じ。

チームを作っていくために、命令して作業を割り振るというよりは、話し合いながら何をすべきかを全員で決めていくことだ。

ただ、何かをきちんと決めるリーダーは絶対に必要。

集合ベース設計では、３パターンくらいの設計案を考えて、最適なものを選んでいく。時間的な成約に間に合わせるために、確実に間に合うもの、間に合わないだろうけど最高なものなど。

リファクタリングは必要なもので、最初から最適なものを作れなかったから行われるのではない。変更を受け入れやすくして、コードの寿命を伸ばすためのものだ。

リファクタリングは必須であり、プロセスにいれて最初から時間を確保すべき。

リファクタリングのためには、自動テストの強力な取り組みが必要となるので、それが血管の混入を防ぐなどの効果もたらす。

自動テストで重要なのは、製造有形で言うところの、ラインストップに相当する効果を狙ったものだ。

出荷前に不具合を検出して、完成品の検証という時間をなくすことでサイクルタイムを短くするのだ。

ここでは、リーン開発を実践するための、 21 ステップのプログラムを提案 する。各ステップでは、何を行うか、手短な説明だけをする。詳細は、本書 の各所ですでに紹介してきたはずだ。 これらは、 提案として受け止めてほし い。 私たちの提案を試してみて、自分の組織で求めている成果が得られるか どうか、確認してほしい。

■全体を最適化する

1. バリューストリーム全体、製品全体を通してリーン手法を実践する。 バ リューストリームのリーダー(あるいはリーダーとなるチーム)を任命 して、顧客に始まり顧客に終わる、バリューストリーム全体の責任を負 わせる。 ソフトウエアだけではなく、 製品全体を重視する。 バリュース トリームマップを描き、 流れに中断がないか、やり直しや揺れ動きがないか、流れの中で必要なときに利用できなかったり、必要な成果を出せ ていない個所がないか、チェックする。 プロセスのほころびを直し、シ ステムに欠けている機能を補足する。

2. 計測基準を作り直す。 バリューストリーム内で、部分的な計測を行って いる可能性が非常に高い。また同様に、そのような計測によって部分最 適化や、さらに悪ければ、機能不全につながっていることも非常に多い。 部分的な計測を行うのをやめて、 代わりにバリューストリームでの計測 を行おう。

3. 境界越えのコストを減らす。 バリューストリームに大きな遅れがある場 合、おそらくそれは、部署や企業の境界で起きているはずだ。 そのよう な境界を注意深く調べて、 そこで実際にどれだけのコストがかかってい るのかを評価する。 そのような境界で、価値の流れのスピードアップに つながることなら、 ほぼ確実に、境界越えのコスト削減にもなるはずだ。

■ 人を尊重する

4. チームリーダーや監督者を訓練する。 プロセスリーダーを重視する代わ りに、現場のチームリーダーを訓練し、指導し、 配備して、彼らの持ち 場でリーン手法を実践するための時間を与える。

5. 責任や意思決定をできるだけ下のレベルに委譲する。 リーン活動は、価 値を生み出している作業チーム自身により、今いるリーダーの指導の下 で実践されるべきである。 作業チームには、新プロセスをうまく機能さ せるために必要なものを要求させる。

6. 技術へのプライドを育てる。 技術へのプライドは、いろいろなもので崩 される。チームへではなく個人への報酬、散らかった職場やぞんざいな 作業プラクティス、守れるはずのない締め切り、きちんとしたテストや リファクタリングを行う時間の欠如、プロセスの押し付け、ロボットが やるような繰り返しの作業など、 すべてがプライドを崩すもとになる。 このようなプラクティスは根絶し、廃止しなくてはならない。チームメンバー間で報奨をめぐっていさかいが起こらないようにし、 繰り返しの タスクは自動化し、作業をする本人にいちばん適切な作業方法を決めて もらう。また、締め切りに間に合わせるために、作業をいい加減に行わ せるような指示は、絶対に出してはならない。 熱意を持って約束をし、 最高の品質を備えた成果を期待しよう。 そのほうが、個人に対して報奨 やボーナスを与えるよりも、より継続可能であり、はるかに大きな効果 もあるはずだ。

■速く提供する

7. 小さなバッチで作業を進める。 プロジェクトサイズを縮小する。 リリー スサイクルを短縮し、安定させる。 そして、繰り返す。 すべてのリスト や待ち行列の掃除をして、規模が大きくならないよう積極的に制限する。

8. 作業を許容量までに制限する。 繰り返し可能なリズムでチームに作業を させて、許容量を確定する。 実証済みの速度(ベロシティ) に基づいて、 チームに作業を待ち行列からプルさせ、その作業を完全に終わらせてか ら、次の作業に手をつけさせる。 待ち行列の長さを制限し、 その待ち行 列に空きができるまでは、作業を受け付けない。

9. 利用率ではなく、 サイクルタイムを重視する。 リソースの利用率に気を 揉むのはやめて、製品化までの時間や、 顧客への応答時間の計測に切り 替える。

■決定を遅らせる

10. 完全に仕様を決定してから開発に着手するのがよい方法である、という 考えは捨てる。 コンカレント開発を行うということは､開発プロセスか ら仕様を浮かび上がらせるということだ。 コンカレント開発によって、 コストも時間も節約でき、 最高の成果が生み出せ、 最も新しいデータに 基づいて決定を下せるようになる。 コンカレント開発を嫌う理由などな い。 それなら、開発に着手する前に、 完全な仕様ができあがっているべ きだという考えに、どうして執着する必要があるだろう? その答えが、 資金調達が事前に行われるためなのであれば、徐々に資金調達を行うように変更しよう。 もし、固定価格での契約によるものなら、別の契約モ デルに移行しよう。

11. 依存性を断ち切る。 依存性を気にかける代わりに、どのような機能も、 どのような順序ででも追加できるように、 依存性を断ち切るあらゆる努 力をする。 分割可能なシステムアーキテクチャは必須である。 依存性を とことん疑いできるかぎりなくしていく。

12.選択肢を持ち続ける。 撤回のできない決定には、かならず､ 複数の選択 肢を設け、 最終責任時点まで、絶対に選択肢を切り捨てない。 重要な設 計上の決定は、トレードオフである。 最善の選択を行うのに必要なデー タと確信を手に入れるため、それぞれの選択肢が持つ影響力を十分に理 解するための投資をする。 それ以外のすべての決定に関しては、変更を 受け入れやすいコードを作り、クリーンかつシンプルに保ち、変更をた めらってはならない。

■知識を作り出す

13. 設計・構築チームを作る。 製品を論理モジュールに分割して、 バリュー ストリームの各フェーズをそれぞれ代表するメンバーからなる部署の壁 を越えたチームを作り、そのチームでモジュールを担当できるようなシ ステムアーキテクチャを作り上げる。 各チームに適切なリーダーシップ やインセンティブを与え、積極的取り組みや透明性、集中的なフィード バックが維持できるようにする。 チームに対しては、情報を早期かつ頻 繁に共有し、 速く失敗し、絶えず学習し続けることを推奨しなくてはな らない。

14. 継続的な改善を行う文化を守る。 各チームや各部署で、継続的にプロセ スを見直し、改善し、仮説をテストするように求め、また、そのための 時間を作る。 チーム間あるいは部署間でミーティングを開いて、 バ リューストリームの流れに内在する制約や、制約への適応手段を見出 し、全体的な成果を改善させるプラクティスや方針に置き換える。

15. 問題解決手法を教える。 PDCAサイクルや科学的方法など、何らかの問 題解決手法を教える。 チームが仮説を立て、 すばやく数多くの実験を行 い、簡潔に文書化し、検討済みの変更を実行するように促す。

■品質を作り込む

16. 同期する。 未完成の作業を積極的に減らす。 テストを最初に書く。でき るだけ早くコードをテストする。欠陥はリストに付け足していかずに、 見つかった瞬間に作業を止め、直すようにする。 コードをできるかぎ り、継続的に、広範囲にわたって統合する。より大規模で複雑なシステ ムの統合には、同期を入れ子にする。

17. 自動化する。 人間は間違うものだという事実を受け止めて、 自動化によ りポカヨケを施す。 できるだけ早く、 自動化できるプロセスすべてを自 動化する。 テスト、 ビルド、インストールなど、 繰り返し行う作業はす べて自動化する。 ただし、 人を支援して、どうすればもっとうまくでき るか、人に考えさせ続けるような自動化でなくてはならない。

18. リファクタリングする。 コードベースをクリーンかつシンプルに保ち、 重複を目にしたらただちに、コードやテスト、ドキュメントをリファク タリングして、複雑さを最小にとどめる。

■ ムダを排除する

19. マーケティングと技術の両方を理解しているリーダーを任命する。顧客 が何に価値を見出すのか、また、それと密接に関連して、 技術側が何を 提供できるのか、両方を深く理解する責任があることを明確にする。 チームが正しいものを確実に作れるようにする。

20. 価値のみを生み出す。 すべてのプロセスのすべてのステップにおいて、 できるかぎり、価値を生み出す活動と価値の提供能力向上が重視されて いることを確認する。 プロセスサイクルの効率を計測し、改善し続け る。

21. コードをできるだけ書かない。 システムの機能を積極的に制限し、価値 を付加するために絶対必要な機能のみを作る。 組織をあげて、 複雑さに 抵抗する姿勢を作り上げる。

トヨタ物語

最近の本であるが、トヨタ生産方式にがどのように作られていったのかを追いかけた物となっている。

トヨタがどのようにして生まれていったのかの歴史的な部分と、後半は大野耐一とその後輩がトヨタ生産方式をどのように広めていったのかが書かれている。

手取り足取り教えるのではなく、現場に放り込んで自分で考えさせる。だめなところを指摘して鍛える。

という感じで全員が鍛えてもらった。みたいな物語になってはいる。

正直、中には耐えられなくて脱落した人もいたろうから、すごく良い教育方針とは言えないかもなとは思う。

特に使い捨てには出来ない新人をきつく叱るのは、いまは出来ないかもなと思う。

時代が、違うというのは、替えがきくから潰れるやつがいてもなんとかなった時代ということだと思う。人が変わるけではないから。

少々、そのへんが賛美的な表現がされているので、真似するのは良くないと思う。

アメリカでは、論理的に説明して説得したというが、それは今の日本もそんなに違いは無いかなと思う。

物語としては、面白かったけど、そんなに学びがあるかというとそうでもない本ではある。

LeanとDevOpsの科学

 なかなかの良い本であった。

世の中でLeanとかDevOpsとか言われているが、実際のところどうなのか？

みたいなところが、計測をもとに網羅的に紹介されている。

網羅的なのでチェックリストというか指針として使えるなと思う。

 CI環境を整えるとか、継続にdeployし続けるとか、ある意味では当たり前のことが言われているわけだが、セキュリティチェックを開発プロセスに組み込んで、毎回やるほうが効率がいいことがわかったとかは、なかなかおもしろかった。

最後の方の結果に関しては、全体的にここにメモを載せておく

組織モデル。これはユニコーン企業の秘密にもあった構造だ。たぶんもう業界標準。

チーム、マネジメント、リーダーシップのそれぞれについて、高いパフォーマンスを生む行動とプラクティスの一覧

A.1 継続的デリバリの促進効果が高いケイパビリティ

1. 本番環境のすべての成果物をバージョン管理システムで管理 GitHubやSubversionなどのバージョン管理を利用して、 アプリ ケーションのコードやコンフィギュレーション、システムのコン フィギュレーション、本番環境のビルドやコンフィギュレーショ ンを自動化するためのスクリプトなど、本番環境のすべての成果 物を管理するケイパビリティである。 第4章を参照。

2. デプロイメントプロセスの自動化　デプロイの完全自動化 (手 作業による介入が不要な状態) の実現の度合いである。 第4章を参 照。

3. 継続的インテグレーションの実装 継続的インテグレーショ ン (Continuous Integration: CI)は継続的デリバリの実現に向 けての第一歩である。CIとは 「コードに定期的にチェックインし、 チェックインのたびに重大な不具合を発見するための迅速なテス トがトリガーされ、不具合が見つかれば開発者が直ちに修正する」 という開発のプラクティスである。このプロセスによって正規化 されたビルドとパッケージを作成し、最終的にデプロイ､リリース する。 第4章を参照。

4. トランクベースの開発手法の実践 トランクベースの開発は、 ソフトウェアのデプロイとデリバリにおけるパフォーマンスの予 測要因となりうることが立証されている。 特徴は ｢コードリポジト リでアクティブなブランチの数は3つ未満」 「統合前のブランチと フォークの『寿命』は非常に短い(たとえば1日未満)」 「アプリケー ション担当チームが統合の際のコンフリクトやコードフリーズ、 スタビライゼーションのためにコードへのチェックインやプルリ クエストをストップする 『コードロック』の期間がほとんど(ある いはまったくない」などである。 第4章を参照。

5.テストの自動化　ソフトウェアのテストが開発プロセス全般に 「わたって継続的に (手作業ではなく) 自動的に行われる､というブ ラクティスである。 効果的なテストスイートは信頼性が高い。 本当 の不具合を探知し、リリース可能なコードだけをバスさせる。 留意 すべき点は「自動化テストスイートの作成と維持管理の主な責任 を負うのは開発者」ということである。 第4章を参照。

6. テストデータの管理 テストデータは慎重に維持管理しなけれ ばならず、テストの自動化においてはテストデータの管理の重要 性が増しつつある。 効果的なプラクティスとしては ｢使用している テストスイートに適したデータを入手する」 「必要なデータをオン デマンドで入手できる」「自組織のパイプラインでテストデータを 調整できる」「実施できるテストの量がデータによって制限されて しまわない」などが挙げられる。 ただし、 自動化テストを行うのに 必要なテストデータの量は常に極力少なくするべきである。 第4章 を参照。

7. 情報セキュリティのシフトレフト 情報セキュリティ関連の作 業を設計段階とテスト段階に組み込むことも、パフォーマンス向 上の重要なカギである。 具体的には 「アプリケーションの情報セ キュリティ関連のレビューを実施する｣ 「情報セキュリティ担当 チームをアプリケーションの設計段階からデモ段階までの全工程 に参画させる」「事前に承認された情報セキュリティ関連のライブ ラリとパッケージを使う」 「セキュリティ関連機能のテストも自動 化テストスイートの一部にする」といったプラクティスが挙げら れる。 第6章を参照。

8. 継続的デリバリ (CD) の実践　継続的デリバリとは ｢ソフトウェ アを、ライフサイクル全体にわたってデプロイ可能な状態で維持 する」という開発プラクティスのことで､チームはこのデプロイ可 能な状態の維持を、 新機能の追加よりも優先する。このプラクティ スを実践すれば、チームのメンバー全員がシステムの質とデプロ イ可能性に関するフィードバックを素早く入手できるので、デブ ロイ不能との報告を受ければ直ちに修正できる。 また、本番環境へ のデプロイやエンドユーザーへのデプロイも随時オンデマンドで 行える。 第4章を参照。

A.2 アーキテクチャ関連のケイパビリティ

9. 疎結合のアーキテクチャ　ー　チームがアプリケーションのテストやデプロイを、他部署との調整を要さまにオンデマンドで、どのよ 度実施できるかは、アーキテクチャの結合の度合いによって決 協力に頼らず独立した形で作業を進められ、 それによりチームの る。 アーキテクチャが疎結合であれば、チームは他チームの支援や 迅速な作業と組織への価値提供とが可能になる。 第5章を参照。

10. チームへのツール選択権限の付与 本研究では「ツールを選 ぶ権限を与えられているチームのほうが継続的デリバリの能力が 高く、それがソフトウェアの開発とデリバリのパフォーマンスを 高める」との結果が出ている。 チームの効率を上げるのに必要なも のは何かを一番よく知っているのは現場担当者である。 第5章を参 照製品管理の領域におけるチームの権限については第8章を参 照)。

A.3　製品 プロセス関連のケイパビリティ

11. 顧客フィードバックの収集と活用 本研究で「顧客に関するフィードバックの定期的な収集と、製品設計におけるその活用に 対して、組織が積極的であるか否かが、ソフトウェアデリバリのパ フォーマンスを大きく左右する」との結果が出ている。 第8章を参 照。

12. 全業務プロセスの作業フローの可視化 チームにとっては、製品の開発段階から顧客対応段階に至る全業務プロセスの作業フ ロー (ならびに製品や機能の現況) の可視化とその十分な理解が必 須である。本研究で、このケイパビリティがパフォーマンスを大き く左右することが立証されている。 第8章を参照。

13. 作業の細分化 — 作業は1週間未満で完成できるよう、細分化す る必要がある。コツは 「ブランチを使って複雑な機能を開発し低 頻度でリリースするのではなく、迅速な開発が可能な機能に細分 化する」というものである。この手法は機能レベルでも製品レベ ルでも応用できる(たとえば MVP [実用最小限の製品] を利用する のも1つの方法。 MVP とは製品自体とそのビジネスモデルの「検証 による学び」が可能な規模の機能だけから成るプロトタイプのこ とである)。 作業をこうして細分化して進めれば、 リードタイムも フィードバックループも短縮できる。 第8章を参照。

14. チームによる実験の奨励 実現　チームによる実験とは、 開発 者が開発プロセスにおいて、チーム外の人々の承認を得なくても 新たなアイデアを試したり、仕様を更新したりできる能力を指す。 このケイパビリティを強化すれば、 チームは革新を迅速に実現し、 価値を創出できる。 特に「作業を細分化して進める」 「顧客フィード バックを製品設計に盛り込む」 「作業フローを可視化する」 といっ た他のケイパビリティと並行して強化すると効果が高まる。 第8章 を参照 (このケイパビリティの技術面に関しては第4章を参照)。

A.4リーン思考に即した管理・監視に関わるケイパビリティ

15. 負担の軽い変更承認プロセス 本調査研究で「チーム外の変 更諮問委員会 (CAB:change advisory board) のレビューを義務 付けるより、 (ペアプログラミングやチーム内でのコードレビュー など) ピアレビューをベースにしたライトウェイトな変更承認プ ロセスを確立したほうが、パフォーマンスが高まる」 との結果が出 ている。 第7章を参照。

16. 事業上の意思決定における、アプリケーションとインフラの監視 結果の活用　事業や日常レベルの作業に関する意思決定で、 ア プリケーションとインフラのモニタリングツールから得たデータ を活かす能力。 プラクティスとしては ｢問題が発生したら担当者を 呼び出す」 というやり方よりも優れている。 第7章を参照。

17. システムの健全性のプロアクティブ (予防的)なチェック　しきい値警告と変化率警告に基づいてシステムの健全性を監視し 問題の予防的な探知と軽減を図る能力。 第13章を参照。

18. WIP制限によるプロセス改善と作業管理 - 進行中の作業(WIP Work in Progress) を制限して作業フローを管理するというのは、 リーン思考の実践コミュニティではおなじみの手法であ る。 効果的に実践すれば、プロセスの改善、スループットの増大、シ ステムにおける制約の可視化が図れる。 第7章を参照。

19. 作業の可視化による、 品質の監視とチーム内コミュニケーショ ンの促進 ダッシュボードや内部Webサイトなどのビジュアル ディスプレイを品質やWIPの監視に活用すると､ ソフトウェアデ リバリのパフォーマンスが向上することが立証されている。 第7章 を参照。

A.5組織文化に関わるケイパビリティ

20. (Westrum 推奨の) 創造的な組織文化の育成 ―これは本研究 で採用した組織文化の測定基準であり、航空や保健医療などきわ めて複雑で高リスクな領域のシステムを専門に研究を重ねた社会 学者 Ron Westrumが提唱したモデルを下敷きにしている。そして 本調査研究では「この測定基準で、チームと組織全体のパフォーマ ンスを予測できるほか、燃え尽き症候群の軽減効果も予測できる 「こと」が判明している。 具体的にこの基準で測定できるのは、 情報 の流れ、 協働・ 信頼関係、 チーム間の仲介などのレベルである。 第3 章を参照。

21. 学びの奨励と支援 自組織は、継続的な進歩を遂げる上で、 「学 び」 を必須の要素と捉えているか｡ 学習を 「犠牲」と受け止めてい るか、それとも「投資」と考えているのか。 これが組織の「学び」の 文化を測る基準である。 第11章を参照。

22. チーム間の協働の支援と促進 従来、チーム同士は「縦割り」の関係にあったが、 それをどの程度脱却し、開発・運用・情報セキュ リティの領域で相互連携を果たせているのかについて、そのレベ ルを反映するケイパビリティである。 第3章および第5章を参照。

23. 有意義な仕事を可能にするツール等の資源の提供 職務満足 度の予測要因となりうるケイパビリティである。 強化のキモは 「各 構成員が困難でも有意義でやりがいのある仕事ができ、自身のス キルを活かし判断力を働かせる権限を与えられること」 「各構成員 が、 職務を全うするのに必要なツール等の資源を与えられること」 リソース である。 第10章を参照。

24 改善を推進するリーダーシップの実現や支援 改善を推進するリーダーシップとは、 DevOps の実践に不可欠な技術的作業とプ ロセス関連作業を支援・増強するもので、 次の5つの要素から成る 「ビジョン」 「知的刺激」 「心に響くコミュニケーション」 「支援 を重視するリーダーシップ」 「個人に対する評価」。 第11章

サイボウズ流 テレワークの教科書

 IT業界であればチャットなどは元々利用しているだろうし、zoomなどのテレビ会議システムも利用しているので、そんなに真新しい内容はない。

ただ、

分報、ザツダンはいいかもなとは思った。

自分がやっていることを一々書くのは良いかもしれない。

ザツダンは、コミュニケーションの機会を意図的に増やすのがいいらしい。

機会とチャネルを両方増やすのが良いというのは、そのとおりだと感じる。

また、言語化がいままで以上に求められており、言語化して不明瞭さをなくしたコミュニケーションが必須となる。

ただ、基本的には書いてる内容で、重要な部分はオンラインオフライン関係なく大事なことな気がする。

オンラインになることで、意図的に今までやっていたことを言語化して仕組み化する必要があるということだと思う。

無印良品は、仕組みが9割 仕事はシンプルにやりなさい

 基本的には、全てをマニュアル化することにより改善する余地が生まれてくるという旨を繰り返し言っている。

内容に説得力があり同意できる部分も多い。

マニュアルを現場からのアイディアを吸い上げつつ更新して行くことで生きたマニュアルになる。

この視点は大事だと感じる。

また、マニュアルのフォーマットして一例を上げると

「部下に注意をする」とは

何：部下のミスやトラブルを是正する行為

なぜ：部下にミスやトラブルの原因を認識させ、反省してもらうことで成長を促す

いつ：部下がミスやトラブルを起こしたとき

誰が：自分

のように作る。マニュアル化することで各個人の力量に依存していたものが見える化されて、担当者が変わっても同程度の結果を残すことが出来るようになる。

結構はっとさせられたのは、管理職に向いていないのは性格のせい。と言ってしまって思考停止に陥っては行けないということだ。

人を変えることで解決を図るのではなく、構造的な問題が何かを明らかにして、それに対処して管理職に向いていないと思える人でも成長を促すという点と

管理業務もマニュアル化することで、だれでもある程度の成果が出るようにしていくということだ。それが会社を強くしていくのだと思う。

あとは、問題がある部下の性格を変えようとするのではなく、行動を変えることで解決を図るとか。Dead lineを設けるとか。当たり前といえば当たり前のことが書いてある。

ソフトウェアの開発でもマニュアル化出来ることは沢山あると感じるので、マニュアル化しつつ、改善していきたいものだ。