岩瀬義昌のレビュー一覧
-
Posted by ブクログ
エンジニア向けのマネジメント本。そうそう、と納得する部分がかなり多いし、参考にもなる。
橋を建てるのがとても上手になったら、、パン屋に昇進させられた
メンバーが活躍できるようにすることがマネージャーの仕事
個人の価値観をメンバーと共有、確認する
信頼は以下の基礎となる
お互いの傾聴
間違いの中の人間らしさを見つける
創造性
仕事をもっと楽しむ
毎週チームの時間をとる
チームメンバー間含め、それぞれの信頼関係が構築される
雑談を促す、くだらない冗談を言う
チームについて語る時、発言に自分自身を含める。が、チームが成功した時、自分自身を含めずメンバーを褒める。失敗した時、自分だけの責任としてメンバーは含めない
弱さを見せて手本を示す
リーダーが最初に行動する
チームの文化と士気を良い状態に保つ
価値観ワークショップをする
一緒に食事する
個人的な話をする
ロサダ係数
ポジティブな相互作用の量によるパフォーマンスへの影響
キャリアラダー
5年後どうなりたいか
自己レビュー
30.90日目標
繰り返しと振り返り
プロダクトとエンジニアリングの時間配分
-
-
-
-
Posted by ブクログ
ユーザマニュアルの書き方の解説であるが、他の本と一味違うのは公開、フィードバック、メンテナンスまで扱っていること。ドキュメントは多くの場合、作りっぱなしになってしまうが、そうならないようにするにはどうすればよいかというところにまで配慮が行き届いている。作りっぱなしの問題はすでに起きているので対処法は非常に参考になった。また、ドキュメントの管理もプログラムと同様のバージョン管理システムを用いたりするなどプログラマの視点での解説となっており、プログラマとしては非常に理解しやすかった。そして、この解説自体が解説通りの書き方となっており、具体的のどうすればよいのか？にも答えている。ドキュメントの管理もソフト開発と同様にチームで対応する必要があるが個人でできる部分も多々あるので本書を参考に少しずつであっても対応してきたいものだ。
-
Posted by ブクログ
読者の皆さんがこの価値観に同意するか、あるいは実際に取り入れるかどうかは、特に重要ではありません。重要なのは、チームとともに価値観を作り上げる機会を設けることです。そうすることで、チームで価値観を支持する方法や、問題があれば異議を唱える方法を見つけられるようになります(実際に問題に巻き込まれてからより、今議論しておいたほうがよいでしょう)。チームで価値観が遵守されていれば、特にキャリアラダーのようなことで慌てる必要はありません。また、私がここで推奨している支持的で協力的な資質は、私がプリンシパルエンジニアを評価する軸とも一致しています。
これらの価値観がしっくりこない人もいるでしょう。その人たちにとっては他のチームを見つけるほうが有意義かもしれません。でも、それでいいのです! 価値観の興味深い点は、必ずしも正解が存在しないことです。自分たちが作り上げたいチームに適した価値観と、そうでない価値観があるだけです。
私は、誰もが自分の価値観に反しないチームでの仕事を探すべきだと強く感じています。理想的には、自分にとって完全ではなくとも大体は価値観が合致していると感じる場所がいいでしょう。異なる視点を持つ同僚から学ぶのもまた、良いことだからです。一握りの主要な、基本的な価値観は合致しているべきでしょう。そうでなければ、目の前の仕事がさらに大変になりかねません。価値観が合っていないと、燃え尽きてしまうのは避けられません。
チームの価値観の大部分が自分の価値観と合致しているチームで働くのは良いものです。なぜなら、チームの文化の本質を深く掘り下げられるからです。こおで私たちが目指しているのは明確さです。明確さが鍵となるのです。
あなたと各メンバーの間だけでなく、チームメンバー同士の信頼をどうすれば築けるのでしょうか?
一つの方法は、すぐには明確にわからないかもしれませんが、チームメンバー同士が信頼構築をどのように避けているかに注目することです。 それを評価するために、信頼関係のあるチームの特徴を見ていきましょう。
・お互いに気兼ねなく、率直に問題提起できます。
・お互いに個人的なことを共有しています。調子が悪い日には、他のチームメンバーにそれを明かしています。他のチームメンバーにとってそれは、大きな負担ではありません。
・良い結果を出すためにお互いに議論できます。
・お互いのニーズに柔軟に対応できます。
信頼関係のあるチームの特徴がわかったところで、今度は信頼関係のないチームがどのように見えるか考えてみましょう。
・問題が起きたら、チームメンバーにではなく、あなたに個別に伝えにきます。
・閉鎖的であり、お互いのことをあまりよく知りません。大変な目にあっていても、気軽にそれを明かせません。だから、状況が悪化しても、誰もそれまでの経緯を把握していません。
・問題が提起されると、すぐに議論が打ち切られます。そのため、誰であっても最初に話した人が「勝つ」という状態になります。
・グループに確認することなく、主に自分のニーズについて考えています。
考えてみてください。同僚と直接顔を合わせるような職場で働いているとして、チームでランチに行くとしたら、会社の全員を連れて行くわけではありませんよね? チームだけで雑談をする時間と場所を持っているわけです。もし会社全体に自分たちが監視されていると感じていたら、心理的安全性の獲得は難しいでしょう。チームだけの時間と場所によって、心理的安全性が生まれます。この心理的安全性が信頼ある雰囲気を築くために重要です。
話し合うことで解決できるような大したことのない対立や問題が、 チーム内で持ち上がることがあります。もしチームメンバーがこういった対立や問題を公の場で話そうとすると、チームに大きな支障をきたしかねません。突然、無関係な他のグループの誰かや地位の高い誰かが、決断に影響を与えるために「介入」してくるかもしれません。
このような状況下では、グループ内で最も内気な人の意見を聞く機会を失ってしまうでしょう。私が今あなたに伝えられることは、内気な人というのは、見落としたくない鋭い観察力をしばしば持っているということです。しかもこの種のオープンな場での議論は、チームの包括感、 信頼感、そして自律性を阻害します。
もちろん、時と場所によっては、オープンな場で会話をすることもあります。私はオープンなコミュニケーションや書面での記録をすべてやめなさい、と言っているわけではありません。オープンな会話と、チームメンバーが少しリラックスできる場所とのバランスをとることが良い方法だと言いたいのです。個人的には、チームのためのプライベートチャットグループを作ることをお勧めします。すべての雑談やチャットをオープンにしたがる企業もたくさんありますが、私は多くのリモートチームをマネジメントしてきた経験から、チームが自分たちだけの場所を持つことが重要だと考えるようになりました。
チームチャットを始めたばかりの頃は、しばらくの間、話しているのは自分だけかもしれません。気まずい感じですね。しかし、すぐ終わります。約束します。前にも述べたように、あなたが先陣を切らなければなりません。私は、軽い感じで物ごとを始める傾向があります。たとえば、馬鹿らしいネットミームを使ったり、あちこちで「良い週末を! (Have a great weekend!)」と書き込んだり、チームの小さな勝利や個人の頑張りを称えたりします。しばらくすると、他のメンバーが追随し始めます。
皮肉なことに、このような外部からのイメージを保ち続けようとするほど、そのイメージは滑り落ちていくのです。なぜでしょうか? それは、マネジャーとして解決し続けている問題は、実のところ「あなた自身のもの」ではないからです。
あなたのチームは「私たち」です。組織内の序列でどれだけ地位が高かろうと、あなたはチームの原動力なのです。チームで何が起きようと、 それはあなたの責任です。チームについて語るときは、発言に自身を含めてください。
とはいえ、チームが何かで成功したときは、チームのメンバーを褒め、 あなた自身は除いてください。あなた自身を含めないことにより、チームがそれに値する評価を受けられます。自分を含めてしまうと、自尊心を高めるために話を誇張していると受け取られかねません(しかもそれにより、チームの働きへの評価が下がってしまうかもしれません)。
一例を示しましょう。
「彼らはスケジュールが非常にタイトだったにも関わらず、プロジェクトを成功に導いてくれました。プロジェクト全体を通して意欲的に取り組み、素晴らしい仕事ぶりでした」
しかしあなたには、プロジェクトの成功に向けて相応しいチームを組織する責任があります。だから、もしチームが何かで失敗したら、そのときの主語は「私」になります。
「私はこのスケジュールの厳しさを認識できておらず、チームの時間の優先付けを誤りました。みんなでもう一度集まって、計画を考え直す必要があります」
そこでは決して、「彼ら」と言ってはいけません。たとえば、次のようにです。
「彼らはタイトなスケジュールを守れませんでした。ただ期間内にプロジェクト完了できなかったのです」
最後の例で、責任をどのように人に押し付けているかわかったと思います。あまりにも頻繁に、窮地に立たされたマネジャーが責務から逃れるのを耳にしますが、本当はそういうときこそマネジャーは前に立ち、 自らの責任である問題に取り掛からなくてはいけません。
私が伝えたいことがわかってきたかと思います。リーダーシップチームについて話すときも、主語は「私たち」です。同僚や上司と会議で決定したことに対してあなた自身が賛成でない場合でも、「彼らが(自分は賛成ではない何かを) 決めたんです」とは言ってはいけません。あなたはそこにいたのですから、理想論的に言えばあなたもその決定に加わっていたはずです。だから、そのチームについて話すときに「私たち」と表現することは、自分がマネジメントしているチームの場合と同様に重要なのです。なぜでしょうか? なぜなら、マネジャーとしての私たちの仕事は、バランスと明確さをできる限り作り出すよう努めることだからです。
マネジャーが、リーダーシップチームに属していないかのように話したり、そこで起こったことに対して責任を取らないように話したりしたら、チームは混乱し方向性を見失うでしょう。あなたの直属の部下は、 リーダーシップのレベルで変化をもたらすことはできません。だから、 もしあなたがリーダーシップチームへの関与を放棄したら、自分のチームを落胆させ、会社全体への信頼を失わせかねません。他のチームやその取り組みを悪者扱いする風潮が生まれ、それは(すでに述べたとおり) 非常に不健全です。
「私たち」と言うことは、自分のチームに対して、自分が一端を担っているリーダーシップの説明責任を負うことであり、それがあるべき姿です。もしリーダーらが向かっている方向性に対して自分のチームメンバーらが懸念を持っているなら、橋渡し役として、コミュニケーションをとり次のステップへと主導することもあなたの責任です。
しかし、特定の状況では、リーダーシップチームの決定を守ることが適切ではないかもしれません。もしリーダーシップチームの決定が、あなたの核となる価値観に極めて反する場合、それは断固として戦うべきときです。このような状況は、理想としては稀であるべきです。頻繁にあるならば、残念ながら他の組織での職を探す必要があるかもしれません。
フロー状態のもう一つの素晴らしい利点は、不満への耐性が高まることです。このことは、情熱に関する議論でよく耳にする懸念に回帰します。つまり、困難な状況になったときに、どうやってそれを続けるか、 ということです。フロー状態に入ると、通常であれば不安や負担と知覚されるような障壁が別の形で認識され、その課題を乗り越えるための意志が強まります。
しかし、あなたはリーダーです。チームの文化の強さは、チーム内で許容される最悪の行動によってのみ決まります。声を上げるのはあなたの仕事なのです。
私が最初にしたことは、人が学びの最中に持つべき価値観について考えることでした。その結果、「好奇心」と「謙虚さ」にたどり着きました。この価値観を備えているように見える人に徐々に気づき始め、できるだけ彼らと知り合うようにしました。私たちは、未来について熱く語り合うようになりました。みんなで協力し始め、この価値観を表すプロジェクトを集めて推進し始めました。また、みんなで、なぜ進化が必要なのかを力説し始めました。
大きなスピーチや小さなチームミーティング、1on1の場でも行いました。TPM(テクニカルプロジェクトマネジメント)、PM(プロダクトマネジメント)、戦略的パートナーや顧客の中から仲間を見つけました。そして文書を作成して、フィードバックを得ました。
ここではまとめて書いていますが、これは難しく、何カ月にもわたる一貫した取り組みを要することを理解しておくことが重要です。自信が打ち砕かれたときもありました。諦めて、グループに現状をただ維持してもらえればいいと思ったこともあります。そんな時、チームの他のメンバーが仕事の目的を思い出させてくれたことには、とても感謝しています。
時間が経つにつれて、否定的な意見を持つ中核グループを抜きにして、 みんなが進化的なゴールを提示し始めました。それは小さく、ほとんど気づかれないようなものでした。しかし次第に、多くの人がこれらの概念を中心に将来のデザインを構成し始めました。最終的に私が組織の研究開発部門を提案したときには、みんなが賛同してくれました。これはトップダウンによる組織再編ではなく、私たちみんなが実行していた全体戦略にちょうど合致していたように思えました。
私たちは、プロダクト、OKR、さらには組織構造まで変更しました。 しかし、何よりも最初に起こったのは文化の変化だったのです。
また、チームが同じ目標に向かって一緒に働けるように、周りの人とフィードバックを受けたり与えたりする必要があります。誰も独立して働いているわけではありません。私たちはみんな、職場環境を、幸せで、 敬意がある、生産的な場所にするために、お互いのコミュニケーションスタイルに少しずつ合わせなければなりません。
フィードバックに関して言えば、自分自身のエゴの中に小さく自然な葛藤が存在します。私たちは学び、成長したいと考えていますが、一方で受け入れられたいとも思っているのです。より成長するために、 を絞り、自分自身に挑戦するためにはフィードバックが必要となります。 しかし、このフィードバックを本当に受け入れるためには、自分を守るように設計された体内のシステムを回避しなければなりません。これがやっかいです。
私の提案は、すべてのフィードバックのやりとりをできるだけパートナーシップのように扱うことです。完璧で誤りのない立場からアドバイスをするのではありません。むしろ、共通の目標に向かって一緒に働く二人が、パートナーシップを健全で生産的にするための一貫としてフィードバックを行うのです。「ねえ、歯に何か挟まっているよ」というような感じです。このような信頼できる注意喚起であり、相手が耳を傾ける必要があるかもしれないが、その人自身が気づけないことを伝えるのです。このプロセスでは、あなたが相手を判断しているわけではないことを伝えるようにしてください。 -
-
-
Posted by ブクログ
原題は『Engineering Management for the Rest of Us』である。
本書は専門領域としてのエンジニアリングに触れることはほとんどなく、一般的なマネジメントについて記述している。邦題に含まれている「エンジニアリングが好きな私たちのための」という表現は対象を狭めているようにも捉えられるが、逆説的にむしろそのような人に手に取ってもらいたいという気持ちの表れなのではないかという気がする。
平易な文章で書かれていて、読みやすい。
全体的に同意できないような内容の記述はない。啓蒙的な内容も多く網羅的ではないが、著者がマネジメントにおいて大切だと思う要点はよくまとまっている。
評価や採用など本書ではカバーされない領域があり、それらの話題については他の情報源に頼る必要がある。本書は、例外的でない日常のマネジメントのサポートとなるような助言を提供する書籍と言える。
本書は大きく4つのパート、自分のチーム/コラボレーション/チームが最高の仕事をできるように支援する/自分の仕事、に分かれている。
Part1「自分のチーム」では、チームを作るためのツールが紹介される。
> リーダーとしてあなたが最初に行動しないといけません。あなたは自ら信頼に値することを示すと同時に、他人を信頼することも必要です。これは、チーム内では弱みを見せても大丈夫なことを意味します。（chapter3 信頼と弱さ 弱みのモデリング）
> 企業は複数のグループから構成されますが、それらのグループは共に働いてこそ成功できるのであり、いかなる犠牲を払っても自分たちのグループだけ守ればいいという訳ではありません。...組織の健全性は、互いに協力して働けることにかかっています。（chapter4 自分のチームは「彼ら」ではなく「私たち」 より広範囲の組織）
Part2「コラボレーション」では、マネージャーとメンバーのコミュニケーションの仕方や効果について書かれる。
> あなたは、ただ現状を維持するためにこの役割にいるのではありません。組織（文化、プロセス、システム、プロダクト）を改善するためにそこにいるのです。...「物ごとをより良くすること。それが仕事なのです」（chapter10 チェンジマネジメント）
> フィードバックは、二人の顔の重要な議論や、ドキュメントへのコメント、また情報を伝えるときに人の顔に現れるほとんど気づかないような感情として現れます。（chapter11 フィードバックの与え方）
> ミーティングの目的の一部は、議論そのものなのです。（chapter13 良いミーティング）
> 「自分の好みをよく理解しておかなければなりません。なぜなら、何をしようとも、あなたは間違っていると誰かに言われるからです」（chapter14 対立のマネジメント）
Part3, Part4 では、チームや自分の仕事に対する優先度付けやエンジニアリングに近しい領域の話題について触れられている。 -
-
Posted by ブクログ
エンジニアによるドキュメント作成（ユーザーガイド、運用手順書、APIリファレンス、設計書など）について、架空のプロジェクトを例にして順を追って解説されている。
ドキュメントの種類・書き方・考え方の概念的な方法論や教訓が、ある程度高いカバー率で網羅されている。基礎的な知識・原理を身につけることで長い目で見て役に立つ知識を得られるものであり、これを読んですぐにそのままマネすれば良い、というものではないと思う。
実務でエンジニアがやりがちな失敗や「考えが及んでいなかった」というケースへの言及が多く、経験者としては耳が痛いし、それゆえに学びが多い。
文量が多くて時間がかかりそうだったため、全体的に見出し・太文字を中心に飛ばし読みをしたが、それでも十分に学びがあった。もし見出しだけで著者の意図や根拠を読み取れない・納得できない場合には本文を熟読すると良いだろう。また後で時間があるときに本文の熟読をしたいという読後感を持った。
42ページ
ユーザージャーニーマップ
→作り手はユーザー体験を考慮しないことが多い。あるいは考慮しようとしているのに考慮できていないということも多い。利用者や読み手に優しくないモノを生産しがちなので、この問題に対する答えのひとつがユーザージャーニーマップなのだと思う（本文を読んでいないのでこの解釈で合っているかは自信がない）。
56ページ
・できるだけガイド単体で読めるようにしましょう。ユーザーが必要とするすべての行動を1つのページにまとめておきましょう。
→これは本当にそのとおりで、ほかのページと行ったり来たりすることの煩雑さを考慮するべき。できればリンクを飛ばずに単体で完結するほうが最も望ましいが、構成次第ではやむをえずリンクをつけて往復させることもあるだろう。また、たとえばWikiとファイルサーバのように異なるプラットフォーム上で往復させることも避けるべき。リンクを貼ること自体はやっても構わないが、リンク先の概要・サマリー表やスクリーンショットなどをリンク元に貼るようにしたい。
83ページ
最も重要な情報を冒頭で述べる
→これも本当にその通りで、できていない人が多い。仕事においては「起承転結」よりもPREP法（POINT→REASON→EXAMPLE→POINT）を使いましょう。ストック的なドキュメントだけでなく、メールやメッセージでも結論を先に書きましょう。長々と何行も文を書くときに下から2行目くらいに結論を書くのはやめてほしい。
177ページ
タイトルと最初の段落の両方に、ドキュメントの目的と、読み手が達成できることを書いておきましょう。
→やるべき。考えなしに作ると省きがちだが、読み手はまずそのドキュメントの位置付けを理解してから内容を読まないと正しく解釈できないので、位置付けや意義を早い段階でわかるように作るべき。 -
-
Posted by ブクログ
第1章：導入
第2章：組織 機能する組織を作り、維持する
6～8人のエンジニアを支援：マネージャー
4人未満のエンジニアを支援：テックリードマネージャー
4人～6人のマネージャを支援：マネージャーのマネージャー
1~2人の小さなチームはチームではない
→抽象化に漏れが多い 個人で動く場合と見分けがつかない
成長するチームの4段階
1.遅延 ハードワークだが進捗が乏しい 士気低い
→新しく人を増やす
2.現状維持 重要な仕事はできている 士気は多少あり
→現在の仕事を減らす
3.負債返済中 技術的負債の解消に取り組み、その恩恵を受けている
→ゆとりをもたせる
4.革新 士気が高い ユーザーニーズを満たす仕事にとりくむ
→さらにゆとりで、イノベーションに取り組む
チームファーストに徹する
チームが結束するには時間がかかる。解体すると結束が初期化される
エンジニアが増えるほど問題も増える
サクセッションプランニング（後継者育成計画）を進める
同僚が何をしているかを理解する
ギャップを埋める
第3章：ツール 変化をマネジメントする手法
システム思考、メトリクス、ビジョン
・システム思考
プロダクトマネジメント：
エンジニアリングとプロダクトそれぞれでリーダシップが必要
プロダクト開発
問題の発見→問題の選定→解決策の検証→実行→問題の発見→・・・
戦略とビジョンの合意形成
戦略：具体的に、実用的
ビジョン：方向性を示す、願望的に長期視点
文書化し、内容を検証する、定期的に更新、シンプルに記載
メトリクス
ゴールの定義
ターゲット：到達場所
ベースライン：現在の場所
トレンド：現在の速度
タイムフレーム：変化の期間
マイグレーション
技術的負債の唯一のスケーラブルな解決法
リーダシップの発揮
モデル：プロセスを繰り返し試行錯誤する
ドキュメント：採用方法を説明する
シェア：ドキュメント送付、プラクティス採用を義務付け
タイムマネジメント
四半期ごとの時間の振り返り
短期的な品質よりも長期的な成功を優先する
学習コミュニティをつくる
簡単なプレゼン、長い議論
経験豊富な人の参加を促す
事前学習を任意にする
少人数のグループに分割する
全体のグループに学びを共有する
第4章：アプローチ 問題解決につなげる
ポリシーに従う、例外に従わない
よいポリシーは制約をもたらす
優先順位の確定
すべての要求を文書化する
タスク選択するための原則を作る
原則に基づいて選択したサブセットを共有する
マネジメントの哲学
強い関係性はどんな問題にも勝る
プロセスよりも人が大事
困難なことからすぐ取り込む
エンジニアリングマネージャーが行き詰まる
部下または上司だけをマネジメントする
関係構築に時間を費やさない、または使いすぎる
局所最適化する
第5章：文化 継続的に取り組んで育成する
機会とメンバーシップを提供する
ルーブリック（評価指標）を持ちいる
定期的に開催されるイベントを設ける
ヒーローを作らない、頑張りすぎをやめる
第6章：キャリア 同僚と自分に対して責任を持つ
キャリアナラティブを紡ぐ
去年の出来事の振り返り
第7章：さらに先へ
他書籍の紹介など -
Posted by ブクログ
ネタバレ概要:
本書は、システム・エンジニアリング分野におけるチーム・マネジメントの教科書として位置づけられる。ヌケモレなく、マネジメントに必要な基本が淡々と述べられており、筆者の主観的な経験談や感情的な記述はほぼ見られない。そのため、良くも悪くも読み物としての面白さは期待できないが、マネジメントの基礎を体系的に学ぶには最適であると言える。逆に言えば、本書の内容がピンと来ないと感じるマネージャーは、その職を再考すべきかもしれない。それほどまでに、基本に忠実で網羅性の高い内容となっている。
特に印象に残った点:
エンジニアのマネジメントも、結局はマネジメントの基本の組み合わせであるという原則は改めて認識させられた。しかし、実務においては、エンジニア一人ひとりの多様性を無視することはできない。それぞれの個性やスキル、興味範囲だけでなく、仕事へのスタンスも大きく異なる。特に、私の経験が異業種のメンバーが混在するプロジェクトが多かったため、その多様性の大きさを痛感している。ソフトウェア開発の現場では、ある程度の役割分担やスキル構成の前提があるかもしれないが、多様なバックグラウンドを持つメンバーをまとめ、成果を出すためには、より個別に向き合う必要性を強く感じる。
本書の内容と自身の経験:
本書に書かれている原則は理解できるものの、それを多様なメンバーに対してどのように適用し、具体的な成果に繋げるのか、という点に大きな課題を感じている。教科書的な知識だけでは解決できない、個々のメンバーとのコミュニケーションや動機づけ、そしてチーム全体の方向性を示すリーダーシップが不可欠であると改めて認識した。特に、異業種のメンバーとの協働経験が多い私にとっては、本書のような普遍的な原則だけでは対応しきれない場面が多いと感じる。
今後の課題と疑問点:
本書で得られた知識を、実際の多様なチームでどのように活かしていくかが今後の大きな課題である。理想としては、本書のような普遍的な原則をベースにしつつ、個々のメンバーの特性や状況に応じた柔軟な対応策が示されていると良かった。具体的なモデルやソリューションが提示されていれば、より実践的な学びになっただろう。
深層心理の反映:
本書の網羅性と客観性は評価しつつも、どこか物足りなさを感じているのは、私がマネジメントにおいて、単なる知識や原則だけでなく、もっと人間味あふれる、泥臭い部分も重要だと考えているからかもしれない。また、教科書的な正しさを求める一方で、現実の複雑さや多様性に対する理解も深く、そのギャップに苦悩している様子が伺える。過去の異業種混合チームでの成功体験から、多様性を活かすマネジメントへの強い願望がある一方で、具体的な方法論を見出せていない現状への焦りも感じられる。普遍的な知識だけでは解決できない問題に対し、具体的な解決策を強く求めている。 -
-
-