[ITA] ITアーキテクトの役割とは(2) [良い要件定義]

元ネタがあれば、書くことには困らないし、すぐに書き終わるぞ( ^ω^ )と考えた、しょっさんです


後悔先に立たず

実際に書いてみると、おおまちがいだったことに気が付きました。原稿書けよ、俺って本気で感じています。

要件定義をしていく

要求編はまだ続きます。前回では、「想いを言葉にできる」人をアーキテクトとすると定義しました。では、その想いをどうやって言葉にしていくか。手法とフレームワーク、注意点を確認します。

良い要件定義とは

まず、そもそもの「要件定義」の目標を定めましょう。

先日ご紹介したIT アーキテクト育成ハンドブックや、Wikipediaでは、次のように記されています。

要求の充足評価では、ビジネスシステムの効果測定が可能な評価項目を明確化し、それを具体的に計
測できる基準を明確にしてゆきます。その上で設計したアーキテクチャに基づくシステムの要求に対す
る目標達成の見通しを明確にするのです。そしてその結果は要求者に対して合意形成すると共に、下流
のシステム設計者に技術移管と指導することが重要です。 「IT アーキテクト育成ハンドブック

「要件定義」は(開発依頼のあったソフトウェアやシステムについて)顧客が望んでいる機能や仕様などについて、その概略をまとめた文章・文書を指すこともある[3]。ただしこうしたことをまとめた文書は通常は「要件定義書」と呼ばれる。Wikipedia

重要なポイントは次の二つです。

  1. 機能や仕様をまとめたもの
  2. 効果測定可能な評価項目

簡単にまとめましたが、いずれも難関です。それでは、これらポイントから「良い」要件定義と評価するための、具体的な内容に落とし込んでいきましょう。

1. 機能や仕様をまとめたもの


その機能は必要ですか

個人的な経験則も踏まえて、次の3つがポイントです。

  1. お客様が必要と認識しているすべての機能が、網羅されていること (FR:needs)
  2. 実際に利用するユーザーの視点に立って、期待値を超える機能が網羅されていること (FR:seeds)
  3. 異常動作時における動作・方針が定められていること (FR:exception)

これらが「網羅」されていることが重要です。1.に特に重点が置かれがちですが、実現したい機能以上に、その機能が利用しやすかったり、利用したくなるような UI/UXは重要です。Web系やモバイル系では、UI/UXデザインの画面デザインベースで勧められるケースも多く、解消されている感はありますが、それらの正当性や提案は ITアーキテクトからできるべきと考えます。

忘れがちな「障害が発生した場合」の処理は、方針が定まっていないと、個々に方向性の異なった異常対処を行うことになりますので、かならず含めましょう。「それって可用性要件では?」としか感じないインフラエンジニアは、「クレジットカード番号の検証が済んで、カード会社への要求もすんで、お客様への請求処理まですすんだけれども、そこで障害が発生してDBに処理状況が保管できなかった」ケースは、どの非機能要求に含めるのか考えてみてください。なお、このフロー自体おかしいので、真似しないでくださいネ。

最後に、「その機能は本当に必要ですか?」

2. 効果測定可能な評価項目


品質チェックに余念なく

  1. 技術動向や、お客様の経営課題・経営状況・予算など制約条件が考慮されていること (NFR:制約)
  2. すべての機能は、効果測定可能な評価基準を定めて「数値で」判断できること (NFR:品質)
  3. すべての機能は実現可能であること (reliability)

これらも「網羅」できていることが、必須条件です。さっきから「MECEMECEMECEMECE」うるせえよ( ゚д゚ )クワッ!!と思われるかもしれませんが、これが担保できないとなりませんし、担保する方法も無きにしもあらずです。今日は書きませんが。

多少 ITアーキテクトをかじっていた人にはおなじみの、「非機能要件」です。可用性、性能・拡張性、移行性、セキュリティなどなどがここに含まれます。しかし、それらは 2.で示している、ソフトウェア(アプリケーション)の品質的要件です。それらすべてを実現することが正しいのではなく、1.の社会的、企業的制約条件にしたがって、何をどこまで実現するかが関わってきます。

なお、「制約」とは、今のお客様の力では変更することができないもの、例えば法的効力、予算などです。「非機能要件」とは、お客様が個々で定めることのできる「目標」です。すべてのシステムは24/365で稼働する必要などなく、自社営業時間内(たとえば、9:00-17:00)だけ 99.9%のシステム稼働率を目標にすれば、夜は止まっていても良いなど、そのシステムの目的によって変わるものです。重要性などにより、データの保全性や、可用性も変わることでしょう。しかし、システム稼働要件を100%とすることは実質不可能ですから、落とし所をどこにするかを、納得いく「数値」へ確定することが重要なポイントです。

