hidekatsu-izuno 日々の記録

プログラミング、経済政策など伊津野英克が興味あることについて適当に語ります(旧サイト:A.R.N [日記])

工数見積りの海を彷徨う・征服

過去、何度かIPAの資料に基づき工数見積りを計算するためのエントリを書いた。今回のエントリは、その暫定解決編という位置づけとなる。

hidekatsu-izuno.hatenablog.com

hidekatsu-izuno.hatenablog.com

hidekatsu-izuno.hatenablog.com

前回までは、ロバスト回帰を使って分析していたのだが、実際に使ってみると単一基準ではリスクがどれくらいあるのかわかりにくく、やや使いづらいところがあった。

先日、いつものようにネットサーフィンをしていたところ「分位点回帰」という手法があるのを見つけた。分位点と言えば、1/4(第一四分位数)、1/2(=中央値)、3/4(第三四分位数)など、サンプルを相対的な位置関係を元に判断する手法であり、ロバスト回帰同様、偏りのあるデータに対しても頑健に動作することが期待できる。

さらに、ロバスト回帰に比べ、実際のプロジェクトがどれくらい収まっているのか範囲が明確になるため、リスクの範囲も想像しやすいというメリットがある。

なお、今回は R ではなく Python を使っている(前回記事参照)。ロバスト回帰のペナルティ関数が異なるため、データは同じでも多少数値に差が出ていることをお断りしておく(イマイチどの手法が良いのかはよくわかっていない)。

結果は次のグラフを見ていただくのがわかりやすい。

f:id:hidekatsu-izuno:20170723175138p:plain

X軸が機能数(1.5✕画面数+1.0✕帳票数+0.7✕バッチ数)、Y軸が人時工数となる。散布図が原データ、各直線は OLS が単回帰、RMG がロバスト回帰、QR が各パーセンタイルでの分位点回帰の結果を表している。

一見してわかるように、ロバスト回帰と50パーセンタイルでの分位点回帰の結果はほぼ同じ結果を導き出している。そういう意味で、前回までの方法論もさほどおかしくな数字ではないという確信が得られたのはありがたい。

ロバスト回帰と分位点回帰(50%)での工数算出式は次の通り。

ロバスト回帰:工数[開発5工程/人時]=142.05×画面数+94.70×帳票数+66.29×バッチ数

分位点回帰(50%):工数[開発5工程/人時]=136.36×画面数+90.91×帳票数+63.64×バッチ数

Python での統計処理メモ

たまに時間があると統計を身に着けようと試みているのだけど、データサイエンティストというわけでは当然ないので、すぐにやり方を忘れてしまう。というわけで今日のエントリは完全にメモ書きです。はい。

環境

Python は Anaconda を使ってインストールするのが一番簡単なようだ。

実行は Anaconda をインストールするといっしょに入る Jupyter Notebook という REPL ツールを使うのが一般的な模様。たしかにグラフがその場で表示できるのは便利。

  • 実行は「Shift+Enter」
  • ヘルプは「h」
  • 行挿入は「a」、行削除は「dd」。ちょっと vi っぽい。

データ操作

データ操作は pandas を使うのが一般的らしい。numpy は直接使わず、pandas 経由で使うのが今風なようだ。使ってみるとたしかに便利。ライブラリで SQL 的な操作ができる。

データの読み込み

# インポート
import pandas as pd

# TSV の読み込み(1行目は列名)
data = pd.read_table("パス")

# CSV の読み込み(1行目は列名)
data = pd.read_csv("パス")

# NaN (= Not a Number) を 0 に置換
data2 = data.fillna(value = 0)

# 列の選択 (SQL で言えば SELECT)
data3 = data["列1"]
data3 = data[["列1", "列2"]]

# 行の選択
data4 = data.iloc[3]

# 抽出(SQL で言えば WHERE)
data5 = data[data["列1"] > 0]

# ソート (SQL で言えば ORDER BY)
data6 = data.sort_values(by=["列1", "列2"])

統計処理

統計処理はいくつか方法があるけど、R 相当のことをやりたい場合は、statsmodels を使うのが良いようだ。statsmodels には python っぽい通常の API と R っぽい formula API の2種類があるが、今のところ、通常の API を使ってみている。

# インポート
import statsmodels.api as sm

# 単回帰
result = sm.OLS(data["従属変数列"], data["説明変数列"]).fit()

# 重回帰
result = sm.OLS(data["従属変数列"], data[["説明変数列1", "説明変数列2"]]).fit()

