今の日本における「情シスの悩みトップ5」とは、エンジニアは、どう応えられるのか：特集：今、市場に求められるITアーキテクトの視点（2）

「市場に求められる」「本当の価値を持つ」エンジニアであるために必要な考え方を身に付けるにはどうすればいいのか。そのヒントの幾つかは、企業で業務部門のIT課題を解決すべく日々奮闘する、情報システム部門が持つさまざまな悩みにある。

[吉村哲樹，＠IT]

特集：今、市場に求められるITアーキテクトの視点

クラウドによって誰しもが大量のコンピューティングリソースをすぐに使える時代になり、開発・運用エンジニアにおいても「技術を実際のビジネスサイクルの中でどう効率良く、かつスピーディに生かすか」が重要視されている。そのために必要な技術や手法にも目を向けることによって、エンタープライズにおける、あるべきアーキテクチャ設計が見えてくる。

本特集は「市場に求められる」「本当の価値を持つ」エンジニアであるために必要な考え方や、手法を詳しく解説。あらためて“エンジニアとしての自分の価値”に気付ける＠ITからの処方箋だ。

特集：今、市場に求められるITアーキテクトの視点

「情シスの悩みトップ5」をITアーキテクト視点から読み解く

　「市場に求められる」「本当の価値を持つ」エンジニアであるために必要な考え方を身に付けるにはどうすればいいのか。そのヒントの幾つかは、企業で業務部門のIT課題を解決すべく日々奮闘する、情報システム部門（情シス）が持つさまざまな悩みにある。＠IT編集部が2015年に行った読者調査では、限られた時間とコスト、人員の中で奮闘する情報システム部門が抱える数々の課題や悩みがフリー回答で寄せられた。まとめると、以下の5つに集約される。

システムの変更容易性をいかに確保するか？

開発効率を向上させ、より少人数で対応するには、どうすればいいか？

開発環境をいかに選定・統一するか？

人材不足。ノウハウをいかに伝承していくか？

セキュリティ脅威および高負荷トランザクションに、いかに対応するか？

　ほとんどの企業の情報システム部門では、多かれ少なかれ上記トピックのうちの幾つかが、リアルな課題として持ち上がっているのではないだろうか。そこで本稿では、これらの課題を解決するためのアドバイスを、TISにおいてトップアーキテクトとして活躍する熊谷宏樹氏に、「ITアーキテクトの観点」から聞いてみた。

システムの変更容易性をいかに確保するか？

ビジネスの変化に追随できるよう、既存の重厚長大なシステムをマイクロサービスのような小さな単位に分割したいが、どうしてもうまくいかない

今後、社内の基幹システムを刷新していく予定ですが（Excel・手作業のIT化）、業務運用のルールやインタフェースを大きく変更することになるため、各業務部署が変化に対応できないことが最大の懸念点です（過去にも1度頓挫しているため）

　＠ITの読者調査でも、上記のような具体的な悩みがフリー回答で寄せられているように、今日の業務システムは日々速さを増すビジネス環境の変化スピードに追随できるよう、カットオーバー後も柔軟に変更を行えることが求められている。しかしエンタープライズシステムの「大規模で複雑」な要件と、ビジネスが求める「変更容易性」という要件は、そう簡単には相いれない。

　こうした状況を打破するには、どうすればいいのか。新たにシステムを設計・開発する際には、2つの考え方があるという。

　1つは、「システム全体の中でも変更が入りやすい箇所を特定し、そこを変更を受け入れやすいアーキテクチャにしておく」という考え方だ。変更が入りやすい箇所を予期するのは、顧客がビジネスを今後どう変えていこうかという“ポリシー”がないと非常に難しい。

　そこで熊谷氏は、変更を予期することは不可能だとした上で、「アジャイル開発的な発想」を取り込むことがもう1つの打開策になると提言する。「システムを設計する際、将来の変更を見込んだスペックをあらかじめ盛り込んでおくという手もあるが、将来発生すると予想される変更内容があらかじめ見えていないと難しいし、開発コストも掛かってしまう。そこで、まずは最小限のスペックで開発し、将来新たな要件が発生するたびに変更箇所を新たに開発していくというアジャイル的な方法が有効だ」。

　現存するシステムに変更容易性を持たせる場合は、まず、ソースコードの変更履歴を確認し、変更が入っていない箇所と多かった箇所を特定・分類する。その上で、変更が入っていない箇所は、そのまま使い続け、変更が多かった箇所は今後も変更が入りやすいだろうと予期し、プログラミング言語やプロットフォームを変えたり、ユーザーが自分で変更もできるルールエンジンベースのアーキテクチャにしたりするなどして、変更容易性を持たせる方法がある。ルールエンジンベースにすれば、ユーザー自身がシステムを変更しやすくなるという利点もある。

