ニュース

Jul 11, 2023

早く納品したい場合は、テストが最終決定権を持ちます

Se desideri visualizzare gli articoli sulla home page di InfoQ,

InfoQ ホームページの記事 早く納品したい場合は、テストが最終決定権を持っています

2023 年 6 月 6 日 23 分で読みました

による

ホルヘ・フェルナンデス・ロドリゲス

によってレビュー

マット・キャンベル

ソフトウェア エンジニアリングが他の職業と比較して特別であることに同意していただけると思います。 物事は劇的かつ急速に変化します。 最新の情報を入手するだけでも多くの知力が必要です。

おそらくその結果として、私たちは確立された一般的な慣例や考え方にしがみついているのです（たとえそれが問題を引き起こしたり、場合によっては当てはまらないとしても）。 これらのプラクティスはほとんどのケースをカバーしようとしますが、すべてをカバーすることはできません。 しかし、これらの実践は私たちに安心感を与えます。 私たちは、変わらないもの、安心感のあるもの、本当に合うかどうかを考える負担から心を解放してくれるものが必要です。 自動操縦モードに入ります。

問題は、私たちがソフトウェア開発を組み立てラインのように動作させたいことです。組み立てラインが構築されると、私たちはそれに決して触れません。 私たちは常に同じやり方で活動しています。 これは CI/CD レーンではしばらくは機能するかもしれませんが、残念ながらコードでは常にうまく機能するとは限りません。

Kalix を使用すると、クラウドに簡単に移行し、信じられないほど速く革新できます。 NoOps が必要な、高性能のマイクロサービスと API を構築します。 もっと詳しく知る。

時にはメッセージが何度も伝えられすぎて本質が失われ、ある時点で私たちはその実践を自分たちのアイデンティティの一部として受け取り、それを擁護し、異なる視点を入れないようにするため、事態はさらに悪化します。明らかにさらに努力が必要な場合。 また、単に周囲に合わせたいだけで、新しいアイデアを提案したくない場合もあります。

コードを書くときは、それと闘い、その実践が現在のシナリオに適合するかどうかをあらゆるケースで反映する必要があります。 「ベスト プラクティス」を「ベスト 一般的なプラクティス」と考えてください。

その一例は、アジャイルが誤解される可能性があるさまざまな方法です。 本質が失われている場合もあります。

この記事では、アジャイルの実装では多くの場合間違った点に焦点が当てられているため、アジャイルの本質が失われることが多いと主張しています。 定義上、アジャイルなものは簡単に方向を変え、変化に素早く対応できます。

私たちは、CI/CD (継続的インテグレーション/継続的デプロイメント) などの技術的なものや、反復開発などの戦略的なものなど、さまざまな性質の実践でこの即応性を達成しようとしています。 しかし、ソフトウェア開発の中核であるコーディングを扱うとき、私たちはアジリティを忘れがちです。 レシピの主要材料を使わずに、お気に入りの食事やデザートを準備するところを想像してみてください。 コードを考慮せずにアジリティを追求すると、これが実際に行われていることになります。

コードを改善するというと怖くて複雑に聞こえる、あるいはウサギの穴に陥りやすい（これらはすべて緩和することができます）ために、このようなことが起こる可能性があります。 おそらくそれは、一部のソリューションが私たちの操縦性に及ぼす悪影響を確認するのが容易ではないからかもしれません。 将来の開発を悪夢に変えることは、機敏性とは正反対です。 コードに焦点を当てる代わりに、プロセス (スクラムなどの方法論) を完璧に達成することに過度の注意が払われ、重要性が低く、主要な問題に取り組むことなく問題を解決しようとします。

最後に、コードが将来の開発に与える影響 (そしてその結果、ビジネスの将来) をもっと可視化する必要があることを提案します。 うまくいけば、AI が係数のようなものを使用してこれを定量化するのに役立ち、品質を示すだけでなく、潜在的な選択に基づいて開発がどの程度遅くなるかを予測することもできます。 このようなことは、企業が持続可能な開発に投資する必要があることを認識するのに役立つと思います。 技術的負債にいつ対処するかについての議論は歴史になるだろう。

この記事では、十分に疑問視されていないことが多いものの、アジリティにおいて重要な役割を果たしている 1 つのコーディング手法、つまり従来のテスト方法に焦点を当てます。

