検索検索
English

ソフトウェアを通じて社会の発展に貢献する

お客様の事業を支える基盤システムやパッケージ製品。サイオスのメンバーはどのような思いで開発・提供しているのでしょうか。ビジネス開発事業部 副事業部長の山﨑靖之が、エンジニアおよびアーキテクトとしての歩みを、サイオスのヒストリーと重ねて振り返ります。

ピープル2016年2月23日

ビジネス開発事業部のミッション

― 山﨑さんは昨年までサイオスの第2事業部の副事業部長(技術担当)でしたが、2016年1月からは新設されたビジネス開発事業部の副事業部長に就きました。両事業部の関係と山﨑さんのミッションについて教えてください。
昨年まで第2事業部では、プロダクト&サービス事業、ビッグデータ事業、SIOS iQ事業、3つのビジネスに関わる技術部門を統括していました。それぞれの事業戦略の立案・遂行・評価を、後述するアーキテクトとしての視点を持ちながら推進してきました。

これを大きく2つに分け、2016年1月に新設されたビジネス開発事業本部では、コンサルティングサービス事業、SIOS iQ事業、新規事業の3つを柱に注力することになりました。

昨年まで手掛けていたソリューションには、大きく2つの方向性があります。1つは、お客様の事業の基盤となるシステムを、クラウドサービスやOSS、商用プロダクトなどを最適な形でインテグレーションして提供するものです。こちらはお客様に適した一品一様のシステムづくりといえます。もう1つの方向性は、自社開発の製品やサービス提供を通じた課題解決の仕組みとなります。

前者のクラウドインテグレーションの一例が、ID統合管理と認証システムです。企業だけでなく大学など文教市場でもいち早く数多くの実績を挙げています。最近では、クラウド環境とオンプレミス環境をシームレスに統合するSSO(シングルサインオン)技術により、利便性向上と同時に情報漏洩対策などセキュリティを強化する案件が伸びています。
また、膨大かつ多様なデータソースからビジネス価値を見出すためのデータ分析基盤システムを提供するソリューションもそうしたインテグレーションサービスの1つです。こちらにはさまざまな切り口でデータ分析を行う企業のマーケティング部門を中心的な顧客として、ニーズに応えています。

一方、ビジネス開発事業部に移管されたSIOS iQ事業では、米国サイオステクノロジーが開発した製品「SIOS iQ」の日本国内でのビジネスの立上げ、および展開を図っております。「SIOS iQ」は、機械学習技術を用いて仮想環境における性能問題を分析・解決するためのインテリジェントな分析プラットフォームです。「SIOS iQ」は、2015年7月にリリースされた新製品で、日本国内でも、多くの企業様から問い合わせを受けており、既に数社の企業様が評価導入をしています。トレンドマイクロ様の事例も発表されましたが、サイオスの技術力を生かしたオリジナルのプロダクトとして、日本のみならず米欧市場でも注目されています。

こうした自社開発のプロダクトやサービスを活用しながら、お客様の抱える課題を解決するのが、ビジネス開発事業のコンサルティングサービスになります。詳細は後述しますが、コンサルティングを通じて、新規のプロダクトやサービスのヒントもつかむことができます。お客様の課題解決とともに、サイオスの成長につながる新規事業を企画するチームとも連携を図って、事業を推進しています。

よいインテグレーションとは何か

― 先ほど、サイオスの提供するソリューションには、大きく2つの方向性があると仰いましたが、それぞれの技術開発における方針はどのようなものでしょうか。まず、クラウドサービスを活用した基盤システムや事業インフラなどのインテグレーションにおけるサイオスの強みを教えてください。
サイオスが得意とするクラウドやプロダクト、OSSなどを組み合わせたシステムの提供に特色があります。構築するシステムはさまざまですが、そこで提供される「よいシステム」とはお客様のビジネスを成功に導くもの、経営に貢献するものである、と私は考えています。

