技術でチームをリードする「アーキテクト」に不可欠な資質

ソフトウェアエンジニアリングセンター長の、藤本です。

私はこれまで、多くのシステム開発とプロジェクトの緊急対応支援を経験し、アーキテクトとしてキャリアを積んできました。その経験の中で、良いシステムとは十分に検討されたアーキテクチャがあって実現できると、強く感じています。そこで、アーキテクトに必要な資質、特性、組織について私なりにまとめたことを、数回にわたってお届けします。

アーキテクトとは？

アーキテクトは、一般に、要件定義やシステム全体の設計を行う人を指します。IPA（情報処理推進機構）のシステムアーキテクト試験（SA）の項「2．業務と役割」には、以下のように記載されています。

〔情報システム〕
情報システム戦略を具体化するための情報システムの構造の設計や、開発に必要となる要件の定義、システム方式の設計及び情報システムを開発する業務に従事し、次の役割を主導的に果たすとともに、下位者を指導する。

• (1)情報システム戦略を具体化するために、全体最適の観点から、対象とする情報システムの構造を設計する。
• (2)全体システム化計画及び個別システム化構想・計画を具体化するために、対象とする情報システムの開発に必要となる要件を分析、整理し、取りまとめる。
• (3)対象とする情報システムの要件を実現し、情報セキュリティを確保できる、最適なシステム方式を設計する。
• (4)要件及び設計されたシステム方式に基づいて、要求された品質及び情報セキュリティを確保できるソフトウェアの設計・開発、テスト、運用及び保守についての検討を行い、対象とする情報システムを開発する。
  なお、ネットワーク、データベース、セキュリティなどの固有技術については、必要に応じて専門家の支援を受ける。
• (5)対象とする情報システム及びその効果を評価する。

この記事の中では、「技術でチームを引っ張っていく人」くらいに捉えて読んでください。技術でチームをリードする人になるにはどうすればよいのか、お話ししていきたいと思います。

自身の経験から感じる、アーキテクトに必要な資質

私のキャリアのスタートは、汎用機のシステム開発でした。開発言語はCOBOLです。当時の私は、COBOLとJCL（Job Control Language：ジョブ制御言語）しか知りませんでした。仕事を始めて3年ほど経った時、同じ顧客の別プロジェクトでWeb開発が始まりました。1999年のことです。エンジニアとして、汎用機での開発しか知らない状況に焦りを感じ、プロジェクトに参加したいと自ら手を挙げました。

Web開発ではとにかく覚えることが多く、HTML, JavaScript, Java, SQLと、身につけなくてはならない技術が一気に増えました。知らないことが見つかる、わからなくて悔しい、自分で調べる、それでもわからないことを人に聞く、こうした成長のサイクルを回す毎日でした。ここでの数年間の習慣がエンジニアとしての柱になったと思います。

ただ、切羽詰まって勉強したというよりも、常に遊び感覚を持っていました。この遊び感覚がないと技術を掘り下げることができません。実際に仕事だけでは技術のキャッチアップが追いつかず、自宅でも夢中になって技術に触れていました。家でも仕事をするなんて......、と思われたかもしれませんが、自分が心から興味を持てる分野でないとスキルアップしにくいのです。

かと言って、周りが強引に興味を持たせようとしても難しいと思います。技術志向の資質や本人の興味を無視して、アーキテクトを育てようとするのは厳しいでしょう。技術で身を立てたいと思うエンジニアや、社内でアーキテクトを育てたいと考えるマネージャは、この点を理解しておく必要があります。ただ、興味がないものにも一度は触れることをお勧めします。触れてみないと、興味が湧くかどうか判断ができません。最初から食わず嫌いはやめましょう。

アーキテクトが悩まされる孤独

アーキテクトは、自分が興味のある技術分野を掘り下げていくだけでよいのでしょうか？いえ、決してそんなことはありません。

技術で頼りにされるアーキテクトに成長すると、プレッシャーを強く感じるようになります。プロジェクトで採用する技術についての決定を行わなければならないためです。この時アーキテクトは、技術の概要、メリットやデメリットなどをマネージャに分かりやすく説明し、説得できる能力が大事になってきます。

このような仕事をしていると、プロジェクトの成否が自分にかかっているというプレッシャーを感じるようになります。技術に関してプロジェクト全体の責任を一人で負っている感覚です。システムに問題がなければ誰も文句を言いませんが、問題が発生すると「なんでそんなやり方にしたのか？」「誰がこの技術を選んだんだ！」と言われる立場になるわけです。

プレッシャーを感じながらも、どう改善していくか、何が最善か、仮説を立て、論理立てて考え、技術的なことを分かりやすく翻訳して、周囲に説明する技術も必要です。技術について明るいアーキテクトが、丁寧に説明するからこそ、マネージャやお客様が正しい判断をすることができるのです。

アーキテクトとしての活動を続けていると、同じレベルで技術やシステムについて理解している人が周りにほとんどいなくなるため、相談に乗ってくれる人が少なくなります。プレッシャーはそのままに孤独を感じる状況が生まれがちです。ラックでは、アーキテクトが一人で苦しんで相談できない状況をなくすため、社内を横断する部署である、ソフトウェアエンジニアリングセンターがあります。この部署についての説明は、次回以降で触れたいと思います。

アーキテクトが陥りがちな罠

アーキテクトが孤立を深めやすい環境を、自分で作ってしまうこともあります。馬鹿にされたくない気持ちから、マネージャやお客様に「できません」と言わないことです。こうした気質は、技術をキャッチアップするのに必要かもしれませんが、技術に責任を持つ立場では邪魔になります。プライドがあればあるほど言いにくいと思いますが、できないことははっきり伝える必要があります。

本当は「技術力がないからできない」と言いたくないだけなのに、期日的に難しいことまで「できない」と言えなくなってしまうこともあります。

例えば、東京から大阪まで30分で行ってください、というような無理を通り越して、無茶な要求に近いことまで、「できない」と言えない場面が出てきます。プレッシャーを感じる中、プライドを持って仕事に臨むことは大事ですが、無理なことを抱えて苦しんで、チームに押し付けることがアーキテクトの仕事ではありません。できないことはできないと言いましょう。

アーキテクトとしてチームをリードする人になるには

技術をリードしていくには、自分で積極的にスキルを掘り下げられる人でないと難しいと思います。また、成長につれてプレッシャーも増え、孤独感やNOを言えなくなることが、自分を苦しめることもあります。それでも、大変やりがいがある仕事だと私は思います。

次回以降、さらにアーキテクトであるために必要なこと、アーキテクトの特性、アーキテクトを支える組織についてお話したいと思います。どうぞお楽しみに。