　最初のフリー回答にあった、既存システムをマイクロサービスのように小さい単位に分割したいという悩みについても、システムをSoR（System of Record）とSoE（System of Engagement）に分類し、SoEのシステムに関してはマイクロサービスのように小さい単位に分割する方法が有効ではないだろうか。

開発効率をいかに向上させるか？

開発手法が確立できていないため、開発に時間がかかり過ぎている

生産性が低い。保守でプロジェクトに参画するがドキュメントがなく、調査に時間がかかったり、同じ調査を行ったりで、バグが発生しやすい

　開発効率の向上は、いつの時代も開発者にとって重要なテーマだった。事実、これまで開発効率の向上をうたったさまざまなツールが登場し、そのうちの幾つかは実際に大きな成果を上げてきた。ただし熊谷氏は、「新たなツールの導入・活用による実装の効率化は、そろそろ頭打ちに近づいているのではないか」と指摘する。その一方で、ビジネス環境の変化スピードは加速しており、業務システムの開発や改修にもより一層のスピードが求められている。

　こうした状況の中、現在一部の企業で始まっているのが、アジャイル開発手法のコンセプトを自社の開発プロセスに組み込み、システムのリリースまでにかかる時間と手間を「最小化」する試みだ。「一般的なエンタープライズシステムの開発プロジェクトでは、まず設計ドキュメントを作成し、それを基にクライアントと設計レビューを行う。しかし近年、開発者とクライアントがツール上で画面デザインやロジックデザインを共有しながら、一緒に設計を進めるというやり方を採る企業が出てきた。これにより、設計ドキュメントの作成や設計レビューにこれまで掛けてきた手間や時間を省き、より短期間のうちにシステムをリリースできるようになる」（熊谷氏）。すなわち、「設計」を効率化するのである。

　ただし、こういった手法での開発を進めていくためには、解決すべき課題も存在する。システムの構築を依頼する側と、構築する側が、リスクを押し付け合うのではなく、リスクを共有しプロジェクト成功のために協力し合うようにならなければならない。

　現在は開発プロセスの変革期であり、要件が複雑なエンタープライズの基幹系システムなどに、アジャイル開発手法が適用するには、まだまだ時間が必要だが、要件が比較的小さなフロント系システムなどでは、「設計」を効率化するプロジェクトの進め方を試行する先進的な企業が現れてきているという。

　バックエンドの大規模な基幹システムはウオーターフォールで開発しつつ、フロント系システムはアジャイル開発手法を取り入れるというのは、オムニチャンネルやFinTechの流行にも見られる通り、エンタープライズにおける開発プロセス効率化の現実解なのかもしれない。

開発環境をいかに選定・統一するか？

独自開発したツールのメンテナンスが困難になってきた

ツールやミドルウェア、開発手法などで、新しいものを取り入れるべきタイミングの見極めが課題。何でも手を出せるというわけではない。でも、他社よりも後れたくない

　＠ITの読者調査では、情報システム部門の現場の声として上記のような回答が寄せられた。熊谷氏が主に手掛ける大手企業のミッションクリティカルシステムの開発プロジェクトでは、「開発環境の管理や標準化のための手法がしっかり確立されていて、ツールやミドルウェアのバージョンアップに対応しやすくなるMavenやDockerといったツールの利用も進んでいるため、こういった課題が持ち上がることは少なくなってきている」という。

　そうした経験を踏まえ、開発環境の選定や標準化に当たっては、ただやみくもに最新の技術を取り入れるのではなく、より長期的な視点に立って慎重に検討すべきだと熊谷氏はアドバイスする。

　「例えばJavaであれば『Java EE』『Spring Framework』など、世の中でより多くのエンジニアに認知されているオープンアーキテクチャを採用した方が開発者を集めやすいし、技術が陳腐化しにくいので将来のメンテナンスやエンハンスのことを考えても安心感が強い。また、システムの構造やデータ構造を可視化してくれる機能を備えた開発環境なら、後に別の開発者がメンテナンスを行う際も、ソースコードと設計ドキュメントだけを手掛かりにするより、はるかにプログラムの構造が理解しやすくなる。こうした長期的な観点も取り入れた上で、適切な開発環境を選定すべきだろう」

人材不足。ノウハウをいかに伝承していくか？

深刻な人材不足。現状、分析や設計、開発、テスト、運用支援までほぼ1人でやっている状況。社内SEという関係か、募集をしても技術職を希望する人が来ない