また、私が最近発見した、目標を達成し、多くの習慣を変えるのに役立つ戦略である「変化への免疫」についても紹介します。 コーディングの習慣だけでなく、生活の他の習慣も同様です。 さらに、これは、前の記事で述べたポイントの 1 つを示しています。つまり、私たちはいくつかのプラクティスや習慣を変更することで操作性を実現したいと考えていますが、その目標を達成する上でコーディングが果たす役割を知らないため、無意識に自分自身を妨害してしまいます。

(優れた) 自動テストが大きな利点をもたらすことに同意していただければ幸いです。コードを変更して、既存の機能が壊れていないことを迅速に検証できます。 テストは私たちのセーフティネットです。

ただし、それらは安くはないため、コストを補う必要があり、これはしばらくしてから発生します。 実行回数が増えるほど、より多くの価値が得られます。 しかし、テストを変更すると、テストの「利益カウンタ」がゼロにリセットされます。

コストの補償に加えて、別のことも考慮する必要があります。テストを作成するとき、テストが正しいことを保証するために最善を尽くしますが、100% 確実であることは保証できません。 自分が書いたコードが正しいと確信できるのであれば、そもそもテストも必要ありませんよね。

テストは時間の経過とともに自信を与えてくれます。 次のことを考えてください。テストが実行されるたびに、確信がもたらされると想像してください。 1000 回実行すると、1000 ポイントの信頼度を獲得します。

ある時点でテストにバグが発見された場合、1000 ポイントの信頼度を失います。 私たちはそれが私たちを守ってくれていると思っていましたが、そうではありませんでした。

同様に、テストで検証されたロジックをリファクタリングする必要があり、テストが中断した場合、ビジネス ロジックもテストも正しいかどうかはもはやわかりません。 蓄積してきた「自信」ポイントも失われます。 新しいセーフティネットを構築しているようなものです。

それは将来への投資です。 人間も企業も長期的な投資について考えることはほとんどありませんが、ありがたいことに自動テストの利点は広く受け入れられています (ただし、まだ自動テストを受け入れていない人の話を時々聞きます)。

リファクタリングを通じてコードの柔軟性を保つなどの他の長期的な投資は、残念ながらそれほど広く採用されていません。 この記事で述べたまったく革新的ではないアイデアが、その障壁を取り除くのに役立つことを願っています。

新しい機能を追加するたびに、特に多くの機能を備えた大規模なサービスでは、作成されたテストに感謝します。 それらをすべて手動で検証する必要があるとは想像できません。 どれだけ遅くなるかを考えると、それはナンセンスです。

ただし、ケースに応じた適切な戦略に従わない場合、不利益が生じる可能性もあります。 不適切なテスト戦略は配信を遅らせ、開発者の満足度やエクスペリエンスを低下させる可能性があります。

次の質問とともにそれらを見つけてみましょう。

すべての単体テストでは、クラスまたはメソッドを個別に検証していますか?

答えが「はい」で、依存関係を頻繁にモックしている場合は、モックを次々に準備することにうんざりして、場合によってはモックが十分に現実的ではなく、ロジックが実際には正常に動作していないことが判明する可能性があります。 うまくいけば、本番環境に入る前にそれがわかり、多くの変更を加える必要がなくなります。

テストによってコードを変更する方法が制限されているという印象を抱くことがありますか?

これもイエスだと思います。 場合によっては、既存のコードが新しい機能に適合しなくなったり、複雑になりすぎたりすることがあります。 それをリファクタリングすることにしました。 これは小さな変更であり、多くのテストがコンパイルされなくなったり、失敗したりするため、10 ～ 15 分かかります。 テストを調整して実行するには、コードを調整するよりもはるかに長い時間がかかります。 10 ～ 15 分の変更のために何日も費やすことになります。 なぜ？？？！！！！ 行動は変わりませんでした。

機能が変更されない場合、理想的にはテストが中断されないはずです。 テストを適応させれば、再びセーフティネットに飛び乗れるでしょうか? また、テストの「利益カウンター」と「信頼カウンター」は、変更するとリセットされることに注意してください。

