駆け出しITインフラ・エンジニア向けの書籍、資料まとめ

諸事情によりITインフラ力を向上中なので、自分用のメモ代わりに、参考にしている書籍、資料を載せておきます。

各プロトコルのRFC

基本中の基本である、各ネットワーク・プロトコルの仕様です。実装寄りの話は足りないし、より新しいRFCで上書きされることもあるようなので、これだけでは不十分ですが、非常にわかりやすいし、正確です。

参考書籍

実際の実務や泥臭い実装よりの話が中心です。

TCP/IP Illustrated, Volume 1: The Protocols

実装の話も含めて、プロトコルの解説が非常に詳しいです。

TCP/IP Network Administration

「実務のための本」という位置づけで、内容の深さ的に不十分な部分もありますが、ネットワークの設定や、トラブル・シューティングなどを体系立った形で一通り解説しています。より詳しい説明は、manコマンドや各ソフトウェアの公式ドキュメントを読むことをお勧めします。

The Art Of Capacity Planning

ITインフラで重要なキャパシティ・プランニングの解説です。上記の「TCP/IP Network Administration」と同じく、「実務のための本」という位置づけで、Flickrのエンジニアが実践している泥臭い（しかし効果的な）キャパシティ・プランニングを学べます。要するに、「とにかく測定するのが一番」ということのようです。

Webページ

OSやミドルウェアの公式ドキュメントなどです。ディストリビューションごとに異なるネットワークの設定や、初期化スクリプトの仕組みなどは、公式マニュアルを見たほうがわかりやすいですし、ミドルウェアの公式ドキュメントは、そのミドルウェア固有でない、一般的な考え方も解説されているので、他でも応用がききます。
なお、この中ではIBM developerWorksは公式ドキュメントの類ではないですが、クオリティが高いので載せておきました(さすが...)

Web動画

最近、充実してきているらしい、オライリーの動画を購入してみました。簡潔に要点を抑えているのでわかりやすいですが、あくまで「とっかかり」レベルなので、詳細は自分で実際に操作したり、RFCや書籍で深堀することをお勧めします。

個人的には、「値段相応でまぁまぁ満足」ではありますが、せっかく講師のレベルが凄まじく高いのだし、練習問題や、講師への質問、FAQなどの機能がほしいところです。

2014〜2015年に読んだお勧めの技術書のまとめ

今年は「システムの品質」が一大テーマでした。
現場の環境に合わせてテーラリングしつつ、実践していくのは大変です...

品質関係

Software Product Quality Control


最新の考え方、手法に基づく、ソフトウェア製品の品質管理についての教科書です。
ソフトウェアの品質管理の入門書的な位置づけで、ソフトウェアに限らない「品質」についての考え方や、
ソフトウェアの品質管理手法の歴史、ISO 9126や25010などの国際標準の概要など、ページ数が少ない割りに内容は多岐にわたります。
また、現場で使える実用性の高い手法を重視しているらしく、ドイツで開発されたソフトウェアの品質モデル「Quamoco Quality Model」による、システムの品質モデルの構築方法は現場レベルで非常に参考になりました。それ単体では意味が薄いISO 9126や25010の品質モデル（著者の分類だと、Definition Model)を、実際の現場の成果物レベルの品質特性に落とし込む手法は非常に洗練されていますし、各品質特性はステークホルダのビジネス・ゴールに紐づけられているので説得力があります。詳細は以下のスライドが参考になります。

The Quamoco Quality Modelling and Assessment Approach

あくまで入門書的な位置づけで各手法は触りだけしか触れないので、各章の参考書籍も合わせて読むと良いと思います。

Software Inspection


20年以上前の書籍ですが、ゼロ・ディフェクトを目指すためにIBMで実践されている（いた？）らしい、Software Inspectionという手法についての解説書です。インスペクションはJSTQB（Japan Software Testing Qualifications Board）のシラバスでも出てくるので、恐らくメジャーな手法です。前述の「Software Product Quality Control」で「古いけど非常に参考になる」と記述あったことや、現場のプロダクトの品質改善で悩んでいたので、続けて読んでみました。
ソフトウェアの欠陥の発見、解消、抑止は、インプットを入れてボタンを押すだけで対処方法が出てきたり、かっこいいパワポのお絵かきでどうにかなるような、生易しいものではなく、非常に泥臭い日頃の改善の積み重ねで実現されることがよくわかります。チェック・ルールやチェックリスト、手順などの各種ドキュメントの用意、チェック結果をデータベースに記録して次の作業にフィードバックするなど、継続的にPDCAが回る仕組み作りも大事ですが、結局、最後は現場の人間の「この現状を良くしたい！」というモチベーションに強く依存するようです。そのため、仕組みづくりの方法だけではなく、現場の人間のモチベーションを高めるためのヒントや、仕事を回すポイントもたくさん書かれており、「人を動かす仕事のやり方」という意味でも大変参考になりました。IBMのエンジニアリングは深いなぁ....