実開発は外注委託がほぼ100％となっており、若手の実開発経験・ノウハウが空洞化しているため、委託開発の発注・検収の責任が事実上取れていない

　こうした悩みは、現場のエンジニアに大きな負担とストレスを強いるのはもちろん、システムを管理する側にとっても、運用のノウハウが特定の担当者に集中してしまう、いわゆる「属人化」のリスクを招いてしまう。

　しかし熊谷氏は、「こういう嘆きが多く聞かれる現場に限って、ノウハウ伝承のための具体的な施策は手付かずの場合が多い」と述べる。「人が増えれば……」「暇ができたら……」といった受け身の姿勢では、いつまでたっても状況は好転しない。自ら行動を起こさない限りは、ノウハウを他のエンジニアと広く共有し、自身が成長し、他の仕事を手掛けられるようにはならない。

　そのための“コツ”の1つを、熊谷氏は次のように明かす。「もし1人で仕事を抱え込んでいる状況であれば、例えば『あともう2人増やしてくれれば、3人のチームで5人分の成果を上げることができる』と上長にアピールしてみる。こういう内容の提案なら上も決して無視はできないだろうし、実際に人が増えたら、それまで自分1人で抱え込んでいた仕事を他のメンバーに徐々に移管しつつ、時間を作ってノウハウをドキュメント化していく」。

　もし「属人化した状況を改善したい」「もっと別の仕事も手掛けて成長したい」と望むのなら、より多くの価値を提供できることをアピールし、現状を変えていく提案を自ら積極的に行っていくべきだろう。

　一方で、いつ人が増えたり、自身が移動してもいいように、普段から時間があれば、自身が携わるシステムのデータ構造や機能の一覧、作業の手順などをドキュメントにまとめたり、さらにいえば、作業は自動化しておいたりすることで、属人化しないように具体的な作業を進めておくのも有効だ。また、これから新しいシステムを開発し運用していく場合でも属人化しないようにするには、先ほどから話にあるように変更容易性が高いシステムを構築する必要があるだろう。

セキュリティおよび高負荷への対応

セキュリティやサーバ管理専門の担当者がいないため専門外の私が兼務しており、不安を抱えています。広く安定してどこでも使える共通環境がない

独学なので、動作確認ができていても、「それが最適なソースコードなのか」「どこかにセキュリティホールはないか」など見極めるチェック体制がない

　近年、サイバー攻撃の脅威はますます深刻化する一方だ。企業システムにもより強固かつ迅速なセキュリティ対策が求められているが、＠ITの読者調査でも上記のような声も寄せられた。

　熊谷氏は、「セキュリティ対策に限っていえば、妙案は存在しない。セキュリティ部門が社内でしっかりチェックして、セキュリティホールをなくしていくしかない」と提言。書かれたコードの脆弱（ぜいじゃく）性をテストするツールを使ったり、それを自動実行させる仕組みを確立させたり、バックエンドにデータが流れる前に不正なデータではないかチェックしたりするなどが基本だという。

　一方で、利用しているソフトウェアに対する新たな脅威が発生する可能性も無視できないので、新たな脅威の発生をいち早くキャッチし対策するための情報ソースをコンサルティング契約のような形で用意することも重要である。

　一方で、高負荷トランザクションに耐えられるだけの安定性を確保するためには、システムを開発する際に負荷テストを実施することはもちろんだが、同時に「耐久テスト」も行うことが重要だと指摘する。

　「例えば、1時間当たりの最大トランザクション量の要件をクリアするためには、通常は1時間の負荷テストを行うが、たとえこれを問題なくクリアできたとしても、長時間の連続稼働で初めて露見する不具合も考えられる。そのため、できれば長時間耐久テストは、ぜひ実施しておきたい。また高負荷に耐えるシステムを実現するには適切なチューニングが必要だが、例えば『1トランザクション当たりの消費メモリ量』など、アプリケーション側で消費するリソース量を机上計算した上で、負荷テストを行い、その結果に基づいて、チューニングパラメータを設定していくことが重要だ」

情シスが自社のビジネスゴールにより深くコミットしていくには？

　なお、企業の情報システム部門にとって決して看過できない、もう1つの大きな動向として、いわゆる「情シス飛ばし」がある。業務部門が情報システム部門を通さず、独自の判断でSIerにシステム構築を直接依頼したり、クラウドサービスなどを導入したりするケースが増えてきているのだ。

　ビジネス環境の変化に即応するためには、ビジネスに直接関わっている業務部門がITを扱う方が理にかなっている面もある。しかし、各業務部門がそれぞればらばらの考えと判断の下でシステムを構築していけば、全社レベルでのIT統制はとれなくなり、セキュリティポリシーの順守やIT投資の最適化などの面で問題が生じるのは目に見えている。

