アジャイル開発の第一人者、吉羽龍太郎氏が指南するSIerとエンジニアのあるべき姿：特集：今、市場に求められるITアーキテクトの視点（3）

アジャイル開発やDevOpsの分野で数多くのコンサルティング経験を持つ吉羽龍太郎氏。「市場に求められる」「本当の価値を持つ」エンジニアであるために必要な考え方やスキルを身に付けるにはどうすればいいのか。エンジニアが技術の「目利き力」やビジネスにコミットする力を習得する方法について、吉羽氏に聞いた。

» 2016年06月30日 05時00分公開

[益田昇，＠IT]

　「市場に求められる」「本当の価値を持つ」エンジニアであるために必要な考え方やスキルを身に付けるにはどうすればいいのか。エンジニアが技術の「目利き力」やビジネスにコミットする力を習得する方法について、アジャイル開発やDevOpsの分野で数多くのコンサルティング経験を持つ吉羽龍太郎氏に聞いた。

SIの現場でアジャイル開発が普及しない理由

編集部　アジャイル開発など数多くのプロジェクトのコンサルティングを手掛けた経験から「現在のエンジニアが抱える問題をどう捉えているのか」についてお聞かせください。

吉羽龍太郎氏（Ryuzee.com）

吉羽氏　一口にエンジニアが抱える問題といっても、SIerで働くエンジニアと、サービスやプロダクトを作っているサービス系企業で働くエンジニアでは、その状況は大きく異なります。

　サービス系企業の技術者は、エンジニアでも、デザイナーでも、プロダクトを作って利益を上げることを目的に仕事に取り組んでおり、ビジネスのゴールがはっきりしています。

　一方、SIerで働くエンジニアの場合は、SIの仕事の性質上、顧客から請け負った仕事を指定された期日までに決められたコストで仕上げることが目的になりがちで、「顧客のビジネスが成功するかどうか」に関心が向きにくい。こうした働き方の下では、エンジニアが環境の変化に対応してシステムの変更を提案する意欲は抑制されてしまいます。つまり、「SIerのエンジニアは、サービス系企業のエンジニアに比べて、顧客の成功へのコミットメントが小さくなりがち」という問題があります。

　こうした問題は、SIerと顧客との間の契約形態そのものが原因で生じている側面もあります。最初にスコープを定義してあらかじめ費用や納期を見積もるウオーターフォール型の開発モデルとそれに対応する契約形態そのものが、ビジネス環境の変化に対応しにくくなってきています。

編集部　実際に、SIerに対してアジャイル開発の導入を求める顧客も少なくないと思いますが。

吉羽氏　SIerでは、顧客からアジャイル開発の導入を打診されても、自分たちが経験したことのない取り組みをリスクだと判断し、導入に二の足を踏むこともあります。また、日々新しい技術が登場する中で、枯れている安全な技術にこだわって、古いバージョンのままの開発環境やフレームワーク、ミドルウェアを使い続けている話もよく聞きます。このようなSIerで働くエンジニアは変化への対応に消極的になりがちです。

開発体制はインフラからアプリまで“一気通貫に”

編集部　SIerは、アジャイル開発や、それと相性の良いアーキテクチャ設計として、マイクロサービス化やAPI接続を求める顧客のニーズにどのように応えるべきですか。

吉羽氏　アジャイル開発とマイクロサービス化を実現するためには、インフラからアプリケーションまで一気通貫で面倒を見ることができる体制を整える必要があります。インフラとアプリケーションの機能を同時に変更することができなければ、新しいサービスを頻繁に追加したり、仕様を柔軟に変更したりできるマイクロサービスの利点を生かせないからです。また、DevOpsという言葉があるように、Dev側とOps側が同じチームの中で協力して1つのサービスを作ったり、運用したりできる体制を確立する必要もあります。

　加えて、ドメインに従ってきちんとサービスを分割できること、つまり、APIを介してきちんとやりとりできるように分割することも、マイクロサービス化のポイントです。これを徹底できずに、APIを超えて開発チーム間で会話をしてしまうと、サービスが増えるに従ってコミュニケーションのパスが増大し、開発に膨大な時間がかかるようになります。やはり、インタフェースをきれいに切り出して、そこだけでやりとりを完結できるようにすることが重要です。

編集部　現状のSIerにこうした取り組みができるのでしょうか。

吉羽氏　正直なところ課題は多いといえます。というのも、現状のSIerのほとんどは、インフラ開発の部門とアプリケーション開発の部門が同じ会社の中で分かれて存在し、それぞれが別々にプロジェクトで利益を追求する責務を負ってるのが実情だからです。また、インフラ開発とアプリケーション開発の両方のスキルセットを併せ持ったエンジニアが、研究開発の部門にはいても、SIの部門にはあまりいないという問題もあります。これでは、マイクロサービス化の取り組みは難しいと言わざるを得ません。

編集部　マイクロサービス化の取り組みは、どのような分野で進んでいるのでしょうか。