設計

Software Architecture In Practice


有名な「SEI Series in Software Engineering」の一冊です、どうにか読み終わりました。ソフトウェア・アーキテクチャの基本的な考え方や、アーキテクトに求められる仕事に始まり、ソフトウェア・アーキテクチャが満たすべき品質特性と、その品質特性を満たすための各種戦術、パターン、実際の現場で利用され、洗練されたソフトウェア・アーキテクチャの評価手法など、「なんとなく流行りのミドルウェアをいっぱい並べました」の遥かに先をいく内容です。
これ単体でも価値がありますが、ソフトウェア・アーキテクチャで担保する品質特性と、前述の「Software ProductQuality Control」で示されているISO 9126や25010で定義された品質特性の「差分」を見ることで、 ソフトウェア・アーキテクチャでは何が担保できて、逆に何が担保できないのかを考察したり、各種品質特性を満たすための戦術と、現実のミドルウェアやツールの手法を比較して、どのような取捨選択の結果、その戦術が選択されたのかを分析したりと、いくらでも応用が効きます。
抽象度が高い話ばかりではなくて、唐突に「.NET」「EJB」」「Python」などの単語が具体例で出てくるなど、「現場感」を忘れていないのもポイントが高いです。

データベース

Database Modeling and Design: Logical Design


データベースの設計、モデリングの体系だった教科書です。E-R図の各種方言や、概念設計、ビュー統合のような論理設計のポイントや、汎化、集約などのよくあるテクニックが非常に丁寧に解説されています。例があまり実践的ではないのが気になりますが、おすすめ。

High Performance MySQL: Optimization, Backups, and Replication


現場でMySQLを使うので、一通り読んでみました。「Expert Oracle Database Architecture」ほどの濃さはないですが、InnoDBのデータ構造やMySQLでのセオリー、レプリケーションなどの特徴的な機能の解説が丁寧になされているので、現場でMySQLを触る人はMUST BUYでしょう。
この本に書かれている内容程度は最低限理解しないと、使いこなすのが難しいと思われます。

コンピュータ

Write Great Code: Volume I: Understanding the Machine: 1


某Perl神お勧めの書籍です。大学でコンピュータを勉強していた人はおおよそ知っている話ばかりだとは思いますが、復習になるし、例や覚えるべきポイントが実践的なので読んでおいて損はないと思います。
私もアセンブリ・プログラミングなどほぼ未経験だし、大多数のプログラマは業務システムやWebシステムを構築しており、この本に書かれた内容を意識することは少ないかもしれませんが、それでも普段書いているコードの裏側にある「複雑さ」を意識すると、性能問題や意図せぬバグが発生する可能性が少なくなるのではないでしょうか。コンピュータの気持ちに近づける書籍です。

Business Engineeringを勉強してみる

私は今までフレームワークやツールの開発、技術支援等、設計、実装周辺しか担当したことがなく、Business Engineeringに世界に疎いです。しかし、世間的には(特にSIerでは)「ビジネスが最も大事」「設計、実装は下請けに出す」というのがトレンドらしく、私なりにBusiness Engineeringを勉強したので、簡単にまとめてみます。
(といっても本一冊読んだだけですが...)

なお、教材としては以下の書籍を使用しました。結構古いですが、同じ著者の「The Unified Software Development Process」でも頻繁に参照されているし、簡潔で分かりやすいのでお勧めです。



Business Engineeringとは何か?

Business Engineeringとは企業活動をEngineeringの観点で分析、設計、実装するということです。この時の活動の最小単位はBusiness Processとなります。Business Processは我々が普段行っている仕事(関連したタスクの集合)をまとめてEngineeringの対象として認識可能としたものです。目には見えない抽象ですが活動の実体は存在するので、コスト、スピード、アウトプット、品質などを測定可能です。ソフトウェア開発も当然、Business Processのインスタンスですし、ソフトウェア開発の成果物であるITシステムはBusiness Processの効率化、自動化のために開発されます。ITの活用が協調されがちですが、もちろん、業種や仕事の内容によってはITが殆ど関わらないこともありえますし、ITシステムはあくまでBusiness Processの一部分を担うにすぎません。

Business Engineeringを実現するためのフレームワーク