　それではと、上層部から強大な権限を与えられた情報システム部門が、業務部門からITに関する一切の裁量を剥奪し、がちがちにITガバナンスを固めたとしたらどうなるか？ 確かにセキュリティ対策上はこうした体制が望ましいのかもしれないが、その半面、ビジネスの最も近くにいる現場の声がITに反映されにくくなることで、企業全体のビジネス競争力の低下を招きかねない。

TIS 生産革新本部 フェロー 熊谷宏樹氏（＠IT「徹底解説！ ITアーキテクトとは何か？」を連載）

　この相反するファクターのバランスを取るのは極めて難しいが、情報システム部門としてできることは、まずは「開かれた情シス」を実現し、自ら業務部門に歩み寄ることではないかと熊谷氏は提言する。

　「業務部門がやろうとすることにあれこれと制約を設けるだけではなく、むしろ現場がやろうとしていることを積極的にサポートする姿勢が重要ではないか。ガバナンスの効かせ方にしても、『事前に必ず許可を得ること！』ではなく、『事前に相談してくれれば一緒に検討しますよ』というスタンスで望むべきだろう」

　その際情報システム部門のエンジニアには、新たに実現しようとしているシステムと、会社全体のシステムアーキテクチャとの間の整合性を慎重に検討し、全体最適の観点から適切な実装方法を導き出す役割が求められる。と同時に、そのシステムが「会社の収益にどの程度貢献し得るのか」「会社全体の事業戦略に合致するものなのかどうか」といったビジネス上の観点からもシステムの価値と優先度を見極め、現実的な対応を採っていく必要があるという。

　「こうしたビジネス視点は開発者やエンジニアだけではなく、システム運用担当者にとっても本来は不可欠なものだ。システムの運用コストを下げて会社の収益の改善に貢献したり、システムをより早期にリリースして自社製品・サービスの競争力向上に寄与したりするためには、運用担当者がシステム運用の課題を開発者に適宜フィードバックし、共に手を取り合ってシステムの改善に取り組んでいくことが不可欠だ」

エンジニアとしていかに付加価値を提供できるか？

　ちなみに、トップアーキテクトとして数々の大規模開発案件に関わる傍ら、近年では若手アーキテクトの育成にも力を入れているという熊谷氏は、ITアーキテクトとして日々の業務で一体どんなことを意識しているのだろうか？

ITアーキテクトの役割（記事「あらためて見直す、ITアーキテクトの役割」より引用）

　熊谷氏は「自身がアーキテクトとしてプロジェクトに関わったことで、『より短い納期でシステムを納められた』『コストを低く抑えられた』『要望以上の機能が実現できた』といった付加価値を提供できたかどうか――これらを、常に自身に問い続けることが大事だ」と考えているという。

　「もし何の付加価値も提供できなければ、その仕事は誰がやっても同じだったということ。やはりエンジニアとしての努力を目に見える形で提供できなければ、お客さまの満足も得られない。これができるかどうかが、プロフェッショナルなITアーキテクトになれるかなれないかの分かれ目になると思う」

　熊谷氏は、将来アーキテクトを目指す若手エンジニアに対しても、折を見てこうしたアドバイスを送っているそうだ。ただし、こうした姿勢は何もITアーキテクトという立場に限った話ではなく、企業の情報システム部門も、いかに付加価値を業務部門に提供できるかが大事になってくると熊谷氏は言う。

　「『情シスに相談すれば、こんなアドバイスをもらえる』『情シスを通せば、SIerやベンダーとの技術的な課題解決において解決案を提示してくれる』『情シスは、われわれが思いも寄らないようなアイデアを出してくれる』と言われるような“バリュー”を業務部門に認めてもらえるようになれば、ビジネスに寄与する“システムのコーディネート役”としての存在意義を発揮できるようになるのではないだろうか」

関連特集：今、市場に求められるITアーキテクトの視点

クラウドによって誰しもが大量のコンピューティングリソースをすぐに使える時代になり、開発・運用エンジニアにおいても「技術を実際のビジネスサイクルの中でどう効率良く、かつスピーディに生かすか」が重要視されている。そのために必要な技術や手法にも目を向けることによって、エンタープライズにおける、あるべきアーキテクチャ設計が見えてくる。

本特集は「市場に求められる」「本当の価値を持つ」エンジニアであるために必要な考え方や、手法を詳しく解説。あらためて“エンジニアとしての自分の価値”に気付ける＠ITからの処方箋だ。

特集：今、市場に求められるITアーキテクトの視点