shimapapa.io

.NET,VB,C#,AzureなどMS関連中心の技術ブログ

【読了】「任せるリーダーが実践している1on1の技術」

今回はこちらの書籍の感想文。

任せるリーダーが実践している 1on1の技術

任せるリーダーが実践している 1on1の技術

 

 

前置き


会社でメンターとして他のメンバーの目標設定支援を任されていて、定期的にメンバーと1on1を行なっている。

 

以前に「yahooの1on1」という書籍を読んだが、改めて1on1について深堀したくて手に取った。

ヤフーの1on1―――部下を成長させるコミュニケーションの技法

ヤフーの1on1―――部下を成長させるコミュニケーションの技法

 

 

この書籍の面白かった点は、1on1についてが「アドラー心理学」の理論を用いながら語られていくところだった。

 

要約

第1章から、まずは1on1とはなにか。人事考課面談とは何が違うのか。期待される効果などについてから始まる。

期待される効果についての1つには会社と社員のエンゲージメントがある。

1 on 1により期待される効果として、最初に挙げられるのは会社と社員のエンゲージメント(絆・愛着)です。グーグル社が実施した高業績チームの秘訣を探るプロジェクト・アリストテレスで明らかになったことが一つあります。それは、高業績に最も大きく影響を与える因子が「心理的安全性: Psychological Safety」であったことです。「誰もが均等に話す機会があること」「自由に意見が言える」「否定されない」、これらの条件があることで初めてチームの業績が高まるのです。グーグル社では、心理的安全性を確保するという目的で 1 on 1を5つの重要マネジメント施策の一つとして位置づけています。

 

そして1on1の目的は2つのサイクル、すなわちデビッド・コルブが示した「経験学習サイクル」と、ダニエル・キム教授が提唱した「組織の成功循環モデル」のサイクルを回すこと、と述べられている。

人は知識から学ぶのではありません。経験から知識が導き出された時に初めて深い学びが起きるのです。経験を伴わない知識は机上の空論です。コルブが示したこのサイクルは始点を「経験」に置いているところがユニークであり、かつ実務的です。

2つ目のサイクルは、ダニエル・キム教授が提唱した「組織の成功循環モデル」です。このサイクルは最初の項目が「関係の質」から始まる点が極めてユニークです。

「組織の成功循環モデル」では、「関係の質」の向上によって「結果の質」も向上する。つまり、組織としてのパフォーマンスが向上する、ということ。

最初に「結果」を求めるのではなく「関係の質」を向上させるのです。すると、「思考の質」が上がり、「行動の質」が上がって「結果の質」も上がるのです。

そこから、「関係の質」と「心理的安全性」が業績につながる理論がアドラー心理学を用いて説明される。

人間が繰り返す行動や感情には、原因もあるが、それは影響因子にすぎず、決定因子は個人の自己決定にあり、そこには常に目的がある、と考えるのが目的論です。

アドラー心理学はこの目的論をさらに押し進めて、万人に共通する究極目標を明らかにしました。それは、社会への「所属」( Belonging)です。

人の間と書いて人間と読みます。人は社会の網の目に組み込まれ、共同体の中で初めて人間になる。ですから、人間は所属できない、という危機を感じると、頭の中でサイレンが鳴ります。「生命の危機だ!」と過剰に反応してしまうのです。

1on1を行うことによって、「所属」を実感できるようになった社員はパフォーマンスを最大化できるようになる。

上司が部下に対して行う「傾聴」「勇気づけ」などにより、 1 on 1で日頃から「所属」を実感できている部下は、過剰な劣等感を感じる必要もなければ、過剰に高い目標を掲げる必要もなく、現実的で常識的な目標を掲げます。ですから、落ち着いて課題に対処できるわけです。  すると、「心理的安全性」が実現され、さらに「関係の質」が高まり、結果の質も高まるというキム教授のサイクルが回り出します。

1on1では以下の5つのスキルが必要になる。

  1. 傾聴
  2. 勇気づけ
  3. 質問
  4. フィードバック
  5. 結末を体験させる