多くの場合、この状況を回避し、ハッキングの追加を避けることができることが後でわかります。 なぜなら、ハッキングは、少なくとも最初は、自分たちが早く成果を上げているという錯覚を私たちに与えるからです。 しかし、これは短期間の投資であり、私たちに跳ね返りをもたらします。コードは硬直化し、数か月後にはコードの理解と変更にさらに多くの時間を費やすことになります。 数日経っても、そのコードが何をするのか覚えていないでしょう。 そして、状況はさらに悪化し、さらに文脈を持たない哀れな新入社員のことなど考えも及ばないでしょう。 ただし、コード ベースにハッキングが散在している場合は、おそらく長くは続かないので、あまり長く心配する必要はありません。

テスト スイートには多くの統合テストと e2e (エンドツーエンド) テストが含まれていますか?

統合テストは単体テストよりも多くの変更に耐える傾向がありますが、速度ははるかに遅くなります。

多くの e2e テストを開発した人なら、おそらく次のようなつらい経験をしたことがあるでしょう。

e2e テストにネットワーク経由で接続された多くのコンポーネントが関与する場合、痛みはさらに悪化します (ただし、これを避けるために大きな泥の塊を構築しないでください)。

したがって、テスト戦略が間違っていると、それだけで納品が台無しになる可能性があります。 単体テストは、より良いコードを書くことを「妨げる」可能性があります。 「アジャイル」の習慣が適切であるかどうかは関係ありません。 あなたは拘束衣を持っているように感じます（または、200％安全にしようとして、さらに多くのテストを追加する偏執的な場合は、複数の拘束衣を持っています）。 その一方で、市場の大海の変化に素早く適応できる競合他社の鋭い牙が私たちに近づいてきており、拘束衣は身動きすら許さない。 それらの歯に対しても役に立ちません。

したがって、これを読んだ後、自分自身に自問してほしいいくつかの重要な質問があります。

私がよく見るシナリオを簡略化して見てみましょう。 Spring を使用して実装されたバックエンド アプリ。 通常、次の図のように、運用クラスとテスト クラスの間に 1 対 1 のマッピングが見られます。

[画像をクリックするとフルサイズで表示されます]

「メインロジックを備えたクラス」は「サービス」と呼ばれることがよくあります。 サービスがドメイン エンティティごとに固有である場合もあれば、サービスがより抽象的な概念を表す場合もあります。

場合によっては、「メイン ロジック」がコントローラーやリスナーなどのフレームワーク コンポーネントに広がることもあります。 フレームワークとビジネス ロジックの間の境界線が曖昧になるだけでなく、単体テストや統合テストでより適切にテストできるものを区別する境界線も曖昧になります。 その結果、単体テストや結合テストでも同様のシナリオが見られることがあります。 これは無駄でコストがかかります。

クラスに複雑な機能が含まれている場合、クラスごとに 1 つの単体テストを行うことは意味があります。 そうなると、エラーを特定するのが難しくなるため、コードを小さくしておくと、問題をより早く特定するのに役立ちます。 これは実際には、単体テストをサポートする引数の 1 つです。 単純な機能を複雑な方法で実装することは常に可能であるため、私が言っているのは「複雑なロジック」ではなく「複雑な機能」であることに注意してください。

ここで、要件が変わったために機能を追加したり、ロジックを変更したりする必要があると想像してください。 そんなことは滅多に起こりませんよね？ ;)。 現在の実装は新しいアイデアやコンテキストに適合しません。 ほとんどの場合、選択肢は 2 つあります。ダーティハックかリファクタリングです。 もちろん、常にリファクタリングを選択します。

[画像をクリックするとフルサイズで表示されます]

分割がクリーンで (いくつかのメソッドを新しいクラスに移動するだけ)、古いクラスが新しいクラスへの参照を保持していると想像してください。 1 対 1 のマッピングを維持するためにテスト クラスを分割するのは理にかなっていますか? 私たちは何を勝ち取るのでしょうか？ テストをそのまま維持することもできます (わずかな変更のみが必要です)。

リファクタリングがより複雑な場合、ロジック (実装の詳細) が 20 分で適応されたと想像してください。 すでに述べたように、テストはそれほどすぐには変更されません。

テストに関しては、次の 2 つのことがわかります。

それぞれのタイプにいくつかの利点があることがわかります。 したがって、統合テストと従来の単体テストの長所を組み合わせることができるかもしれません。 伝統的に、ユニットはクラスまたはメソッドです。 少なくとも私はずっと前にそうやって学びました。 クラスを分離してテストしないという考えは間違っているように思えるかもしれません。 しかし、おそらく「ユニット」の概念は、それ自体の「リファクタリング」から恩恵を受ける可能性があります。

