Building Secure and Reliable Systems 読書メモ - Chapter 21

f:id:muziyoshiz:20200430014145p:plain:w320

SRS 本の読書メモです。

Chapter 7 までは順番に読んでましたけど、途中を飛ばして、気になっていた最終章の Chapter 21 を先に読んでみました。

SRS 本について

SRS 本はこちらから無償でダウンロードできます。

前回までの読書メモは SRS Book タグを参照のこと。

Chapter 21. Building a Culture of Security and Reliability

この章では、セキュリティと信頼性に関する健全な文化の側面について述べる。また、変化を起こすべきときに、良いプラクティスを選ぶことで、あなたがどのように組織文化に影響を与えることができるかについても触れる。そして、セキュリティと信頼性についての同意を得るために、組織を超えてリーダーとチームに対しての影響を与えるかについての洞察を提供する。

Google やその他の組織で有用だったいくつかのプラクティスを共有するが、同じ組織は2つと無いこと、これらのプラクティスをあなたの組織の文化に合わせて応用する必要があることに注意してほしい。また、Google もこれらを完璧に実践できているわけではなく、日々改善を進めていることを添えておく。

例えばこんなシナリオを想像しよう：あなたの組織には大きな取引（Big Deal）が近づいており、みな締切に追われている。しかし、今日あなたは攻撃者がシステムに進入した証拠を発見してしまう。あなたはすぐシステムをオフラインにすべきと気づいているが、もちろん顧客は怒り、大きな取引はリスクに晒されるだろう。おそらくあなたは、先月のセキュリティパッチを適用していなかったことを責められるだろう。こんな状況で、あなたの組織の文化は、どのような決定を促すだろう？　強いセキュリティ文化を持つ健全な組織なら、従業員がそのインシデントについてすぐ報告することを促すだろう。

この章では、セキュリティと信頼性の文化（a culture of security and reliability）を構築するためのパターンとアンチパターンの両方を紹介する。

Defining a Healthy Security and Reliability Culture

健全なシステム（healthy systems）のように、健全なチーム文化は明示的に設計され、実装され、そして維持されることができる。健全なシステムを構築するための設計の原則（design principles）があるように、健全な文化にもそのような設計の原則がある。

Culture of Security and Reliability by Default

Chapter 4 で議論したように、セキュリティと信頼性について考えることは、プロジェクトの最終盤に回されがちである。しかし、あとから技術的負債を支払おうとすると、長期的なベロシティは低下し、その仕組みには一貫性がなく、失敗を招くことになりかねない。

それはさながら、シートベルトやエアバッグが車に標準搭載されておらず、消費者があとから買わなければならない世界のようだ。これらは車の設計時から考慮されるべきだし、そのほうが最適な場所に設置されるだろう。このたとえ話は、システムにとって、最初から（デフォルトで）セキュアかつ信頼できること（secure and reliable by default）ことの必要性を示している。

最初からセキュリティと信頼性について考える健全な文化を持つ組織は、開発者に、それらをプロジェクトの初期段階で（例えば設計段階で）考えること、そして実装のイテレーションを繰り返すなかでも考え続けることを促す。そのように成熟した製品は、セキュリティと信頼性を維持しつづけることが自然にできるようになる。

Google の、最初からセキュリティと信頼性を考える文化（a culture of security and reliability by default）の発展についての知見を、本書の Chapter 12, 13, 19 で示した。

Culture of Review

強いレビュー文化が整っている環境では、誰もが変更を承認する際に、自分の役割について前もって考えることを促される。本書では、以下のようなピアレビューの方法を取り上げてきた。

最小権限（least privilege）を保つための、アクセスや変更の認可に関する複数人でのレビュー（Multi-party authorization reviews）（Chapter 5）
コードの変更が適切かつ高品質（セキュリティと信頼性の考慮も含む）であることを保証するためのピアレビュー（Chapter 12）
本番システムに適用される前の、設定変更のピアレビュー（Chapter 14）

このような文化を構築するためには、レビューの価値とそれをどのように実行するかについて、組織全体で幅広い理解が必要である。

レビューで期待されることを明らかにするために、変更レビューのプラクティスは文書化されるべきである。レビューで拒否されたときに、その理由を明確にできることは、感情的にならないためにも必要である。

