![]() |
![]() |
|
Loading
|
@IT > .NETエンタープライズ新時代 第4回 |
![]() |
アークウェイが設立されたのは2004年1月。これは2002年4月に.NETの初期バージョンがリリースされてから約2年後、.NETのエンタープライズ分野への適用がようやく現実味を帯び始めたころだ。アークウェイは、.NETによるエンタープライズ・システム構築のコンサルティング・サービスを中心に、メンタリング・サービス(=現場に立つ開発者を相談役としてサポートする業務)やトレーニング、ソフトウェア・ファクトリ支援ツール『aiNote』の開発などの事業を展開する。.NETのエンタープライズへの普及に後押しされ、事業は順調に拡大。2006年10月には、関西圏での拠点となる大阪事業所を設立した。つまりアークウェイの成長の歴史は、エンタープライズ領域への.NET普及の歴史でもあるわけだ。 「実をいえば、創業当初のアークウェイは、.NETにこだわらず、Javaによるシステム構築のコンサルティングも手がけていました。しかしその後、わたしの起業前の古巣であるMCS(Microsoft Consulting Service)の元同僚らがアークウェイの企業理念に賛同して当社に参加してくるにつれ、.NETによるシステム構築の技術やノウハウが強みになっていきました。現在では、ほぼすべてが.NETベースの案件になっています。 .NET Frameworkや.NET対応のVisual Studioは、それらがベータ版の段階から注目を集めていましたが、正式版がリリースされたからといって、.NETの採用が実際の開発案件で急速に進んだというわけではありません。実用的なシステムの基盤技術として定着するまでには、相応の時間が必要でした。いわゆるキャズム(chasm:新しいテクノロジがマジョリティを獲得するまでに越えなければならない障壁)の存在です。これまで、.NETの採用は、じわじわと増えてきたという感じでしたが、創業から3年がたった現在、急速に採用案件が増加しています。.NETは、ついにキャズムを乗り越えたという印象を持っています」
.NETとともに歩んできたアークウェイのビジョンはとてもユニークだ。 「アークウェイのビジョンは、『開発を効率化して残業をなくし』『技術の楽しさをより多くの人に伝えて、開発に対するモチベーションを高める』という2点です。日々の雑務に追われて残業ばかりしていると、体を壊すこともあるし、何より技術者でありながら、技術的な目標が分からなくなってしまう。目標を見失うと、技術者であることの楽しみも見失ってしまいます。残念ながら、ソフトウェア業界では、このような状況のほうが一般的でしょう。アークウェイはこの問題を解決します。こうしたアークウェイのビジョンをひと言で語るキーワードが“Developers Happiness” です。そして、このビジョンを実践に移す施策が、アークウェイ独自の『アーキテクチャ策定サービス』と『メンタリング・サービス』なのです」(森屋氏) アークウェイが提供する基本的なコンサルティング・サービスでは、全体のプランニングが終わった段階で、プロジェクト・メンバーをアーキテクト・チームと開発現場チームの2つに分け、前者にはアーキテクチャ策定サービスを、後者にはメンタリング・サービスを提供する。 まず、アーキテクチャ策定サービスとは一体どのようなものなのか。 「開発作業では、システムの根本となるアーキテクチャが重要となります。しかし、アーキテクチャを決定するための手法やプロセスは、現在でも明確に確立されているわけではありません。そこでアークウェイは、『アーキテクチャ策定サービス』という形でアーキテクチャの決定をサポートします。当然ながら、アーキテクチャには決まった答えはありません。顧客企業の状態などによって、幾通りもの可能性があります。どういうアーキテクチャが最適なのか、顧客と一緒に考えながら決めていきます」(飯田氏) 一方のメンタリング・サービスについて中西氏は次のように説明する。 「メンタリング・サービスは、他社にはないアークウェイ独自のサービスです。例えば開発を進めていくうえで、コンサルティングによってトップダウンでシステム開発を進めようとすると、どこか上から一方的に物をいわれるような印象を現場で働くデベロッパーに持たれて反発を招くことがあります。だからといって、ボトムアップでデベロッパーが好きな技術を好きなように使ってシステムを実装しようとしても、優れたエンタープライズ・システムが構築できるとは思えません。これらトップダウンとボトムアップの中間地点となる横の視点から、バランスを取りながら顧客の開発者と一緒に開発を進めていくのが最良ではないかという発想の下に、メンタリング・サービスは生まれました。 要するにメンタリング・サービスは、いわゆるメンター(=相談役となる同僚)として、側面から現場の雰囲気を変えていく試みです。またこれまでの結果・経験から、現場で開発方法を1回教えただけでは定着しないことが分かっているので、開発現場の企業文化として新しい開発方法が定着するまで、根気強く側面からフォローしようというのも、このサービスの目的です」(中西氏)
アーキテクチャ策定サービスとメンタリング・サービスはどのように連携するのか。アークウェイの開発手法を具体的に見てみよう。例えば、1年以上の開発期間を要するような大規模なエンタープライズ・システム構築では、アーキテクチャ策定サービスに合わせて、下の図のような流れでメンタリング・サービスが実施される。 「最初の段階ではTeam Foundation ServerやSubversionなどによる構成管理を導入するなどして、ソフトウェア開発のベース部分で両者の歩調を合わせます。これはアークウェイが提唱する開発基盤である“Development Baseline”(詳細後述)の適用です。これと並行して、アーキテクチャを決定します。そしてアーキテクチャが決定したら、開発現場でそのアーキテクチャを実装に展開しながら、「アーキテクチャの決定→実装→検証と分析をアーキテクチャ設計にフィードバック」という流れ(イテレーション)を繰り返していきます。開発の初期段階では、まったく機能を持たないアーキテクチャの初期版サンプルが『ゼロ機能リリース』として開発現場に落ちてきますので、それをベースにシステムを実装していき、そのフィードバックをアーキテクチャに返す、というサイクルを繰り返しながら(=イテレーションを繰り返しながら)開発を進めていきます」(中西氏)
「ここで最も大事なのは、イテレーティブにアーキテクチャを検証していくフェイズです。品質特性にはトレードオフがたくさんありますので、そのトレードオフを検証しながらアーキテクチャを設計していく必要があります。例えば、スケーラビリティを重視するのか、セキュリティを重視するのかによってまったくパフォーマンスが変わってきますが、そういったことを開発現場からのフィードバックを受けながらイテレーティブに検証していき、『本当にこれが良いアーキテクチャだ』という確証を踏まえながらプロトタイプやガイダンスを作っていきます」(黒石氏) 「アーキテクチャの設計では、それまでに勉強したことを実際に使ってみたいという気持ちがあると思うのですが、それを安直に実行してしまうと、開発の後半になって初めて設計ミスや問題点に気が付くということがよくあります。こうして設計や実装をやり直す作業は、実質的にはイテレーションを行っていることと変わりません。そんなことなら、変更に伴う工数が少ない開発の初期段階で、きちんとアーキテクチャを検証した方がよい。ちょっとした生活習慣を直すことで、大病を避けられるということですね」(飯田氏)
アークウェイはこれまで、.NETにおけるアジャイル開発を「NAgile」と呼び、開発の基盤となる基本的なプラクティスをソフトウェア業界に普及させようと尽力してきた。 「アジャイルというと、その言葉を聞いただけで拒否反応を示す方がいます。しかしアークウェイが推進したいのは、別にアジャイルという特別な手法の普及ではなく、システム開発の生産性を高めるうえで、開発者がすべき基本的な方法論なのです。このため昨今では、『アジャイル』という言葉は意識的に使わないようにしています。開発者がすべき基本プラクティスという意味で“Development Baseline”と呼び、アークウェイはこれをメンタリング・サービスの中で推進しています。1回トレーニングを受けて、Development Baselineを『良い』と思っても、いままでの習慣をがらりと変えることは容易ではありません。そこで、メンタリング・サービスとして、一緒にDevelopment Baselineに継続的に取り組みながら、習慣を少しずつ変えていくことが重要だと考えています」(中西氏) Development Baselineへの取り組みでは、どのようなツールを活用するのか。 「Development Baselineでは、構成管理や自動ビルド、単体テストなどのプラクティスを実践していきますが、そのプラクティスの効率的な実践においてはツールの利用が必要になります。この場合、支援ツールとして、NUnitや CruiseControl.NET に代表されるオープンソース系ツール、あるいは Visual Studio Team System(以降、VSTS)のどちらかを選択します。例えばプロジェクトにおいて開発ツールのメンテナンスを行なう余裕がある場合はオープンソース系のツールを組み合わせて使います。一方、VSTSを使用する場合は、すべてのツールが開発環境に完全に統合されているので導入がスムーズに進み、また1つの環境ですべての作業を実行できるという魅力があります」(黒石氏) 「またこういったツールを利用することで、マネージャー層にDevelopment Baselineのプラクティスの採用を説得しやすいと思います。例えばテスト駆動開発などの手法は特にマネージャー層にはなかなか受け入れてもらえないのですが、こういったツールを利用すると、作成したテストを使用してビルドごとに後退テストを自動化することが可能になり、ソフトウェアの品質を向上させることが可能です。つまり、マネージャーとしてはこれらのツールを利用することで品質向上のための取り組みを普段の作業に追加するのではなく、Development Baseline という基本的なプラクティスの実践を通じて達成できるようになり、結果として開発の効率化とチームのモチベーションの向上を同時に実現することが可能になります。」(飯田氏) このようにアークウェイでは、さまざまな開発ツールを効果的に活用しながら、生産性の高い開発者の基盤を構築し、最終的に自社のビジョンである“Developers Happiness”を追求しているのだ。 ■ ソフトウェア開発者として働き続けることの意味、そして開発者の幸せとは何なのか? アークウェイが提供するサービスの根底にあるビジョンは、多くの技術者が日々の仕事に流され、忘れがちな大切なことを改めて気付かせてくれる。健康に生きていくこと、楽しみながら気持ちよく仕事をすること。こうした基本をないがしろにして、目先のゴール達成だけでシステム開発が成功したように見えたとしても、本当の成功といえるのか疑問だ。作り手が幸せになれない業界にこれから新しく人が入ってくるのか、またそこにとどまりたいと思うのか。やはり、人とシステムの双方をともに成功に導くことが、真の成功だろう。そのような真の成功を目指してソフトウェア業界を変えていく試みが、日本のエンタープライズ.NET開発の現場から息づき始めている。
提供:マイクロソフト株式会社 企画:アイティメディア 営業局 制作:デジタル・アドバンテージ 掲載内容有効期限:2007年6月30日 |
|