# ロバスト回帰
result = sm.RLM(data["従属変数列"], data["説明変数列"]).fit()

# 分位点回帰
import statsmodels.regression.quantile_regression as smqr
result = smqr.QuantReg(data["従属変数列"], data["説明変数列"]).fit(q=0.5)

# 統計サマリー情報の表示
result.summary()

# 説明変数に対する予測値
result.fittedvalues

グラフの表示

最近のブログを読むと seaborn というライブラリを使うのが流行りみたいなのだけれど、自動で統計処理までやってくれる系のライブラリらしく、自前で計算した数値列をグラフ表示したい場合は従来通り matplotlib を使うのが良いようだ。

# インポート
import matplotlib.pyplot as plt

# グラフを描画
plt.plot(data["説明変数列"], result.fittedvalues)

# 散布図を描画(o で丸記号を表示と言う意味になるらしい)
plt.plot(data["説明変数列"], data["従属変数列"], "o")

# グラフを表示
plt.show()

# グラフのクリア
plt.clf()

調べたところ、pandas にも plot 機能があるようだ。単なるラッパーのようではあるけど、こちらを使ったほうが便利かもしれない。

gdata = pd.DataFrame({"x": data["説明変数列"], "y":data["従属変数列"], "p": result.fittedvalues })

# scatter で散布図を描画
ax = gdata.plot.scatter(x = 'x', y = 'y')

# ax でグラフを重ねることができる
gdata.plot.line(x = 'x', y = 'p', ax = ax)

モチベーションを上げるために本当に必要だったこと

今日紹介するのは、「マネジャーの最も大切な仕事――95%の人が見過ごす「小さな進捗」の力」という本だ。普通、ブログで本を紹介する場合、素晴らしいのでみんな読んでほしいという思いで書かれるものだが、残念ながらこの本は400ページ近くある大著にも関わらず、数ページくらいしか有意義なことが書かれていないので購入はまったくおすすめできない。

マネジャーの最も大切な仕事――95%の人が見過ごす「小さな進捗」の力

マネジャーの最も大切な仕事――95%の人が見過ごす「小さな進捗」の力

 

一番の問題は、当たり前のことが延々と書かれているところだ。当たり前のことは、誰もがわかっていながら実践するのが難しいから皆困っているのであって、気付いたくらいで問題が解決するわけがない。そんなに簡単に意識改革できるのなら、自己啓発本の何冊か読むだけで解決するだろう。

とはいえ、ありとあらゆるページが無内容というわけではない(だからこそ、こうしてブログにエントリを書いているわけだ)。

この本の主張は、多くの上司は、部下のモチベーションを上げるには、給料を上げたり、褒めたり、評価したり、といったことが重要であると思い込んでいるがそれは違う、という点にある。昇給や昇進ではあまりモチベーションが上がらないことについては類書でも多く言及されており、実のところあまり目新しさはないのだが、褒めたり評価することすらも最も重要というわけではない、というのは確かに発見だとは思う。

さて、著者らが発見した「モチベーションを上げるために本当に必要だったこと」とは何だったのだろうか。それは「進捗する」ことだ。ようはタスクをこなして進めていくということそのものがモチベーションをもたらしているようなのだ。

著者らの気付きは日報分析から得られたものだが、その応用として RPG などでよく見かける「おつかい」システムが取り挙げられている。一時期、「おつかい」はその単純さ故に批判にさらされてきたが、今に至るまで「おつかい」要素はイベント駆動ゲームの根幹を成すものであるし、カード収集なども「おつかい」の一種とみなせるかもしれない。たしかに人々は実際に何の利益もないムダな時間をおつかいゲームに喜々として注ぎ込んでいるようである。

しばらく前から「ゲーミング」という仕事にゲーム性を持ち込むことで、楽しく仕事を進めようという考えが出てきているが、「おつかい」の重要性はそれよりも本質的なことのように思える。

例えば、TODOリストは仕事をする上で非常に効果的とされている。しかし多くの場合、その理由としては、作業が整理できる、重要性の低いタスクを頭から追い出すで精神的負荷を下げるといった効果が強調される。しかし、進捗が明示化されることで達成感をもたらすというモチベーション面での効果が一番重要だった、ということも考えられる。この本の主張は小さな気付きではあるが、とても重要なヒントが含まれているのかもしれない。

「会社を立て直す仕事」に見るV字回復の秘密