長い間、なぜ人々がこのことについて話しているのを見なかったのかと不思議に思っていました。 しばらくして、このトピックについて説明している記事やビデオをいくつか見つけました。また、ウラジーミル・コリコフ著『単体テストの原則、実践、パターン』という本を読んで、このトピックやさまざまなタイプのテスト ダブルなどの他の概念についてより明確に理解しました。

それでは、クラスではない場合、ユニットとは何でしょうか? 複数のメソッドまたはクラスにまたがる機能の一部についてはどうでしょうか? 「待って、それは統合テストのようですね」と思われるかもしれません。 そうですね、正確にはそうではありません。 この本からいくつかの定義を借用します。

単体テスト:

統合テストは、前述の基準の少なくとも 1 つを満たしていません。

優れた単体テスト:

したがって、「ユニット」という概念はより抽象的で、より柔軟に見えるようになりました。 また、統合テストでは、システムテスト、e2eテストなど、さまざまなことを検討できます。

それでは、より高い粒度レベルに進みましょう。 最初のロジックをモジュールにグループ化し、さらにいくつかの変更を加えてみましょう。

[画像をクリックするとフルサイズで表示されます]

最初に行ったのは、ドメイン ロジックを相対的にグループ化することです。小さいモジュール。 これが役立つかどうかはわかりませんが、モジュールをマイクロサービス内のマイクロサービスとして考えてください。 どのくらい小さいですか？ ほとんどすべての決定と同様、従うべき単一のルールはありません。 この例は単純化したものであることに留意してください。複数のエンティティが含まれる場合もあれば、まったく含まれない場合もあり、さらに多くのクラスが存在する可能性もあります。

以下のトレードオフに留意することが重要です。

利点:

短所:

本当に複雑な機能については、特定のテストを行うことが合理的である可能性があることに留意してください。

2 番目に行ったのは、フレームワーク コンポーネントからドメインを分離することです。

Spring のようなフレームワークの機能の 1 つは、アプリケーションのさまざまな要素を結合することです。 ここでやりたいことは、ポートとアダプターとも呼ばれる六角形のアーキテクチャに似ています。コントローラー、リスナー、フィルター、DAO、またはその他のフレームワーク構成要素は、ドメイン ロジック (アプリケーション コア) を外部の世界に接続するポートです。 これらのコンポーネントには、ドメインの知識が含まれないことが理想的です。 たとえば、コントローラー、リスナー、およびフィルターには、ドメイン ロジックへの呼び出しが 1 つだけ含まれています (さらに、必要に応じて、データをドメイン モデルにとってより使いやすい形式にマップするロジックへの別の呼び出しも含まれています)。

利点:

ドメインとフレームワーク ロジックを分離することの拡張として、各機能のドメイン ロジックを近くに保ち、一貫性を持たせることができます。 この機能に関連するすべてのロジックは、複数のモジュールに分散されるのではなく、このモジュールに実装されます。

私はすでに、変更が必要な場所をすべて見つけるためにモノリスのコードベースを掘り下げる必要があるという悪夢を経験しました。 私たちは数か月間集中的にデバッグを行い、主な変更は 2 日で完了しました。

他のフレームワーク機能 (エンドポイント構成、シリアル化、データとエラーの逆シリアル化、データ アクセス、リモート呼び出し、認証など) など、単体テストでテストされていないものに対する統合テストのみが必要です。 ハッピーケースのスモークテストも興味深いかもしれません。

最後に言及したいのは、e2e テストについてです。 e2e は統合テストよりもはるかに高価なので、注意して使用してください。

これらの重要ではないシナリオに対する e2e テストの代替案として、コントラクト主導のテストを使用することが考えられます。

このアプローチが役に立ったと思われるケースをいくつか覚えています。 最も重要だったのは、入札システムのアルゴリズムを開発しなければならなかったときです。

アルゴリズムの最初の実装は当初は良好に見えましたが、リリース後は毎週、難しいシナリオが発見され始めました。 私たちはそれらを個別に修正し始めましたが、すぐに実装が複雑になりすぎて、インシデントが発生してしまいました。

