NRIネットコム Blog

NRIネットコム社員が様々な視点で、日々の気づきやナレッジを発信するメディアです

技術選定とアーキテクトの育成について

 こんにちは佐々木です。NRIネットコム Advent Calendar 2021 開催中です。しかし、内部で検討した結果、私は枠外になりました。ということで、Japan APN Ambassador Advent Calendar 2021として書かせていただきます。どちらも宜しくおねがいします。

 今日のテーマは技術選定とアーキテクトの育成についてです。ITエンジニアの間には、定期的にどう技術選定するのかといった議論が出てきます。いろいろな観点があるとは思いますが、私が重要であると考えている所を簡単に述べてみます。

技術選定に銀の弾丸はない

 まず最初に言っておきたいのが、『技術選定に銀の弾丸はない』ということです。銀の弾丸とはIT業界でもよく利用される比喩で、英語で“silver bullet”とは「狼男を倒せる武器」が元々の意味です。それが転じて「困難を解決する決め手」という意味で使われています。ソフトウェア開発の名著「人月の神話」の副題にもなっていたことから、IT業界で好んで使われます。
 ここでいう『技術選定に銀の弾丸はない』とは、どこの組織の問題にも魔法のように解決する技術は存在しないということです。技術選定によくある失敗としては、最近流行りのアーキテクチャを採用してみたけど上手くいかなかったというのがあります。このようなケースの失敗の原因はどのようなものがあるのでしょうか。大きく分けて次の3つのケースがあります。

  • 組織内に、対象の技術に精通した人がいなかった
  • 対象の技術が、その組織のシステムに適用させるのが困難だった
  • そもそも組織内に、技術導入できるアーキテクトがいなかった

 3つの理由それぞれに、意図的に組織という言葉を入れています。どんなに革新的な技術でも、それに精通した人がいなければ失敗します。また、組織内の平均的なエンジニアが使いこなせるようにならないと、生産性は上がってきません。またモノリシックなシステムを運用してきた組織に、いきなりマイクロサービスを導入しようとしても頓挫します。そもそも技術選定したことが無い人に、新規のアーキテクチャを考えろと言っても出来ないし、外からアーキテクトを連れてきてもパフォーマンスを出すには時間が掛かります。

アーキテクチャの刷新方法

 いきなり絶望的な事を述べましたが、ではどうやってアーキテクチャを選定していけば良いのでしょうか?大きく2つに分けることが出来ます。全面刷新と漸進的な改善です。

全面刷新

 全面刷新は、その名の通り古いものを捨てて新しいものに刷新する方法です。この方法のメリットとしては、古いアーキテクチャに縛られないので最善のものを選べるという点にあります。デメリットとしては、プロジェクトの規模としては大きくなり、それに比例してリスクも大きくなります。また、刷新するアーキテクチャが最適なものであるという保証が必要になってきます。
 否定的な事を列挙しましたが、時として全面刷新が必要な場面は必ず出てきます。全面刷新を成功させるには、後述の事項を継続的に実施していく必要があります。また、事前にR&Dなどで技術検証や、並行期間やバックアッププランなどを用意しておく必要があります。この辺りは今回は割愛します。

漸進的な改善

 お勧めの方法としては、漸進的な改善です。これは、システムの一部を新しいアーキテクチャに置き換えていく手法です。置き換え方法としては、サブシステム単位であったり、一部のシステムを切り出していくといった手法があります。また既存のシステムの改修だけでなくとも、新規のシステムの場合にも適用できます。例えば、前回作った方法を踏襲しながら、2割程度に新しい技術を取り入れるといった手法です。こうする事により漸進的な改善を図ることができます。
 漸進的な改善のメリットは2つあります。対象を限定できるので、プロジェクト規模を小さくすることができます。必然的にリスクも小さくなります。次に、これが主題なのですが、常にアーキテクチャの検討が発生するので、アーキテクトの育成ができる点です。デメリットとしては、上手くやらないと増築を繰り返した古い旅館のように、複雑怪奇な構造になる可能性が高いことです。