一介のサラリーマンにとって「経営」というのは神秘に満ちたキーワードだ。なんといっても、どうすればうまくいくのかまったくわからない。優れた経営者の多くは、しばしば神格化され、彼らのどういう資質が会社の成功をもたらしたのかは才能というベールの向こう側にある。

以前紹介した「なぜビジネス書は間違うのか」によれば、多くのビジネス書に書かれる経営者の資質というものはハロー(後光)効果によりかさ上げされ、実際にはほとんど説明することができないようだ。

ジョブズ孫正義といった伝説的なカリスマは天才的すぎてその手法を一般化するのは難しい。それだけではなく、うまく時代に乗ったという強運によるところもある。なかなか普遍性のある教訓を見出すのは難しい。

それに対し、今回紹介する「会社を立て直す仕事」は、ビジネス自体が衰退期に差し掛かり、放っておけば遠からず潰れてしまうであろう企業の再建を果たした著者が、その手法について解説するというなかなかに稀有な本となっている。

 著者は、MSXや月刊ASCIIなど日本のパソコン黎明期を支えた アスキー(現在は、KADOKAWAに吸収)や、繊維や化粧品で有名なカネボウ(現在は、化粧品事業を分離しトリニティ・インベストメントに事業継承)に再建のため代表取締役として投資ファンドから送り込まれた人物。

著者自身が述べるように、カリスマ経営の成功は個別要因が強すぎてなかなかに一般性を持つ方法論を見出すのは難しい。しかし、衰退しつつある企業に外様の経営者という組み合わせなら、その手法の有効性は比較的明確だろう。

本書に書かれている内容はいずれも実践的であるが、その中には理屈から考えても正しいように思われる部分も多い。 個人的にどこかで使えそうだと思った部分を抜き出したのが以下の部分だ。いずれも、再建というキーワードを超えビジネス一般に有効な考え方ではないかと思う。

再建は通常「コスト削減による収益改善」によって成される

これは考えてみれば当たり前のことだ。再建が必要な会社というのは、概ね企業内部の問題ではなく、外部のビジネス環境の変化の影響を受けうまく行かなくなった状況が多いだろう。外部すなわち売上は下がることはあっても上がることは考えにくい。コストを削減することで収益を改善する以外の選択肢はあまりない。

もちろん、新しいビジネスを創造することで生き残るという道も考えることはできる。しかし、イノベーションの常識から言って儲かるビジネスを産み出すのはそもそも難しい。それだけでなく、育つにも時間がかかる(例えば、Cookpad は上場まで12年かかっている)。衰退するまでの間に新たなビジネスの目が育っているならともかく、すでに衰退した状況から始めるのでは遅すぎる。

「コスト削減=人員削減」ではない

会社の再建というと一番最初に思いつくのは人員整理だ。しかし、著者はコスト減少のために人員整理をせず、企業体質の改善によって対応している。この本の中では述べられていないが「事実に基づいた経営」など経営学での研究によれば人員整理は会社の利益率を下げることが知られている。また、人員整理は優秀な社員の流出をもたらし、社内の志気を下げることになる。人員削減は原材料を間引きするのと同様に商品の品質を下げる行為に他ならない。再建どころか現状維持すら危うくなるかもしれない。

通常、企業は利益率が低くともビジネスを拡大し売上を増やすことは(損ではないので)良いことであると考える。しかし、ビジネスが縮小している状況ではそうではない。コスト削減したければ、単に利益率が低い仕事をやめるだけでいい。利益が増えれば、業務改善を行う人員や余裕を確保することができるし、会社の将来への不安も減り追加の融資も受けやすくなる。

再建は1~2年で達成する

1~2年という超短期で再建を達成できたからこそ大成功と考えがちだが、著者はそうではないと言う。再建は1~2年で成果を出さなければ達成できない。社員や銀行といった関係者が諦めることなく前向きに突き進むためには早期に「成功する」ということを印象づけなければならない。ビジネスの変更といった長期的な改善はたとえそれがいつの日かは利益に結びつくのだとしても、実現するところまで辿り着かない可能性の方が大きい。

前節で述べたように、利益が改善するとそれ以外の問題も解決する。成果は短期で出すことに注力する必要がある。

コスト削減はインパクトの大きいところから

小さいコストをいくら削ったところで影響は微々たるものだ。日本企業は(休憩中に電気を消すといった)小さな改善が大好きだが、著者の言うとおり会社のコスト体質をきちんと見極め一番効果が大きいところに注力するところが必要だろう。

