2024.12.03
セキュリティ製品を入れても検出されず…被害事例から見る最新の攻撃トレンド 不正侵入・悪用を回避するポイント
リンクをコピー
記事をブックマーク
古川陽介氏(以下、古川):今までE2Eとかでやっていた時、もしかしたら倉見さんにも同じようなことが起きていましたか? 実際どうですか?
倉見洋輔氏(以下、倉見):そうですね、先ほど和田さんがおっしゃったところは、JavaでJSPで画面書いていた新卒から5年ぐらいの間、たぶん僕も含め、みんな同じようなことを考えていました。
フロントのテストというのは、とかく壊れやすい。それも、何が正という状態も、要件が変わると壊れてしまうので、そういった意味でも壊れやすい。なので、「コストをかけてやるべきではないよね」というのが主流だったというのは、肌感としてもあります。
例えば画面を通してやらなきゃいけないE2Eみたいなものも、なるべくそういう負荷を行わないように、最小限に済むようにしましょうというのがベストプラクティスというか、扱われていて、テストピラミッドみたいなものでとか、たぶんそういう話だと思うんですけどね。やはりそれがけっこう、感覚としてありました。
あと、僕はけっこう外でしゃべっている時も、やはり「コストかかりますよね」って。
古川:言われる?
倉見:言われますね。「倉見さんのところはやっているかもしれないけど、それってすごくコストをかけてやっているだけでしょう」みたいな意味合いで言われます。「そんなことはないんだよ」と言いたい自分がいる時もけっこうありますね。
古川:あぁ、そうですね。ちょっとお話を元に戻すと、確かに「Viewのテストを書きましょう」という時に、単体でViewをテストする仕組みが整理されてこなかった中で、おそらくE2Eみたいにすべてのサービスをいったん組み上がった状態にしてから、外側からテストするというやり方を取ろうとすると、どうしてもビルドのタイミングになってしまう。
あと、ブラウザを模したヘッドレスブラウザだったり、ブラウザそのものを使ってE2Eテストをすることも多いですが、そうするとやはり依存関係が複雑になりすぎて、「タイミングによってはダメというのが起きるから、謎のスリープを30秒入れておこう」みたいなコードが増えてきちゃう。
結局、メンテナンス性も再現性も悪いテストコードになってしまう。結果、コストが高いという印象を植え付けられてしまっていたところがあるのかなという話ですね。
つまり、やり方もあまり良くなかったし、それに加えて、そのやり方がもたらしていたメンテナンス性や再現性も良くなかったから、結果、トータルとして費用対効果が悪いものというふうに印象付けられていたのが、たぶん歴史上の話ですね。
古川:じゃあ今はどうなのだろうか? というところですよね。過去はそうでしたが、現在はどうか? というと、フロントエンドテストを書くのがけっこう普通になってきたかなという印象があります。
この5年から最近に関して言うと、わりといろいろなことが普通になってきたなと思います。何がターニングポイントだったのか、今までずっとテストをやられてきた和田さんと、やっている倉見さんの2人の意見を聞いてみようかなと思います。これ、何がターニングポイントだったと思いますか?
和田卓人氏(以下、和田):ターニングポイント。フロントエンドでのテストがまあまあ書けるようになってきたターニングポイントは、そもそもで言うと、フロントエンドの分離。フロントエンドという領域の出現。
それより前のテストが書かれていなかった頃って、サーバーサイドでDOMの断片が作られて、それに対してjQueryで動きを与えるとか、アプリケーションっぽい構造を導入するとか、そういったかたちでした。そもそもバックエンド、サーバーサイドがなければDOMが出来上がらなくて、テストもできないみたいな。
つまり、テスト容易性が低かったんですよね。テストが簡単に動く仕組みがなかった。テストって「書きやすさ」だけではなくて、「動かしやすさ」も大事で、「バックエンドを立ち上げておかないとテストが動かないんですよ」と言うと、みんなテストをしなくなってしまう。
ターニングポイントは、フロントエンドにロジック、仕組みがじわじわじわじわと寄ってきた時。その結果、フロントエンド側が独立して描画などを扱うようになりましたよね。DOMの断片の構築がサーバーサイドで行われていたのが、そうではなくてデータのかたちでフロントエンドにやってきて、フロントエンド側で複雑な画面も含めて、構築・描画されるようになってきた。
簡単に言うと、データが用意できれば画面は作れる。バックエンドがなくてもデータがあれば画面が再現できる。ということは、テストが動かせるという話になるので、じわじわじわじわと責務がフロントエンドのほうに寄っていって、フロントエンドとバックエンドの責任分界点が……一時期、HTMLみたいなやり取りをしていたのが、JSONをやり取りするところに収束してきましたね。
テストで「ピンチポイント」と言うんですけど。道が細くなったポイントがあって、ここをギュッと押さえておけば、戦略上……戦争の話で言うと、狭い谷があって、そこを押さえておけば、全体の首根っこをつかまえることができるみたいな。テストの自動化においては、アーキテクチャ上のそういうポイントを押さえるというのがとても大事です。
ギュッと狭くなった首根っこを押さえれば、サーバーサイド、バックエンド、フロントエンドを並列で開発できる。その後はスキーマの話になってくるんだけど、やり取りのルールだけを決めておいて、データとしてはある程度独立したかたちで開発できるようになったら、テストが書きやすくなったし、データを用意すればよくなった。
もう1つ、複雑なロジックもフロントエンドに寄っていったので、テストを書く動機も生まれたんですよね。なにかをいじるたびに、なにかがぶっ壊れるというのをひたすら目で確認するとなると、やはり人はだんだん疲れてきたり、飽きてきたり、モチベーションが落ちたり、成果も落ちたりします。そこで、これは自動化しないと(となった)。
まさにコスパの話で言うと、自動化がコスパとしてペイするようになってきたんじゃないかというのがあります。それとほぼ時代を同じくして、Reactとかも出てきて、いよいよフロントエンド側を独立させてテストが書きやすくなってきた。
やはり、バックエンドとフロントエンドの責務のバランスが、ややフロントエンドに寄った結果、アーキテクチャ上で重要なポイントを押さえれば、どちらもテストを書いて開発を進められるようになった時代になったことが、ターニングポイントだったなと思っています。
古川:すごくわかりやすい話。
和田:DOMスクリプティングの時代からアプリを作る時代になったからだと思っています。
古川:なるほど。
古川:私なりの言葉でもう1度話すと、今、バックエンドとフロントエンドと呼ばれているアーキテクチャが2つあります。今までは1つのモノリシックなもので、その時に出てくる最終的なアウトプットはHTMLと呼ばれるかたちで出てきていました。
それは、人間の目やブラウザからすると扱いやすい単位だったけれども、コンピューター自体がチェックするのにあまり向いているフォーマットではなかった。全体がモノリシックであるがゆえに、それ自体があまりワークしてこなかった。
そこで、マイクロサービスとか、バックエンドとフロントエンドでHTMLそのものを作るのではなく、データを受け渡しして、データからHTMLを作る部分、つまり表示をする部分がフロントエンドの役割・責務であって、データを作るところまでがバックエンドの責務というふうに切り分けをした。
その切り分けをすることによって、先ほどのナローポイントと呼ばれている、首根っこをつかまえることができるようになってきた。データを出力するところだけを見ておけばバックエンドのテストができるし、フロントエンドは、その出力されたデータを今度は逆に入力として捉えて、その入力があったらこういうHTMLが返ってくるとしちゃえば、全体のシステムが要らないのでE2Eまでする必要もない。
そうすると逆に、ちょっとフレーキーな安定性の低いテストも、データを用意するところだけは確実にできるから、そこから先はやり方が少しシンプルになってきている。
かつ、フロントエンドがReactとか、Vueのライブラリとか進化してきたことによって、Reactは特に、特定のプロパティを与えたら特定のReactのコンポーネントのオブジェクトが返すので、ある程度それはそれで、HTMLそのものよりかは、コンピューターとして、JavaScript内で扱いやすいものになっていって、というところですね。
なんかすごく、俺だけずっとしゃべっていたけど(笑)、言いたかったことはおそらくそういうことで、バックエンドとフロントエンドそれぞれが、アーキテクチャ上、疎結合になってきているということですね。
和田:そうです。
古川:疎結合になってきたことによってインとアウトをうまく利用することで、その部分部分でテストが可能になってきたというお話だったかなと思います。
古川:ちなみにここは、いろいろなものがあると言っていたんですが、特にReactとかJestとかで言った時に、倉見さんもけっこうずっと前からやっていたのかなと思います。そのへん、明らかにやりやすくなった感じってありますか? テスティングライブラリとか出てきてからまたちょっと話が進化するのかなと。
倉見:たぶん、いろいろなテーマを内包しているところだとは思うんですが、ちょっと今までのお二人のところから引っ張って、先ほど古川さんが言ってくれたReactを例に取ります。
ナローポイントから降ってくるJSONのデータを与えたらHTMLを作ってくれる、そういう関数だという捉え方ができることによって、インが決まればアウトが決まる、ほかの副作用は持たない。これはたぶん、テストの中において一番テストが書きやすいパターンの1つですよね。
なので、単体テストのノウハウがすべて使えることに気づいた人たちがいろいろなツールを拡充し出した。たぶんテスティングライブラリとかも、その一環で整備されだしたものの部分だと僕は理解しています。
あるJSONを与えると、あるHTMLが返ってくる。これを検証する。これがユニットテストの基本なんですが、ポイントになるのは、「検証する」というところだと思っています。HTMLを検証するコードをテストコードとして人が書くということが、実はけっこう大変だということにその次に気づくんですよ、みんな。
ここで、Jestの人たち……最初にたぶん考えとしてあったのは別にJestではないと思うんですけども。彼らが用意したのが、初めてテストを書いた時の結果を正しいものとして、そのHTMLの文字列同士を次回の検証時に使いましょうというアプローチ。
これは、よく言われる「スナップショットテスティング」。別にフロントエンドだけのものではないのですが、これを使えば、とても面倒くさかったHTML部分の検証が、かなり低コストでできるようになるぞと。
入力の部分は、先ほど和田さんがおっしゃってくれたとおりで、ナローポイントから降ってくるデータをしっかり押さえておけば、フレーキーさもなくできる。この状態をReactで見せつけられた時に、「おっ、これは来たな」って(思いました)。
古川:そうですね。「来たな」と思ったと。
倉見:そうですね。
(次回へつづく)
関連タグ:
2024.11.26
タスクの伝え方が部下のモチベーションを左右する マッキンゼー流、メンバーが動き出す仕事の振り方
2024.11.27
何もせず月収1,000万円超…オンラインゲームにハマって起こした事業 大学中退し4社立ち上げ・2社売却した起業家人生
2024.11.29
「明日までにお願いできますか?」ちょっとカチンとくる一言 頭がいい人に見える上品な言い方に変えるコツ
2024.11.28
管理職の「疲弊感」がメンバーに伝わるリスク 部下の「働きがい」を育む6つのポイント
2024.11.25
仕事はできるのに、なぜか尊敬されない人が使いがちな言葉5選 老害化を防ぐために大切な心構えとは
2024.11.27
部下に残業させられず、自分の負担ばかり増える管理職 組織成長のカギを握る「ミドル層」が抱える課題
2024.11.27
仕事中の「今ちょっといいですか」が苦痛… いしかわゆき氏が語る、ADHD気質にマッチした働き方のヒント
2024.11.25
論理的に「詰める」マネジメントでは本質的な解決にならない マッキンゼー流、メンバーの理解と納得を得る接し方
2024.11.28
“新規事業が生まれない組織”に足りていないもの 「PoC貧乏」に陥らず、アイデアを形にするためのヒント
PR | 2024.11.29
検知が難しいサイバー攻撃が増加中 サイバーセキュリティの専門家を唸らせた脅威アクターの実例
長期投資の衝撃の真実!20年投資しても年率1.9%しか増えない!?
2024.10.04 - 2024.10.04
第1076回 ペライチ書評『みんなのフィードバック大全』
2023.06.06 - 2023.06.06
第765回 トレンド経営学『顧客に謝る基準とは?』
2022.04.18 - 2022.04.18
不機嫌な自分をやめるために!認知行動療法の専門家 中島美鈴先生新刊『脱イライラ習慣! あなたの怒り取扱説明書』発売記念【無料オンラインイベント】
2024.10.25 - 2024.10.25
ログミーBusiness リニューアル記念イベント開催
2024.11.29 - 2024.11.29