Business EngineeringはBusiness ReengineeringとBusiness Improvementの2つの活動からなります。Business Reengineeringはビジネスのラディカルな変革を狙うもので、その名の通り、ビジネスをフロム・スクラッチでEngineeringし直します。最近流行のSystem Reengineeringもこの活動の一環で、ITシステムをビジネスの変革に追随されるための活動です。Business Improvementはもっと穏やかでBusiness Processをモニタリングし、継続的に改善します。どちらの活動もITシステムによる支援が必要不可欠です。

Business Modelingとは何か?


Business Modelingとは、極めて複雑な企業活動を目的に合わせて抽象化し、目に見える形にしたものです。例えば前述のBusiness Processも見える化の対象になります。目の前の仕事をこなすだけならばModelingは必要ないですが、ビジネス上の重大な変更や選択を迫られたときに、自分達のことを把握していないと何もできなくなる可能性があるので、企業活動を見える化し、普段から管理することが重要です。

Object OrientationによるBusiness Engineering


参考にした書籍ではBusiness Engineeringの手法として、Object Orientationを活用しています。オブジェクト指向によるシステムの分析、設計の手法をそのままビジネスの世界に持ってきており、ソフトウェア開発者にはわかりやすいです。UMLの記法は以下のように対応します。

  • ユースケース図 -> Business ProcessのModeling
  • オブジェクト -> Business Processの主体である人間、またはシステム。ビジネスの見える化が目的であり、そのままOOPで設計、実装するわけではないため、複雑な関連や継承等のModeling手法に深入りしすぎないことがポイントです。
  • シーケンス図 -> 人、システム間のインタラクションの図式化。

例としてレストランのBusiness Processのうちの一つ、Serving Dinnerでは以下のようなオブジェクト図が示されています。恐らくこの時のActor, Boundary, Controllerの各オブジェクトは全て人間ですね。何がやりたいのか直感的にわかると思います。

上記のようにBusiness Processをソフトウェアシステムと同じ手法でモデル化することで、ITシステムとビジネスの連携、必要なエンティティの抽出等をよりスムーズに実施できますし、各タスク(あるいはプロセス全体)のソフトウェア化や、各アクティビティのVA, NVAを分析することで、外注化の検討にも使えるでしょう。例えば、最近の飲食店では注文処理がIT化されていることもありますが、Business Process上のOrderと、ITシステム上のOrderは同一のエンティティを指すと考えるのが自然だと思われます。

まとめ

本当に簡単な概要だけですが、Business Engineeringの世界を見てみました。ITシステムの役割、立ち位置を考えれば、ビジネスについて知ることは極めて重要なはずなので、少しずつ理解を深めていこうかと思います。

デザインパターンとは何か?

私のキャリアはわずか数年ではありますが、最近になってデザインパターンについて考えがまとまってきたので「そもそもデザインパターンとは何か」を簡潔に説明したいと思います。人によって捉え方は様々ですので、こういう考えの人もいるんだと軽く捉えて頂ければ幸いです。

初めに

Java等のオブジェクト指向プログラミング言語を学習していると、「デザインパターン」という単語を良く耳にします。しかし、一方で「デザインパターンは使えない」「実際の開発で役に立たない」という話も聞きます。というか、SIの世界では、開発プロセスの中で出てこないし、ふつう使わないですよね? この「デザインパターン」とは何者なのでしょうか?

結論を言うと、オブジェクト指向開発のコンテキストにおけるデザインパターンは、オブジェクトの設計の根幹を担うものです。ただし、オブジェクト指向開発プロセスにおいてのみ重要です。本記事では、デザインパターンが必要な理由、使われ方について説明します。

オブジェクト指向開発は難しい!

次にデザインパターンの前提となる、オブジェクト指向開発について解説します。

オブジェクト指向は開発プロセスとセット

オブジェクト指向は開発プロセスとセットでないと意味がありません。オブジェクト指向は「1実装技術」ではなく、日本で主流のDOAと同じく、開発プロセスのパラダイムそのものです。例えば有名な「Unified Process」はオブジェクトの、オブジェクトによる、オブジェクトのための開発プロセスです。開発プロセスそのものがオブジェクトであり、成果物もオブジェクトです。オブジェクト指向開発プロセスの歴史と具体的な手法については、下記の書籍が詳しいです。

The Unified Software Development Process

Object-Oriented Analysis and Design With Application

Object Oriented Modeling and Design

プログラミングありきの世界もあるのかもしれませんが、少なくともエンタープライズにおけるオブジェクト指向開発は、「顧客の要件と動くソフトウェアの世界のギャップを埋める」「コンポーネントの再利用により生産性を高める」等を目的として、開発プロセスの一環として進化してきたことがわかります。特にBoochの書籍ではドキュメント・ドリブン、構造化設計手法を採用した大規模プロジェクトで起こりがちな問題点と、それを乗り越える方法としてのオブジェクト指向開発手法が提示されており、衝撃を受けました。オブジェクトの役割を「stable intermadiate form」と表現しているもわかりやすくて良いです。
(極東の某国では未だに前者のパラダイムで頑張っていることが多いようです。「(当時の)多くの企業が20年以上前の古い開発プロセスで〜」等との記述がありますが、そこから数えて日本は40年遅れといったところでしょうか。)

