［PR］システムインテグレータがアーキテクチャ設計から導入支援まで提供すべき理由。グロースエクスパートナーズ

2014年4月17日

システムを開発し、その価値をユーザーに届けるというプロセスにおいて、コードを書く作業が占める割合は3割もないのではないか。新宿にオフィスを構えるシステムインテグレータ、グロースエクスパートナーズ株式会社（以下GxP）の執行役員鈴木雄介氏は、GxPのシステム開発を見渡しつつそう説明します。鈴木氏は日本Javaユーザーグループ会長でもあります。

GxP | Growth xPartners

システムインテグレータにおいて、あるいは開発者と呼ばれる人たちにとって、優れたコードを生み出せる能力はつねに注目されるものです。しかし鈴木氏は、優れたコードを活かすためにも、コード以外の部分の重要さにも目を向けるべきと言います。

その示すところを、顧客の課題や要望を、アーキテクチャ設計の段階から顧客と一緒に考えていくGxPのシステム開発を通して見ていきましょう。

（GxPは現在、人材募集中です。募集する職種などは記事の最後で）

課題解決をアーキテクチャの設計から考える

例えば、医療関連機器メーカーと同社がパートナー関係を築きながら取り組んでいる人工透析システムの開発では、アーキテクチャ設計時に「患者に発行されるカードに、その人の人工透析に必要な情報をプリントする」という提案が行われています。

人工透析システムのプロジェクトメンバー（一部）

「透析時に必要な情報は個人情報なので隠す、というのがそれまでの常識でした。ところが東日本大震災のときに、患者さんが避難先で透析を受けようとしても必要な情報が医療機器と一緒に失われてしまったため、すぐに透析が受けられないという非常につらい経験をしています。

こうしたことが今後起きないようにするにはどうすればいいのか。以前から、患者さんが旅行をする際に、旅行先の透析病院で透析が受けられるように必要な情報を紹介状に書くことは知っていました。そこで、カードに紹介状に書く情報をプリントし、患者さんが常に携帯していれば災害時に活用できると考えたのです。システムやクラウドも大事ですが、やはり最後は文字ですね」（鈴木氏）

システムが提供する価値はシステムが止まってしまえばそこまで。アーキテクチャにはそれを超えて価値を提供できると鈴木氏。「こうした広い視点で顧客と一緒に問題解決を考えるのは楽しいですよ」（鈴木氏）。

アーキテクチャと、仕様の膨張を未然に抑える仕事

この人工透析システムは、患者の予約から当日の受付、患者ごとの医療機器の設定、透析状況の把握など、人工透析に関連する病院のワークフロー全体をカバーするものです。これはつまり、設備も人員も規模も異なるさまざまな病院へ導入される際に幅広いカスタマイズ要求が寄せられることにつながります。

しかし病院ごとにシステム改変していては迅速な展開のボトルネックになりかねませんし、システムの信頼性にも関わります。開発プロジェクトの責任者を務めるGxPの今野睦氏（ソリューションデリバリー部マネージャ）はそれを見越して、コアとしての共通機能を作りつつ、プラグインモジュール形式で病院ごとのニーズにも対応するというアーキテクチャを選択しました。

このとき必要になったのが、病院ごとのニーズから要件となるものを抽出し、仕様へと的確に落とし込んでいくこと。これを担当していたのが黒子千恵氏（ソリューションデリバリー部データベーススペシャリスト）です。

黒子氏は病院を訪問してヒアリングから要件定義をしつつ「要望に対して既存の機能や似た機能で応用可能であれば『この機能をこう使うのはいかがでしょう？』と提案することもありました」と、コンサルティングによって要件を一定の範囲に抑えるという大事な役割を果たしています。

優れたシステムを作り上げるには適切なアーキテクチャが選択されるだけでなく、適切な要件がきちんと絞り込まれて仕様化されることが前提だということは、システム開発の経験者なら誰でもうなずくことでしょう。GxPにはこうしたコード開発以外の部分でも優れた能力を発揮できる環境があります。

プロジェクト責任者の今野氏は現在、黒子氏らと病院の現場でシステムの導入支援のフェーズに入っています。システムの価値を届けると言う意味では、ここでうまく行かなければそれ以前の多くの作業が無駄になると言ってもいい、重要なプロセスです。

小規模案件でもコンサルティングからビジネスまで

大きなシステム開発だけでなく、小規模案件でもGxPはビジネスコンサルティングからITアーキテクト、開発、運用の役割を請けています。ソリューションデリバリー部 ITアーキテクト関満徳氏はこの1年、音声認識を利用したオンラインサービスの設計からビジネス展開にまで関わってきました。