そして、「数値化」です。「システムテストしますよー」といったとき、一体何を基準にそれらを評価するのでしょうか。「〜の機能が動くこと」とは何を持って動くことと判断するのでしょう。「それは、すべての機能が正しく動作することです」といった場合「では、1万人が同時にアクセスする可能性があるこのシステムにおいて、それらの機能は、どのように動作することが正常動作でしょうか」という反証に答えるすべがなければなりません。機能テストだけを済ませておいて、実際にサービスインした後、「動かないんだけどー」は、この数値目標がないために起こります。性能テストを行うにしても、「何をクリアできたら、この性能テストはいいんだっけ…」となったら、破綻目前です、おめでとうございます、サービスイン後に寝られない日々が続きますね( ^ω^ )ニコニコ

最後に「実現可能性」が担保できるシステムであることを、よくよく検証してください。すべての要件と非機能要件がでてきて、それらをすべて記述できたら「完成ヽ(´ー`)ノ」ではありません。例えば「役所に問い合わせが必要な処理があり、これは1分間に20回しかコールできない制約がある」のに「役所へ問い合わせる機能は、最大で1分間に100回コールする可能性がある」は相反する要件です。よくあるのは予算が不足するケースです。要件定義では「要件まとめたぞヽ(´ー`)ノ」で終わりではなくて、システムの概要が見えている、または想定アーキテクチャは記述できているべきです。そして、実現するべきシステムの概算は準備できていて、ホントに予算内に納まりそうかどうかのアセスも必要です。デスマーチの温床となる基本は、スケジュール不足ですが、その要員工数は1日を何時間で作業させるつもりなのか、テストを実施する環境はあるのか、法的にリスクはないのか、お客様の責任者は退職しないか、十分にあんテナを貼る必要があります。

良い要件定義を実現するには

これらを遂行するために必要なことは、システム工学において要求分析として定められています。実際に、この要求分析に従って実現することは、不可能であることは見ていただければ明確です。とは言え、本来、ITアーキテクトやコンサルタント、ITエンジニアに求められる能力とは、それ相応のものであることは理解しておかねばなりません。とは言え、何を学んでおくべきか、何を知り得るべきか、については世の中に便利なフレームワークや体系がありますので、これらを利用しない手はありません。ただし、技術的知識よりもITアーキテクトは、コミュニケーション能力が重視されます。

それらについては、次回以降。これ、完成するのかな。

まとめ

まだ推敲したい段階ですが、FR/NFRともに3:3の項目が出ているので、後はより詳細に書いていくくらいしかなさそうなので、この辺にしました。

[ITA] ITアーキテクトの役割とは(1) [要求]

blogも連続で40日を超え、さすがにそんなに毎日ネタなんてねぇよ、と考える程度になりました、しょっさんです


都市計画・ビル設計

嘘です。ネタはあるんです。ただ、どう考えても長くなるので、時間が取れないと無理だなーと思う次第だけです。

IPAネタでしばらく時間稼ぎをするの巻

IPA作ったあるあるシリーズを久々にネタモノにして、しばらく何度かに分けて書いていきます。

最近、ITABoK v2日本語版が刊行されまして、これを読むにはちょいとハードルが高いと感じていたところで、IPAのつくったITアーキテクト育成ハンドブックというものを発見しました。作成年月が 2007年6月と随分と昔なのですが、今でも役に立つことはたくさん書いてあります。これらを元に、この10年間で変わったことや、モダンな考え方に修正していこうかという、天に向かって何かをはく行為です。