吉羽氏　サービス系の企業はもちろんですが、先進的なユーザー企業も、マイクロサービスの取り組みが進んでいます。日本でも、既にファーストリテイリングなどのユーザー企業が自らの手でマイクロサービス化の取り組みを開始しており、優秀なエンジニアの採用も積極的に進めています。また、コンサルティングファームの中にも、アジャイル開発のコンサルティングを提供しながら、自社の優秀なエンジニアを顧客の開発チームに送り込んで、開発の教育や支援を行うところも出てきています。

変化の大きい領域での契約に請負型は適さない

編集部　マイクロサービス化など顧客のニーズに対応するために、SIerはどう変わるべきだとお考えですか。

吉羽氏　アジャイル開発やマイクロサービス化に本気で取り組みたいと考えるのならば、契約もそれに適した形態を選ぶべきです。確かに、最初に全体のスコープと納期を決めて見積もり通りの費用でシステムを完成させる従来の請負契約だと、予算内、期限内での完成は保証されます。しかし、システム全体が完成するまでに時間がかかり、ビジネス要請の変化に合わせて柔軟に対応できないため、実際にシステムが完成してみると実情に合っていなかったケースも少なくありません。

　一方、アジャイル開発に合わせた契約形態、例えば準委任の下で、開発するサービスの優先順位付けを行って、市場価値が高いものから順に開発を進められれば、本当に必要なサービスだけを短時間で開発でき、実情に応じて開発の方向性を変えることもできます。どこかの段階で本来のビジネス要件を達成できたことが分かれば、残りのサービスの開発を取りやめることも可能です。

編集部　SIの現場では準委任型の契約は、まだ一般的には行われていませんね。

吉羽氏　確かに、業務の自動化や効率化を目的とした従来の基幹業務システムなどの開発プロジェクトでは、最終的なゴールがはっきりしており、顧客から見ると、開発の費用や期限が保証される請負契約の方が受け入れやすく、完成まで保証されない準委任型契約は敬遠されがちです。またSIerも、大規模なシステムを請負契約で一括受注し、コーディングや運用などの作業を外注した方が、利益を上げやすいため、準委任契約はやりたがりません。

　しかし、IoTやビッグデータ活用など企業のビジネスに直結するシステムの開発では、ゴールがはっきりしない未知の領域をカバーしなければならず、PoC（Proof of Concept：概念実証）などの開発手法を駆使して変化に対応する必要があるため、準委任契約の方が適しています。

　SIerが準委任契約によるアジャイル開発を提供するためには、顧客のチームと、共通するゴールを目指して頻繁なコミュニケーションをとりながら協力して作業を進めないといけません。そのため、SIerはこれまで外注してきたコーディングなどの業務も自社で提供できるようにする一方で、アプリケーション開発だけではなく、インフラ開発や運用のスペシャリストをきちんと配置するなど、クラウドを含めたサービス全体で顧客ニーズに対応できる体制を確立する必要があります。

エンジニアは「目利き力」を持って深掘りする領域を徐々に広げていこう

編集部　エンジニアは、顧客のニーズに応えるために、どのようなスキルを身に付けるべきだとお考えですか。

吉羽氏　顧客のビジネスの成功のために全力を尽くすことがエンジニアの責務だという前提に立てば、まずは日本国内だけではなく世界中にどのような事例があるかを知る必要があります。それができていなければ、そもそも選択肢さえ提示できません。

　具体的にエンジニアが身に付けるべきスキルは、アーキテクチャから、言語、フレームワークなどの実装レイヤーに至るまで、かなり幅広くさまざまな領域にわたっており、正直言って全てを身に付けることは不可能です。従って「目利き力」が必要となってきます。どこにフォーカスするかはエンジニア個人の好みに依存するので、一概には言えませんが、雇用環境の現状を考えると、どこに行っても食べていくことができる市場価値が高い領域を選び、学ぶコストを掛けるべきです。その領域は、スキルでも、技術でも、フレームワークでも、あるいはクラウドでも構いません。

　自分の例でいうと、アジャイルはその1つです。2000年代前半に、ウオーターフォールの限界を感じ、数年間アジャイルにフォーカスしました。日本の事例だけではなく海外の事例も多く調査し、海外の書籍も数多く読みました。そして、アジャイル開発のコンサルティングを行うようになり、その結果、書籍の執筆や講演を依頼していただけるようになりました。

編集部　「日々の多忙な業務の中で新技術を調査したり、学習したりする時間がない」という意見をよく聞きますが、いかがでしょうか。

吉羽氏　生存戦略として自分のキャリアを真剣に考えることをお勧めします。エンジニアがどうやって「目利き」するかという前に、自分がどうやって生きていくのかを考えることがすごく重要です。そうすれば、朝や通勤時間など、日々の空いてる時間を有効に使う必要性が出てきます。いきなり「毎日、3時間自分の時間を取る」のが難しかったら、1時間でも10分でもいい。疲れている日はしょうがないから休むのでもいい。とにかく“持続”させることが重要です。

　持続させるには、“好き”であることも大切です。「目利き」の話をしましたが、どの技術が将来、市場価値が高まるか見極めるのは難しい問題です。COBOLのエンジニアの数は年々減少していますが、大企業の中ではその需要はいまだに高く、今では逆にエンジニア不足になっています。このように、必ずしも新しい技術やスキルではなくとも、市場価値が高い有力な領域も、市場価値が高い有力な領域も存在します。自分が好きで有効だと思った領域を掘り下げる能力は身に付けておくべきです。