レビューの文化は、そのレビュープロセスに全員が参加することを必要とする。その人がシニアロールであるとか、参加したくないとかいう理由で、レビューから逃れることを許すべきではない。

（コラム：Reducing Friction）軽微な変更に対しては、より軽量なレビューを選択肢として提供できるようにすることを考えてみよう。Chapter 14 で述べたとおり、レビューはそれが必須である場合のみ有効に働く。ただし、どのような場合に軽量レビューを実施できるかを、ガイドラインで明確にする必要がある。

レビュアーが、意思決定するための十分なコンテキストを知らない場合は、レビューを断るか、他の人にレビューを回すという選択肢を保証すべきである。

自動チェックは、このようなコンテキストの構築を補助することができる。例として、Chapter 13 では、コードのサブミット前に、開発者とレビュアーに、セキュリティ問題を自動的に示すツール Tricorder を Google がどのように使っているかを示した。

Culture of Awareness

組織のメンバーが、自分たちのセキュリティと信頼性に対する責任に気づいていて、それを実践する方法を知っていたら、良い成果物を効率的に生み出すことができる。認知と教育の戦略は、強いセキュリティ文化を作るための鍵である。

Google では、従業員の教育のために、複数のアプローチを取っている。広範囲には、年1回の必須のトレーニングを全従業員に提供している。さらに、ここで伝えたメッセージを、役割ごとの特別なプログラムで強化している。Google での長年の実践により、有効とわかったいくつかの戦略を以下に示す。

Interactive talks
- 参加型の講演。例えば、Google では重大なインシデントに関する主要な根本原因および緩和策について共有することで、私達がなぜこのようなトピックに集中しているかを従業員によく理解してもらうことができた
Games
- 例えば、ゲームを通して XSS を見つける方法および悪用する方法を学べる XSS game
Reference documentation
- Chapter 12 で、リファレンス文書の重要性を書いた。詳しい情報を口頭で正確に伝えることは難しい
Awareness campaigns
- 開発者に、最近のセキュリティおよび信頼性に関する問題について知ってもらうことは難しい。この問題に対して、Google では1ページ形式の週刊のアドバイス "Testing on the Toilet" を発行している。これを全 Google オフィスのトイレに張り出している
Just-in-time notifications
- なにか、良いプラクティスに反したことをした瞬間にタイミングよく知らせることで、従業員の理解を深めることができる。例えば、ソフトウェアを信頼できないリポジトリからアップグレードしようとしたときや、センシティブデータを未承認のクラウドストレージシステムにアップロードしようとしたときにポップアップを出す。Chapter 13 に、これに関連した話題を書いた

Culture of Yes

時とともに、組織にはリスクに対して保守的な文化が育ちやすい。特に、セキュリティ上の欠陥や信頼性の問題によって、収益を失ったり何らかの悪影響を被ったことがある場合はそうである。

そのような考え方は No の文化（a culture of no）、すなわちリスクのある変更や、ネガティブな結果になりうる変更を回避する文化に繋がりうる。健全な組織は、ある程度のリスクはあるがメリットのある選択を取る際に、"yes" と答えるための方法を持っている。

例えば、Chapter 8 の Google App Engine の例がある。Google App Engine は悪意のあるコードがその上で動く可能性があるサービスである。そのようなリスクはあるが、製品チームとセキュリティチームが連携することで、最終的にこのプロダクトをローンチできた。

リスクを許容するための他のアプローチには、エラーバジェットがある。

（コラム：Balancing Accountability and Risk Taking）コードレビューを行う人が、自分が最後の砦だ、と思うようになると、リスクのある変更は受け入れがたくなっていく。リスクを共用できるようにするためには、このプレッシャーを下げるための、例えば、最小権限や、回復性、テストといった要素のためのデザイン戦略が必要である。多層的なアプローチで、個人に対する重荷を軽くすることができる。例えばレビューでミスを犯しても他の自動的なチェックが働くなど。

Culture of Inevitably

完璧なシステムなどなく、どんなシステムもいつかは失敗する可能性がある。Googleでは、失敗はいつでも起こりうると仮定している。実世界のシステムは、100％セキュアかつ信頼できるとは決して言えないと私達は知っている。

Chapter 16 では、このような不可避の問題に対する準備の必要性について議論した。不可避の文化（culture of inevitability）を持つチームは、大規模な障害（disasters）に備えるために時間を割き、そのような場合に効率的に対応できる。

