blogも連続で40日を超え、さすがにそんなに毎日ネタなんてねぇよ、と考える程度になりました、しょっさんです
嘘です。ネタはあるんです。ただ、どう考えても長くなるので、時間が取れないと無理だなーと思う次第だけです。
IPAネタでしばらく時間稼ぎをするの巻
IPA作ったあるあるシリーズを久々にネタモノにして、しばらく何度かに分けて書いていきます。
最近、ITABoK v2日本語版が刊行されまして、これを読むにはちょいとハードルが高いと感じていたところで、IPAのつくったITアーキテクト育成ハンドブックというものを発見しました。作成年月が 2007年6月と随分と昔なのですが、今でも役に立つことはたくさん書いてあります。これらを元に、この10年間で変わったことや、モダンな考え方に修正していこうかという、天に向かって何かをはく行為です。
これだけだと偏ってしまいうので、他にも幾つかの書籍をベースに、しばらく ITアーキテクトとアーキテクチャについて記していきます。あとでまとめて、社内に展開するためのメモだと認識してくださって構いませんヽ(´ー｀)ノ
ITアーキテクトは「想いを言葉にする」
まず「アーキテクチャとは」から入るべきか、それとも「ITアーキテクトとは」から入るか悩みましたが、話の流れ的に「アーキテクチャを作る人」を知ってから、その人の作るものを「アーキテクチャ」と呼べば理解しやすいかと、というか書きやすいのでその流れにします。
ITアーキテクトを一言で表すと「想いを言葉にできる人」です。
この2週間で二番目のスマッシュヒットのセンテンスだと自負してます。さきほどのITアーキテクト育成ハンドブックにも出てきますが、顧客の「想い」を言語化できることが重要であると記されています。原文では
「思い」の中に明確にされていない隠れた要求を引き出し、
とありますが、要求とか要件とかグダグダいうよりも「新しいことを始めたい」という、その想いを受け取って、何をやり遂げたいのか、どんな夢があるのか、それらを一緒に話し合って、考え込んで、それを具体的なシステムにできる人、それが「ITアーキテクト」の役割です。
巷では、この「要求・要件」をどのように網羅的に洗い出すかのフレームワークや、ツールがたくさんありますが、それはあくまでも要件定義と設計を支援するだけのものです。まず、お客様が本当に実現したかったこと、必要なものは何だったのか。そこをコミュニケートできる力が第一です。
かの有名な「How Projects Really Work」も、知らぬ間に版を重ねて 3.0になっていましたが(正式かどうかは知らぬ)、どうやって、この差を縮めていくことができるのかが、ITアーキテクトの力量と言っても過言ではありません。そのためには、どうやって、その想いを言語化、可視化できるかが必要です。そのための方法に、フレームワークは必要かもしれません。