この記事を書いてみようと思ったきっかけはここにある。

　「仕事ごっこ」や「○○の問題地図」、といった著書を数々出している沢渡あまね氏ではあるが、そんな彼でも言語化に悩む問題がこちらのツイートだ。
　新たな価値を生み出すことはもちろん大事だが、多くの企業は新たな価値を生み出すことに躍起になって、実際の現場を見ていないケースが多く、地に足がついていない状態なのは、社会人として日々働いている人たちには少なからず感じている違和感だと思う。

　では、何が難しいのか、そこに関してIT知識に関してわかりづらい人の為に、ちょこちょこ歴史や料理に例えつつ、軽く説明してみよう、これはそんな記事だ。
　内容が専門的なので、聞き慣れない用語も多いだろう、そのための説明文も含んでいるので非常に長くなるのはご理解いただきたい。

ITアーキテクト？クラウドマイスター？広義的には業務ハッカー？

　この節が論点だ。沢渡氏がこれを定義しようとしているのには、現在実際にその業務を行っており、難易度の高い業務であるにも関わらず既存の別の呼び名で呼ばれ、実際のその職で持つべき対価や理解を得られない中、頑張っている人達の為に、定義しようというものだ。
　こうなる前提に、各職種・業種での呼び方が最近どうにも雑になってきているというか、日本語と同じで意味を調べずに使うケースが増えているからだと思う。

ITアーキテクトとは？

　会社で情報システムを構築するにあたり、複数のシステムで業務は回るようになっている。
　例えば勤怠管理システム、人事管理システム、採用管理システム、会計システム、経理システム、購買(調達)システム、資産管理システム、プロジェクト管理システム、ドキュメント管理システム、情報機器管理システム、入室管理システム、他にも製造業などでいくと部品構成管理システム、図面管理システム、製造実行システム、備品管理システム、計測システム、更に細かくいうとそれぞれの業務単位でExcel管理までもがシステム予備軍だ。
　ITアーキテクトは、それら大量に発生するシステム群が、機能が重複したり抜けがあったり、運用性に問題があったり、そういった企業のビジネスのバックボーンを最適かつ最高のパフォーマンスを叩き出すための企画・設計業務が出来る役割であり、業務種別だ。
　近頃の中小企業では社内SEと呼ばれる人がこの役割を担っていたりする。
(逆に社内SEの範囲が広範になってきており、社内システムの開発も社内SE(実際はアプリエンジニアが近い)、ヘルプデスクも社内SE(これはいうまでもなくヘルプデスク)、インフラ構築も社内SE(こちらはインフラエンジニア)、ISMS対応も社内SE(これは内部統制)、システム導入も社内SE(こちらがITアーキテクト)、なんて社内SEという言葉が使いやす過ぎて、企業の求人の社内SEの業務範囲を見ると、まぁこれまたどれだけ採用担当は業務を知らないのか、と思ってしまう)
　IPA(情報処理推進機構)の資格の中に、ITストラテジストというものがあるが、こちらは経営戦略に対し、\その基盤となるIT戦略を策定し、昨今流行りのDX(デジタルトランスフォーメーション)を始めとした業務改革などで事業の業績UPを図ったり、他社との差別化を打ち出したり、と大号令をかける準備をし、実行するいわばPJリーダーだ。
　かたやITアーキテクトはというと、主にはそれを支えるシステム群を、実際に要件定義などを行い設計し導入にあたる役割を担う。
　身近に例えて言うと、「マッチョになりたい」が経営戦略、「では食事で見直そう、献立はこうだ」がIT戦略、「献立を実現するには、食材はこれとこれ、調理器具はこれとこれ、レシピはこれ」がアーキテクト、シェフが開発、味はどうか、栄養価はどうか調べるのが検証、それを食べて肉体改善を図るのが企業自体、といったところだ。

クラウドマイスターとは？

