1. 初めに
社内でAdvent Calendarをやっていると話題になったのが2018年。
これまでは様子見をしていたものの、昨年末に「Advent Calendarに挑戦したら？」と同じ案件メンバーから背中を押して頂き、1年越し（！）の宿題を果たすべく書くことにしました。
今年からアーキテクト(自称)ということで、技術に強く業務知識もある程度求められるシビアなポジションになり、今現在取り組んでいる仕事は新しいことばかりで常に手探り状況1ですが、そんなアーキテクト初心者が普段仕事をしている時に心掛けている３つのことをご紹介します。
2. この記事は誰に宛てて書いているか
以下の方々に向けてアーキテクトに興味を持ってほしいと思い、この記事を書くことにしました。
アーキテクトは大変ですが面白い仕事ですよ！
- SEに興味を持っている学生の皆さん
- 入社したばかりでこれからのキャリアプランを考えているSEの方
3. 仕事紹介
私が今主に担当しているのは製造業のあるお客様に対するシステム提案・設計です。
まだ従来型のSIも多いですが、DXやIoT、コロナ禍に対するテレワーク対応といった新しいキーワードも様々な案件で増えてきており、どういった提案をしていけばお客様の強みの業務をより高度化できるか、またセキュリティを担保しながらも社外で仕事を推進できるようになるかを考えることが多くなってきています。
その他にも、下記のような多種多様で複数のプロジェクトを跨る業務も多く、臨機応変かつ流動的な活動が多いです2。
- 情報システム部門向けにコラボレーションツール類の提案活動
- 各種ミドルウェア・フレームワーク類の設計手法の相談対応
- 開発プロジェクトからの技術的な問合せ対応
- 担当部署内の非定例のレビュー活動
- 開発者・運用保守担当者向け勉強会・説明会
今まさに困っている開発・運用保守担当者を迅速にサポートし、一方では将来的に問題になりそうな点を早めに予測して技術的な手法で対策を打てないかを考えるのが、今行っている仕事の全体感です3。
4. なぜアーキテクトを志望することにしたか
もともと私は情報系の大学に入ったこともあり、勉強したことが活かせるSIerを仕事に選びました。
入社していろいろな開発現場を経験している中で、決して長くない工期の中で複雑な処理を組み上げていく作業は難易度が高く、また想定外の問題によりプロジェクト全体が遅延してしまう等、さまざまなトラブルに遭遇することになります。
幸いにして、私自身はインフラ系のメンバーや研究開発部門の方、上司や周囲の方にも助けられてうまく解決できたことが多かったわけなのですが、こういった 自分自身の経験やIT技術を活かして周囲の開発・運用保守担当者の様々な困難をうまく解決できるよう手助けしていきたいと考えるようになったのが、現在のアーキテクトを志望するきっかけです。
もちろん、今のポジションは様々な案件や関係者、技術に触れる機会がある為、知的好奇心を満足させるという面もなくはないですが、どちらかと言えば、今持っている知識・技術で解決できないかどうかをまず考え、うまくフィットしない場合は別の新しい手法4を考えていくスタンスです。
5. アーキテクト初心者が心掛けていること
アーキテクトとして気にすべきポイントは数多くあると思いますが、他の職種と比較して特徴的だと思われるものを記載します。また、今回はシステム構築の領域において心掛けていることを３つ紹介します。
5.1. 時間経過による変化を整理する
システムは、構築される背景によって様々な変化を伴い構築・運用されていきます。
別のシステムと連携して使いたい、オンプレ環境からクラウドに移行したい、OS・ミドルウェアのEOLに伴い置き換えが必要といった理由によるものが多いです。
こういった予見される変化点を予め整理しておき、システムにも変更を行いやすいように対策を実施しておきます。連携するシステムとのインターフェースの整理であったり、クラウドでも利用できるミドルウェア・フレームワーク類を採用し設計にも織り込んでおく等です。
もちろんこういった作業はアプリケーションSEの方はされていると思いますが、システム全体を俯瞰してバランスを取るようにしているか、また本番運用した後も見据えて設計に反映できているかが違いとしてはあると思います。
5.2. 各レイヤの役割を明確にし、特異な構成にならないよう工夫をする
OS・ミドルウェアだけでなく、ソフトウェアの領域でもいくつかのレイヤを定義しておくことで、変更・拡張に強く、保守の際も効率良く作業を進めることができるようになります。
「資料は探す時間に多くを割かれる」とよく言われますが、ソフトウェアの世界でも同様のことが言え、理解しやすい統一的な構成になっていた方が効率的に作業を進められます。統一的な構成になるように、開発者に対する導入説明や定期的なレビュー、ツール類を活用したチェック5も対策としては考えます。
レイヤの不統一は技術的負債の一種とも言えるかもしれませんが、全て統一するのではなく制御可能な範囲で管理ができていればよいのではないかと最近は思うようになっています。
5.3. 実現すべき価値を大切にする
システム構築作業をしているとどうしても作り上げることに意識が向きがちで、システムが提供する付加価値がお客様の要望に沿っているか、当初の目的を達成しているかが薄れがちになります。
頻度は多くはないもののお客様との対話やプロジェクトメンバーからの情報をもとに、お客様が大切にしている価値観を把握することを心掛けています。それが分からないと真に解決すべき課題も見えづらくなったり、もっと別の簡単で迅速な方法も見つからなくなる為です。
また、システムやIT技術はあくまで業務効率化や高度化、新しいビジネスを開始する為の手段であって、それ自体は目的ではないことを心掛けるようにしています。
システムは構築し終わったらそれで終了ではなく、お客様にとっては新たな始まりの為、運用中のイレギュラーな業務フローにも耐え得るか、想定した以上の負荷がかかったときでも拡張性・性能は保たれるかといった観点を重視してシステム設計をするようにしています。
6. まとめ
アーキテクトとしての経験はまだ浅いので、案件に参画した時に知識不足を実感することが多いです。
- OSからアプリケーション層までの幅広い知識
- OSSだけでなく、各ベンダーが提供する製品の特徴の把握
- システムの非機能や一般的なドメイン知識の理解
上記のような幅広い領域の知識や経験が求められます。また自身の強みと呼べる領域がないと、他者との優位性がなく器用貧乏になってしまうので、何か1つは他者に負けない強みを作っておく必要があると感じています。
全般的に求められる水準が高いですが、お客様やプロジェクトメンバーから頼りにされるやりがいもある仕事です。
アーキテクトを目指そうと志す方が増えてくれると嬉しいです。また、挑戦好きで高みを目指したいと言う方、ぜひ協力していきましょう！
7. 但し書き
本記事の内容は個人の見解であり、所属する組織の公式見解ではありません。