表題の通りですが、Infragistics Web Day 2017に参加してきました。
ここ数年（多分8年とか？）まともにWebシステム開発に携わって来なかったのですが、今後ノータッチという訳にもいかないし、特にWebフロントエンドの知識の最新化は、今期の組織課題としてちょうど取り上げていたところでした。非常によいタイミングで告知があったので少し厳しいスケジュールでしたが参加させていただきました。
結果としては満足いく内容で、とくにパネルディスカッションと懇親会でお話させていただいた内容は、面白くもあり、ためにもなりました。
こういった場を提供していただいたInfragisticsさんに感謝の念が絶えません。
という訳で？簡単にですが感じたこと、考えたことを残しておきたいと思います。ぶっちゃけポエムなんで怒らないでください。
なお当日の時系列には全く沿っていません。
また完全仕事モードでしたので、個人の趣味嗜好ではなく一般的な受託開発メインのSIer的視点での感想になっています。個人の趣味趣向とは大きくずれている点があることを先にお伝えしておきます。
- 自動テストを導入するSIer的要求
- AngularをVue.jsやReactと比較したときの違い
- ベンダーロックされずに済むのは、高スキル持ちに限ると言うのはやっぱり名言だと思う
- 大切なのはユニットテストを増やす事そのものじゃないんじゃないかなあ
- 大きなライブラリに依存すると、それを置き換えたいとなった時に困るんじゃないの？という質問に対して
- ライブラリのアップデートサイクルが短くなった時、それに適応するコストを開発サイドで支払うメリットは何か？
- さいごに
自動テストを導入するSIer的要求
自動テストやユニットテストは大切だと言ったとき、その理由として挙げられるのはアジャイル開発で大胆にリファクタリングや機能追加をするためだ、とか、（自社）プロダクトを継続開発していくためには必須である、みたいな論調をよく見かけます。この理屈でいうと、受託開発でリリースしたらリプレースまで5年間システムが塩漬けされる（なんて事はちゃんと「使われてる」システムならほとんどないですけど）受託開発業には必要ないんじゃないかと考えている人も多いように思います。
セッション内で自動テストのROIみたいな話が出ていましたが、まさにそれを理由で自動テストをしないSIerが多いように、僕の狭い観測領域では見て取れます。実際、自社も特定の部門以外ではあまり取り組めていなかったり、出入りしているクライアントの同業他社がやってる気配を感じたこともありません。
ですが私はSIerはSIerで本当は自動テストを必要とする要求を持ち合わせていると考えています。
先ほど5年塩漬けなんていいましたが、遅くても5年後のハードウェアリプレースに伴うソフトの更改や、実際には半年から数年以内に機能追加要望が来るわけですが、ここでSIerには致命的な弱点があります。それは
「二期以降の開発に初期開発メンバーが参加することはほぼ期待できない」
という悲しい現実です。
一部の社員は残っているでしょうが、全体を詳細まで把握しているメンバーが残っているとは限りませんし、仮に残っていても半年から数年放置されていたら、その間に普通に忘却の彼方ですよね。少なくとも私は3日前の事は覚えていません。
そういうケースで質の高い自動テストがあるというのは、心理的にも実際的にも非常に大きなメリットだと私は思っています。なのでユニットテストはViewレイヤーを除き徹底して作りこみます。
ってツイートしたら東さんからこんなレスきました。
外資も人の入れ替わりが激しいので、自動テストは大事な「資産」です。おっしゃる通り、怖くてやってられませんよ。
— Ken Azuma (@kenazuma) 2017年12月12日
背景は全然違うのに、自動テストを導入したい直接の理由が近しいのが非常に面白いなと感じました。
あと昔、中国にオフショアでだしたら3カ月の間にメンバーが半分入れ替わって、こっちが死にかけた事を思い出しました。
AngularをVue.jsやReactと比較したときの違い
一つの視点という意味ですが、Angularは全部入りお任せパック（そんな表現してませんでしたが）みたいなもので、Vue.jsやReactは軽量で他の多くのプロダクトと自由に組み合わせて作ることができる側面がある、というニュアンスに感じるものがありました。
元々Vue.jsに少し心が傾いていたのですが、お仕着せ部分が多いけど逆に言うとお任せできる部分が多いというのはSIerとしては一つの魅力かなと感じます。SIer全般で言えることな気がしますが、組織的な技術投資の限界が低いですし、プロジェクトの都度どういう人が集まるかも全く不明なので、現時点で経験者を集めやすい側面とあわせてAngularという選択は一つの説得力があるなと思いました。
これを聞いただけで来た甲斐があったかもしれません。と言いつつ、どこに投資していくかはまだまだ悩みますが。
ベンダーロックされずに済むのは、高スキル持ちに限ると言うのはやっぱり名言だと思う
いつだかTwitterかどこかで誰かがつぶやいていた言葉なんですが、これ大切だと思うんですよね。もう一つ追加すると、別にベンダーロックじゃなくてプロダクトロックと置き換えても同様です。
OSSの利点の一つとしてベンダーロックを回避できるということはよく耳にします。
ベンダーロックされないというのは一つの魅力なんですが、ロックされずに多彩なプロダクトを適切に使いこなせる人なんてどれだけいるんでしょうか？また、別にベンダーにロックされなくてもプロダクトにロックされたって同じ事です。Angularしかできませんじゃ、OSS使ってたって「ベンダーロックされないこと」の利益を享受できているかというと、限定的な利益しか得られていないんじゃないでしょうか？
そして別に戦略的にベンダーやプロダクトにターゲットを絞って投資すると言うことも、一つの正しい回答だと私は思っています。特に技術的投資限界が（ｒｙ
大切なのはユニットテストを増やす事そのものじゃないんじゃないかなあ
あらゆるプロダクトは統合されて初めてユーザー価値を生みますよね。ユニットが正しく動くことそのものには実際のところ価値はないわけです。
そういう意味では、ユニットテストよりもシナリオテストなんかのシステムテストや受入テストのレベルで自動化されたほうが、テストそのものの価値は高いと思います。しかしROIとしてはどうなのか？となります。
実際、Viewを除いたそれ以下のレイヤーを統合した状態で自動テストを作りこむことを過去に何度かトライしましたが、正直辛かったです。データベースやネットワーク通信や非同期処理なんかが含まれると本当につらいです。正直コストが見合いません。実際、実装の倍どころじゃないテストコストがかかりました。
でもユニットテストは価値が低いんですよね？じゃぁどうすればいいの？ということで、私のいまの回答は
「ユニットテストをすることで、プロダクト全体の品質を保証しやすいアーキテクチャを構築した上でユニットテストに重点を置く」
です。言うは易しで、その境地に到達できたとはとても言えませんが日々努力はしています。でも最近、部分的に統合テストを自動化することも計画した方がいいんじゃないの？と悩んでもいます。
ただ確実に言えるのは、それらの前段階として、「ユニットテストの比率を高くするように努力する」のではなく、「ユニットテストしやすい設計を導入する」ことで自然とユニットテスト比率が上げるよう取り組むべきだということです。テストしやすい設計を導入せずに自動テストを無理に導入して比率を上げようとするのは、ROIの低下を招きますからね。悲惨ですよ（経験者は語る）。
大きなライブラリに依存すると、それを置き換えたいとなった時に困るんじゃないの？という質問に対して
今になって、挙手して自分も喋ればよかったなと思ってるんですが、そもそもそうなるケースってどういう理由があるのか考えれば難しい話じゃない気がします。
プロダクトの多くを回収してまで、フレームワークを入れ替えなくてはいけなくなるケースというのは、少なくとも二つあると思います。
ひとつは、作ろうとしていたものに対して、選択したフレームワークが不適切だったと判明したときです。これは仕方がない、コストを払って置き換えて目指していたところを追求するのか、フレームワークを置き換えずプロダクトを妥協するかどちらかしかないでしょう。
もう一つは、当初は適切なフレームワーク選択だったんだけど、導入後なんらかの要求の変化に伴ってプロダクトやサービスを大幅に変更する必要が発生し、それに伴って適切なフレームワークが変わってしまった場合です。これも結局同じことでしょう。コストを払って置き換えて目指していたところを追求するのか、フレームワークを置き換えずプロダクトを妥協するかどちらかしかありません。
言ってしまえば、やらかしちまったか、コストはかかってもそれは適切なものなのか、悩むべきことではない気がします。
と書きましたが、当日東さんが仰っていた意図と基本的に同じなんだと思います。
ちなみに、既成フレームワークを適用しないことが最善なら、それはそれで選択肢だと思いますが、多くの場合はベストの選択肢じゃないケースが多いんじゃないでしょうか。趣味でやるならそのアプローチは大好きですけどね。
ライブラリのアップデートサイクルが短くなった時、それに適応するコストを開発サイドで支払うメリットは何か？
という意図の質問があったと思います。それに対して東さんが仰っていましたが、「必要がないのであれば開発サイドでそれに付き合ってあげる必要はない」というのは、そうだよなと思います。
それはそれとして、新しいバージョンが短期サイクルでリリースされるということは、新たな魅力が小まめにリリースされるということなのですから、開発者としては素直に喜べばいいんじゃないですかね？
その上で、作り手として考えるのではなく、利用者やそのサービスの提供者としてバージョンアップにコストを払う価値があるかどうか検討すれば良いんじゃないのかなと思います。
その際に大切なことの一つが、「ちゃんと各種実績のメトリクスを残しているか？」という点にあると常々考えています。
アップデートしたら当然、直接および間接的な影響範囲は、回帰テストする必要があるわけです。そして先にも書きましたがシステムテストレベルの自動テストは難しいとなると、手動テストが必要となります。そうなったときに、アップデートしたら回帰テストに具体的にどれだけのコスト・期間がかかるのか？メトリクスが残っていないと、バージョンアップで得られる利益と、それにかかるコストのギャンブルを毎回行わなくてはならなくなります。そしていつかはギャンブルに負ける日がやってきます。
開発時の機能・フェーズ別のメトリクスをちゃんと残しておくことが、結果的に正しい選択の一助になるはずです。
なんて偉そうにいってますが、正しいメトリクスを収集していますと自信もって発言なんてできないんですけど。
さいごに
なんか思ったままを書き散らかしましたが、参加させていただいて色々得られたうえ、考えるきっかけもいただけた良い機会でした。
個人的には今回のスタイル（とくにパネルディスカッション）は面白かったです。また次回機会と興味が合えばｗ参加させていただきたいと思います。
それではまた！
