謙虚なITアーキテクトを目指す

私はITアーキテクトが集まる組織に所属し、ITアーキテクトとして活動しています。ITアーキテクトとは建築業界における建築家（アーキテクト）と同じように、システム全体の基本構造（アーキテクチャ）を設計する人です。
私はこれまでBPM（ビジネスプロセスマネジメント）のプロジェクトに参加することが多く、BPMの設計を得意としています。BPMとは別名ワークフローとも呼ばれ、例えば、保険業務の場合、保険申込→審査→承認→保険証券発行という一連の流れに沿って、複数の業務担当者が連携しながら1つの申込を処理していくシステムです。

ITアーキテクトと聞くと、どのようなイメージをお持ちでしょうか？IT技術に詳しく自信があり、職人気質で、他人の意見をあまり聞かない頑固な人をイメージされる方が多いのではないでしょうか？私は他社のITアーキテクトの方と一緒に仕事をする機会があるのですが、そういった傲慢？なタイプのITアーキテクトの方は確かにいらっしゃいます（傲慢という表現は大目に見てください）。技術に自信があり羨ましいと思う反面、もう少し他人の意見に耳を傾けてもいいのになあと思います。私はそういったタイプではなく、謙虚なITアーキテクトを目指しています。謙虚なITアーキテクトは、自分の考えに固執せず、人の話を良く聞き、物事を冷静に分析し、自分が間違っていれば素直に考えを訂正するイメージです。なぜ、謙虚なITアーキテクトを目指すかというと、自分一人の考えには限界があり、複数の意見を聞いて設計した方がより良いアーキテクチャが生まれるからです。

私が謙虚なITアーキテクトを目指す上で心がけていることには次の3つのことがあります。

これらの心がけを過去のBPMのアーキテクチャ設計の事例をもとに紹介します。

1. 意見を広く深く聞く

アーキテクチャを設計する際は、まず、システム関係者からシステムへの要求を聞きます。このときに広く深く意見を聞くことを心がけています。広くというのはシステム関係者の対象範囲を広くするという意味です。システム導入先の業務担当者の意見は当然お聞きしますが、さらに開発者や運用担当者の意見も重要視します。開発者には生産性の高い技術を使いたいという要求があります。運用担当者には安定稼働が再優先であるため、使い慣れた技術で運用したいという要求があります。このような幅広い意見を聞いて総合的にアーキテクチャを設計します。

また、深く意見を聞くことも心がけます。システム要求が出てきた背景を深掘りし、より上位の要求を把握します。BPMでは、業務担当者から入力効率化のためにショートカットキー機能や次入力欄への自動遷移機能などの要求をもらうことがあります。この要求の背景には、大量の業務を業務時間内に処理したい、顧客からの問い合わせに素早く対応したいという上位の要求があります。上位の要求を把握していれば、下位の要求がシステムの制約で実現できない場合でも上位の要求に対する代替案を提示して調整させてもらうことができます。

2. 設計を素直に素早く修正する

システムへの要求を聞いた後は、要求を分析し、アーキテクチャを設計していきます。このとき、私はモデリングを利用します。モデリングとはシステムを様々な視点から単純化（抽象化）し、分かりやすいモデルに表現することです。私は、まず、対象業務を理解するために概念モデルを作成します。概念モデルとは、業務に登場する概念（言葉）をUMLのクラス図で表現したものです。業務に登場する概念はお客様ごとに異なるため、認識合わせに有効です。また、BPMでは、ワークフローを理解する必要があり、UMLのアクティビティ図やBPMN(Business Process Modeling and Notation)を使ってワークの流れをモデルとして表現します。

ここで心がけていることが、分析・設計した結果のモデルを素直に素早く修正することです。BPMは複雑な業務であることが多いため、1回で正確なモデルを作ることはできません。我々SEよりも業務に詳しい業務担当者の意見を広く深く聞きながら、素直に素早く修正していくことが大切になります。

BPMのモデリングをするときの私のコツは、ワークリストに求められる検索条件を業務担当者に確認しながら、モデルを素早く修正していくというものです。ワークリストとは業務担当者や業務管理者が担当するワークを参照する一覧画面のことです。ワークリストは対象業務の全体像が画面の形式で確認できるため、業務担当者にも分かりやすく、モデルの検証に便利だと感じています。ワークリストの検索条件として次のような項目が候補となります。

■ワークリストの検索条件の候補
　起票者、ステータス、現在の担当者、組織、ロール、自分が処理したワーク、業務の種類、業務ごとの独自データ

3. 先人の知恵を活かす

アーキテクチャを設計する際は、自分で一から考えるのではなく、積極的に先人の知恵を活用します。
ソフトウェア業界にはデザインパターンやアナリシスパターンといった設計や分析に関する先人の知恵が蓄積されています。BPMに関してもワークフローパターンという知見がまとまっています。

また、プログラムレベルの先人の知恵にはOSS（オープンソースソフトウェア）があります。これらの知恵を使わないのは勿体ないです。
このように先人の知恵を活かそうと考えるようになったのは、昔、ジェームス.W.ヤングの書籍「アイデアのつくり方」に「アイデアとは既存の要素の新しい組み合わせ以外の何ものでもない」と断言されていて、「なるほど、それなら凡人の私でもできるかも」と思ったからです。

BPMとは話がそれますが、エクサでソースコード品質点検ツールのCHE-COBOを開発したときに先人の知恵を活用しました。当時、プログラム言語Javaの品質点検ツールはありましたが、COBOLのツールは見当たりませんでした。無いならば、自分で作ろうと思い立ちました。
品質点検ツールを構成要素に分解すると、「プログラムの構文解析」＋「品質点検ルール」になります。COBOLの品質点検ルールについてはCOBOLの開発経験が多いエクサに長年の先人の知恵が蓄積されていたので、構文解析をなんとかすればツールを開発できると感じました。そして、複数のOSSを組みあわせてCOBOLの構文解析を実現しました。この経験から、先人の知恵を活用すれば凡人の私でも大きなことが実現できる素晴らしい方法だと実感し、それ以来、積極的に活用しています。

BPMでもワークリストを実現するためにOSSを活用しました。ワークリストへの要求として、数千件のワークを1画面で参照したいという要求がありました。Webシステムでは、大量データを1度に表示すると、HTMLの画面表示に時間がかかり、ユーザの待ち時間が発生します。そこで、一般的には1画面に全てを表示せず、10～50件単位でページ分割する方法を取ります。OSSを調べたところ、スクロールした時の表示領域のみHTMLを生成し、非表示領域はHTMLを生成しないという方法で数千件の一覧画面を待ち時間少なく表示できるOSSがありました。このOSSを活用することでお客様からの要求を実現できました。自分一人では実現できなかったので、このOSSの作者には感謝の気持ちで一杯です。

先人の知恵は強力ですが、活用するためには先人の知恵を事前に知っておく必要があります。いろいろなことにアンテナを張り、先人の知恵をひたむきに学ぶ姿勢が大切だと感じています。

～～～

以上のように、自分一人の考えに固執せず、複数の人の意見を広く深く聞き、設計結果を素直に素早く修正し、先人の知恵を活用する、謙虚な姿勢のITアーキテクトを目指していきたいと考えています。