はじめに

いまさらですが、ラムダ式に正面から取り組んでみることにしました。
そう考えるのに至った理由とこれからどう取り組んでいくかをまとめてみます。
ラムダ式そのものの説明はありません。

対象

.NET プログラマ
デリゲートや匿名メソッドと聞いてどのようなものかをイメージできる人
私と同じようにラムダ式に消極的な人／消極的だった人

これまでラムダ式に消極的だった理由

匿名メソッドで事足りるから。
- デリゲートとして使うなら匿名メソッドでよい。
- 式木として使う場合のみラムダ式にすればよい。が、そのような場面はほとんどありませんでした。
書きやすいが読みにくいと感じていたから。
- Visual Studio のインテリセンスのおかげで書きやすいと思います。
- 対して、インテリセンスがないと読みにくいとも思います。ラムダ式の表現に慣れていないからというのもありますが、慣れてしまえば読みやすいのでしょうか？これは今でも疑問です。
- 省略表現のパターンが複数あるため、ゆらぎが発生する。
自社にとっては難しすぎるのではないかと考えていたから。
- 私が所属する企業はいわゆる「SIer」で、プロジェクトにかかわる多くのプログラマはプログラミングスキルがあまり高くありません。
- 10~20年前に開発されたソースコード（ルーツを辿るとVisualBasic）の焼き直しのプロジェクトが多く、そもそもデリゲートや匿名メソッドを活用しているプロダクト・プログラマ自体が少ないです。
- 今でも VB.net のプロダクトが比較的多く、残念なことにその多くが option strict off（型の明示的な宣言を強制しない）です。option strict off であってもある程度はコンパイラによる型チェックが行われるようではありますが、そのようなプロダクトではラムダ式の利用はリスクが高いと思います。
LINQ to SQL に対する拒否反応（笑）

ラムダ式に取り組んでみようと考えた理由

記事やサンプルで目にすることが多くなったから。
- オブジェクト初期化など一見ラムダ式に見えないものなども含めると、かなりの浸透度。
- むしろ匿名メソッドを見かけなくなった。
デリゲートの活用は避けられないから。
- 最近の開発スタイルの流れからもデリゲートは益々活用されていくものと考えられます。自社では「デリゲート？」な人が多く、組織としても取り組んでいく必要があります。
問題が起きる前に自社内に展開したいと考えたから。
- ネットから拾ってきたコードサンプルを内容を理解しないままコピペするプログラマが一定数います（ラムダ式に限ったことではありませんが）。ラムダ式が記事やサンプルで使用されることが多くなった分、コピペの対象になる可能性も高くなり、野放しにしているとカオスな状態に陥ることが予想されます。
- そうなる前に何かしらのコーディングルール・基準を設けたほうがよく、そのためには自分も理解しておく必要があると考えます。

どのように取り組んでいくか

まず自分が匿名メソッドからラムダ式へ移行する。
- 自然とラムダ式が頭に浮かぶように。
- 使ってみることで周知の仕方も明確になっていくと考えられます。
関数型プログラミング（と呼んでもいいのでしょうか）の周知にラムダ式を用いる。
- （幸いなことに？）自社では匿名メソッドを活用したプログラミングは広まっていません。匿名メソッドではなくラムダ式を用いて説明するようにします。
- ただ、匿名メソッドを利用していた人であれば「あれがこのように簡略化されている」という理解から進めていけばよいのですが、そうでない人には簡単でないような気もします。ラムダ式の文法だけを教えても活用できるようになるとは限らないため、うまく両方を教える必要があると考えています。
コーディングルール・基準を検討する。
- がちがちの原理主義にするつもりはありませんが、多くのプログラマが入れ替わりながら長期間にわたって開発・改修を行うことが多い SIer としては必要なことだと思います。
- 例えば、
  - 内容や型が分かりやすい引数名を用いたり、引数の型を明示的に記述する。(u, l, h) => (u + l) * h / 2 のようなコードでは引数が何か、何をしているのかを考えるためのロスが大きくなります。ちなみにこれは台形の面積を算出する式です。(upperWidth, lowerWidth, height) => (upperWidth + lowerWidth) * height / 2 と記述されていれば、わかりやすくなります。ラムダ式に限ったことではありませんが、ラムダ式では短い変数名を用いているコードが比較的多いと感じます。
  - 過度なメソッドチェーンは推奨しない。基幹業務系システムでは仕様変更が多く、せっかく綺麗につなげたチェーンが途切れる仕様変更もそれなりの頻度で発生します。メンテナンスのしやすさを重視したいところです。
それでもやっぱり LINQ to SQL は積極的には利用しません。

ラムダ式に関するリンク

【Qiita】
【LINQの前に】ラムダ式？デリゲート？Func？な人へのまとめ【知ってほしい】
はじめての LINQ
続・はじめての LINQ
私はこうしてLINQ・ラムダ式を理解できた

【++C++; // 未確認飛行 C】ラムダ式
 【++C++; // 未確認飛行 C】式木
 【Bug Catharsis】C#で今風メタプログラミング。Expression Tree(式木)に慣れ親しもう。

おわりに

私はこの記事が Qiita デビューです。ブログサイト（mxProject）を利用していますが、技術系の記事が集まる Qiita を始めてみることにしました。単純な比較はできませんが、エディタはこちらのほうが書きやすいですね。
匿名メソッドからラムダ式への流れもそうですが、開発者を取り巻く環境はどんどん変化しています。今までのやり方で不足はなくても新しいやり方をやらないのは機会ロスであって、やってみた上で何を取り入れるかを考えればよいと思います。「やらない」と思っているのは自分だけで実際は「やれない」ということにならないようにしていきたいと思います。