その後、もう一度検討して、別のアプローチを見つけました。 最終的にコードは 75% 減り、実装ははるかに簡単になりました。 それは良い部分でした。

悲しい部分は、単体テストで多くのメソッドが個別にチェックされ、それらのメソッドが大量に存在したことです。 ロジックを機能の単位としてテストしていれば、(15 日中) 12 日間の作業と、すべてのテストを再度やり直すことで生じる多くのフラストレーションを節約できたでしょう。

したがって、前述したすべての利点に加えて、このテストアプローチは開発者/チームとしての幸福度を高めることができます。 より速く提供することを目的とした他の戦略では、最も近い環境以外の人々を説得する必要があり、それは非常に困難な場合があります。 これはすべてあなたの手の中にあります。

要約すれば：

そして次のことに留意してください。

私は、この方法でのテストが常に誰にとっても良いことだと言っているわけではありません。 これが役立つかどうか、またどのような場合に役立つかを評価する必要があります。 前述したように、これは、多くの実験が行われ、ドメインが反復的に作成および進化し、新しい機能が定期的に組み込まれるアジャイル環境で特に役立ちます。 これらのアクションの多くはリファクタリングの恩恵を受けるでしょう。

これらの利点の一部は、意識的に実行すれば TDD (テスト駆動開発) でも実現できます。 悲しいことに、繰り返しになりますが、私たちは本質や本来の目的を理解せずにツールやテクニックに集中しすぎる傾向があるため、そこから何も得ることができず、最終的には放棄してしまいます。

このような慣行を採用するには習慣を変える必要があり、これがどれほど難しいかを私たちは知っています。 私たちは意志の力が必要だと考えていますが、それだけでは十分ではありません。 私が最近発見したアプローチを共有したいと思います。 これについては、リサ・レイヒー編著『変化への免疫: それを克服し、自分自身と組織の可能性を解き放つ方法』という本で説明されています。 ハーバード大学教育大学院のメンバーであるロバート・キーガン博士。

私たちは意志の力だけで変化を実現しようとすることがよくあります。 彼らの理論は、私たちには変化に対して働く「免疫システム」のようなものがあり、あらゆる試みを妨害するため、これはうまくいかないのではないかというものです。 したがって、変化を取り入れるには、まずその「免疫システム」を明らかにし、その根本に取り組む必要があります。

この「免疫システム」は過去に開発されました。 時間をかけて、私たちは目標を達成しようと努めます。 これらを達成するには、次の一連の手順に従います。

これらの概念は、実装されたプロセスの基礎を形成します。 手順を非常に簡単に説明します。

仮定がもはや有効ではないとわかった場合は、その仮定に取り組みます。 そうすることで、変化を受け入れやすくなります。

ポッドキャスト「Dare to Lead」では、リサ・レイヒーとブレネー・ブラウンが、ブレネー自身の人生の例を通して、免疫力を実践して変化をもたらしました。 2 つのパート (パート 1 とパート 2) で構成されています。 私は他の作業をしながらポッドキャストを聞くことが多いのですが、これはじっくり聞く価値がありました。

ポッドキャストはブレネからの強力な質問で始まります。「なぜ私たちは皆変わりたいと思うのに、誰も変わりたくないのでしょうか?彼らは、私たちが変化の失敗を、それを十分に望んでいないことや偽りの意図と結びつける傾向があることについて話し続けています。彼らは、命が危険にさらされており、生きたいと望んでいる人々が、それでも変化できないことがあるので、意図がすべてではないと述べています。

その後、彼らは 1 つの例に取り組みます。これはおそらく私たちにとってよく知られたものです。ブレネは、定期的な会議の開催についてチームにもっと規律を持たせたいと言いました。

リサは、ブレネーが欄に記入できるようにいくつかの質問をしてガイドします。 ブレネーにとって、それは人生を楽にし、成功を収めるための鍵です。 それにもかかわらず、それは彼女自身の力で変えることができるものであるにもかかわらず、彼女はそれを実行することができませんでした。