― では、お客様の経営に貢献するシステムを作るため、どのようなことを心掛けているのでしょうか。
予算と納期の中で確かな品質のソフトウェアを提供するためには、プロジェクトを管理するプロジェクトマネージャー、アーキテクト、設計者、開発者、などさまざまな人材からなるチームづくりが一つのポイントになります。その中で最も重要なのは、アーキテクトです。ここでいうアーキテクトとは、企業・組織の構造、業務プロセス、業務を動かしているITのサービスに至るまでの全体を俯瞰したモデルが描けるスキルや、EA(Enterprise Architecture)で定義されているビジネスアーキテクチャー、情報アーキテクチャー、アプリケーション・アーキテクチャー、テクノロジー・アーキテクチャーの構築スキルを有する技術者を指しています。アーキテクトの役割を考えるときに、ITのインフラやソフトウェアなどの技術的なアーキテクチャーをデザイン&構築すると思われがちですが、現実的には、ビジネスアーキテクチャーの定義を含む全体としてのアーキテクチャーデザインが整わなければ、ビジネスにマッチしたITシステムの提供は叶いません。業務は組織横断的に流れるプロセスによって遂行されており、その業務を支えるITシステムが適切に機能しなければ円滑な業務遂行を妨げることになります。利用者にとって、より良いITシステムとは、単なるシステムとしての機能だけではなく、利用組織や業務フローと密接な連携を実現しているものと考えます。エンタープライズレベルでのアーキテクチャーデザインができるアーキテクトが重要となる理由はそこにあります。そして、そのような人材の育成・確保が大きなポイントの一つになります。

また、要件の認識齟齬によりお客様の満足が得られない失敗ケースで考えてみましょう。不満の原因は、予算や納期、品質などさまざまなところにありますが、端的なのはシステム開発を発注する側、それを受注する側にあるボタンの掛け違いです。例えば、納品したシステムの機能や使い勝手が顧客からの要求と異なるケースが当てはまります。建築でいうと家屋がほぼ出来上がってから、「この部屋をもっと広くしたかった」といっても、間取りはそう急に変えられません。変えられるにしても当初の予算を超える改修コストが発生するでしょう。あるいは、施主にその家に我慢して住んでもらうしかありません。システムについても同様で、お客様のニーズと納品物の食い違いがシステム稼働直前に露見すると、大きなトラブルになります。

そうした掛け違いを避けるためにお客様の要件、と一口にいってもさまざまな現場の声がありますからそれらをシステムエンジニアが取りまとめ、システム化のための技術、予算、納期などのさまざまな条件下でプロジェクトを編成・推進していくのがプロジェクトマネージャーで、アーキテクトは、要件を満たすためのシステムの構造決定や技術要素の取捨選択をすることで、システムの骨格となる要素を整えてモデル化する存在です。私はそういう立場で仕事をしていました。

また、ビジネスの変革が激しく、迅速な対応が求められる現代においては、アーキテクトの素養を持ったプロジェクトマネージャー(PM)が理想的だと私は考えています。アーキテクト、PM、設計者・開発者(プログラマー)、インフラ技術者にそれぞれ専任を割り当てると、みな違う絵を描こうとするからです。一人がすべてをこなせれば、そのリスクを小さくできますが、そういうスーパーマン、いわばフルスタックのエンジニアというのは、そう簡単には育てられません。現実的には、アーキテクトとPMを兼務し、設計が行える開発者(または開発が行える設計者)とインフラ技術者から成る体制をつくるチームビルディングが効果的だと考えています。この例は、あくまでも変化に対するスピード感が求められる小・中規模プロジェクトチームでの話であり、大規模なプロジェクトにおいては、専任のプロジェクトマネージャーは必要であると考えています。