「結末を体験させる」では、お弁当を忘れた子供に対してお母さんが結末を体験させて教育する例が挙げられる。

失敗した時には叱ったり、助けてあげるだけでなく結末を体験させて以下のような質問をして本人に考えさせる。

あなたは『そのことから何を学んだのかしら?』『明日からどうしようと思うの?』」

もちろん、この技法は上司と部下が 1 on 1で用いる場合にも有効です。ポイントは、部下の体験に対して先取りして説教や教訓を垂れないことです。そうではなく、質問をするのです。「その体験から何を学びましたか?」「明日からどうしようと思いますか?」これがポイントとなるのです。   

続けてスキルを土台とした5つのメソッドが紹介される

そのメソッドとは、「傾聴」「経験学習サイクル」「課題の分離」「協力と目標の一致」「解決志向ブリーフセラピー」の5つです。

その中でも「課題の分離」はアドラー心理学の書籍でも読者に衝撃を与えた概念。

具体的には、対人関係のスタートにおいて課題の所在が誰にあるのか、を明確にすることです。それにより、教育する立場の人間が相手の課題に土足で踏み込む、などの過干渉やお節介を予防し、教育者と教育される者との間に良好な対人関係の土台を築くのです。

「課題の分離」は、好きな人に嫌われていると感じた時にも有用。

相手が私を好きになろうが嫌いになろうが、構わず気にしないことが大切です。人はあらゆる人から好かれることは不可能です。 100人相手がいたとすれば、通常は 2割程度の人が大なり小なり私に好感を持ち、 6割程度の人が中立的、残りの 2割程度の人が大なり小なり私を嫌うことでしょう。それは私に限らず誰もがそうなのです。であるならば、嫌われることを過度におそれたり、私に好感を持たない相手の感情を変えようと無駄な努力をしたりしないことが大切。自然体で本来の自分の人生の課題に向き合っていけばいいのです。

「協力と目標の一致」では、アドラー心理学でも提唱されている「距離感」について述べられている。

この辺り、1on1や目標設定は「やらされ感」が出ないようにするための距離感を掴むためにも重要な考え方だと感じた。

アドラー心理学が提唱する「協力」では距離感を大切にします。つまり距離が近すぎる「過干渉」ではなく、距離が遠すぎる「放任」でもなく、適切な距離感となる「協力」をするのです。

戦わず、服従せず」というものです。協力関係において「戦わず」とは、怒りなどのマイナス感情と共に指示・命令をして力任せに相手を動かそうとしない、ということを意味します。そして「服従せず」とは、共同体に迷惑をかける不適切な行動を取る相手、もしくは、やるべきことをやらない相手に対してあきらめず、関係を絶ちきらない、ということです。では、どうすればいいのでしょうか。「協力と目標の一致」を行うのです。

協力と目標の一致におけるスタートラインは課題の分離です(前項で既述)。その上で、お節介を焼きたくなる気持ちを抑えてから、次のステップへと進みます。  次にすべきは傾聴です。

部下は上司の協力を拒否しましたが、自ら責任を持って課題に立ち向かうことにより、「体験を通じた学習」のチャンスを手にするのです。「結末を体験させる」の具体的内容については第 4章で既にお伝えした通りです。

上司が部下に協力を申し出て、部下がそれに一回 NOと返事をした場合の続きです。その次のステップは「注文を取る」の続編となります。つまり、開いた質問である「何かお手伝いできることはありますか」に対して注文が出にくそうだった場合に、それをサポートする意味でより具体的な選択肢を提示して、もう一度だけ注文を取る、というステップへと進むのです。

上司が部下の課題をすべて肩代わりしてはいけない、ということです。つまり、「過干渉」にならず、「放任」し過ぎない適切な「協力」の距離感を取ること。

スキル、メソッドは土台となるマインドがあって初めて有効になる。

それは以下の5つ。

  1. 尊敬
  2. 信頼
  3. 協力
  4. 目標の一致
  5. 共同体感覚

 

「尊敬」とは「二度見」すること。