また、本書の Chapter 18、および SRE 本の Chapter 15 にある、批判のないポストモーテム（blameless postmortems）もその一例である。

Culture of Sustainability

システムの信頼性とセキュリティを長期的に維持するためには、その組織が、それらを改善するための努力を継続的に行う、つまり十分なリソース（スタッフと時間）を割き続けることを保証しなければならない。

この努力を維持するために、チームはリアクティブな仕事と、長期的に報われるプロアクティブな投資の間でバランスを取ることができなければならない。Chapter 17 の例では、効率的なチームは、ある1人に過大な責任を追わせないために、ハードワークを大勢の人の間で分かち合っていることを示した。

持続性の文化（a culture of sustainability）を持つ組織では、改善のための投資と同様に、運用業務（例えばインシデント対応）を扱うために必要な工数も計測する。ストレス、燃え尽き、士気（morale）を考慮する。

Google SRE の "follow the sun" シフトもその一例である（コラム：Sustainable Reliability and Security Culture at Google）。

持続性の文化を持つということは、例外的な状況では通常の業務量から一時的に逸脱することがありうるということを理解し、そのような逸脱を扱うための良いプロセスを持っているということも意味する。そのような例外的な状況が解決したあとで、引き続き持続性の文化を維持するために、以下のようなことを考慮するとよい。

一時的な対応は、問題が解決したらもとに戻す。トイルが増えたまま戻さない、ということにならないようにする
通常のプロセスを迂回する権限を持つ、専任のグループを持つ。ただし、ベストプラクティスを迂回したり覆した点を記録しておき、必ずあとで対処する
イベントが完了したら、ポストモーテムにて、今回の障害を導いた報酬システムを必ずレビューすること。開発を優先して信頼性やセキュリティを蔑ろにする文化では、このときに技術的負債を生む可能性がある

Changing Culture Through Good Practice

セキュリティと信頼性に関する新しい活動は、恐れを生じさせる。それは、開発速度を低下させるのではないか、新しいリスクを生じさせるのではないか、という恐れだ。しかし、著者らの意見としては、そのような摩擦を生じさせるというのは神話（myth）である。

もし、ある種の文化的な配慮を行ったうえで変更を実施すれば、それらの変化はすべての人の経験を向上させることができる、と私達は信じている。

この節では、変化を導入するための技術的な戦略について議論する。あなたは CEO やリーダーではないかもしれないが、すべての開発者、SRE、セキュリティ専門家はそれぞれの広さで影響を与えるための手段を持っている。

Align Project Goals and Participant Incentives

信頼を築くのは難しく、失うのは易しい。システムを設計、実装、維持する人々が、異なる役目を超えてコラボレーションするためには、みんなが共通の報酬システム（common reward system）を共有する必要がある。

技術的なレベルでは、プロジェクトの信頼性や安全性は、SLO のような測定可能なメトリクスや、脅威モデル（例：Chapter 2, 14）を通して評価できる。プロセスや人のレベルでは、信頼性や安全性への貢献がキャリアアップに繋がることを保証すべきである。理想的には、そのような評価基準が明文化されているべきである。

プロジェクトのゴールを組織の目的に揃える一方で、個人のインセンティブに揃えない場合、それは非協力的な組織文化に繋がりかねない。

Reduce Fear with Risk-Reduction Mechanisms

大きな変更は、組織の中で反対されることがある。そのような場合は、よいデプロイ上の選択を提示することで、信頼を得ることができる。Chapter 7 で触れた話題だが、組織文化への影響についてここで改めて触れる価値があるだろう。

Canaries and staged rollouts
- 安全なリリースを繰り返すことで、次第に、組織はそのような気配りと勤勉さをすべての変更に期待するようになる。そして変更に対する信頼を構築し、恐れを減らすことができる
- このようなリリース方法については SRE workbook の Chapter 16 で触れた。また本書の Chapter 19 では Chrome のリリースサイクルについて議論した
Dogfood
- 自分たちが実施しようとしている変更を自分たち自身に適用し、それをユーザーに示すことで、その変更が安定性や生産性に与える影響をユーザーに保証することができる
- 例えば、多要素認証のような新しいメカニズムを導入する際に、まず自分たちの業務に導入する
Trusted Testers
- 社内でテスターを募集し、フィードバックをオープンに求める。そして、フィードバックを活用して、自分たちがフィードバックを聞いていることを知ってもらう
Opt in before mandatory
- いきなり必須にするのではなく、移行期間を設ける。いつ有効化するかを選択できるようにする
Progressive stringency (漸進的な説得力、妥当性、厳密さ)
- いきなり厳密なポリシーを適用するのではなく、徐々に適用できないかを考える
- 例えば、最小権限を例に挙げると、最初は対象を開発者に制限したり、権限がないアクセスを拒否するのではなくエラーを出すだけに留めるなど