会計制度にだって重要性の原則があるのに、細かい所にこだわりすぎるのはよいこととは言えないだろう。

見える化、情報共有に注力する

典型的な不振企業の傾向として、組織の各部門がばらばらで連携できていなかったり、問題が提起されても解決のプロセスが明確にならないことに触れられている。著者は、PDCAやガバナンス、危機感といったコンサル用語で説明しているのだが、個人的にはピンとこなかった。実際のところ、有効だったのはそれに付随する「見える化」や「情報共有」という行為そのものだったように見受けられる。

結局のところ、実際は危機的なのに危機感を持っていないのは、自分のやっているビジネスの現状について損益を正しく認識できていないからに他ならない。自分の仕事が儲かっていないということがきちんとフィードバックされれば人々は行動を変えることができる。しかも、本書の例のように末端の損益だけでなく、上から下まで全員が現状を理解すれば調整もスムーズになる。

システム開発でも、プロジェクト・マネージャーと現場の危機感に乖離が起こることはよくある。本書では中間管理職も経営会議に参加させるという方法が取られていたが、会議の様子をビデオでとって社員全体に共有するだけでもずいぶん違うのではと思う。

一方で、製品事業の収益責任を明確にすることは個人的にはあまり重要ではないのではと思う。プロジェクト運営でもそうなのだが、担当範囲を明確にすることが重要であって、責任はある意味どうでもいい。むしろ責任を持たせることで協力関係が崩れることも多々あるように思う。

説明責任の重視

これは再建そのものにどれだけ影響があったのかよくわからなかったが、説明責任を重視するというのはたしかに良い考えかもしれない。日本ではしばしば結果責任ばかりが重視されて説明責任が重視されない。著者がいうようにまかせたけれど失敗したのでクビでは誰にもメリットがない。きちんと説明し、上司に判断する材料を提供し、問題を逐次解決する方がよほど有意義だろう。

2017/7/11 追記

社内勉強会に流用するために作ったスライドを公開しました。

才能とは努力を継続できる能力のこと

ビジネス書のようなものはある意味「答えのない」内容が書かれている。とはいえ、何冊も読んでいくと、個々の本では明確になっていない事実が立体的になりあぶり出されてくるように感じる。ぼんやりとした状況を手探りで進んでいるが、その方向は皆同じといった感じに。

そうやって気付かされたことのひとつが「才能とは努力を継続できる能力」であるということだ。

昔からエジソンの「1%のひらめきと99%の努力」という言葉や「好きこそものの上手なれ」という格言があったりもしたけれど、結局のところそれが答えだったようだ。才能か、努力か、という二分法がそもそもの間違いの元のような気がする。

以下、根拠を挙げる。

前半のトピックと後半のトピックでは逆のことを言っているように思えるかもしれない。しかし、繋げて考えるとその矛盾を解消できる考え方がひとつあることに気付く。

努力をすれば誰でも能力が身につく可能性があるのに、実際には人はそうそう変われない。そしてそれは、自分の身体特性や嗜好性により、努力を傾け続けられなかったということに起因する。

もちろん、努力で苦手を克服した人の記事が目に入ることもある。しかし、それは珍しいから記事になるのだし、努力をできた時点でなんらかの嗜好性があったとも考えられる。

この結論は、人材育成というトピックに大きな疑問を投げかける。あえて教育を止める必要はないかもしれないが、教育を施すだけで人材が育っていくという発想は必ずしも適切ではないのかもしれない。会社の方向性と嗜好性があった人材を獲得したり、成果を上げられない人には嗜好性にあった仕事を割り当てる方がより現実的な対応なのかもしれない。

良い経営者の資質?

気が向いた時にだけ書くことにはしているのだけど、あまりにも更新がないのもなんなので、拾ったネタをメモがわりに書いておくことにしてみた。それがこの記事。

タイトルは「内部昇格より外部から来たCEOの方が優れている」とあるのだが、個人的にはこの結論は頂けない。重要なのは、外部/内部ではなく、その理由だろう。仮に、複数の会社の制度を知っていることこそが経営者の資質だというのであれば、このタイトルでもよいのかもしれないが、本文では少し違うことが書かれている。

優れたCEOの特徴として、就任後の最初2年間は、「戦略の見直し」と「コスト削減」を重視して行うようだ。また、優れたCEOは最初の2年間では組織改編、新しいビジネス・商品の開発、経営陣の改造などには、相対的に消極的だ。そもそもの戦略を見直し目指す方向を確かにし、コスト体質を刷新した上で、コストのかかる組織再編や新ビジネス・新商品の開発といった領域に手をつけるという優先順位の見極めが、一つの優れたCEOの条件のように考えられるだろう。