　国家資格や法人資格でもないただの通称になるが、IBMのクラウド事業統括理事などがクラウドマイスターを名乗っている。
　マイスターとは職人(匠)を表すドイツの資格制度が語源となっており、日本でもここ数年でかなり聴くようになった単語だ。
　クラウドはもちろんITなのでクラウドサービスの事を言うが、GAFA各社のサービスも勿論のことながら、今や殆どのIT企業のサービスがクラウドへと変化していっている。
　クラウド戦国時代、とでもいうべきか、大小様々なサービス(大名)が群雄割拠している。
　クラウドマイスターはそのサービスを熟知しており、どこのサービスがどの特徴や基盤を持っていて、どうすればニーズに対して最適なサービス構成となるか、そしてサービスや機能が存在しなかった場合どうすれば解決出来るか、それらの知見を持ち合わせており、有効打を出せる人達のことを言う。
　どれくらい凄いかというと、各地の戦国大名の名前や資金力、軍事力、経済力、家臣の数、強みをまるっと把握しているようなものである、当時で言うと朝廷か神かのどちらかだ。
まぁ実際IBMのクラウド事業統括理事にお会いしたわけでもなく、実力も知らないのでさすがに上記は持ち上げ過ぎかもしれないが、クラウドマイスターというのはそれだけクラウドの世界に対する知見がとてつもなく幅広い。
靴職人がそうであるように、職人というのはその分野に意識を全振りしているのである。

業務ハッカーとは？

　業務ハッカー、聞き慣れない言葉だ。
　業務ハック+人を表すer、つまり業務をハックする人。
　ハック(またはハッカー)というと、相手のシステムに潜り込み、相手の情報を盗んだり破壊したりするのを想像するかもしれない。
　かたや、最近ではライフハックという言葉が一般的になっており、身近にあるものをちょっと見方や使い方を変えることで、生活を便利にする、というものを意識する人もいるかもしれない。
　今回話す内容は、どちらも当たっていてどちらも正解だ。
　こちらも資格などではなく、ソニックガーデンさんが発した人の役割の定義だ。

業務設計とシステム化の問題

　業務改善のためのシステム導入において、最大の難関は、導入担当者はその職場のことを知らないことにある。
　その職場で普段どういう業務が行われていて、どれだけ電子化されていない情報があって、どんな課題があり、そのうち何%が見えるように管理されているか。
　例えばあなたが社会人ならば、自分の職場の問題や人の関係は理解しているだろう。
　あなたが学生の場合は、あなたのクラスがとても仲良く、先生たちから理想と呼ばれるクラスだったとしよう。
　さて、そんなあなたたちがいきなり、となりの職場(クラス)の問題を何らかの方法で解決してほしい、と言われたらどうか。
　まず「いやいや、無理無理」となるだろう。
　ITアーキテクトや社内SEと呼ばれる人達がシステム導入の要件定義をする、というのはそこから始まる。
　私は元々製造業の社内SEをやる前は、製造現場で実際に機械を回していたし、その後備品管理や工程、ヘルプデスクを経験したこともあり、その職場の生産ラインからインフラまで全容を理解していた。
　そういった中身を知っているなら出来る事が、普通は中身を知らないのが当たり前だ。
　現職で正に「人事労務を本でしか知らない」状態で、「使った事がない人事システム」の仕様を理解し説明し、導入担当として業務に当たっている為ここの事はよく分かる。

　話が逸れたが、業務ハッカーは、業務を実際に行なっている人がシステム化もする、という定義だ。
　ただ、一般的にある問題として各業務チームの従業員は「仕事の知識はあるけど、システムの事はよく分からない」ということ。
　この言葉はホント、システム導入をする際にめちゃくちゃ耳にする。
　分からないのではない、誰に聞いたら正しい答えが返ってくるかも知らないので、なぜ使うのか、なぜこのように出来ているのか教えてもらえる人を知らないので、分かる気がそもそもないのだ。
　過去の業務改善でシステム導入する体制は、技術者がヒアリングし、勝手に作ったものを提供し、不満や不具合を吸収してバージョンアップを繰り返すというもの。
　自分たちが仕事のやり方を周りの環境の変化に合わせて変えたとしよう、そしてそれが技術者がいる事を知らない層ばかりで行われた場合、当然技術者に話が行かない。
　やり方を変えた事を知らない技術者は何もできないので、システムのバージョンアップは起こりえない、その結果最悪「使いづらい古臭いシステム」として文鎮になってしまう。
　では、自分たちがシステムを作り上げていたらどうだろう？
　身近なものでいうと、地図アプリや電車乗り換えアプリは今や誰もが使っているだろう、なのでそれで例えようと思う。
　地図アプリでいくと、新しい道が出来た、新しい建物が立った、そこによく行くので、その経路を登録したい、建物名を登録したい、だがそのアプリにはユーザからの登録機能はない。
　技術者の元にその道や建物の情報が然るべきルートで行かないと登録されない仕組みだ。
　そんなアプリ使いたいだろうか？否。
　また、そうした時に自分たちはどうするか、他の媒体でその場所を管理しようとする。
　そうした結果生まれるのが、システムの機能を補完するためのExcelだったり紙台帳だったりするわけだ。