Make Safety Nets the Norm（セーフティネットを規範にする？）

信頼性およびセキュリティに対する改善が、あなたが今まで頼ってきたリソースを使えなくすることはよくある。例えば、いままで root 権限を使えていたものが使えなくなったら。緊急時の作業の妨げにならないか？といった恐れを抱くことは自然なことである。

breakglass procedures のようなセーフティネット（Chapter 5）を提供することで、変更に対する恐れを減らすことができる。セーフティネットは最後の手段であって、便利な代替手段とみなされないようにすべきである。また、システムを安全に保つための段階的なロールアウト手段が、場合によっては緊急リリースの邪魔になるかもしれない。変更を即座にプッシュするための迂回手段があれば、そのような懸念は避けられる。この種の状況については Chapter 14 で議論した。

Increase Productivity and Usability

セキュリティ及び信頼性の観点での組織的な変更が、生産性や使い勝手を落とすのではないか、という恐れが生じると、その導入を難しくする。そのため、導入戦略について注意深く考えることは重要である。私達は、以下のテクニックが摩擦を減らす助けになることを見てきた。

Build transparent functionality
- Chapter 6, 12 にあるように、デフォルトの選択が良い状態なら、罰を与えるようなことをしなくても、開発者は正しいことをする
- このアプローチではれば、開発者自身がセキュアかつ信頼できるシステムの恩恵を受けるだけでなく、これらの活動をシンプルかつ簡単にしようとしているあなたの意図を理解できる
Focus on usability
- 今までの仕組みより、新しい仕組みのほうが使いやすければ、導入は簡単に進む
- chapter 7 の二要素認証の例では、認証はセキュリティキーをタッチするだけで済むようになり、パスワードの定期変更も求められなくなった
Self-registration and self-resolution
- Googleではインストールして良いソフトウェアの allow list と deny list を持っている。中央集中で管理していると、そこが許可のボトルネックになってしまう
- Googleでは、これらのリストにないソフトをインストールしたいときには、Upvote というポータルを通して、必要な許可を迅速に得られるようにしている。また、大勢の希望があるときは自動的に許可する仕組みもある

Overcommunicate and Be Transparent

システム変更を主張する際に、コミュニケーション手段は結果に影響しうる。Chapter 7 および 19 で議論したように、よいコミュニケーションは変更への同意と信頼を得るための鍵である。

どのように変更が起こるかについての情報とわかりやすい知見を与えることで、人々の恐れを減らし、信頼を構築できる。私達は以下に示す戦略が成功するのを見てきた。

Document decisions
- 変更を行うときは、なぜそれが起こっているのか、成功はどのように見えるのか、操作が状況を悪化させたらどのように変更をロールバックするのか、懸念がある場合は誰に話せばいいのかを明確に文書化する
- それが従業員に直接影響する場合は特に、なぜあなたがその変更を行っているのかを明確に伝える
- 注釈に、SRE が行う Production Excellence reviews についての記載あり
Create feedback channels
- 懸念を持つ可能性がある人々が使えるフィードバックチャンネルを作り、双方向のコミュニケーションを作る
- フィードバックフォームや、バグトラッキングシステムへのリンク、あるいは単なるメールアドレス
- 関係者を巻き込むことで、恐れを減らすことができる
Use dashboards
- あなたが人々に期待していることを明確に示し、その進捗に対するフィードバックを提供するためにダッシュボードを使う
Write frequent updates
- 変更に長い時間がかかる（Google の場合は数年に渡ることも）場合は、進捗を頻繁に（例えば月1回）ステークホルダーに共有するための担当者をアサインする。これは、特にリーダーへの、信頼を得る役に立つ

Build Empathy