「尊敬」を英語で書くと Respectです。これを分解すると、 Re(再び) + Spect(見る)となることがわかります。つまり、尊敬とは「二度見する」くらい重く見る、軽くは見ていない、という意味が語源のようです。

 私たちが「不適切である」と相手をジャッジしてしまう行為のほとんどは、単なる失敗です。まずは、ここを「二度見」してみるのです。一度目の見方では、音を立ててドアを閉めた相手の行為を不適切である、と決めつけます。しかし、もう一度、見直してみる。相手の行為は不適切な行為ではなく、失敗である、と二度見することが尊敬の一つ目です。

行為と人格は分離して相手を見る。

「あらゆる行為の目的は所属である」。先に学んだアドラー心理学の考え方です。これに照らせば、その人は「不注意な人、うっかり屋さん」として所属したい、と子どもの頃に決意しており、不注意さを繰り返し子どもの頃から磨き、クセにしてきた人なのです。

ここで、気をつけるべきことは行為と人格を分離することです。つまり不適切な行為 ≠不適切な人格、と分けて見るのです。

「不適切な行為をしている(ように見える)人もその目的は所属であり、善である。あらゆる人の人格は善である」。

自分の行為と人格を分離して、自分を尊敬する。

「私は不適切な行為をしてしまった。しかし、目的は所属であり善である。私の人格は善である」、このように自分を尊敬するのです。すると、他者を尊敬できるようになります。

信頼と信用は異なる。

仕事では信頼と信用を分けて考える。

信用というのは過去の実績と担保という裏付けがあって初めて相手を信じること。つまり条件付きで信じることなのです。  信頼 Trustはその逆です。たとえ担保がなくても、過去の実績がなくても、無条件で相手を信じること。いわば白紙委任状。それが信頼です。

日常業務は信用で運営し、 1 on 1は信頼で運営する。

人に優しく(信頼)、仕事に厳しく(信用)。   1 on 1では、人に優しく(信頼)を優先させるくらいでちょうど良いでしょう。そして人事考課や就業規則、業績管理制度、インセンティブ制度などのルールを淡々と運用することで、仕事への厳しさを担保する。

そして最後にアドラー心理学でも重要な「共同体感覚」について述べられる。

「共同体感覚」は、アドラー心理学における治療と教育の目標であり「導きの星」です。  共同体感覚は、心の正常さのバロメーターです。アドラーは著作の中で「共同体感覚以外の基準を認めることはできない」とまで言い切りました。  共同体感覚とは「他者を助け、喜ばせることを喜ぶ心。協力する能力」のことです。そして、それが目に見えてわかるのは、競合的態度か、協力的態度か、ということです。

自分たちは主観的な思いこみの世界=自分の価値観の中で生きている。なので1on1では相手の価値観を肯定的な配慮で受け止めることが重要。

私たちは客観的な事実の世界に生きているのではなく、主観的な思い込みの世界に生きています。同じ街に住んで、同じ人に相対していても、まったく異なる印象を持つのです。ですから、私たちの意見や価値観を絶対的なものや客観的なもの、と思ってはいけません。主観から逃れることはできないのです。

 

まとめ

振り返ってみても、この書籍の秀逸な点はアドラー心理学を用いて1on1の効果を語っているところだと思う。

自分たちが求めている根源なところはやはり「所属」、共同体感覚を実感出来ていること。

共同体感覚を得られていることによって、人は自分の力を最大限発揮できるようになる。

ただし、人間の意識を変えるのは難しいので、組織では1on1などの「仕組み」を用いて、意識を変えていく場を作ることが重要なのだと感じた。

【読了】「本気でゴールを達成したい人とチームのためのOKR」

今回はこちらの書籍の感想文。

本気でゴールを達成したい人とチームのための  OKR

本気でゴールを達成したい人とチームのための OKR

 

 前置き

OKRは以前にも以下の書籍を読んだことはあったが、会社で目標設定に関する取り組みが新しいフェーズに入ることもあり、手に取った。

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法

OKR(オーケーアール) シリコンバレー式で大胆な目標を達成する方法

 

 要約