これだけだと偏ってしまいうので、他にも幾つかの書籍をベースに、しばらく ITアーキテクトとアーキテクチャについて記していきます。あとでまとめて、社内に展開するためのメモだと認識してくださって構いませんヽ(´ー`)ノ

ITアーキテクトは「想いを言葉にする」

まず「アーキテクチャとは」から入るべきか、それとも「ITアーキテクトとは」から入るか悩みましたが、話の流れ的に「アーキテクチャを作る人」を知ってから、その人の作るものを「アーキテクチャ」と呼べば理解しやすいかと、というか書きやすいのでその流れにします。

ITアーキテクトを一言で表すと「想いを言葉にできる人」です。

この2週間で二番目のスマッシュヒットのセンテンスだと自負してます。さきほどのITアーキテクト育成ハンドブックにも出てきますが、顧客の「想い」を言語化できることが重要であると記されています。原文では

「思い」の中に明確にされていない隠れた要求を引き出し、

とありますが、要求とか要件とかグダグダいうよりも「新しいことを始めたい」という、その想いを受け取って、何をやり遂げたいのか、どんな夢があるのか、それらを一緒に話し合って、考え込んで、それを具体的なシステムにできる人、それが「ITアーキテクト」の役割です。

巷では、この「要求・要件」をどのように網羅的に洗い出すかのフレームワークや、ツールがたくさんありますが、それはあくまでも要件定義と設計を支援するだけのものです。まず、お客様が本当に実現したかったこと、必要なものは何だったのか。そこをコミュニケートできる力が第一です。


顧客が必要だったもの(v3.0)

かの有名な「How Projects Really Work」も、知らぬ間に版を重ねて 3.0になっていましたが(正式かどうかは知らぬ)、どうやって、この差を縮めていくことができるのかが、ITアーキテクトの力量と言っても過言ではありません。そのためには、どうやって、その想いを言語化、可視化できるかが必要です。そのための方法に、フレームワークは必要かもしれません。

[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義]

「超上流」という言葉自体はとても気に入らないけれども、IPA 独立行政法人 情報処理推進機構 が作って公開している「超上流から攻める IT 化の原理原則17ヶ条」が、当たり前のことを当たり前に並べてあってとても役に立つ。

超上流から攻めるIT化の原理原則 17ヶ条

“[IPA] デスマらないために「超上流から攻める IT 化の原理原則17ヶ条」が思った以上に使える件 [要件定義]”の続きを読む

夏休みにやりたいこと rev. 0.3

面白いくらいに忙しくて、とてもじゃないような状況下にありながら、来週は夏休みの予定です。
ホント申し訳ないなと思いつつも、今週後半に営業がサッパリいない方が、個人的大問題なんですが。

まぁそれはおいといて、今年の夏休みはお出かけするようなことは考えてないです。家に引きこもるつもりです。
では、引きこもって何をするか。ちょっと、今から夏休みのモチベーションを上げるために考えてみました。

“夏休みにやりたいこと rev. 0.3″の続きを読む

[生存証明] 最近やっている技術的なこと [vagrant chef serverspec]

いい加減「WEBサーバを新しいのにしたら、blog書くようにしよう(´∀`)」なんて言っている状態ではなく、なにも書いていないので、日本語を書くことがものすごく苦手になっている気がしてやみません。
致し方ないので、やっぱり、日々アウトプットもしていく飛鳥があるなとキーボード叩いてみます。やってみます。おう、やってやんよ!!( ゚д゚ )クワッ!!

最近やっている技術的なこと

最近の活動内容はこんな感じです。
そろそろ、これらについて、ちょっとずつアウトプットしていかないとなーって気はしてます。ホントに。仕事の気分転換的ですけど。

  • qpstudy 2014.04
  • 自宅サーバ更改
  • vagrant+chef+serverspec
  • Mac 環境設定

qpstudy 2014.04

先日、”qpstudy 2014.04 一般枠 〜俺の屍を超えて行け、でも踏まないで〜 on Zusaar” 久しぶりの、本年初めての qpstudyでしたね。もう、Markdown の書き方すら怪しいくらいにアウトプットしていなくて、ホントに自分がやばい気がします。死にそう。
さて、そんな qpでは「インフラエンジニアとは、なんだ」と称して、インフラの領域と、構築フェーズについて一般的なことに少し拡張してお話ししてきました。

このまとめも、そのうちやらなきゃなーと思ったら、あれから 2週間くらい経過してますね。ゴメンなさい。本番編のスライドも作らないといけない気はします。でも、本番スライドできたら、数年それで食べていける気がするので、それネタになんか書いても良さそうです。

自宅サーバ更改

