BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アーティクル ”分かりやすさ” - 追跡されていない最も重要な指標

”分かりやすさ” - 追跡されていない最も重要な指標

キーポイント

  • Change is the only constant in life. Nowhere is this more apparent than in software engineering, where a developer’s daily job is to modify, adapt, tweak, or even remake the systems they are responsible for. 
  • As applications grow and teams scale, it becomes more challenging to maintain a clear understanding of the software itself. Complexity hurts engineers’ ability to understand and effectively change the software as needed. 
  • Understandability is the concept that a system should be presented so that an engineer can easily comprehend it. The more understandable a system is, the easier it will be for engineers to change it in a predictable and safe manner.
  • A system is understandable if it meets the following criteria: complete, concise, clear, and organized.
  • Understandability and observability are complementary, but the latter focuses more on two things: the ability to alert when the system misbehaves and help to identify the causes so that normal service can be restored; and the ability to help identify performance bottlenecks so that additional resources can be allocated or that the relevant teams be informed.
     

原文(投稿日:2020/06/06)へのリンク

2,500年前、ヘラクレイトスは、"人生で唯一不変なものは変化だけである(change is the only constant in life)"と言いました。ソフトウェアエンジニアリング以上に、この言葉がぴったり当てはまる場所はないでしょう。自らが責任を持つシステムを修正し、適用し、調整し、時には作り直すのが、開発者の日々の仕事なのです。人間の行動分野の中において、ソフトウェアエンジニアリングを比較的ユニークなものにしているもうひとつの側面は、コンピュータサイエンスの技巧で定義された人工的な境界の中で、私たち自身が作業の形を作らなければならないという、途方もないほどの自由度です。

その巨大な力を効果的に駆使するための私たちの能力は、大変に驚くべき制限 — 私たち自身の創造物を知る能力において不足をきたすことが少なくありません。アプリケーションが巨大化し、チームが大規模になるにつれて、ソフトウェアそのものに対する明確な理解を維持することが困難になり、聖書におけるバベルの塔のごとくプロジェクトを崩壊させるのです。

典型的な例

商業的なソフトウェアエンジニアリング事業の大半は、白紙の状態からは始まりません。何らかのコンピュータ言語で記述され、いくつかのフレームワークやライブラリを導入し、ある種のオペレーティングシステム上で動作する、既存のアプリケーションが存在しています。

新機能の開発や既存バグの修正など、いくつかの要件に合うように既存のアプリケーションを変更する作業は、私たち(あるいは私たちのチーム)に任されます。それと同時に、既存のすべての文書化された(あるいは、されていない)要件を引き続き満足することや、既存の動作を可能な限り維持することも求められます。

そして、単純なコンピュータサイエンスの問題を解くためにコードを書く(あるいはStackOverflowから答をコピーする)のと、同じ問題を大規模かつ複雑なシステム内でやるのとでは、複雑性のレベルがまったく違うという、すべての若手ソフトウェアエンジニアが仕事の初日に気付くような気付きに至るのです。

"分かりやすさ"とは何か?

金融業界から知恵を拝借して、分かりやすさ(Understandability)を定義してみましょう。"理解可能性(分かりやすさ、understandability)とは、エンジニアが容易に把握できるようにシステムを提示すべきという概念である。" システムが分かりやすければ、予測可能かつ安全な方法で、容易に変更できるようになります。

このアナロジをさらに進展させると、システムが"分かりやすい"ためには次のような基準を満たせばよい、ということが理解できます。

  • 完全性。システムは、すべての重要な情報を網羅して事前定義された、ソースのセット(ソースコード、ドキュメントなど)を用いて提示されなければなりません。重要な情報がエンジニアのイマジネーションのままで残っていてはならないのです。
  • 簡潔性。システムのソースコードは、ユーザに過度な詳細情報を詰め込むべきではありません。ここでは、関心の分離抽象化を活用することで、エンジニアが目前のタスクに集中することが可能になります。
  • 明快性。読み手が見渡しやすいような表現手法を使用してください。ここでは一貫性、コーディング規約、ソースコードのフォーマット、コードコメント、構文の強調表示、といったものが大きな違いを生み出します。
  • 組織性。システム内で相互参照された情報を簡単に見つけられることが必要です。モジュラリティ、ソフトウェアのドキュメント、ソースコードのナビゲーション管理、ソースコード管理ツールを使うことで、システム内を自由に移動することが可能になります。