　では、地図アプリの基本的な機能は用意されていて、登録機能は自由にカスタマイズ可能、項目を増やした場合にそれを地図アプリの何に反映するかは選べる仕組みにしていたとする。
　ユーザは自分たちで地図を編集し、自分たちの使いやすいようにカスタマイズしていく。
　これならば、その職場にとって使いやすいアプリにはなるだろう。

　ただ、ここで二つ問題が発生する。
　アプリの更新をみんなでしていた頃は良かったが、1人の人に更新業務が偏ったとしよう、そしてその人が急に倒れ、そのまま退職の運びとなってしまった。
　職場はすでに世代交代が完了していて、それをみんなで更新していた頃の人たちは誰もいない。
　この場合、誰もメンテナンスが出来ない状態になり、文鎮になってしまう。
　そしてもう一つ、各々がやりやすいようにカスタマイズする=他の機能との整合性が取れなくなってしまう、こちらはIT戦略にとっては痛手だ。
　地図アプリと電車乗り換えアプリは駅名、というキーとGPSの位置情報で連動している、だからこそ少ない編集項目で100%の機能を発揮していた。
しかし、地図アプリがユーザーによって自由に編集出来るようになったことで、地図アプリのデータ量は増大、データを補完するサーバーは負荷が高くなり維持コストが増加したせいで減益となった。
　また、ユーザーが登録した情報の中に、顧客の住所や電話番号が含まれている。
　これらは、本来顧客管理システムに登録され、その情報が地図アプリに反映される。
　だが、同じ情報が地図アプリに先にあった場合、顧客管理システムから地図アプリに情報を飛ばすタイミングで重複し、例えば「地図アプリに既に情報があった場合、顧客管理システムは整合性確認の為、登録出来ないようにする」といった仕様が含まれていれば、顧客管理システムにはいつまでたっても登録出来なくなってしまう。（いうまでもなくこんな設計がされていたらクソ仕様だと思うが）
　そうでなかったとしても、顧客管理システムに登録すれば自動で登録出来た情報をわざわざ手で作ったのだ。その分二重作業が発生している。
　どちらの登録作業も時給1500円の人が0.5時間(30分)かかる作業なら、750円で済んだ所が1500円掛かっているのである。

　これでは本末転倒だ。

　業務ハッカーによる業務改善とシステム化をIT戦略と紐づけるのはそういった観点で難しい場面がある。
　なんとも頭の痛い話だ。

業務ハックとアーキテクトの切り分け

　そこでまずは業務ハッカーに対する意識付けだ。
　「単純にシステム化するだけではダメ。自分が使う機能、データはどこから受け取り、何に使われ、誰が必要としているか、どういう問題を解決するためになぜ作られたか、を意識しつつ、また、本当にその業務の中でその工程は必要か」を考えさせることだ。
　基本的に行動というものはInがありOutだ。仕事も同じ。
　商売は基本「受注→納品」だが、細分化し、例えば納期短縮の為に受注生産ではなく先行生産をとる場合は、需要→在庫予測→調達→製造→検査→受注→納品、となる。
　では先程の取引先住所のところで考えてみよう。
　顧客管理システム(顧客の連絡先)→地図アプリ←顧客情報入力→運用
となる。地図アプリに対し、複数口Inがあり、どちらも同じ項目を使っている。
　そこを意識出来ないと、業務ハッカーによるシステム化は混沌を作り出す。

　逆に業務ハッカーにやってもらいたいのは、Excelや紙からの脱却、つまりは業務のデジタル化や自動化の基礎部分、つまりはフローとデータの整理と業務の見直しだ。