第1章〜2章では、そもそもなぜ「目的」が必要なのかを、「組織」と「集団」の違いなどが挙げられながら述べられている。

共通の目的」を、個人で達成するのではなく、他の人と「協力して達成を目指す」ことで「組織」となります。

組織の共通の目的に共感できないのであれば、組織にいる理由はない、と言えるほど「目的|」は重要。

たとえ、「自分の目的」と「組織の目的」が合わないと感じるような場合でも、まずはトライしてみましょう。そのうえで、「組織の目的」にどうしても共感できない場合は、別の組織に行くというのが、個人にとっても、組織にとってもプラスになるでしょう。そもそも、組織は共通の目的を達成するために複数の人が集まったものです。共通の目的に共感できないのであれば、同じ組織にいる理由はありません。

そして、組織の力とは個々人の力を合わせたもの、個人のパフォーマンスを最大化させるのにも目的が重要になってくる。

個人の力の単純合計に、相乗効果(プラスの場合もあれば、マイナスの場合もあります)を加えたものが、組織力

個人の力は最大出力と発揮率の掛け算となります。

成長につながるのは、今の状態では背伸びしてやっと届くか届かないかのところにある目標で、「ストレッチゾーン」と呼ばれます。背伸びして挑戦することになるので目標に対して不安やストレスを感じることになり、快適で居心地がいいゾーンではありません。

組織における個人の力を最大限発揮させるには、自律を促し、組織の透明性を保つ事、心理的安全性の確保が重要。

人は「自律」してこそ、初めて持っている力を最大限発揮することができます。上司の指示命令に基づき言われたことを言われたとおりに行っているだけの状態は、自律ではありません。自分で計画し、自分で自分を律しながら行動することが、自律です。

同じ情報に触れる機会を持つことで、自律のために必要な方向性や役割を正しく理解することができます。組織の透明性を高めることは、組織や他のメンバーへの信頼を高めることにもつながります。社長が何を考えているのか、隣の部署がどんなことをしているのか知らない状態でお互いを信頼し合うことは不可能です。

第4章以降でOKRについて語られていくことになりますが、その前にいったん第3章で、なぜ目標設定がうまくいかないのかという問題点の指摘から、変えるべきは「意識」という話が展開される。

うまくいかない例として、目標が組織内で共有されていなかったり…

たとえば、同じ仕事をしている Aさんと Bさんがいたとします。そして、 Aさんは新たな取り組みに挑戦し、目標を高く 200と設定し、一方 Bさんは現状の延長線上で保守的に 100と目標設定しました。この 2人の実績が、 Aさん 150、 Bさん 120となった場合、どのような評価がなされるでしょうか?多くの場合、 Aさんは達成率 75%で目標未達成と低く評価され、 Bさんは達成率 120%で高く評価されます。高い目標を掲げ、それに挑戦し、高い実績を出した Aさんの方が Bさんより低く評価されてしまうのです。このような仕組みのもとでは、誰も高い目標を立てて挑戦しようとは思わなくなるでしょう。

以下のように挑戦が評価されない仕組み例が挙げられている。

たとえば、同じ仕事をしている Aさんと Bさんがいたとします。そして、 Aさんは新たな取り組みに挑戦し、目標を高く 200と設定し、一方 Bさんは現状の延長線上で保守的に 100と目標設定しました。この 2人の実績が、 Aさん 150、 Bさん 120となった場合、どのような評価がなされるでしょうか?多くの場合、 Aさんは達成率 75%で目標未達成と低く評価され、 Bさんは達成率 120%で高く評価されます。高い目標を掲げ、それに挑戦し、高い実績を出した Aさんの方が Bさんより低く評価されてしまうのです。このような仕組みのもとでは、誰も高い目標を立てて挑戦しようとは思わなくなるでしょう。

そんな状況を変えるにはまず「意識を変えること」。意識を変えるのは難しいので、「仕組み」を変えること、作ることが重要。

