noImplicitAnyの有効化は“未来への投資”
- ――noImplicitAnyを有効にしたときの状況はどうだったのでしょうか。
鈴木：これからnoImplicitAnyを有効にすることを決めたとき，
エラーの数は550もありました。正直， 途方もない数だなと思いました。もう少し型の重要性が浸透しているのではと思っていたのですが， 今と比べるとまだまだ浸透していなかったのですね。 そこで，
3～4名のエンジニアで一気にコードを修正し， エラーを減らしました。そのとき， およそ半分ほどにまでエラーを減らしましたが， そこで力尽きたというのが正直なところです。本当はそのまま一気にゼロまで修正できれば良かったのですが， 半分くらいやったところで 「ああ， もうこれは無理だ」 と思いました （苦笑） 
実際の修正で最も大変だったのは，
そのエラーを潰すことだけではなく， 修正した結果， 芋づる式に新たな問題が発覚することでした。anyはコンパイルエラーを抑制してくれる機構であり， any型を修正することにより， anyに頼っていたことで隠れていた別のコンパイルエラーが姿を現すことがあります。表面に出ているのは 「anyを使っていますよ」 というコンパイルエラー1つですが， そのanyによって隠蔽されていた内なるコンパイルエラーまで解消して， やっと数字上の1つのエラーを消したことになります。そのため， 1つのエラーであっても修正作業は重かったですね。 水牧：noImplicitAnyを有効にする前は，
そもそもanyに対する危機意識が低かったんです。そのため， どれだけ潜在的にanyがあるのかといったことは意識していませんでした。おそらくチームメンバーのほとんどがそうだったのではないかと思います。やっぱりnoImplicitAnyを有効にしないと， anyを意識せずにコードを書いてしまいますね。 ただanyが1箇所あると，
いろんなところがどんどんanyになっていきます。そのanyになる箇所は， 型の安全性が確保されない部分になってしまう， つまりバグの危険性が潜在的にあるということになってしまいます。それをnoImplicitAnyを有効にすることで， 個々のエンジニアが意識するようになったことは良かったと考えています。 - ――noImplicitAnyを有効にした後，
どのような変化があったのでしょうか。 鈴木：チームメンバーの考え方が変化し，
JavaScript的ではなく， TypeScript的な考え方に変わって， 最初から型安全なコードを書けるようになりました。 水牧：これから書く，
あるいは追加するなりリファクタリングするなりしたときに， バグを生む確率が減るという意味で， 型を付けることは未来への投資だと思います。なので， すぐにバグが減ったというよりも， これから先で生まれるかもしれなかったバグが減ったということがメリットだと思います。 鈴木：生産性の観点では，
noImplicitAnyを有効にし始めた当初は多少手戻りが発生していました。コードを書いたけれどもnoImplicitAnyでエラーが出るという状況です。それによって多少は生産性が落ちたかなと感じましたが， チームメンバーがTypeScriptの考え方に慣れるにつれて， 生産性のロスはほとんどなくなりました。今ではみんなが最初からnoImplicitAnyに適合したコードを書けるようになったので， 無効にしていたときと比べてコードを書く速度が落ちているということはないと思います。 水牧：コーディングスピードの観点で言えば，
型があるほうが確実に速く書けると感じています。しっかり型を書いていれば， IDEの補完でポンポンポンと書いていけるためで， その恩恵は大きいと感じています。
noImplicitAny有効化の経過
LINE証券の開発におけるこれからのチャレンジ
- ――型安全以外の部分で，
トラブル回避のために意識していることはありますか。 水牧：すごく基本的なことですが，
ロジックとUIの分離はやはりすごく重要だなと思っています。そこがしっかり分離されていると， リリースでバグが出たなどといったときの修正のしやすさがまったく違います。逆にロジックとUIがちゃんと分かれていないと， 見通しが悪くなり， バグが発生したときに原因がどこにあるのかが特定しづらくなってしまうため， しっかり分離することを意識しています。 鈴木：これも基本的なところですが，
もっとテストをしっかり書いていかなければならないと思っているところです。設計からテストが書きやすいコードにすることは， やはり大事なことだなと思います。 このテストにおいても，
型安全と同様に意識が重要です。テストがなくても動くものは動いてしまいますから， 意識がないと本当にテストのないものができてしまいかねません。 またテストが理由でチームメンバーが不快にならないことも重要です。たとえばプルリクエストを出してCIによってテストが実行されたとき，
コードに問題があるわけではないのにE2E （End to End） テストで失敗してしまうといったことが時折発生します。そうすると， E2Eテストはよく失敗するものだという意識がメンバーの中に芽生え， E2Eテストの重要性が低くなり， あまり重視されなくなったりテストが書かれなくなったりしまうということになりかねません。こういったことから， チームメンバーから信頼される仕組みにすることは重要だと痛感しています。 - ――今後チャレンジしたいことはありますか。
鈴木：我々のLINE証券というサービスの開発には，
ちょっとしたバグで大きな影響が発生する可能性があります。そのため， 何か新しい機能をリリースするといったことに対して， つねに高いリスクがつきまとうことになると感じています。そのリスクを下げるために， マイクロフロントエンドに取り組みたいと考えています。 1つのアプリに見えていても，
その内部では複数のアプリが個別に動作しているマイクロフロントエンドであれば， たとえば株の取引にかかわる部分などクリティカルなところには手を付けず， 別のところを新しくするといったことが可能になります。これによって新機能をリリースする上でのリスクを下げられるでしょう。こういった取り組みを今後進めていきたいですね。 水牧：今後やりたいのはコンポーネントの設計の見直しです。現状はデザインが多岐に渡っていて，
似たようなコンポーネントでもあまり共通化できていません。デザインに微妙な違いがあり， それをコードに落とし込むのが難しいため， 別のコンポーネントとして作るということがあるためです。そこで何らかの手法を使ってピュアなコンポーネントを定義し， それに対してバリエーションを作るといったことに挑戦したいと考えています。 - ――最後に，
LINE証券の開発において， やりがいを感じるところ， あるいは自分が成長できたことを教えてください。 水牧：このサービスで動くお金の額はものすごく大きいので，
そのためのサービスを開発しているというのはすごくワクワクします。またLINEということで多くのユーザーに利用されていて， それを自分が作っているんだという満足感も大きいですね。 鈴木：我々のチームの成果物はQA
（Quality Assurance） のフェーズで， 実際に動かしてみて問題がないことを入念に確認されます。当初は， なんでこんなにしっかりやるのかと思っていましたが， 金融にかかわるサービスのリリースや運用に携わる中で， リスクを抑えながら運用していくことの大切さを学びました。なので， バグを出さないことが重要だということを理解した上でリスクを下げていく， あるいはコストを下げるということに関心が向いています。こういった考え方になったことが， ファイナンシャルに携わることのチームに入って自分が成長できた証ではないかと思います。 - ――本日はありがとうございました。
現状の構成