― ところで世の中には、さまざまなモデリング技法、アジャイル型の開発の手法、フレームワークや知識体系があります。アーキテクトはそれらの知識を網羅する必要がありますか。
基本的にはいずれの知識も重要です。ただ、バズワードも多いので振り回されないほうがよいでしょう。また重要な知識であっても、それらが示すものはあくまでやり方であり、規範集だということです。そのやり方をどのようにチーム作りや開発、レビュー環境の整備、個々のタスクやスケジュールといったものに具体的に落とし込むか、そこに決まった答えはありません。落とし込む環境や前提条件が現場ごとに異なるからです。3人いれば、三者三様の回答がでてくるかもしれません。そのうちどれがよいのかジャッジできるのが、アーキテクトです。

私が常に意識しているのは、システムエンジニアリングは「科学」だということです。結果には必ず原因と経緯があり、それらを測るための、何らかのメトリクスが存在するということです。それらのデータを計測し、それをもとにプロジェクトにおける活動を分析し、改善策を講じます。検証・評価を繰り返すことでプロジェクト自体の品質も高まり、チーム力も高まります。一人ひとりの力や意欲、あるいは性格なども、もちろん大事ですが、プロジェクトは、チーム全体がどういうパフォーマンスを発揮するかが重要です。トラブルからのリカバリーに根性論を振りかざしても、誰かのせいにしても、むやみに要員を増やしても決してうまく進みません。

これからアーキテクトを目指す技術者の方は、科学的な視点を持ちながら、理論を1つひとつ実践を通じて身につける自己研鑽を行ってほしいと考えています。

独自プロダクトやサービス開発の本質

― もう1つ、サイオスの提供するソリューションの方向性として、新規のプロダクトやサービスの開発(R&D)にも注力しているという指摘がありました。こちらの取り組みについても教えてください。
R&Dは、サイオスの今後の成長において非常に大きな役割を担っています。ただ、そのプロダクトやサービスの開発の本質は、前述したシステム開発と変わらないと私は考えています。やはり「お客様の経営そして世の中にいかに貢献することができるか」ということに尽きると思います。

特にここ数年、ITで実現できることが、従前とは異なる大きな変化を遂げていると感じています。それは、IoT、機械学習やクラウドの領域です。当社のR&Dでも、IoTに関する開発は積極的に取り組んでいます。すでに米国サイオステクノロジーで開発した「SIOS iQ」で採用している機械学習についても、「SIOS iQ」とは別の製品開発に向けて日本のR&Dチームで取り組んでいます。R&Dの内容ですので詳細にはお話しできない部分が多いのですが、機械学習を金融業へ適用することで、最近話題になっているFintech領域へ進出することも可能であると考えております。サイオスグループは、2015年にProfit Cube, Inc.という銀行向けのパッケージメーカーをグループ会社化していますので、グループ内のシナジーを発揮するという意味でもFintechは注力している領域になります。

R&Dでの新しい試みは、未来のサイオステクノロジーを支える製品づくりが目的であり、ここで確実に成果を残すことが、今の私にとって最優先の課題です。

前述したように、お客様のシステム開発においては、アーキテクトの視点をもって、企業(エンタープライズ)レベルのモデリングを行います。そこから、個々のシステム開発に落ちていきます。ビジネス開発事業のコンサルティングサービスもそのようなアーキテクトの考え方で、ビジネスを展開しています。

お客様の経営課題に応える数多くの案件を通じて、市場にあるクラウドサービスやOSSでも、あるいは現状あるサイオスの提供する製品ポートフォリオでも対応できないギャップが見えてくることがあります。そのギャップを埋めるのに、既存製品のカスタマイズやスクラッチ開発ではなく、新たなプロダクトやサービスとして提供できないか。またそれによってお客様もハッピーになり、サイオス自体の企業成長にもつながるのではないか。新規事業開発における考え方のベースは本来、こういう順序で行われるべきではないかと考えています。

ソフトウェアエンジニアリングを追究

― ところで、山﨑さんは、どんな経緯で現在のサイオスに入られたのでしょうか。
80年代に国産メーカー系企業に就職し、システムエンジニアとなりました。主に携わったのは、メインフレームのオンラインシステムの構築やPOSシステムの開発です。お客様は流通業で、販売、物流、クレジットカード決済などほぼすべての基幹業務システムの開発に携わりました。ハードウェアの更新時には「縦管にネットワークは通るか」「分電盤の容量が足りるか」など設営手配から始まる現場も数多く手がけました。当時はCOBOL、PL/I、アセンブラでプログラミングがメインです。