自分の意識を変えることも難しいですが、もっと難しいのが他人の意識を変えることです。家族、友人の意識を変えることはもちろん、会社において複数のメンバーの意識を変えるのはとても難しいことです。

メンバーの意識を変えようとして悩む前に、仕組みを作ることで解決できることも知っておくべきです。多くの場合そのほうが効率的かつ効果的です。さらに、リーダー個人の資質に依存しないため、再現性、持続性も高いと言えます。

そこで「仕組み」として提唱されるのがOKR。

再び前述の組織における透明性の重要性、目的、目標が共有されない問題点が指摘され、OKRではそれらが解決する機能かあることが述べられる。

先が見通せない夜道を歩くとき、不安を感じ、すれ違う人のことを警戒してしまうものです。同じように、組織内で何が起きているのか見えていなかったり、すぐ側にいる人が何を考えているのかが分からないとき、不安や不信が芽生えてきます。

従業員との信頼関係を構築するためには、受注がどれほどあり、それが計画からどれくらい遅れているのか、また利益がどれくらい出て、それがどのように使われているのかなど、会社の置かれている現況について、幹部だけではなく末端の社員にも、よく見えるような「ガラス張りの経営」でなければなりません。

 

以降、

第5章ではOKRの始め方、

第6章ではOKRの運用、

第7章ではOKR運用実例インタビューという構成になっている。

まとめ

この読了記事を変えて改めて思ったのは、自分はOKRに魅力を感じたのはやはり透明性と情報共有が成されていく点なのかなと感じた。

企業組織における目標設定と、目標に対する行動は個々人の組織内での評価へとつながっていくことになる。

評価で納得感を得るためには、組織における共通の目的=ミッション、ビジョン、バリューが共有され、その目的、目標に対してどんな行動をとった人が評価されるべきかが、メンバー内で共通認識できている必要がある。

以下の一文はそれらを明確に示している。

自分が「成果」に対してどれだけ貢献しているか、周りの「成果」はどんな状態かを知り、どうやったら「成果」があがるか考え続けることで、なれ合いを生まない組織になります。そのような組織は、妥協案を探るような議論をすることなく、成果をあげるために、ときに衝突しながらも、最適な案を生み出していけるでしょう。

【C# / ASP.NET WebForm】HttpRequestBase を継承しMock クラスを作成し、HttpRequest をテストする

前置き

現場の案件で、外部APIやDB接続が絡んだ少々複雑な判定でCookie を作成するという処理を実装することになり、
対象の処理でユニットテストを作成しておきたくなりました。

Cookie の作成や、作成した値を検証するには当然ですがHttpRequestHttpResponseインスタンスが必要ですが、
これらのクラスのインスタンスユニットテストで生成するのは困難(ほぼ不可能のはず)です。

そこで、ASP.NET ではHttpRequestWrapperというクラスが実装されています。
HttpRequestWrapperHttpRequestBaseという抽象クラスから派生されています。
HttpRequestBaseHttpRequestと同じプロパティ、関数を保有したクラスです。
対象となる処理の実装ではHttpRequestBaseを使用し、
HttpRequestWrapperHttpRequestをラップしたインスタンスを使用することにします。
これらはHttpResponseでも同様です。
文章だとややこしいので、サンプルコードを実装してみました。

Controller(HttpRequestBase, HttpResponseBaseを使用する処理)

public class IndexController
    {
        public IndexController()
        {

        }

        public void createCookie(HttpRequestBase request, HttpResponseBase response)
        {
            if (request.QueryString == null)
            {
                throw new ArgumentNullException();
            }
            string value = request.QueryString["hoge"];

            var cookie = new HttpCookie("hoge");
            cookie.Value = "hoge" + value;
            response.Cookies.Add(cookie);
        }

    }

aspx.cs

 public partial class Index : System.Web.UI.Page
    {
        private readonly IndexController  _controller = new IndexController();

        protected void Page_Load(object sender, EventArgs e)
        {
            _controller.createCookie(new HttpRequestWrapper(Request),
                                                     new HttpResponseWrapper(Response));
        }
    }