技術の選定

 次に皆さん気になっている技術の選定です。技術の選定には、AWSやAzure、Google Cloudなどから、どのクラウドを選ぶかといったこともあります。AngularやVue.jsのどれを選ぶかといったことや、バックエンドの言語をJavaベースにするか、PHPにするかといったこともあります。ここで重要なのは、他の組織の選択が自組織にとっても正しいとは限らない点です。多くの場合は正しくない選択になることの方が多いでしょう。
 それは何故でしょうか?どのようなアーキテクチャであれ、扱うのは人間です。COBOLばかりやってきたチームに、いきなりJavaのSpring Bootで作ってといっても難しいのは解りますよね。ここまで極端じゃなくても、利用する人の特性を考慮する必要があります。技術によっては、使いこなすと効率があがるけど、習得が難しいものがあるのも事実です。また、Railsのような規約を重視するアーキテクチャは、少人数の開発では高いパフォーマンスを発揮しますが、大人数の場合は途端に難易度があがるといったものもあります。同様に変数の型なし・型ありの向き不向きなどもありますね。
 このような前提があるので、その組織のシステム・開発チームの実情を知らずにアーキテクチャを検討しても、ミスマッチが起こる可能性が非常に高いです。

小さな失敗を繰り返す

 それでは、どうしたら良いのでしょうか?先述した通り、漸進的な改善で小さなアーキテクチャ変更を繰り返していくことをお勧めします。アーキテクチャの改善を始めてみると、かならず多少の失敗は発生します。しかし、その失敗を許容することが大事です。小さな失敗も恐れて、失敗を許容しない文化になると、かならずどこかで大きな失敗を発生させることになります。そして、その大きな失敗は取り返しがつかない事態を招く可能性があります。それよりを防ぐためには、小さな失敗を繰り返して、その失敗から学んでいくことが大事です。
 私が見てきた所では、失敗を許容できる組織では、人の成長が早いです。理由として考えられるのは、次の3つです。

  • 失敗が許容されるので、積極性が生まれる
  • 事前の100%の計画・検討が省略できる。結果、短期間で沢山の試行ができる
  • 新しい事への挑戦を通じて、様々な知見を得られる

 こういった取り組みを繰り返すことで、いわゆるアーキテクトと呼ばれる技術の目利きが生まれてきます。

次世代につなげる

 アーキテクトが誕生したら、それで全て解決という訳ではないです。一人のアーキテクトに依存する組織は、様々な弊害が発生します。一番端的な例としては、第一人者の老害化です。一般的にアーキテクトの出番は、常にあるわけではないです。またアーキテクトは量より質が重要です。必然的に、特定のアーキテクトに仕事が集中することになります。結果、更にその人に知見が溜まってきます。これ自体は問題ないのですが、この状態がずっと続くと弊害が出てきます。人間どうしても、ある段階で保守的になる可能性が高いです。また、日進月歩で技術が遷移していっている世界では、その潮流に乗り続けるのも大変です。アーキテクトが一人しかいなくて、その人が成長を止めると開発組織としての成長も止まることになります。
 これを防ぐためには、構造的に次世代を育てる仕組みが必要です。その方法論はいろいろありますが、単純にいえば第一人者が若いものを見守って、いろいろ試させる環境をつくるといったことに集約できます。この際に、失敗が予見できた場合も、傷が大きくならない範囲で許容するといった事も大事かもしれません。失敗しないように過保護になると、失敗の経験ができません。しかし、失敗のまま放っておくのも問題なので、この塩梅は難しいです。

まとめ

 Japan APN Ambassadorのアドベントカレンダーの記事なのに、AWSに関することは全く出しませんでした。でも、私が技術選定をする際は、こういった事を考えながら選定しています。たぶんサーバレスで作るのがジャストフィットするといったケースでも、利用する人がEC2しか使った事がないのであれば、ここはコンテナ化で止めようかなど。或いは、チームの成熟度が上がっているので、このタイミングでアーキテクチャの全面刷新に取り組もうかなどです。これは自組織の場合もそうですし、アドバイザリーとしてお客様の開発組織をみる時も同じです。
 システムを作るのも使うのも人間です。そのシステムが誰が使うのか考えて作っていきましょう。また、自分がいつまでもいる訳ではないので、後継者の育成も重要です。こんな事を書いていると、自分も歳をとったなぁと思います。老害化していたら、遠慮なく周りから刺してください。お願いします。

 あとNRIネットコムのアドベントカレンダーも宜しくおねがいします

adventar.org

f:id:takurosasaki:20210326005216p:plain

執筆者佐々木拓郎

Japan APN Ambassador 2019
ワイン飲みながら技術書を書くのが趣味なおじさんです

Twitter:https://twitter.com/dkfj

Facebook:https://www.facebook.com/takuro.sasaki

個人ブログ:https://blog.takuros.net/

Amazon著者ページ:Amazon.co.jp: 佐々木 拓郎:作品一覧、著者略歴

Booth:https://takuros.booth.pm/