その後、ブレネーは、声にならない約束、思い込み、心配が彼女を妨害し、現在の状況につながっていることに気づき、驚きます。 彼女は、規律と創造性は相互に排他的であることを過去に学んだため、定期的な会議があると、最も楽しんでいること、つまり創造性を発揮するための時間を失うと信じていると言います。 そのため、彼女はそれらの会議をスキップしますが、その結果、1 回限りの会議を多く持つことになります。 それは、自分が親しみやすいリーダーであることを示したいからだと彼女は言います。 これにより、彼女は多くの目標を達成することができましたが、今ではそのために多くの時間を費やしており、定期的に会議を開くことで状況が悪化するわけではなく、時間を大幅に節約できることに気づきました。

最後に、リサは、規律と創造性は確かに両立するというこの新しい信念を検証する方法を見つける必要があると提案しました。 目標は、新しい神経経路を作成し、何年にもわたって刻まれてきた古い神経経路を上書きすることです。

私は、この戦略から 2 つの点で恩恵を受けることができると考えています。「免疫システム」によるこの妨害行為は、コードがどのように見えるかを無視しながらアジャイルになろうとしているときに私たちが何をしているかを示しています。 これは私たちの生活のさまざまな側面に応用できると思います。

たとえば、この新しいテスト戦略に切り替える場合を例にとると、その変更で何を達成したいのか、そしてなぜそれが他のものよりも重要なのかを知る必要があります。 私にとって、現在の状況では柔軟性が非常に重要です。

私たちが目標に反することをしている可能性があること、それを行う理由、それらの活動を活性化するために行った仮定に関して、私たちは、次のことを行う必要があるだけなので、通常の方法でそれを実行した方が生活が楽になると考えることができます。惰性で続ける。 また、それを行わない理由も見つけます。「これは、私たちが常にテストを行ってきた方法であり、そうするように教えられてきた方法です。誰もがこの方法でテストを行っているため、それは正しいはずです。」

したがって、これに対抗するには、否定的な副作用を声に出してその信念を書き換え、その前提が間違っていることを証明する方法を見つけて、最終的に変更を実装する必要があります。

さらに詳しく知りたい場合は、上記の Dare to Lead ポッドキャスト (パート 1 とパート 2) にリンクされているリソース、Web サイト、または書籍をチェックしてください。

InfoQ で執筆することで多くの扉が開かれ、キャリアの機会が増加しました私にとって。 専門家や思想的リーダーと深く関わり、自分が扱ったトピックについてさらに学ぶことができました。 また、学んだことをより広範なテクノロジー コミュニティに広め、テクノロジーが現実世界でどのように使用されているかを理解することもできます。

私は今年初めに InfoQ のコントリビューター プログラムを発見し、それ以来楽しんでいます。 ソフトウェア開発者のグローバル コミュニティと学習を共有するためのプラットフォームを提供してくれたことに加えて、InfoQ のピアツーピア レビュー システムのおかげで私の執筆力は大幅に向上しました。 。 ソフトウェアの専門知識を共有する場所を探している場合は、InfoQ への貢献を始めてください。

私はテクノロジーを最新の状態に保つ方法として InfoQ .NET キューのニュースを書き始めましたが、それ以上に多くのことを得ることができました。 知識豊富な人々に会い、世界的な知名度を得て、ライティングスキルを向上させました。

InfoQ の編集者になったことは、私のキャリアの中で最良の決断の 1 つでした 。 それは私に挑戦をもたらし、非常に多くの点で私を成長させてくれました 。 もっと多くの人に来てもらいたいです私たちのチームに参加してください。

InfoQ はフルタイムの編集長を募集しています C4Media の国際的な、常にリモートのチームに参加します。 私たちと一緒に、現代の最も革新的なテクノロジーを取り上げ、世界で最も優秀なソフトウェア実践者と協力し、160 万を超える開発チームが新しいテクノロジーや実践を導入して、ソフトウェアとチームが提供できるものの限界を押し上げるのを支援してください。

毎週火曜日に送信される InfoQ の先週のコンテンツのまとめ。 250,000 人を超える上級開発者のコ​​ミュニティに参加してください。 例を見る

私たちはあなたのプライバシーを守ります。

コメントを投稿するには、InfoQ アカウントを登録するか、ログインする必要があります。 しかし、登録の背後にはさらに多くのことがあります。

InfoQ のエクスペリエンスを最大限に活用してください。

許可される HTML: a、b、br、blockquote、i、li、pre、u、ul、p

許可される HTML: a、b、br、blockquote、i、li、pre、u、ul、p

許可される HTML: a、b、br、blockquote、i、li、pre、u、ul、p