そして、ユニットテストコードでは以下のようにHttpRequestBaseから派生したMockクラスを作成し、
テストで必要となるプロパティや関数をOverrideして実装します。

Mockクラス

 public class HttpRequestMock : HttpRequestBase
        {
            private readonly NameValueCollection _queryString;
            public HttpRequestMock(NameValueCollection queryString)
            {
                _queryString = queryString;
            }

            public override NameValueCollection QueryString => _queryString;
        }

        public class HttpResponseMock : HttpResponseBase
        {
            private readonly HttpCookieCollection _cookies = new HttpCookieCollection();
            public override HttpCookieCollection Cookies => _cookies;
        }

テストコード

[TestMethod]
        public void createCookieNormalCase()
        {
            // Arrange
            var requestMock = new HttpRequestMock(new NameValueCollection() { { "hoge", "12345" } });
            var responseMock = new HttpResponseMock();
            var sut = new IndexController();

            // Act
            sut.createCookie(requestMock, responseMock);

            // Assert
            Assert.AreEqual("hoge12345", responseMock.Cookies["hoge"].Value);
        }

サンプルコード

今回の記事で作成したサンプルコードをGitHubにアップしました。

github.com

【Azure】「az webapp up」コマンドでエラー「The scale operation is not allowed for this subscription in this region. Try selecting different region or scale option.」

Microsoft Leanの以下の演習内で引っかかった箇所があったのでメモ。

docs.microsoft.com

AppService内に.NET Coreアプリをデプロイするコマンド

az webapp up \
    --resource-group Learn-XXXX-XXXX-... \
    --sku F1 \
    --name $WEBAPPNAME

上記を実行すると、以下のエラーが発生。

The scale operation is not allowed for this subscription in this region. 
Try selecting different region or scale option.

どうも、デフォルトで設定されているリージョンではデプロイできない権限設定になっているようだったので、
--locationオプションで許可されていそうなリージョンを設定してみてコマンド実行。

az webapp up \
    --resource-group Learn-XXXX-XXXX-... \
    --sku F1 \
    --name $WEBAPPNAME \
    --location eastus

無事デプロイされました。

【VB.NET】「区分オブジェクト」のようなクラスを作れないか試行錯誤

前回の「区分オブジェクト」に関する投稿に引き続いて関連した投稿を。

rikupapa-shima.hatenablog.com

列挙型の区分ごとにプロパティを持たせる事ができないかなと思い、
実装してみたのが以下のような抽象クラスと具象クラスを使う形式。

Public MustInherit Class Perfume

    Public ReadOnly Property myFavorite As Boolean
    Sub New(myFavorite As Boolean)
        Me.myFavorite = myFavorite
    End Sub

    Public Class Nocchi
        Inherits Perfume

        Sub New(myFavorite As Boolean)
            MyBase.New(myFavorite)
        End Sub

    End Class

    Public Class Kashiyuka
        Inherits Perfume

        Sub New(myFavorite As Boolean)
            MyBase.New(myFavorite)
        End Sub

    End Class

    Public Class AaChan
        Inherits Perfume

        Sub New(myFavorite As Boolean)
            MyBase.New(myFavorite)
        End Sub

    End Class

End Class

クラス名からインスタンスを生成するにはActivator.CreateInstance
区分の判定はGetTypeで列挙型と同様に行えます。

Module Module1

    Sub Main()

        Dim myPerfume = createMyFavoriteMember("Nocchi")

        Select Case myPerfume.GetType()
            Case GetType(Perfume.Nocchi)
                ' ...
            Case GetType(Perfume.Kashiyuka)
                ' ...
            Case GetType(Perfume.AaChan)
                ' ...
        End Select
    End Sub

    Private Function createMyFavoriteMember(memberName As String) As Perfume
        Return CType(Activator.CreateInstance(
                                    Type.GetType("Enumeration.Perfume+" & memberName),
                                    New Object() {True}), Perfume)
    End Function
End Module

実行すると以下のようになります。

f:id:rikupapa-shima:20191010231631p:plain