また、Rambughの書籍ではモデルの本質が簡潔に説明されており、オブジェクト指向開発手法は元来、上流重視であることがわかります。コンピュータの世界から切り離されたシステム化対象(real world object)を抽出し、少しずつコンピュータの要素を肉付けするスタイルです。実装はできるだけ後工程に遅延させます(そして単純作業化する)

どの書籍も「開発手法としてのオブジェクト指向」がメインであり、オブジェクト指向を一実装技術と思いこんでいるエンジニアは一読することをお勧めします。多分、ソフトウェア開発の世界観が変わります。単純なCRUD + αなWebシステムならともかく、ある程度以上の規模と複雑さで、再利用性が高い領域でオブジェクト指向は極めて有効です。

オブジェクト指向開発の問題点

オブジェクト指向開発は優れた手法ですが、重大な問題があります。それは「オブジェクトの抽出」が極めて難しいという点です。Boochの書籍では「ソフトウェア開発をlabor intensiveでつらいものからcreativeなものに転換したい!」という熱い思いが語られていますが、その代償がこの難しさです。

そもそもオブジェクトはどこから来るのでしょうか? 一般的には、システム化する領域(Domain Model)でしょう。これらの領域からオブジェクトを抽出するMethodlogyは様々です。例えば、名詞がオブジェクトの候補、動詞がメソッドの候補になったりします(詳細は前述の書籍等を参照。他にもいっぱりあります。)

しかし、真面目に考えればわかりますが、動くシステムを作るにはDomain Objectを抽出するだけでは不完全です。それらのDomain Objectを生成、管理し、「つなぎ合わせる存在」が必要です。例えばAccountというオブジェクトがあったとして、それをどうやって生成、維持管理するのでしょう? また、Domain Object自身の粒度、関連、振る舞いの設計は自由度が高すぎるので、参考にできるテンプレートが欲しいと思うのが普通でしょう(詳細はRambughの書籍を参照。頭が痛くなります...)

そこでデザインパターンの出番です。デザインパターンは上記のオブジェクト指向設計の問題に対する処方箋となります。

デザインパターンの役割とは?

デザインパターンとは、一言で言ってしまえば、「オブジェクトの設計テンプレート」であり、オブジェクト指向開発プロセスで利用すべきものです。オブジェクトを設計、抽出するときに参考にします。

前述の通り、オブジェクトの抽出は極めて難しいため、経験者のオブジェクト設計の知見を再利用できる形でカタログ化し、開発者のレベルの底上げすることが重要です。その道何十年とやっていて、自分なりの方法論を確立しているならともかく、大多数の開発者には基礎知識として必須でしょう。
(もちろん、開発プロセスがDOAの時に実装ありきで気まぐれで使うべきではないでしょう)

もっとも有名なのはGOF本のパターンであり、デザインパターンといったら大抵これのことを指します。



次は、具体的なパターンの説明に入らず、誤解されやすいポイントであるデザインパターンの抽象度を見ていきたいと思います。

デザインパターンの抽象度は高い

デザインパターンはどこにでも存在します。GOF本の例が具体的すぎて、誤解されがちですが、ブロックのようにくっつけるというよりも、オブジェクトの関連、ライフサイクル等の設計に自然になじませる感じです。具体例としてJavaのAPIである「Servlet」を見ていきます。