　Microsoft Office365にはFlowというOfficeの自動化機能がある。
　どんなものかというと、Officeにあるアプリを自動連携するものだ。
　軽く例を紹介しよう。
　・MicrosoftFormsで問い合わせを受ける
　・→連絡先を管理するExcelシートに入力内容を記述する
　・→Slack/Skypeに問い合わせがあった旨を通知する
　・→カレンダーに回答期限と回答先をセットする
　・→Microsoft Plannerにタスクを起票する
　・→問い合わせ内容のフラグからOneDriveにあるPowerPoint資料をPlannerに添付する
　これらがFormsという1個の入り口から全て自動で出来るようになっている。
　もちろんPowerPointのファイル名と問い合わせ内容の項目が合致していないと機能がコケたりする。
　ただ、この一連の自動化に、一切のプログラミングは行われていない。単純にFormsでフォームを作り、FlowでExcelや資料の指定、連絡先の選択などパラメータを弄るだけだ。

　これならばプログラミング知識は必要ない。論理的に考え、色々試していくうちに使えるようになる。
　ここまではOffice365やGoogleCloud Platformsといった包括クラウドサービスを使う事で業務側で解決出来るだろう。

　ではITアーキテクト側の出番だが、その前に、上記のFlowで出来るのは営業部門への通知と業務支援機能だ。
　SalesforceなどSFAツールでも同様の事ができる。
　では何が違うか、それはUI(ユーザーインターフェイス、操作画面のこと)や他機能にある。
　何より、データがデータベースに保管されるため、ユーザーによる気軽な編集、削除が出来なくなる。
　Excel管理などでよく起きる問題として、誤編集や削除といったものがある。
　業務で利用していたデータが消える、ということは業務が回らなくなる可能性があり、非常にリスクが高い場合がある。
　リスクマネジメント、という言葉があるように、ISMS(情報セキュリティマネジメントシステム)でも情報の機密性、完全性、可用性で点数をつけ、重要度を表す場面がある。
　それほど、データ管理は昔から重要視され、万が一に備えなければならない。
　そこがユーザーが気軽にさわれない、というのはとても重要なことなのだ。
　また、当然システムで不明瞭な点、問題が起きた時のトラブルシュートなど、自分たちでやらない分実務に専念できるし契約を続ける限り手厚いサポートが受けられる。

　そういう各ツールを導入することで、各種自動化やドキュメント管理が安定運用出来る、また従業員が本来の業務に専念できる、といった利点がある。
　ただし、最初の頃にも話したように実務でどういう事をしているか、は聞かないと分からない。

　ではその段階で、業務フローが業務ハッカーによって整理され、無駄な業務が省かれ、必要な項目が洗い出され、どのデータが何に使われているか明記されていればどうだろうか？
　そうした時にITアーキテクトのする仕事の半数以上は終わっている。
　パッケージのシステムに対し、必要な機能があるかどうかの調査、なければアドオン(追加機能)の開発、他システムとの連携設計と必要なデータの移行作業の計画、実行、これらのみで終わるため、導入期間は非常に短期で済み、プロジェクトも炎上したりしない。

さいごに

　沢渡氏のツイートに対する答えがまだ出ていなかった。
　結果から言うと、人材、という意味では「ファンのつくストラテジスト」だと思う。
　総じて纏めるならば、人材ではなく「全員そうあること」が求められる。

　大手企業にいるITストラテジストではなく、あくまで企業全体を見据え戦略を布教でき、何より従業員の業務改善意識を一緒になって盛り上げられるストラテジストだ。
　戦争において、ストラテジスト、戦略家と呼ばれる存在は戦略一つで軍の進退や勝敗を決するほど、責任も重く経験も必要とされる役割だった。
「戦争に勝て」という抽象的な指示を持ちうる能力をフル動員して「勝つための手立て」を立てるのである。
　そんな戦略家を信じ、自分の持てる能力にその戦略を併せ持ち粉骨砕身する従業員が出来上がる企業、それがその時勝つ為の最高のチームとなるだろう。
　かつての山本五十六将軍、そして大日本帝国海軍が真珠湾で勝ったのがそれだとすれば、その後米国を奮起させ、さしずめ戦争終結のきっかけとなった原爆投下は「IT戦略で先を越され、業界で勝ち目のなくなった企業に対し、放置すればいずれ負けると考え、企業自体を巨額で買収することで決着を得た」と言った所だろう。

おわり