しばしば、政治の世界では、橋本徹のように革命的な根本改革を目指す人が出てきて、たいていの場合、悲劇に終わるものと相場は決まっている。それは経営者においても同じようだ。「事実に基づいた経営―なぜ「当たり前」ができないのか?」においても、リストラが会社の利益率を引き下げることが指摘されているが、この記事によれば組織改編、新しいビジネス・商品の開発、経営陣の入れ替えなどいかにもな根本療法もあまり良い手段ではないことになる。

「戦略の見直し」「コスト削減」と書かれるとわかりにくいが、ここで指摘されているのは「過去の経緯などサンクコスト無視して不採算事業を縮小せよ」という単純なことなのではないかと思う。外部から来たCEOの方が優秀な成果を上げがちなのは、サンクコストを無視できる可能性が高いから、なのかもしれない。

Kotlin の気に入ったところ、気に入らないところ

前から気になってはいたとはいえ、どうせ実務では使わないだろうしなぁ、と思っていたのだけど、「KotlinがAndroidの正式サポート言語に」というニュースがあり、これはまじめに使う意味があるという気になったのでここ一週間ばかし Kotlin を触ってみている。

人によってはAndroid でサポートされるプログラミング言語がひとつ増えただけじゃないか、と思うかもしれない。しかし、Kotlin だけでなく Swift、Rust、TypeScript と型推論、不変性、関数型、Null 安全性という同じような言語概念を持つ言語が研究レベルでなく仕事で使える形で出てきた今の状況は、まさに Java という GCオブジェクト指向を持った言語が仕事で使えるようになった時と同じようにも感じられる。

業務システム開発の次の言語としての Kotlin の可能性」という記事もあったけれど、今それが実現しつつあるのかもしれない。

正直、どの言語も似たり寄ったりなのでもう少し収斂してほしいところではあるけれども、各社の思惑とかJavaScriptやABI、既存ライブラリとの親和性などそれぞれ多少要件が違うので仕方ないところもある。

もはや懐かしい話になりつつあるけれども、Java も20年ほど前まではメモリ管理できない言語なんて使えない、オブジェクト指向なんて必要ない、起動が遅すぎて使い物にならないと否定される一方で先進的な言語として輝かしい存在だったと記憶している(当時、Java House ML などで活発な議論が繰り広げられていた)。

Java は古臭くスクリプト言語こそが最先端という風潮もしばらく前まではしばしば見られた光景だったけれど、業務アプリ分野に限れば COBOL に代わり Java の一人勝ちという状況が続いている*1スクリプト言語にはスクリプト言語の良さがあるけれども、セキュリティへの対応、(サーバー課金を安くするための)パフォーマンス、並列処理という昨今のコンテキストを考えれば、事前検証可能な(曖昧な言い方にはなるが)カッチリした言語が必要という認識が広まっていたように思う。

型推論の採用によりスクリプト言語のような簡潔な記述と厳密な型チェックを両立しつつ、不変性と関数型で並列処理に対応し、Null 安全性でよりチェックも進化させるという新しい言語群の特徴は、時代の変化に対応したものであり、ある種のイノベーションと呼ぶべきものだ。研究者が見れば、どの言語もあの言語のあの機能のパクリだ、と見えるかもしれないけれども、実際にはそうではない。この20年をかけて、この機能は有用だ、この機能は別のこの機能で代用できる、この機能はすごいけど複雑だからよくない、この言語概念は今なら開発者に受け入れられる、といった小さな実績の積み重ねが、今ようやく次世代言語という形で表に出てきたということだ。

閑話休題。Kotlin を触ってみて、オライリーに倣って、Good Parts / Bad Parts と言いたいところだけど、専門家でもないので、個人的に気に入ったところ、気に入らないところを書いておくに留める。