ServletはHTTPのサーバサイドのReceive/Replyの処理を抽象化したものです。ServletのAPI一つとっても、GOFのデザインパターンの要素が複数含まれています(少なくとも、私はこう解釈しました)

  • オブジェクトのライフサイクル管理 => Singlton Pattern
  • リクエスト毎にインスタンスを生成せず、HTTP処理の外部的な特性をメソッドの引数とする => Flyweight Pattern
  • init, destroy等のコールバック => Template Method Pattern
  • Serviceオブジェクトや、フレームワークへの入り口 => Facade Pattern(見方によっては)

    • また、別のパターン本にあるIPCの抽象化パターン「Fowarder-Receiver Pattern」の実装そのものでもあります。入力がInputStream、出力がOutputStreamであり、プロトコルの実装を隠ぺいしたIPCメカニズムの抽象を提供します(現実には、実装であるHttpServletを相当意識しますが・・・)

    また、上記のデザインから、Servletの目的はあくまで「HTTP処理の抽象化」であり、開発効率を上げるための複雑な機能をゴテゴテ盛り込むべきではないということもわかるでしょう。他のJavaのフレームワークはServletを土台としていますが、それは「Servletが使えないから」ではなく、初めから意図された設計です。

    上記の例を見ていて、なんとなく察しがつく人もいると思いますが、パターンには以下のような特性があり、一筋縄にはいきません。非常にトリッキーで難しいです。

    • パターンは複雑に絡み合い、特定の目的のためにオブジェクトの振る舞い、ライフサイクル、関連、拡張、再利用性などを決定します。
    • パターンは抽象度が高く、設計の基本的な考え方のテンプレートなので、「パターンを適用する」というよりも、「目的に合わせてパターンを選択し、すり合わせる」作業が必要となります。目的ありきであることが重要です。

    Servletの開発者も、問題領域、制限等を良く理解したうえで、パターンカタログや他のAPIなどを参考にしながら、他のメンバとのディスカッションやプロトタイピング、コミュニティからのフィードバックを得ながら、現在のデザインにたどり着いたはずです。パターンを上手く使うコツは、「自分で問題領域を良く理解し、自分の頭で考えて、自分で手を動かしてみる」以外にないと思います。

    色々小難しいことを書きましたが、もちろん、パラダイムがDOAの場合はオブジェクト指向設計をスルーするのもありだと思います。

    パターンの効果

    パターンには様々な効果があります。

    • 語彙の共有 => 開発者間のコミュニケーションを円滑化します。「あんな感じ」とか言わないで済みます。
    • ソフトウェアのデザインの分析 => 何百、何千とオブジェクトの山があっても、設計的に重要なところや、設計の意図を理解できます。
    • オブジェクトの変更性、再利用性を高める => フレームワークやミドルウェアなどの再利用性の高い分野で特に威力を発揮します。

    しかし、デザインパターンには、複雑化という暗黒面もあります。基本的にデザインパターンありきで考えずに、オブジェクトの設計目標、目的ありきで必要に迫られたときに利用すべきです。

    様々なパターン

    デザインパターンやその亜種は様々です。もっとも有名なもののうちの一つは、POSA(Pattern Oriented Software Architecture)等で詳細に説明されている、Architecture Patternです。有名なLayer, MVC等が分類されます。また、今流行りのMicroservices Architectureも、Microkernel Patternの亜種として見ることができます。 極めて重要な考え方ですので、エンジニアならMUST BUYでしょう。

    コンポーネントの設計に影響を与えるデザインパターンに対して、アーキテクチャパターンはソフトウェアの根幹の設計なので、日本では方式設計、基本設計などと呼ばれます。アーキテクト的な観点では、デザインパタ-ンよりも重要です。

    また、デザインパターンにも、様々な亜種が存在します。

    POSAのデザインパターン

    GOFよりも特定の領域に特化したパターンたちや、GOFのパターンをオーバーライドしたパターン(嫌がらせっぽい...)が説明されています。VOL.2のパターンはAPサーバ, 非同期処理マニア向けです。

    Patterns of Enterprise Application Architecture

    エンタープライズ開発者には必須のパターンです。知ってるのは常識扱いでしょう。

    ほかにも、PLOPDのバラエティー豊かなパターンたち等、パターンの種類は豊富だし、日々増えています。また、自分たちで特定のドメインに特化したパターンカタログを作るのもありだと思います。

    まとめ

    以下、まとめになります。

    私の理解はまだまだ浅いですが、参考になれば幸いです。

JJUG CCC Fall 2014に行ってきました

JJUG CCC 2014 Fallに行ってきましたので、軽くまとめます。

イベントの概要

イベントの概要、タイムテーブルなどは、下記のURLを参照してください。

JJUG CCC 2014 Fall

会場の様子等

私は初参加なのですが、休日にも関わらず大盛況でした。
セッションにもよりますが、基調講演が実施されたホールは殆ど満席でしたし、Javaとその周辺技術に対する関心は高いようです。また、個別のセッションは人気や発表の雰囲気に差はあるものの、全体的に「真剣に聞こう」という雰囲気がありました。OracleとJava標準の話題が中心で、いまいち現実感が乏しいJava One報告会と異なり、コミュニティ主体で実践的な泥臭い話題が中心なのが理由かなと思います。

また、余談ですが、会場の入り口でスポンサーのOISIXさんが野菜ジュースを配っており、これがなかなか美味しかったです。ネットスーパーらしいので、スポンサーなのが意外ですね。

以降は私が参加したセッションのまとめになります。

K-1 基調講演1 : これからのJavaエンジニアの生きる道 橋本 吉治

当日のスライド

セッションのまとめと補足