「どういう体制で仕事の仕組みを回すのか、ビジネスの体制を考えるのも含めてITアーキテクトの仕事だと思っています。社内には技術に強いITアーキテクト、データベースに強いITアーキテクトなどもいますが、私はビジネスの設計と実装が得意な部分です」（関氏）。

本件は技術的な検証や実装が依頼の中心だったものを、事業企画から支援するという提案を行い、顧客と共に事業を形作りました。なぜそうした提案をしたのか、その理由を「利用者に使われてキャッシュフローが回って初めてシステムの価値が実現します。そういうところから顧客と一緒に作り上げたいと思ったんです」と関氏は語ります。

選択と責任があるプログラマの仕事

このようにGxPは顧客をビジネスパートナーとして一緒にビジネスとシステムを考えるシステムインテグレータですが、もちろん社内ではエンジニアもバリバリと活躍しています。「うちでいちばん頼りになるエンジニア」（執行役員鈴木氏）と評されるソリューションデリバリー部エキスパートリーダーの石橋崇寿氏は、「私はプログラマなので、アーキテクチャの設計に関わったりもしますが、基本的には実装をするのがメインの仕事です」と自分の仕事を説明します。

石橋氏がこの3年ほど担当しているのが、マルチベンダーの大型プロジェクトの一角として、Javaを用いたアプリケーションフレームワークや難易度の高いビジネスロジック部分などの実装です。

もちろん石橋氏の仕事も単なるプログラマにとどまらず、「今回はSpringフレームワークとVelocityテンプレートエンジンを使っていますが、運用の要件やセキュリティの作り込みなどを考慮して、フレームワークの選定や作り方を検討し、初期サンプルも含めて考えています」と、技術の選択部分から任されているのが同社らしい点です。

一方、昨年にエンタープライズ系の開発部門からWeb系の開発部門に異動した小林友一氏（クリエイティブエンジニアリングユニットエキスパートマネージャー）もプログラミングが仕事の中心です。アーキテクトやプロジェクトマネージャへと昇格するよりも開発現場にこだわるという本人の考えが、この異動につながりました。現在はお客様と相談の上で「AngularJS」のような新しいWebフレームワークを採用したWebアプリケーションの開発案件に取り組んでいます。

チームの中で自分で役割を見いだせる人材を

GxPにはここまで紹介してきたように、アーキテクトやコンサルタント、プログラマはもちろん、プロジェクトマネージャ、テスト、プロジェクト支援、保守運用、Webデザインなどのさまざまな役割を得意にするエンジニアが柔軟にチームを作りながらシステム開発を行っています。

こうした多様な人材から構成されるGxPにおけるチームの様子を、数億件の企業情報を提供するオンラインサービスの開発プロジェクトチームで働く岡澤裕二氏（ソリューションデリバリー部ソフトウェアエンジニア）は、次のように話します。

「チームとしては、誰かが言ったからこれをするというよりも、全体としての舵取りはリーダーが行い、その中で自分の役割を各自が考えて行動しつつ、お互いにフォローしながらやっている感じです。結局仕事を通してチームビルディングしたようなもので、上からコミュニケーションを取りなさいとか、仲良くなるために飲みに行くとか、そういうのはなかったですね。見ているとリーダーがいちばん詰まっていたので、逆に自分も頑張らなくてはと思いました」

一方、そのプロジェクトのリーダーだった和智右桂氏（ソリューションデリバリー部 ITアーキテクト）はチームについて、「これはGxPの文化でもあるのですが、お客様の言うとおりに作りましたというのを良しとしない。違うと思ったら違いますと言うんですね。それはチーム内でも同じで、困ったときには杓子定規にならず、元々の仕事の枠組みを超えて助けあったりもします」と話します。

ではチームにはどんな人材がいてほしいのでしょう。「必ずしもプログラミングスキルが高くなくとも、周囲が見えてチームの中での役割を見いだしていけるという人の方がいいと思います。アーキテクチャを作る。オフショアや協力会社と一緒に開発をする。システムがある程度形になってきたら、そこから最後の完成まではお客様やチーム内で細かくコミュニケーションを取りつつ開発していく。そういう中では『設計書を書いてくれたらその通り作ります』という人は活躍できません」（和智氏）

システムの価値を届けるのはプログラミングだけはありません。価値のあるシステムを作り上げていくためには、色々な専門分野を持ったメンバーが必要です。価値を提供したいという思いがあれば、完璧な能力を持っている必要はありません。それを後押しする環境がGxPにはあります。