ぶっちゃけ、数年前から「要件定義書いてー(´∀`)」「設計書書いてー」なんて言いつつもずっとすすんでおらず、テンポラリで移行した仮想鯖で満足した日々を送っていますが、イロイロとやたらめったら課題山積なので、本気でサーバの更改案件を進めています。
んで、qpstudy 2014.04 でもやった手前、その考え方に従って、要件定義からテストまで実施してみようと、実際に要件定義書を書き始めました。適当でいいやと思っていたら、なかなかの傑作(分量的に)になってきてしまい、このまま進んでいっていいのかどうか、非常に悩んでいるところです。
なにをというと、誰も長すぎて読まないんじゃないかという一抹の不安。

文書は置いといて、構築自体は進めています。で、フツーにやったら面白くもなんともないので、インフラ構築にアジャイルの要素を組み込んでみたり、TDD してみたりと幅は広いです。新しいことを取り込んで進めているために、遅々として作業自体も進んでいかないのですが、全部できあがった暁にはそれなりの経験を積めて楽しいことになるんじゃないかと、一人キャッキャうふふしてます。仕事の役には立たないのに。たぶん。

今、作ってみようと考えているサーバはこんな感じになってます。年内には、全てのサーバが移行できたら良いなぁ、なんてそんな時間感覚での気構えです。所詮、家のサーバです。

  • LDAP でユーザ情報一括管理
  • SAMBA も LDAP へ。AD は使わないことにする
  • ownCloud や git いれて、ドキュメントやファイル管理できるようにしちゃう
  • rsyslog でログを集約、fluentd もいれて解析しやすくしちゃう
  • 一般的な Internetサービス(dns,mail,web)あたりはどれだけ先端技術を組み込んで、サイト自体を守れるかに挑戦
  • バックアップは、家の別バックアップサーバに取得するとともに、s3+glacier もふんだんに使う
  • zabbix と munin で監視するけど、どうやってこうかなー
  • そういえば、サーバリソース(CPU/MEMORY)とストレージリソースは筐体別にして、よろしくやってます

vagrant+chef+serverspec

ということで、開発環境やテスト環境がなかったので、vagrant 活用してます。そして、上記のサーバ更改にあたり、chef や serverspec のお世話にもなってます。
sho7650 – Qiita“でも、vagrant や chef に触れられていることで、その熱き想いは理解いただけると考えています。そんで、どれくらい熱いかというと、会社の社内勉強会(研究会とでも言うほうがいいのか)でも、この 3つのプロダクトをターゲットにして、利活用について検討を始めてます。おいらがリーダーやってるので、好きし放題です。やりたい放題です。しかし、なんで女子が少ないのか。

さて、そんなこんなで、今、この 3つのプロダクトは私から外して語ることはできません。面白いネタができたら、小出しにしていこうと思います。
ついでに chefは “sho7650 (sho kisaragi)” github にも更改済。おい、パスワードモロみえじゃないかという突っ込みはスルーします。基本、パスワードは変更されるための初期パスワード扱いです。data-bag にいれて暗号化するとかゴメンなさいめんどくさいのです(おい

Mac 環境設定

先ほどの githubQiitaを見ていただくと分かるとおり、.emacsrc とかもいじって遊んでいます。楽しいです。もう、ほとんど飽きました実生活の一部となっていますけどね。
それと、GNU screen です。気がついたら 4.2あたりで縦分割できるようになってオシャレです。でかい画面のオレには必須機能でした。楽しいです。
しかし、hardstatus と caption はホントに意味が分かりません。どっかに、hardstatus シミュレータとかないんでしょうか。

ということで、気分転換に *rc ファイルをいじり始めると、夜更けになっているので、こういう楽しい環境設定は、ヒマでヒマで仕方ないときに廻しておくことにした方が良い気がします。でも、気分転換にやっちゃうんですよね。平気で 2時間くらい。そりゃ、資料もできませんわ。

最後に

こんな感じで生きてるのでご安心ください。
最近、寝室が変わって、毎晩フライングボディプレスト、ローリングソバットに耐えしのぐ夜をすごして睡眠不足ですが、なんとかしてみたいと思います。

かしこ

[tmkm-amazon]4863541333[/tmkm-amazon]
[tmkm-amazon]4774146005[/tmkm-amazon]

[応用編] アクアリウムエンジニアリング(1/3) 要件定義から設計局面 [再利用]

ということで、昨日の”[基本編] ITエンジニアが習得したスキルを元に、日常生活へ転用してみよう [再利用] | oshiire*BLOGoshiire*BLOG“の続きです。

“[応用編] アクアリウムエンジニアリング(1/3) 要件定義から設計局面 [再利用]”の続きを読む

[基本編] ITエンジニアが習得したスキルを元に、日常生活へ転用してみよう [再利用]

最近考えていることに、「習得したスキルの再利用」というものがあります。

再利用
再利用

小学生でも分かるように言えば、ならった足し算・引き算・掛け算をつかって、販売する商品の料金を計算することです。
何を当たり前のことをと思われるかも知れませんが、このごく当たり前のスキルではなく、社会人になって業務や勉強して取得したスキルを同様に応用できないでしょうか。

IT業界のエンジニアでいけば、そのプログラミングやサーバ構築、ネットワークの敷設は他に役に立たないだろうかと。
まぁ、残念ながらこのようなプロダクトに依存するスキルというものは再利用が難しいのですが、プロジェクト管理やアーキテクチャデザイン(設計)、はてはコンサルで使うテンプレートや、交渉術と言ったものは抽象度も高く、日常への転用・再利用性が高いものと言えます。

せっかく、習得した技術です。これらを使って、日常生活を豊かにすることができないだろうか、なんてことを最近考えて暮らしています。

“[基本編] ITエンジニアが習得したスキルを元に、日常生活へ転用してみよう [再利用]”の続きを読む