Javaはあまり関係なく、これからエンジニアとしてどう生きていくか、という話題でした。
橋本さんは13年間務めたSIerからベンチャーへ転職されたそうですが、その理由は技術の進化の速度が非常に早く、必ず変化が起きる(要するに今の会社ではその変化についていけない)と考えたからとのことです。

主な革新が進む技術領域として、クラウド、人工知能、Java(Javaのイベントなので・・・)を挙げられています。筆頭であるクラウドは、最近は単に早くて安いだけではなく、自前で構築するのは無理なレベルの高度なサービスが提供されており、最早、「安いから」ではなく、「リッチなサービス」が選択する理由になっているそうです。

私が普段見ている情報サイトinfoworld.com(結構、有名?)でも、クラウド関連の話題は非常にホットです。人工知能と絡んできますが、IBMはWatsonをIBMのBluemix Cloud ServiceのAPIとして提供を開始しています。


IBM debuts first Watson machine-learning APIs

別の記事では、Watsonの利用促進のために、開発者向けに無料のお試しプランを提供する話題もありクラウドは単にコンピュータをいっぱい並べて安く提供することから、高度なサービスを提供する実行基盤に進化しています。
(こうなると、もはやオンプレミスに価値は無いんじゃ・・・。勉強用にはなるけど。)

AIについては殆どわかりませんが、ざっくり言うと、近年のWebの発達で膨大なデータを取得可能となり、実用性が大幅に向上したそうです。AI技術の進化によって、単純な作業(コールセンター等)が徐々に不要になっていく流れで、IBMのWatsonを国内の銀行が導入する話も進んでいるので、AIは避けては通れない技術になりそうですね。
(専門的過ぎて、ほかの技術と兼務できないんじゃ・・・。そうでもない?)

Javaに関しては、言語そのものはともかく、枯れていて性能、信頼性の高い実行基盤(JVM)の価値は非常に高く、「(上で動く言語は別物かもしれないけど)20年使われたものは、50年後も使われるだろう」とのことです。Web業界の流れは非常に早いので、Web業界に追随するために2年毎にメジャーアップデートが入る(そして、10年くらい経った古い仕様が切り捨てられる)流れは変わらなさそうですね。

今後のエンジニアに必要とされる技術は、上記の「クラウド」「AI」「Java」のほかに、グローバル対応のための英語力(+多分、数学力)が主ですが、結局、人間の活動なので「最後は熱い心!」とかっこよくまとめられていました。また、企業が社員を教育する余裕が無いので、コミュニティは非常に重要とのことです。

雑感

セッションの内容は真っ当だし、上記の話を「そんなことは無い!」と真っ向から否定できる人は殆どいないでしょう。
(アンテナの感度が低い、あるいは隔離された世界にいる人は除く)

SIの世界からは全く想像もつかない、厳しい世界ですが、セッション中でも述べられていた通り、デジタル・ビジネスの市場は急拡大するので、キャッチアップできれば、いくらでもチャンスはありそうですね。むしろ同じことの繰り返しにならず、いつまでもやることがあるので、楽しみながら仕事をできると前向きに取り組むべきかな、と思います。

また、管理、パワポ、政治劇がメインのSIerの世界では、上記のようなテクノロジの変化を想像すらできないのではないでしょうか。というか、上記の世界を開発標準とか、開発プロセスに落とし込むのは非常に難しいでしょう。誰も今までやったことがないことに、標準もプロセスもないので、エンジニアがその都度、最良と思われる方法を考える必要があり、アジャイルが最も得意とする世界ですね。

K-2 基調講演2 : Java 2014 将来に向かって Simon Ritter (オラクルコーポレーション Java エバンジェリスト)

スライドが見つからないorz

まとめと補足

Oracleの偉いおじさんによる宣伝です。Oracleはコミュニティを大事にします、世界ではこんなにJavaのイベントが盛んです etc... あまり興味無いので以下略。通訳の人大変そう。

R1-1 私がTDDできないのはどう考えてもお前らが悪い！〜エンタープライズJava開発でのTDD適用の勘所〜

当日のスライド

まとめと補足等

実案件でTest Driven Developmentを導入するときの難しさ、ポイント等が中心となる話題でした。
どんな技術、開発技法でも重要ですが、教科書に盲目的に従わずに割り切るのが重要なようです。このケースでは「テストファースト」の原則も、問題点を認識したうえで「同一Sprint内で記述すれば良い」というように緩和していますね。テストはプロダクトのための手段なので、「テストがプロダクトの品質保証の手助けになっているか(むしろ負担になっていないか)」を常に意識しながら、全体最適を考えてアレンジすると良いようです。

細かい技術的な話題は省きますが、KPTを地道に回す、プロジェクト・メンバにノウハウを伝授する、開発メンバの一体感、チームの養成、信頼関係の醸成等、地道な人間ドリブンの活動が重要ですね。