気に入ったところ

  • プロパティがある
  • 不変性が作りやすい。遅延評価もできる。
  • 関数型が普通に使える。継承できるし、JavaScript みたいに 関数にプロパティを生やすこともできる。
  • クロージャからローカル変数が更新できる(Java ができないだけという気もするけど)
  • デフォルト引数が指定できる。
  • 移譲による実装の再利用ができる。
  • 検査付き例外がない。今となっては不利益の方が大きいでしょ。どうしても必要なら Either 作ればよいだけだし。
  • Generics に不変、共変が指定できる(Java の総称型以後、C#Scala の経験から議論が収斂し、これが一番使いやすいというね、というコンセンサスが取られた機能のひとつな気がする。is とか async/await も同じ雰囲気を感じる)
  • 従来なら言語機能で実現していたものを、できるだけ通常機能で実現しようとしているところ。タプルとか try-with-resourcs とか synchronized とか。
  • スコープ関数が便利すぎる。
  • == でオブジェクトの比較ができる

気に入ったところは、やはり Java で困っていたところが多い気がする。プロパティや不変性は20年前のコンテキストでは全然重要だと思われていなかったので Java にないのは仕方ないところではあるけれども(JavaBeans も RAD ツールでの必要性から作られている)。

機能がありすぎて初学者は辛いだろうなぁー、とは思いながらも、欲しかった機能は大抵あるので個人的にはすごく満足している。正直、JavaGenerics/Lambda は使いづらすぎるので、Kotlin に移行する意味はあると思う。

気に入らないところ

  • JVM の制約を引きずってる。Array と List が共通のインターフェイスを持っていなかったりとか、ByteArray 型があったりとか。Unsigned 型がないのも同様(C言語からの移植にとても困る)。
  • Null はチェックできても配列のチェックはできない(言語仕様的には範囲外アクセスで null が返ってくれば整合性取れる気がするんだけど、実装的に java.lang.Character への変換が発生してパフォーマンスが落ちるとかの問題があるのかも)
  • 演算子の多重定義が拡張メソッドになっていてインターフェイスになってない。演算子が実装されてるか調べようがない。例えば、ArrayとList の両方に適用できる列挙メソッドを定義するには、一旦 iterator() を呼んで Iterator に変換する必要がある。
  • 不必要にキーワードが変わってる。例えば、static → companion、switch → when とか。trait を interface に戻したのは正しい判断だと思う。
  • 文字列のテンプレートが $ なのは失敗では。外で変換するのも見越して文字列内に${...}を書きたいケースは結構あると思うけどエスケープが必要となると結構困るのでは(例えば、シェルスクリプトの生成とか)。Swift の \(...) は既存のエスケープ文字を流用したという意味で慧眼だと思う。
  • vararg キーワードは微妙では。JavaJavaScript ですら ... で書けるのに。むしろ退化してるような。
  • 実装関連の機能はキーワードじゃなくてアノテーションにしてほしかった。例えば、infix とか const とか。趣味の問題ではあるんだけど。
  • Range に 1..10 みたいな文法が割り当てられている。数値のイテレーションってもはやそんなに重要な言語機能じゃないんだから range(1, 10) で良くない?
  • 関数とクロージャで文法に一貫性がない。この言語仕様なら全部 fun() {} or fun() = xxx とかで良かったんでは。短くするのが流行りというのはわからなくはないけど。
  • ruby みたく false あるいは null が偽という扱いにしてほしかった。
  • クラス変数の扱いが微妙。元々 Kotlin 的には static 不要という論らしい。拡張メソッドがあるから static メソッドいらないのは同意するけど、パッケージに変数やメソッド置けるからいらないでしょ、てのは納得感ない気が。実際 Int.MAX_VALUE は companion object として実装されているし。それに導入するなら static object という名前にしてほしかった。
  • スコープ関数便利だけど数が多すぎて使う時に混乱する。
  • 遅延評価周りはこなれていない印象。lateinit と  lazy() と Delegates.notNull() の使い分けが難しい。 
  • JVM版に dynamic class がない。まぁ、ほとんど使わないんだけどオプション用途だと欲しくなる。Java でオプション的なAPI作る時いつも悩むのよね。遅くていいので実装してほしい(JSON っぽく初期化できるとさらにうれしい)。
  • 気に入らないというほどではないんだけど、Union Type は欲しいかも。val value:(String | Number | Boolean) と書きたいケースはたまにある。すでに TypeScript では実装されているけど、JavaScript との相互変換を考えると必須機能なのかもという気もする。

JVM言語が発祥だったり、Swift とは生まれた時期の都合のあるので仕方ないところも多々あるんだけど。もしかすると、これからしばらくは Swift 同様、言語仕様の小幅な修正はあるかもしれない。

*1:個人的見解で言えば、今ようやく Java は古くなったのであって、スクリプト言語と対比して新旧を比較するのはあまり適当とは思えない。