チームを超えた共感（Cross-team empathy）は、それがシステムの信頼性とセキュリティに関わるものであれば特に重要である。なぜなら、Chapter 20 で論じたように、信頼性とセキュリティに対する責任は組織全体で共有されるべきものだからである。

Chapter 19 では、チームを超えた共感を作るためのいくつかのテクニック、特に実装、デバッグ、コード修正に対する責任を共有する方法について述べた。

共感を作るための他のアプローチとしては Job shadowing（他の人の仕事を後ろで観察する）や job swapping（仕事を交換する）がある。これらはトップダウンでの組織的な変更を必要とせずに実施できる。これは数時間から、（マネジメント層の許可は必要だろうが）数ヶ月までの幅がありうる。他の人にあなたのチームの仕事を経験してもらうことで、あなたは組織のサイロを壊して、共通の理解を作ろうとしているというシグナルを送ることができる。

Google の SRE Security Exchange Program は、他の SRE やセキュリティエンジニアを1週間経験できる（shadow, 後ろで観察する）プログラムである。この交換プログラムの最後に、SRE は自分たちのチーム自身と、ホストチームの両方に対する改善提案をレポートに書く。このプログラムは非常に低い投資で、組織をまたいだ知識共有の面で大きな利益を生んでいる。他には、SRE 組織に6ヶ月参加してもらう Mission Control program もある。

最後に、感謝を伝える仕組みの構築（building in mechanisms to say thank you）ーー簡単なメールから、より詳細な形式のものまでーーは、人々がお互いに対して与えるポジティブな影響を強め、正しいインセンティブを与える。Google には、長年に渡るピアボーナスの文化がある。これの、現金のやり取りがないバージョンは Kudos と呼ばれるもので、Googler は全員に見えるフォーム上で感謝を伝えることができる。いくつかのオフィスでは、感謝のポストカードも試してきた。

Convincing Leadership（リーダーを説得する）

もしあなたが大きな組織で働いているなら、あなたが行いたいセキュリティや信頼性に関する変更に対して、支持を得る（原文では get buy-in = 買付を得る？）のは難しいことだろう。多くの組織は、自分たちの数少ないリソースを、利益を生むために使うように動機づけされているため、彼らの目に見えない部分を改善するための支持を得ることは難しい。

この節では、そのような変更に対して、リーダーからの支持を得るための戦略について見ていく。これらは私達が Google で用いたものに加え、他の場所で用いられているのを見たものも含む。

Understand the Decision-Making Process

ここでは、リーダー（leadership）という単語は、方針決定やリソース配分、利害関係の調整にまつわる決定を行うことができる人々を緩やかに指すものとする。

あなたがそれらの人々に影響を与えたいので、それが具体的に誰なのかを明らかにする必要がある。あなたが大企業で働いていたら、それは VP であったり、上位の管理職かもしれない。スタートアップや非営利団体のようなもっと小さな組織なら、それは CEO かもしれない。オープンソースプロジェクトなら、プロジェクトの創設者かトップコントリビューターだろう。

「誰がその変更に対する決定権を持っているのか？」という質問への答えは、解くのが難しい場合がある。それは組織上のリーダーではなく、テックリードのような場合もある。また、複数の人の場合もある。Chapter 7 で述べた Chrome の HTTPS 対応の例のように、コミュニティの場合もある。しかし、この質問の答えを避けて通ることはできない。

意思決定者を見つけたら、その人が直面している困難や要求について理解しようとすべきである。それらを理解することは、あなたの提案する変更がうまくはまる場所を理解するために重要である。

Build a Case for Change

すでに述べたように、変更への抵抗は、恐れや摩擦の認識に起因する。しかし、多くのケースでは、変更の理由を理解していないことにも起因する。

成功する case-building process に必要なステップを以下に示す。

※ ここで言う case はどういう意味？リーダーに問題として認識してもらう、といった意味？