雑感

セッションの中心はテストですが、実際に開発するうえでテストだけを考えるわけにはいかないので、実質的に上手いアジャイル開発プロセス(この場合、Scrum)の回し方になっているのが印象的です。ScrumのSprint Executionは決まったやり方がなく、開発者を信じて、その都度、最良と思えるやり方で進めるものらしいですが、このケースではお互いに信頼関係があって、皆で同じ目標に向かって進んでいたので上手くいったのでしょうね。遣り甲斐がありそうで、とても羨ましいです。
(そういうところで働いてみたい・・・)


ただし、開発者がもう1〜2桁増えて拠点が分散したら、トップダウンで戦略ゲーム的な進め方をするしかない気がします。このやり方でどこまでスケールするのか興味がありますね。
(大手SIerが得意とするのは後者の戦略ゲーム的な開発。開発者は戦場の駒・・・。)

テスト系の小技(テーブルのΔAssertion, SpringのApplicationContextのCachingとその問題点等)も如何にもありそうな問題に対する対処方法なので、頭の隅に入れておこうかと思います。

R1-2 Spring Boot + Doma + AngularJSで作るERP（統合基幹業務システム）松崎 学

当日のスライド

まとめと補足

AngularJS, Spring Boot等の技術で開発した自社サービスのERPの開発の足跡、技術的な苦労話等がセッションの中心でした。Java EEはコマーシャルサポートや、JSFのコンポーネント化技術の生産性を高く評価したが、システムを作り直す上ではスケールアウト(=ステートレス)、動作の早さ等を考慮してAngularJSを選択したとのこと。お客さんの目が肥えていて、ハイレスポンスでないと受け入れられないようですね。


自社開発のSaaSでは、スケーラビリティ、レスポンシビリティは死活問題なので、多少複雑でも、JavaScript MVCを利用する意味があったそうです。逆に、隔離された環境で限られた人が触るツールの場合は、JSFの方が生産性が高いので良いとのこと。

なお、注目のAngularの評価は「エンタープライズでも十分使える」「学習コストは高いがディレクティブが強力」とのこと。ただし、JavaScript MVCは過渡期の技術なので、安定したプラットフォームと比べて、維持保守、マイグレーションのコストは余計にかかるそうです。


また、今回初めて聞いたDomaというO/R Mapperフレームワークは、SQLをゴリゴリかける系なので便利とのこと。「MyBatisじゃだめなの?」との突っ込みが入っていましたが、方言を意識したページング・クエリの自動生成等、かゆいところに手が届く機能があるそうです。機会があれば使ってみようかな。


Doma

雑感

JavaScript MVCは、Web業界向けのおもちゃ(SIerのおじさんたちは、Web業界のことをおもちゃだと思ってます。)ではなく、エンタープライズで使える実用的な道具として使われているのが印象的でした。当日はぼーっとしてたので、すぐに思いつきませんでしたが、今思えば、JavaScriptで記述するビジネスロジックの維持管理方法とか、JavaScript側とサーバ側のモデルの同期化とか、テストどうしてるの、とか、色々聞いてみたかったです・・・。

また、Angular云々よりも、むしろERPシステムの設計、実装をもっと突っ込んで聞きたかったかも。

R2-3 リクルートにおけるソリューション開拓と実装展開 〜Elasticsearchによる検索基盤の展開と新ソリューションの開拓状況 宮川典久

スライドが見つからないorz

まとめと補足


リクルート社内で全文検索エンジンElasticSearchを展開するうえで苦労したところ等の話です。リクルート社内では、Apache Solrと比べてスケーラビリティとリアルタイム性に優れたElasticSearchを展開中で、リクルートの要件に合わせて独自に作りこんでいる部分もあるそうです。


リクルートは紙媒体がメインなので、紙面の発行前に検索結果を変えるわけにはいかず、媒体ごとにインデックスの面管理を実施しているとのこと。

雑感


会社の宣伝ときれいなパワポがメインぽかったので、ぬーぼーと聞いてました。むしろ、もう一人の発表者、伊藤さんの自作ツールRedPenのほうが使いどころがありそうで気になりました。

H-4 Javaエンジニアのためのアーキテクト講座 鈴木雄介

当日のスライド

まとめと補足


Java One報告会でも圧倒的な存在感を示していた鈴木雄介さんのセッションです。現代的なITサービス(≠ITシステム)に求められる要件、サービス運営モデル等、抽象度が高い話がメインですが、非常に聞き応えがありました。

