以前から度々話題に上げている
「項目移送おじさん」ネタですが、ちょっと前に、こんな依頼があったので、
今回は、これを始点にして、
記事を書いてみようと思います。
上記を読んで頂くと解る通り、VBで訳の解らないラムダ式の使い方をする輩が居て、「単純に迷惑なんだけど...。」という話なんですが、こう言うのは昔からよくある事で、
- 「メソッド引数に、配列に纏めれば
イイような仮引数が20個並べてあった。」とか、
- 「意味の異なる変数を配列に纏める際に、
int型のインデクサを使用している。」とか、
検収時にそう言ったクソコードに遭遇して悶絶した経験をお持ちの管理者の方も多数いらっしゃるんじゃないか？と思いますが、こう言った事もあり、「コーディング規約」的なモノが制定されて、その中で、サラッと「ラムダ式禁止」なんて言う事項が追加されたりする事があります。
私の場合、既に聞き分けのあるオッサンとして出来上がっているので、仮に「ラムダ式禁止」と言われたら、プロジェクト特性を考慮して納得したりする訳ですが、「項目移送おじさん」系の中でも、「テクノロジ方面に尖りたいと思っている脱初心者したぐらいのプログラマ」はコレに反発してきたりします（"ラムダ式 禁止" などでググっても観測できます）。
この理由ですが、特に、前述の様な芸風のプログラマは、「プログラム言語の新機能や、新しいアプリケーション・フレームワーク」を理解して使用できるようにする位しか自分に価値を付加する戦略が無いので、「プログラム言語の新機能や、新しいアプリケーション・フレームワーク」を使える現場を求めるんだろうと思います。
しかし、そもそも、その付加価値、敷居が低くて差別化にならないから、実際は大して給料は増えないので、下手な技術を習得するよりは、従事しているプロジェクトの業務方面の勉強を優先した方がイイ気もします。また、以下の反響を見ても解るように、
みんなクソコードは嫌いだし、実際ダメージがあるのは、ソレを保守する組織や、資産として保有する組織なので、前述のようなクソコードが混入しないような方法を提案出来ないのに、変に突っ張っていると、現場に呼んで貰えなくなると思うので、そんな下らない拘りは、サッサと捨てた方がイイと思います。
ソレか、ゲームの「ナントカ縛り。」みたいに考えればイイんじゃないですかね？「ラムダ式無し縛り」≒「喰いタン後付け無し」。似たようなものじゃないか？と。...そう言う事を考えながら、以下のツイートを見ると、
コレは、単純に、
- 付加価値＆差別化の戦略の欠如。
- 単に自分のスキルセット内にある技術推し。
- 業務知識の軽視 ≒ 現場を転々としている。
等の能力不足が、技術の好き嫌い
に表れているダケな気がしますね。
...と言うのが、SI界隈の常識（？）ですが、そのSI界隈にも、昨今、徐々に徐々に変化が訪れて来ている気がしていて、そもそもパッケージやSaaSでないとペイライン乗らない時代が来ている気がするんですよね。
以前から「汎用性がある基幹系をスクラッチ開発するのは日本ぐらいだ。」みたいなことは言われてきましたが、以前、
コチラにも書きましたが、ソロソロ、本格的に、ベンダ・ユーザの資金や人材などのリソース面に問題が出て来て、これから、パッケージ適用やSaaS導入によってスクラッチ開発が更に減り、ベンダ・ユーザの比率も国際標準に近づいていくんじゃないか？なんて思ったりもしています。
私も、長々、メガステップ級の大規模な開発プロジェクトをサポートする開発基盤の開発をしてきましたが、これは2017年度から方向転換をしています。というのは
前回に言及した通りですが、大規模SIも最近、ソロソロ、胸を張って出来なくなってきたと言う感じがして来ています。
その根底には、
- × : ステップ生産性と言う
単位工数あたりのステップ数の低さ。 - ○ : オーダーメイドならではの
１ステップあたりが稼ぎ出す金額の低さ。
という問題がある気がしています。
翌々考えると、この問題をクリアするため、パッケージ適用やSaaS導入を進めていくには、マーケティング ＆ プロモーションの強化などをして行かないといけないので、既存のSI事業とは結構、仕事の仕方が変わってくる筈で、この変化に対応できるか？と言うような話もあると思います。
（もちろん、パッケージとは名ばかりで、カスタマイズが多数入り、ほぼ受注ツールとしてしか機能していないSIテンプレートや、ソレをIaaS上にSIしただけでSaaSと称する様な芸風も厳しくなって行くんじゃないでしょうか？）
しかし、この変化に対応できないと、ソロソロ「令和」に突入する時代に、「採れる予算で受注して、スコープ外も拝承して、下々を使い倒す。」みたいな「昭和」スタイルを継続しなくてはなりませんが、こう言う事をしていると、「働き方改革関連法による2019年4月労働基準法の改正」後には「1年以上10年以下の懲役または20 - 300万円の罰金」に処せられてしまいます。
（...と言う事もあり、社会インフラの大規模プロジェクトだったらAS-ISでOK。なんて言う、簡単な話でも無いでしょう）。
スクラッチ開発がパッケージ適用やSaaS導入に切り替わって行く中で、昨今、ソレらをインテグレートするタメには、
「フロントエンドからバックエンドまでの全スタック」＆ 「システム連携させるための認証/認可、システム間連携プロトコル」を抑えることが重要になってきている。
...と、個人的には思っています。また、PaaSは、まだ微妙な気がしますが、SaaSの隆盛と共に、その基盤部分もIaaS → PaaSへと、徐々にシフトして行くんじゃないか？と思っています。確かに、こう書くと、生産性が上がっていく可能性を感じますよね ⁉
最後に、話を戻すと、パッケージやSaaS開発が中心となって、スクラッチ開発と比べて生産性が上がるとすると、従来のスクラッチ開発の「項目移送おじさん」より高いスキルを持つ人材を集めることが出来るようになるので、「コーディング規約」に「ラムダ式禁止」と書かれることはなくなるんじゃないか？と思います。
ただ、ソレに達しない「項目移送おじさん」の仕事は、確実に無くなって行くモノと思われます。...と言う事で、マーケット・インするには、自身のスキルをどう変えていったら良いのか？を、「ラムダ式 禁止」云々、言わずに、常々、考えて行く必要があるという事だと思います。
Open COBOL Solution WG
「項目移送おじさん」に続く「λおじさん」が「λ」利用禁止になる理由
「コードから無駄な冗長性が減っているが、理解に必要な背景知識がそれ以上に増えるので、コードの理解に必要な総情報量はむしろ増えてしまっている、というパターン。」上記では似たような事を言いたかったのだケド、この表現はイイですね。