ただ次第に私の関心は、ソフトウェアエンジニアリング、ソフトウェアの作り方そのものに向きつつありました。7年ほど経ち私は独立系SI企業に転職しました。そこで、サイオスの前身であるテンアートニのことを知り、興味を持ちました。時代はハードウェアとOSが一体になったメインフレームから、UNIX系OSを使ったオープンシステム化の動きが出てきた頃です。

独立系SI企業を辞め、テンアートニに入社したのは、当時の新技術であるJavaとLinuxに専門特化した異端児的な会社に共感を持ったからです。Javaが発表された1995年頃は、雑誌などで目にすることがあり面白そうだな、と感じていました。Java100%で開発することを標榜していたテンアートニでは、新しい技術を追及できるかもしれない、と思ったのです。

3度目となる転職でしたが、迷いはありませんでした。もちろん、当時のJavaコンパイラと実行環境はまだ成熟度が低く、システムを開発するのはかなり大変だった記憶があります。約3年間、寝袋とともにJava開発に没頭する日々が続きました。

しかし、Javaに習熟した私は、あらためて原点に立ち返りソフトウェアエンジニアリングを追究したいと考えるようになりました。ものづくりの方法論を極めることと、ソフトウェアを作ることを両立するのは難しかったのです。そこでテンアートニを退職し、ラショナルソフトウェアに移りました。そこでは、以前から実践していたオブジェクト指向分析設計、UMLモデリング、反復型開発プロセスとプロジェクト管理、ソフトウェア要求管理などの分野を専門とするコンサルタントとして仕事をする道を選びました。それから3年ほど経ち、ラショナルソフトウェアがIBMに買収されることになりました。「こっちに戻らないか」と、テンアートニ時代の仲間から声をかけられたのはそんな時期です。サイオスでは多くのシステム案件が増え、開発体制を工学的な視点から、いまいちど見直すべき時期と重なっていました。私がそれまで身につけたアーキテクトとしての知識が活かせると思い、サイオスでのチャレンジを決めたのです。代表取締役社長の喜多との出会いはその時でした。

世の中に貢献するアーキテクトを目指す

― さらなるチャレンジに向けて、どのような展望をお持ちですか。
引き続き、世の中に貢献するアーキテクトでありたいと考えています。私自身がサイオスで担うビジネスのミッションだけでなく、社外のコミュニティ活動にも力を入れていきたいと考えています。その1つが、The Open Groupという世界的なコミュニティで、私はその日本支部の活動支援を行っています。ここではかつてSOA Source bookというホワイトペーパーを他のメンバーとともに日本語に翻訳しました。今後、EA(Enterprise Architecture)のモデリングに関する仕様書の日本語版も出そうと、いまThe Open Groupのメンバーと盛り上がっているところです。

仕事をやればやるほど、ソフトウェアエンジニアリングそして、アーキテクチャーというのは奥が深い世界だと実感しています。私にもその究極の姿がどんなものか見えていません。これからも真摯に探求し続けたいと考えています。


山﨑靖之(Yasuyuki Yamazaki)
サイオステクノロジー ビジネス開発事業部 副事業部長
メインフレーム、UNIX、PCサーバーの全てのプラットフォームにおける大規模プロジェクトでの開発経験を経て、後にソフトウェア開発方法論やオブジェクト指向分析設計などをベースとしたソフトウェアエンジニアリングを専門として従事。現在は、執行役員として経営に参画しながら、Enterprise Architectureについて追求すべく、The Open Groupの活動にも参加しており、ビジネスアーキテクチャーのモデリングを掘り下げている。休日は、サーフィン、サッカー、水泳などのスポーツを楽しみ、心身ともにリフレッシュしている。


記事の関連情報