　掘り下げる能力を持っていると、新しい技術が出始めたときに、対応しやすくなります。よく「T」字型あるいは「π」字型という言い方をしますが、基礎的な幅広い知識や技術を身に付けながら、1つ、2つ、3つと、深く掘り下げる領域を増やしていけば、比較的容易に能力の幅を広げていくことができます。1つ掘り下げると、2つ、3つと掘り下げやすくなっていきます。

　「目利き」するために掘り下げる能力を身に付けるには、当たり前の話ですが自分で試して体感することが必須です。以前に比べて学習するためのコストは下がっていて、例えば自宅にLinux環境がなくても、Linuxを試す環境はクラウドで少しのコストを払うだけで手に入るようになっています。止めるのも容易です。

技術選定のキーワードは「勝ち馬に乗れ」

編集部　「目利き力」で言いますと、例えばクラウドプラットフォームに関しては、どれを深掘りすべきだとお考えですか。

吉羽氏　技術選定の観点からすれば、「勝馬に乗れ」ということをアドバイスします。クラウドに限らず、どのレイヤーでもそうですが、勢いに乗って優位に立っている技術は、顧客からフィードバックを多くもらって新しい機能もどんどん追加され、改善も進み、進化も速い。さらに、扱っているSIerやエンジニアの数も多いため、ネット上に多くのドキュメントが出回って、導入のハードルが下がるというメリットもあります。

　「勝ち馬に乗る」という観点で、今IaaSを深掘りするとすれば、やはりAmazon Web Service（AWS）かMicrosoft Azureということになるでしょう。Google Cloud Platformも有力ですが、IaaSの部分よりは、どちらかというとビッグデータ解析の「BigQuery」の方が注目されているのではないかと思います。

編集部　PaaSについても、幾つかのサービスがありますが、どのように評価していますか。

吉羽氏　PaaSの役割という点で評価するなら、インフラのレイヤーが透けて見えないもの単純なコマンドを実行するだけでデプロイが完了するものが望ましいです。

　具体的には、Azure Web Appsは画面上でクリックなどの簡単な操作だけでデプロイできますし、Herokuもインフラレイヤーを意識する必要がありません。Amazon Elasitic Beanstalkについても、オールインワンでデプロイできますが、複数のAWSサービスの組み合わせでできており、それぞれの中身を確認することもできます。ただし、SIerのエンジニアによっては、こちらの方が使いやすいと感じるかもしれません。

　特定の領域で使うなら、CRMだったらSalesforceのPaaS（Force.com）やDynamicsCRMなどを使えばいいし、ERPだったらSAPなどのPaaS（SAP HANA Cloud Platform（HCP））を使えばいい。データ処理の部分はAWSやAzureを使うなど、他のプラットフォームと組み合わせることもあるでしょう。

テクニカルロックインよりも問題なのは「SIerロックイン」

編集部　PaaSでは、テクニカルロックインの問題が指摘されることがありますが。

吉羽氏　PaaSのロックインの問題はDockerの登場により最近はあまり言われなくなりましたが、私はもともとPaaSがテクニカルロックインの問題を抱えるとは思っていません。なぜならば、PaaS上で開発したサービスを他のPaaSに載せ替えることは、Dockerの技術を使わなかったとしても、多くの技術者にとってそれほど難しい話ではないからです。

　むしろ問題なのは、技術よりも業務知識やノウハウの方がロックインされやすいということです。例えば、「企業のシステムを改修するために、業務フローを知ろうとしても、常駐しているSIerの担当者しか詳細が分からず、結局リプレースもそのSIerに依頼するしかない」という問題によく遭遇することがあります。そういう意味では、「SIerロックイン」の方がもっと深刻です。

編集部　ユーザー企業、とりわけ大企業はクラウド活用やアジャイル開発にどのように向き合えばよいとお考えですか。

吉羽氏　ビジネスに直結し競争力が求められるシステムについては、SIerに開発を丸投げする従来のやり方を改め、リスクを負ってでも、自分たちでITプロジェクトをコントロールできるようにすることが重要です。そのために新たに優秀な人材を雇う必要もあるかもしれません。そうしなければ、より早くフィードバックのサイクルを回すことができず、現状のビジネスの変化に対応することはできません。もちろん、ビジネスに直結しないとか定形的なシステムは今まで通りにSIerに依頼してもよいと思います。

目標となる人を定め、自分の価値をアウトプットする

編集部　最後に、社会に求められる市場価値が高いエンジニアになるためのアドバイスをお願いします。

吉羽氏　自分にとって目標となる人、すなわちロールモデルを定め、それを目指して経験を重ねていくようにすれば、成長しやすいでしょう。また、ブログの執筆、勉強会での講演、オープンソースの活動などを通して、自分の価値をアウトプットすることも重要です。いくら経験を重ねて価値を磨いても、その価値を世の中に表現できなければ、価値を持ったことにはならないと肝に銘じていただきたいですね。