最近のトレンドは「仕様が固定的なシステムから、絶えず進化を続けるITサービスへの移行」であり、当然、求められるスキルセットがかなり異なります。ITシステムでも十分難しいですが、IT「サービス」となると、企画、業務、運用、開発と、視点が異なる人たちの利害関係を調整しつつ、サービスをデザイン、運営しなければならないため、膨大なスキル、知識が必要となるそうです。
(スライドのP25あたりを参照)


技術面で言うと、一つのサービスは複数のアプリケーションから構成され、それぞれ最適となる実装は異なるので、否応でもMicroservice Architecture的な設計にせざるを得ないようです。また、設計パターンとしてDomain Driven Designを挙げられていますね。
(私の解釈では、DDDは重厚なUnified Processと、その周辺のモデリング技法に対するアンチテーゼなのかな、と思ってましたが、認識が浅いようですorz)

雑感


一番聞き応えがあって、脳みそが刺激されるセッションでした。ITサービス運営のモデルは、ただのポンチ絵、パワポ遊びではなく、実装(含む、人間)を深く理解したうえでの高度な抽象化であり、素晴らしいですね。まだv0.1とのことですが、個人的にはScrum的なPortfolio管理の視点の含めると、「ITサービス運営のモデル」から、「ITサービスを運営する企業の企業活動のモデル」に進化するのではないかと思います。このモデルは特定のサービスに閉じていますが、実際は同一(あるいは他社)のサービスが相互作用しながら発達するわけですし。
(スコープを広げすぎ?)


もう一つ気になるのが、サービスと言っても様々な局面があることです。
(立ち上げ、発展、方向性の修正、他サービスとの連携、新サービスへの移行、統合、サービスの停止 etc... バリエーションが多そう)
そうすると、同じアーキテクトが同一サービスのライフサイクル終了までずっと張り付いているのは現実的ではなく、アーキテクトはどこまでプロダクトの責任を持つべきか悩ましい気がします。
(生き物に近いので、ITシステムよりも手離れが悪そう。飼い犬的な・・・。)


また、サービスのフェーズで必要とされるスキルは異なるはずで(統合、移行はレガシー・モダナイゼーションに近いのでは)、アーキテクトチーム内でも人の入れ替えは頻繁に発生すると思われます。そうすると、重厚なドキュメントが必要になり、アジャイル的なやり方って短期決戦以外は向いていないのでは、とか。

11/18 見づらかったので、見やすいように修正、一部雑感を追加

Unified ProcessとScrumを比較してみる

有名なイテレーティブ系の開発プロセスであるUnified Processと、もっともよく利用されているアジャイル開発プロセスであるScrumのオーバービューを一枚絵にまとめてみました。

かなり抽象化していますし、私の理解が浅いので、突っ込みどころも多いですが、少なくとも私にはこう見えています。

Unified Process



Scrum



考察


Unified Processはオブジェクト指向、要件、設計、実装のモデル化を基盤としたソフトウェア・エンジニアリングありきの開発プロセスです。開発プロセスそのもののフィロソフィもオブジェクト指向的です。一方で、Scrumはかなりビジネス・ドリブンで、早い話が「ROIの最大化」「権力をProduct Ownerに集中することによる即断即決」「マーケットの変化への対応性」に焦点が当てられていて、あまりソフトウェア・エンジニアリングのにおいがしません(ソフトウェア開発以外の領域でもそのまんま使えそう・・・。)


Unified Processが大規模で複雑なシステムをきっちり作れそうな雰囲気なのに対し、Scrumは市場変化が激しいWebサービス業界で次々にサービスを改良していく雰囲気です。
開発プロセスが対象とするスコープや想定する市場がかなり異なり、どちらが良いとも言えないです。ただし、世界的に主流になりつつあるのはアジャイルらしいので、世の中の流れ的に、時間をかけて丹念に作るよりも、とにかく出してリターンを大きくするほうが求められているのかもしれません。

なお、どちらのプロセスもプロフェッショナルが回すことが前提となっており、SIer的な「だれでもできる」「流れ作業化」とは全く異なります。開発プロセスは、想定される組織、人員、技術、ビジネス環境等によって、最適解が変わるようなので、日本のSIer的には、ウォーターフォールが良いということなのかもしれません。

参考文献

The Unified Software Development Process

Essential Scrum

シンプルなO/R Mapperを作ってみました

「なるべくシンプルに!」「XML、アノテーション、動的プロキシ、バイトコード生成の廃止」をお題目に、おもちゃみたいなO/R Mapperを即興で作ってみました。

https://github.com/zyake/sumo

きっかけは、仕事で利用したJPAのあまりの複雑さ、遅さ、効率の悪さに嫌気がしたことです。
シンプルなほうが好きなので、機能を削れるだけ削っています。
実用性よりも、シンプルなフレームワークのPOCのつもりです。