Gather data
- 変更が必要と思うに至った理由があるはず。それをデータで説明できること
Educate others
- 例えば、Google の Red Team postmortems（Chapter 20）。SREが直面するリスクの種類について、リーダーを教育するためのもの。もともとは教育が目的に作られたものではないが、会社の全階層における認識を高めることができる
Align incentives
- 他の面でもメリットが有ることを説明し、お互いにインセンティブがあるという状態にする
- 例えば、DDoS 攻撃に強いフレームワークを導入することで、セキュリティ上の利点に加えて、より安定したウェブサイトは売上を高めるという効果もある。これは企業のリーダー層にとって強い根拠になる
Find allies（支持者を探す）
- 支持者の存在は説得力を高めるし、あなたの論拠をピアレビューしてより強くしてくれる
Observe industry trends
- あなたが適用しようとしている変更が、他の組織がすでに適用している変更であれば、その他組織の経験はあなたの組織のリーダー層を説得する際の助けになるかもしれない。その特定のトピックおよび業界トレンドに詳しいエキスパートを呼んで、あなたの組織のリーダー層に説明してもらうことさえ可能かもしれない。
Change the zeitgeist（時代精神を変える）
- もしあなたが、あなたの問題について日々考えている人々の考え方を変えられるなら、そのあとで意思決定者を説得するのはより容易だろう。これは、あなたがその変更に対する広いコンセンサスを必要としているときに、特に有効である。Chapter 7 の HTTPS のケーススタディはこれにあたる

Pick Your Battles

組織が信頼性とセキュリティの課題に数多く直面している場合、継続的なアドバイスは、アドバイスされることへの疲れや、追加の変更への抵抗感を生んでしまう。あなたの戦う場所を慎重に選ぶ（pick your battles carefully）、つまり成功する見込みのある取り組みを優先し、勝ち目のない戦い（lost causes）の止めどきを知ることが重要である。

勝ち目のない戦い、つまり棚上げにしなければならない提案にも価値がある。変更をうまく主張できないときでさえ、自分のアイデアを裏付けるデータや、自分の計画を支持してくれる仲間がいること、そして問題について人々を教育することには、価値がある。将来、あなたの組織がその課題に取り組む準備ができたときに、それまでにあなたが準備したものがあれば、チームはより素早く行動することができる。

Escalations and Problem Resolution

最善の努力を尽くしても、セキュリティや信頼性に関わる変更についての意思決定の必要が、爆発的に表面化することがある。重大な障害やセキュリティ脆弱性により、あなたは急遽追加のリソースやスタッフを必要とするかもしれない。あるいは、2つのチームが問題解決の方法について異なる意見を持ち、意思決定の自然な流れが働かないかもしれない。

このような状況では、あなたはマネジメントチェーンから解決手段を探す必要があるかもしれない。意思決定のエスカレーションを行う場合、私達は以下のガイドラインを推奨する。

その状況に関する意見を、両方の側から提供するために、同僚、メンター、テックリード、またはマネージャーのグループを作る
そのグループに、現在の状況と、提案された選択肢を、マネジメント層のために要約させる
あり得る解決手段についてさらに調整するために、あなた自身のチームのリーダーにその要約を共有する
影響を受けるマネジメントチェーン全員にその状況を説明し、それぞれのチェーンでの適切な意思決定者を指名するための会議を設定する

具体例をあげると、Googleでは、セキュリティ問題に対するアクションについて、プロダクトチームとセキュリティレビュアーの間で意見が一致しなかった場合に、エスカレーションが必要になる。このケースでは、セキュリティチームからエスカレーションが開始される。Googleではこのようなエスカレーションを通常の企業文化の一部としているため、エスカレーションは対立的なものとはみなされない。

Conclusion

あなたがシステムを設計して管理するのと同様に、あなたはセキュリティと信頼性の目標を達成するために、時間をかけて組織の文化を設計、実装そして維持することができる。

セキュリティと信頼性の向上は、摩擦の増大に対する恐れや懸念を抱かせることがある。そのような恐れに対処し、変更の影響を受ける人々からの支持を得るのを助けるための戦略がある。あなたのゴールと、リーダーを含むステークホルダーのゴールを揃えることが鍵である。ユーザビリティに焦点を当て、ユーザーへの共感を行動で示すことで、ユーザーが変化を受け入れることを促すことができる。他の人が変化をどのように認識しているかを理解するために小さな投資をすることで、あなたの変更が妥当なものだとユーザーに納得させることができるかもしれない。

この章の冒頭で述べたように、同じ文化は2つとして無いので、本書で紹介した戦略をあなた自身の組織に適合させる必要がある。あなたの組織で最も解決すべき問題領域を選び、それを時間をかけて解決していくことが必要である。