実行時の分かりやすさ

ソフトウェア・アズ・ア・サービス(SaaS)など新たなソフトウェア提供パラダイムの台頭に伴い、多くの企業がソフトウェアのトータルオーナーシップを実践し始めて、エンジニアがアプリケーションのライフサイクル全体を通じて責任を持つようになっています。

このような企業では、エンジニアがソフトウェアの運用方法を理解し、アプリケーションがユーザによって活用されるレベルを決定するものとして、分かりやすさがより強力な形となって現れています。

それにより、利用パターンや実運用時のインプットとアウトプット、実際のパフォーマンスおよび可用性などの統計的情報といった、極めて価値の高い情報が、必要と判断されたチームによってアクセス可能になるのです。

可観測性は分かりやすさではない

ここまで読んで、まさに可観測性や監視ツールの目的とするものではないか、と思うかも知れません。残念ながら、それは違います。これらのツールは、もっとトラディショナルなITの問題をサポートするためのもので、次のような機能を提供しています。

  1. システムの不正な動作を警告して、根本原因の特定を支援し、正常なサービスへの復帰を可能にします。
  2. パフォーマンス上のボトルネックを特定して、追加のリソース配分を行ったり、関連チームに通知したりします。
  3. 運用、セキュリティ、サポートを目的とした詳細なイベントログを保持します。

これらはみな、ITがはるか昔から取り組んできた立派なユースケースであり、そのROIも極めて明確であるため、数多くのベンダが問題解決のための優れたツールを提供し続けてきました。しかしながら、いずれもソフトウェアエンジニアリングチームが責務を負うユースケースではないため、これらのツールは彼らを支援するためのものではないのです。

これらのユースケースすべてに共通するのは、システムの基本的動作に関する知識を持つ誰かが、特定の状況においてシステムがどのように振る舞うのかを正確に把握することで、それに対して適切に対応できるようにする必要がある、ということです。これはつまり、事前に定義されたイベントセットに関わるデータを収集するということであり、中でも特にシステムと外部とのインタラクションが重視される傾向があります。

一方でソフトウェアエンジニアリングチームは、システムの内部動作に関する深い知識を持っていて、それがどのように動作しているかを理解することに関心があるのです。収集する必要のあるデータは日毎(時間毎とまでは言いませんが)に、彼らがシステムに施した変更毎に変わります。

複雑性に打ち勝つ

拡大と変化に伴って、ソフトウェアは複雑さを増します。複雑性の大きな部分を占めるのは、ビジネス要件の数は永遠に増え続けるという、単純な事実に由来する生得的なものなのですが、それ以外の部分は、アプリケーションの目的の変更や不適切な設計選択が原因となって、時間の経過とともに生じる望まれざるものです。これは一般的に技術的負債(tech dept)と呼ばれています。

原因が何であれ複雑性は、ソフトウェアを理解する、要求に従った効果的な変更を行う、というエンジニアの能力を低下させます。この問題は通常、人員の離職による知識喪失によってさらに悪化します。

当然ながら、ソフトウェア業界においては、ソフトウェアの複雑性は最小化されるべきである、というのが常識です。ソフトウェアが複雑になるほど、新機能の開発に多額の費用がかかるようになり、システム全体の品質は低下します。複雑性を最小限に維持しながら、システムとチームのスケールアップを可能にするアプリケーションソフトウェアの構築法に関しては、多くの書籍が著されています。

新しいソフトウェアにおける"分かりやすさ"