うーん・・・具象クラスのコンストラクタを全部書く必要があるのと、
Activator.CreateInstanceでType名をセットする部分があまりイケてない感じがする・・・

参考

aerodynamik.hatenablog.com

Git For Windowsでメッセージ「Warning: 'C:\ProgramData/Git/config' has a dubious owner: 'XXXXX'.」が表示された

背景

現場で新しいPC(離任された方が使用していたPCを引き継ぎ)に変更になったので、Git For Windowsをインストールした。
Git For Windowsのバージョンは「2.23.0」。

現象

Gitコマンドを実行したところ、以下のようなエラーメッセージが表示された。

Warning: 'C:\ProgramData/Git/config' has a dubious owner: '(XXXXX)'.
For security reasons, it is therefore ignored.
To fix this, please transfer ownership to an admininstrator.

自分の場合、「XXXXX」がこのPCを前に使用していた方のユーザーアカウントだった。
現場のポリシーとして、PCの使用者を変更する場合は、クリーンインストールせず引き継ぎ。
よって、今回はGit For Windowsは前任者の方がインストールしていた状態だったところに、
上書きインストールしたような形になった。

解決策

メッセージの指示通り、「C:\ProgramData/Git/config」のプロパティから所有者を変更しようとしたが上手く行かず、
configファイルを自作して「C:\ProgramData/Git/config」に配置した。

参考

stackoverflow.com

VB.NETでJavaの「列挙型クラス」を模倣して「区分オブジェクト」を作る

増田本、読了しました。
Amazonのレビュー見ると結構賛否両論のようですが、
オブジェクト指向設計ドメイン駆動設計の基礎固めとして最適では、と自分は感じました。

「CHAPTER2 場合分けのロジックを整理する > Javaの列挙型を使えばもっとかんたん」を読んで、
おお、JavaEnumの値ごとにコンストラクタを付与したりできるのか・・・便利・・・
と恥ずかしながら初めて知りました。

.NETでも似たようなことをできないなかな、と探したら以下のようなMS公式リファレンスがありました。

docs.microsoft.com

上記と増田本のサンプルコードを真似してVB.NETで書いてみたのが以下のコード
(YenをValueObject化するのは端折ってIntegerにしてます)

本体

Public Interface Fee
    Function yen() As Integer
    Function label() As String
End Interface

Public Class AdultFee
    Implements Fee

    Public Function yen() As Integer Implements Fee.yen
        Return 100
    End Function

    Public Function label() As String Implements Fee.label
        Return "大人"
    End Function
End Class

Public Class ChildFee
    Implements Fee

    Public Function yen() As Integer Implements Fee.yen
        Return 50
    End Function

    Public Function label() As String Implements Fee.label
        Return "子供"
    End Function
End Class

Public MustInherit Class Enumeration
    Public Shared Function valueOf(Of T)(typeName As String) As T
        Return CType(GetType(T).GetField(typeName, Reflection.BindingFlags.Public Or Reflection.BindingFlags.Static Or Reflection.BindingFlags.DeclaredOnly).GetValue(Nothing), T)
    End Function
End Class

Public Class FeeType
    Inherits Enumeration

    Public Shared Adult As New FeeType(New AdultFee)
    Public Shared Child As New FeeType(New ChildFee)

    Private ReadOnly fee As Fee

    Sub New(fee As Fee)
        Me.fee = fee
    End Sub

    Public Function yen() As Integer
        Return fee.yen
    End Function

    Public Function label() As String
        Return fee.label
    End Function

End Class

クライアント側

Module Module1

    Sub Main()

        Dim feeForAdult = feeFor("Adult")
        Dim feeForChild = feeFor("Child")

    End Sub

    Public Function feeFor(feeTypeName As String) As Integer
        Dim theFeeType = FeeType.valueOf(Of FeeType)(feeTypeName)
        Return theFeeType.yen
    End Function

End Module

実行してみましょう。

f:id:rikupapa-shima:20190927230703p:plain

値取れてますね。
良い感じですが、リフレクションで変数名を指定するのはちょっと怖いです。以上。