2011年に注目したい技術 – ThoughtWorks Technology Radar

感想おまちしてます!

Screen shot 2011-03-17 at 6.16.24 PMデブサミ2011でちらちらでていたグラフが気になったので調べてみた。

その資料はマーティン・ファウラーさんが所属することで有名なThougheWorksという会社のTechnology Radarというものだった。資料はHTMLやPDFで確認でき、2011年版の資料はこちらにある。

Publickeyさんでも取り上げられており、毎年チェックしたい資料の一つになった。

レーダーは以下の領域に分かれる。

  • Hold:注意をしはじめるレベル。
  • Assess:将来的にどう影響をおよぼすか知るため、価値を探し始めるレベル。
  • Trial:将来性を感じるためどのように利用するかを調べることが重要で、動向を追跡べきレベル
  • Adopt:試用期間を終え、利用方法などがパターン化され、採用に至るレベル

新しく登場したものは三角。既知のものは丸で表されている

*

ビジネスは24時間365日動きつづけている。情報はビジネスの意思決定を必要とし、意思決定はETL(データを抽出し[Extract]、それを加工し[Transform]、データベースなどに書き込む[Load])といった、バッチ処理のような時代遅れの方法を使っている。そんなことをして作られたデータすら時代遅れで、トランザクションが発生するたびにデータに反映するようなリアルタイムビジネスインテリジェンスを手に入れる必要がある。

Screen shot 2011-03-18 at 10.42.13 AM

以下、技術面で新しく登場した技術

  • Smart System (http://www.economist.com/node/17388368) – スマートフォンのGPSやカメラはUIはSmart Systemの一例でしかない。Smart Systemはリアルとデジタルを融合させることで、次第に、我々の周りに広がっていくと考えられる。
  • DevOps – 開発と運用の関係悪化に注意を払った考え方。DevOpsでは、Agileプラクティスを運用部門にも適用する。DevOpsは、本番環境への継続的なリリースを生み出し、組織としての基板を確かなものにする。
  • Automated database deployment − 継続的なリリースがあたりまえになってくると、データベースも手動ではなく自動で変更を加えれるようにせざるを得ない。Automated database deploymentによって、アプリケーションとデータベースを自動的にリリースし、フルサイクルでデプロイできるようになる。
  • Acceptance Test of Journeys − 受け入れテストは、ストーリーベースのテストで、巨大となり、メンテナンスコストがかかってしまう。システム全体を通してのAcceptance Test of Journeysは、ユーザ操作の一連の流れであり、ビジネスとユーザの両方に価値を提供する。一連の流れだけでは、一部分しか品質を担保できないようにみえるが、この方法は、ユーザの状況に合わせて、それ以外の部分もテストで取り囲むように広がっていく。
  • Progressive enhancement (http://en.wikipedia.org/wiki/Progressive_enhancement) – Webデザイン戦略。強制的なUXを構築するWeb技術の中でユーザレイヤの部分を指す。Progressive enhancementは、あらゆるブラウザを通して、Webコンテンツにアクセスするというアクセシビリティに特化している。この戦略は、システムパフォーマンスからスケーラビリティまで、総合的な改善を可能にするものになる。
  • Concurrency Abstractions and Patterns – CPUはマルチコアの時代となり、モバイルのCPUもそうなってきている。Concurrency abstractions and patternsは、新しい考え方ではないが、広く知られているもので、特に、Clojure、Erlang、Retlangに見られるモデルである。イベントパターンは、テストが簡単で、スレッドや、ロック、セマフォよりもよいアプローチである。
  • Categorization of Technical Debt技術的負債は、ソフトウェア開発における妥協のメタファーとしてとてもわかりやすいものだ。不幸なことに、技術的負債は、チームの中でも混沌としており、優先度も下げられてしまう。Categorization of technical debtは、ユーザストーリに沿った類似した解決方法を見つけ出し、優先順位の付けられた負債を払い戻すことである。この方法は、チームをより重要な部分に集中させ、透過的で、測定しやすい形にしていく。

これ以外で、聞いたことのない技術でAdoptに近いレイヤのもの。

聞いたことのない技術要素は、海外ではすでに書籍化されていたりしている。また、ファウラーやジェフリーの記事は2001年〜2003年だったりするので、相当、昔からあり、徐々に注目されてきたということなのだろうか。