ソフトウェアを新規開発する場合には、分かりやすさは無視して、その代用のひとつである複雑性への対処を優先する方法もあります。複雑さを回避し、低減することに注力すれば、分かりやすさは自ずと保てるからです。幸運なことに、ソフトウェアの複雑性を重視したソフトウェア開発ツールやテクニックは、数え切れないほと存在しています。

まず何よりも、質の高い要員で始めることです。才能のあるエンジニアたちは、自らの経験を引き出して、ソフトウェアのソースコードとアーキテクチャの両面から、複雑な問題をシンプルかつエレガンスな方法で表現して、理解の容易なソフトウェアを開発してくれます。

次に、システムを可能な限り小さくしましょう。小さなシステムは本質的に複雑性が低く、理解が容易だからです。本当に必要なビジネス要件を重視し、必須ではない要件、少なくとも一時的な要件については放棄することによって、システムを"トップ"から削減することが可能になります。また、新たなプログラム言語や高度なフレームワーク、最新のデータベースなど、高レベルの抽象化を用いることによる"ボトム"からの削減も可能です。

最後に重要なのは、複雑性が発生した場合に対処するための足場を確保しておくことです。ユニットテストとシステムテストのふたつの形式で自動テストを記述して、エンジニアリングチームが複雑性を排除するためのリファクタリング作業を安全に行えるようにしてください。高品質の監視ツールを導入すると、システムを高いレベルで理解する上で役に立ちます。インテグレーションとデプロイメントのパイプラインを自動化して、改善のイテレーションの速度を向上させましょう。

既存ソフトウェアの"分かりやすさ"

一方で、既存のソフトウェアに関しては、エンジニアリングチームがコードの理解に失敗したことを、避けがたい天災であるとして受容する傾向があります。複雑性に正面から取り組む方法は、もはや分かりやすさを改善するための有効なアプローチではありません。

大半において、目の前にあるレガシシステムは、ずっと前にいなくなった人たちが、現在使われているよりも低レベルな機材を使って記述したものであって、その上、何の足掛かりも残されていないのです。返済しなければならない技術的負債や、理解できないほど"読めないコード"に不満を言ったところで、何の救いにもなりません。あるいは、長期にわたるリファクタリングやマイグレーションを思い描いたとしても、希望が通ることはまずないでしょう。

ここで役に立つのが、製品デバッグプラットフォームです。エンジニアが取り組んでいるコードを、その動作中の深部まで見えるようにすることによって、内容が理解できるようになります。その上で、さまざまな環境やユースケースにわたる動作(cookie crumbles、クッキーの割れ方)を追えば、複雑性をひとつひとつ取り除くことができるのです。

最後のことば

ここまでの考察で、ソフトウェア開発における分かりやすさの重要性について、よりよい視点を得ることができました。一方で、コードの可読性とメンテナンス性を維持することが重要であり、ソフトウェアエンジニアリングの多くがその技能を重視しているということを、私たちは常に理解しています。さらには、ソフトウェアが成長し進化する時間の中で、それがどれ程の違いを生み出し得るか、という点についても、私たちは多大な感謝の念を抱くようになっています。

その一方で、複雑性に対処し、よりよい、よりシンプルなソフトウェアを設計し記述することで、分かりやすさはいつでも改善することができる、という仮説に挑戦もしているのです。大半の場合において、私たちは列車に途中から乗り込む立場であって、行き方をコントロールすることはほとんど、あるいはまったくできません。ですから、重要なメトリクスとしての分かりやすさの追跡と管理に着手して、理想的な条件に遠い中であっても、エンジニアリングの速度と品質を最大化する必要があるのです。

著者について

Liran Haimovitch氏はRookoutの創業者のひとりでCTOです。アジャイル、リーン、DevOpsといった最新のソフトウェア方法論を提唱し、ソフトウェアが実際に動作する方法を理解することに情熱を持っています。コードを考えていない時の氏は、ダイビングかハイキングをしています。

この記事に星をつける

おすすめ度
スタイル

特集コンテンツ一覧

BT