update it, Inc.社長のブログ

近年、システム開発の世界ではITアーキテクトの必要性が叫ばれています。現実問題として、プロジェクトの中でITアーキテクトという職種が実際に存在しているチームはまだ少数派なのかもしれませんが、様々なシステムの仕組みを熟知し、要求仕様に対して適切なアーキテクチャを提案・実現する能力を持ったスーパーSEは、みんなから待ち望まれているのだと思います。

最近はプログラマのキャリアアップの１つの目標としてITアーキテクトの存在は大きくなってきているようです。スペシャリストとしての頂点という意味合いが強いのでしょう。

ITアーキテクトは対象のシステムの、アーキテクチャの全体像を設計する役割を持ちます。ITアーキテクトが決めた方向性に従ってシステムが設計されることになり、その大方針はそのシステムのライフサイクルにおいて大きな意味を持つことになります。

私はこの「システムのライフサイクル」という部分がポイントだと思います。つまり、ITアーキテクトは対象のシステムのライフサイクルを見据えて全体像を設計する責任を負う、ということです。しかし、昨今のシステムを取り巻く状況を考えると、これはとてつもなく大変な仕事であることがわかります。

システムを取り巻く環境は非常に早いサイクルでどんどん変わっています。従って採用したアーキテクチャが非常に早いタイミングで廃れてしまうことも十分考えられます。もしそうなってしまうと、エンハンスやハードウェアの載せ変えもできなくなってしまい、早々にシステムの「死」を迎えることになってしまいます。そのためにシステムのライフサイクルが不用意に短くなってしまい、作り変えのための余計なコストが必要になったとしたら、それはITアーキテクトの責任である、ということなのです。

つまりITアーキテクトは、一時の流行にとらわれることなく、少なくとも対象システムのライフサイクルの期間内は十分に使い続けることができるような、信頼のおけるアーキテクチャを選択する義務があるということになります。そしてもっとも重要で、難しいのは、採用する技術について未来を見通す力を持たなければならない、ということです。

ということで、私はITアーキテクトは予言者、それも客観的な予言者であれ、と考えています。できるだけ客観的に、技術動向を予言できる能力が必要だ、ということです。

ちょっと前にPair Programing（ペア・プログラミング、略してペア・プロ）という言葉が流行りました。コーディングを2名で同時に同じPCに向かって行うことで、より効率的にプログラミングができ、かつ互いの技術上のスキルの向上に寄与できる、というコーディング・スタイルです。update it, Inc.でもややこしい部分をコーディングしなければならないような場合に、社員が自主的にペア・プロを行っています。ただし普段からやっているわけではないです。

おそらく、技術的なスキル・ノウハウを「盗む」上では効果的な方法だと思います。ただし使うときを限定しないと、トータルの生産性はやはり下がるように思います。（どうしても片方の人が手を動かしている間はもう片方の人は見ている、つまり受身の状態になりやすいようです。）

以前、私自身の経験としてペア・プロ以上に効果的で、かつ生産性もかなり向上する方法だと思った方法として、Pair Designing、つまり2名で設計するというやり方があります。やっていた当時はそんな名前を付けていたわけではないのですが、今振り返って名前を付けるとなると、Pair Designing、ペア・デザですね。

用意する道具はパーティションのあるブースとホワイトボードだけです。そこに2名でこもって、会話と絵を描きながら延々と設計を進めます。誰でも打ち合わせと称して、パーティションに2名でこもってホワイト・ボードを相手に話し合いを進める、ということをよくやると思うのですが、そのスタイルで設計を行う、というだけの話です。

そんなの、いつもやっているよ、って人も多いかもしれません。

うまくツボにはまるとどんどんアイデアが沸いてきますし、一人で設計しているとなかなか見えてこない問題も見えるようになります。また「話す」ことによって、自分の考えをまとめるという効果も期待できます。

ペア・プロの場合と同じなのですが、この2名の設計者は2名とも実担当で、同じくらい設計対象のことをよく知っている必要があります。実力差が大きかったり、実担当ではない人とやるのではあまり効果がでません。

２、３時間もこれを真剣にやると、どっぷり疲れるのですが、非常に効率的に設計を進めることが出来ると思います。みなさんもぜひ1度、ペア・デザ、トライしてみてください。

SE（システム・エンジニア）は業務系SEと技術系SEに色分けされることがよくあります。業務系SEは特定の業務に対してのシステム設計を得意分野とする人、技術系SEは特定業務に寄らず、一般的なシステム・アーキテクチャ設計を得意分野とする人、といったところでしょうか？

例えば若いSEが自分が目指す方向として業務系SEを目指すのか、技術系SEを目指すのか、などといった観点で使われています。私自身はというと、証券・銀行などの金融の業務系SEとして今まで歩んできました。特に「業務系SE」という肩書きをもらったことはないですけどね。

今まで経験的に感じていることとして、システムが得意な人ほど業務系SEを志向しない傾向があります。システムが得意な人はシステムだけ詳しければそれでいいと考えている人が多い、ということです。でも私から見ると、これはとてももったいないことをしている気がしてなりません。なぜかというと、両方ができると間違いなく活躍できるフィールドは広がるからです。バリューが高まる、ということです。

私は業務系SEでしたが、目指したのはシステムが得意な業務系SEです。業務についての勉強をしつつ、同時にできるだけ最新のシステム技術動向を取り入れ、それを実際の業務システムにいち早く応用していくことを楽しんでいました。これはとてもやりがいのある仕事ですよ。

そして経験的に感じることなのですが、もともとはシステムが得意でなかった業務系SEが努力してシステムも得意になるよりも、システムがもともと得意なSEが努力してさらに業務も得意になるほうが簡単なようなのです。

そう、若い人がSEを目指すならば、システムが得意な人こそぜひ業務系SEにトライして欲しいと私は思います。実際に業務を知ることで、その中で自分が得意なシステムに関する知識を存分に発揮できる可能性が高まります。最新のアーキテクチャを実際のシステム開発に応用し、実際に皆に使ってもらうのはこの上なくエキサイティングな経験です。また業務系SEは顧客との接点も多いので、コンサルタントとしての素養も磨くことができます。

ま、大変なことも多いです。でもやりがいのある仕事であるのは確かだと思います。

持っている技術水準やアウトプットの水準はむちゃくちゃ高いのに、あまり評価してもらえない人っていませんか？　逆に技術水準はそんなにでもないのだけど、やたら受けのいい人もいる。この「実際に仕事をこなす能力の高さ」と「評価」との乖離はなぜ起こるのでしょうか？

私が経験上感じていることとして、非常に高い評価を受けていた人が他に移ったときに、必ずしも前回と同じ高い評価を受けるとは限らない、ということがあります。おそらくその人は前回と同じ水準のアウトプットを出すと思うのですが、それでもなぜか、評価というのは周りの人によって大きく変わってくるのです。つまり、以前ものすごいいい評価を得ていた人が、会社を転職したり、まったく直接関連のないプロジェクトに移ったりしたときに、同じような評価を受けるとは限らない、ということなのでしょう。

この評価の「ぶれ」は、評価というのは結局、主観的に判断されることから発生するのだと思います。もしプロジェクト内における、ある人の働きぶりについて判断しろ、と言われたら、ほとんどの人はその人に対する「印象」をベースに判断すると思います。ところが、その印象には「実際に仕事をこなす能力の高さ」が大きく反映されるとは限らないのでしょう。

そもそも、人がある人に抱く印象というのは、最初に出会ったときのほんの数秒ですべてが決まってしまう、という話があります。最初にパッと見たときの印象で「この人は仕事ができそうだ」と思ってしまうと、その人に関するいろいろな話題のうち、仕事が出来そうだという印象を強化する情報ばかり取り込んでしまいがちです。一方で、同じように最初の印象が「なんかあまり出来なそう」と思ってしまうと、その人に関するいろいろな話題のうち、ネガティブな情報ばかりを取り込んでしまいがちなのだと思います。

正確に人を評価するには、できるだけ主観を外す必要があります。でも主観のない人の評価なんで、まず無理ですよね。実際、成果物（アウトプット）だけで評価すると、過程などが判断材料から外れてしまい、それはそれで評価としては適切ではない結果になってしまう可能性があります。

できるだけ自分の心の偏向・バイアスを取り除き、適切な評価を行うためには、例えば心象がネガティブな人に対しては逆にできるだけ心象を良くする事実を集めるとか、心象が良すぎる人については逆に冷静にネガティブな情報を集めるとか、そういったことを意識的に行わなければならないのだと思います。

あるプロジェクト・マネージャの方から聞いた話です。その人のプロジェクトでは、たとえ新卒２，３年目程度の若手であろうが、リーダとして将来性があると見込んだ人は、７，８人程度のプロジェクト・チームのリーダーのポジションに据えて経験をつませる場合がある、という話をしていました。７，８人程度のプロジェクト・チームというのは新卒２，３年目には通常はまだ重いポジションだと思いますが、そこを敢えてTryさせることで育てるということでした。

この話は私も非常にうなずけました。プロジェクト・リーダやプロジェクト・マネージャをうまくこなすには経験が重要になりますが、経験を積み始めるのが一定年齢を越さなければならない、なんてことは本来ないはずです。むしろ経験を積むには早ければ早いほどいいのだと思います。

一方で、これを実践するには2つの問題があると思います。１つは失敗するリスクにどう対処するか、もうひとつは抜擢されなかったそれ以外の人たちをどうサポートするのか、という点です。

失敗するリスクにどう対処するか、というのは若かろうが、年を食ってようが、プロジェクト・リーダやプロジェクト・マネージャとしてやり始めたときには誰でも同じ問題に直面するといえます。ただ若い分、失敗したときに、「ほら、見たことか」のような中傷を受ける可能性が高いといえます。

でも、誰でもなんらかの失敗はするものです。失敗が一切許されていないというのでは息が詰まってしまいます。失敗を許容する文化を育てるべきではないでしょうか？

抜擢されなかったそれ以外の人たちをどうサポートするか、という点については、上記で述べた「失敗を許容する文化」を創るという話と関連するのですが、失敗を許容するというのは単に暖かく見守るということだけではなく、大きな、致命的な失敗を犯さないように周りの人たちが新人リーダをサポートするような、そんな文化を創れるか、ということだと思います。

つまり、リーダ⇒メンバへの一方的な命令で物事を進めるのではなく、リーダ⇔メンバのように相互にコミュニケーションしながら、対等な立場で仕事を進められるようにできるか、ということです。言い換えると、メンバ間に、プロフェッショナルとしての自覚を育てるということだと思います。

だいぶ以前に、?設計書に書くべき範囲という似たようなタイトルでブログを書いていますが、今回は「詳細化」という観点から考察してみましょう。なおここに取り上げていないドキュメントについては、下のいずれかに相当するものとして考えてください。

昔は詳細設計書というのがあって、フローチャートなどという懐かしい図とともにかなり細かいレベルのドキュメントを書いていましたが、最近では詳細設計書は書かないのが当たり前になってきたと思います。（ただしミッションクリティカルな分野については違うかもしれません）

理由の１つにはオブジェクト指向の普及などにより、詳細設計書とソースコードがほぼ同義語と考えられるレベルになってきており、「２つのドキュメント（詳細設計書とソースコード）」の二重メンテナンスは避けるべきだと考えられるようになってきたこと、そして、コンピュータリソースが貴重だった時代とは異なり、昔では考えられないような高度な統合開発環境が誰でも使えるようになってきており、詳細設計書のレベルのことはソースコードで十分じゃん、というのがはっきりしてきたため、ともいえると思います。

では他の設計書はどうでしょうか？　基本設計書や概要設計書はその名の通り、詳細化しては「いけない」ものです。ここに詳細なことを書き込んでは、読み手が本当にそれを読んで押さえるべきツボを押さえられなくなります。基本設計書には基本的なこと、概要設計書には概要を書くべきであって、それ以上のものを書く場所ではありません。詳細化を避けることによって、これらの設計書が読みやすくなり、プロジェクト全体の方向性を定めるコンセンサスを取るための道具として、またプロジェクトへの新しい参加者向けの導入書として、またテスト設計する上での基準としても役に立つようになります。

では外部設計書はどうでしょうか？　これは十分に詳細化されてしかるべきものでしょう。もしシステム間インターフェースとなるデータベース項目やファイルフォーマットなどが最終化されたものがない状態で開発し始めると、後になって大きく回り道をする羽目になります。ユーザーI/Fも同じです。ユーザーI/Fが詳細化されていない状態で開発が進んだ場合、操作の一貫性が損なわれたり、同じような処理があちこちに散らばる結果になります。

ただし外部設計書も最初から詳細化されたものがいきなり出てくるわけではありません。通常はいくつかの段階を踏んで、徐々に詳細化していくものだと思います。最後に残ったドキュメントは詳細化されているべきだ、というだけで、途中の中間成果物まで詳細化されているべきだ、とは申しません。

トム・デマルコさんの書いた書物のいくつかには、ユーザマニュアルこそが究極の設計書だと書かれています。ユーザマニュアルは、ユーザが読む視点で書かれた外部設計書といえます。外部設計書としてはユーザマニュアル程度の詳細化が必要だ、ということかもしれません。

以前、@ITに書いた記事の内容と関連しますが、今日はリスク・エクスポージャという概念をご紹介します。

リスク・エクスポージャはもともと金融の世界の概念です。金融の世界では、今自分が持っているポジション（例えば株や債券など）がどれだけ「やられる」可能性があるのか、それを金額で表した数字をリスク・エクスポージャと呼んでいます。現物資産（株や債券）の場合、その現物の金額に「やられる確率」(リスクの発生する確率)をかけて求めます。数学の期待値というヤツと一緒です。

この概念を用いると、システムのプロジェクトが抱えるリスクを金額で表示することができるようになります。つまりプロジェクトが失敗することにより、どういったコストがかかるのかを原因別にリストアップし、それらのコストと発生しうる確率を求めて掛け合わせて各要因毎のリスクエクスポージャとします。そしてそれらを全部足し合わせたものがプロジェクトの抱えるリスクエクスポージャとなります。（@ITの記事では、これをテスト不足によって発生するリスクエクスポージャとして求め、テストの金額を求めるということを書いています）

私の敬愛するトム・デマルコさんのティモシー・リスターさんとの共著「熊とワルツを」（日経BP社 伊豆原弓訳）の本でもこのリスク・エクスポージャについてわかりやすく説明しています。お勧めです。

なぜこれを書いたかというと、この概念はプロジェクトマネージャであれば皆が知っているべき概念だと思うからです。プロジェクトにはリスクがつき物です。リスクがあるのは、おそらくどんなプロジェクトマネージャでも知っていることだと思います。でも、それを適切に表現する方法を知らない。こんなリスクがある、あんなリスクがある、ということは言えても、それがどれだけ深刻なものなのかを表現する術を持っていないと思います。

そこで、リスク・エクスポージャの出番です。そのリスクを金額で表現してしまうのです。みんな、お金になっているとわかりやすいでしょ。例えば、このリスク・エクスポージャは1億円相当だ、なんて言われたら、目の色を変えて対応しますよね。
ぜひうまく活用してみてください。

もう自分の今日の仕事は終わった、時間的にももう帰る時間だ、疲れたし、もう帰ってくつろぎたい、と思っているのに帰れない、というか帰りづらいときってありませんか？

プロジェクトの雰囲気によってだいぶ異なるのだと思いますが、なんか帰りづらい雰囲気がかもし出されている場合も多いと思います。でもそれでだらだらと帰らないでいると、さらにその人の下の人たちも同じように帰れないままになってしまい、余計に帰りづらい雰囲気が強化されてしまうことになります。

ある人から聞いた話なのですが、残業の時間帯に上司の人が残っていてなんか帰りづらいな、と思って覗き込んでみたら、なんとその上司の人は一生懸命、携帯メールを打っていたそうです。あぜんとしますよね。

しかし日本の職場というのは、自然にまわりと同じような行動を求められる場合が多く、一人だけ先に帰ってしまったりすると、陰口をたたかれたりします。そんなこんなで、なかなか帰らない人がでてくると思うのですが、ここはひとつ、プロフェッショナルの仕事をしましょう！　つまりやるべきことをやったら帰る。これは非常に当たり前の話だと思います。だらだらと残っているのは、仕事ではなく、作業をしている人です。クリエイティブな仕事をするためには、自分で適切な時間管理が必要になります。それができないのはプロフェッショナルとはいえないのではないでしょうか。

あ、もちろん、プロフェッショナルというのはやるべきことをきちんとやる人であり、残業をしない人という意味ではありませんので、よろしく。

今日のテーマはカテゴリーをプロジェクトとしていますが、ちょっとずれているかもしれません。

「エンジニアの運」と書いたのは、ある人が仕事に就いてからどういう活躍をするのかは、一番最初に新卒で配属されたところの職場によってかなりの部分が決まるのではないか、という仮説です。私も長年仕事をしてきて、いろんな人からいろいろな影響を受けていますが、一番決定的な影響を受けたのは、やはり新卒で配属された最初の職場が一番大きかったと思っています。

やはりそれまでの学生時代と就職してからではありとあらゆるものが変わるので、非常に印象深くなるのは当然かもしれませんが、単にそれだけではなく、そのときの職場の先輩や上司の方から受ける影響は、それ以降のその人の仕事におけるベース（仕事に対するスタンスや考え方、習慣など）を決定付け、それ以降で受ける影響とは比べ物にならないぐらい大きなものだと私は考えています。

もしこの仮説が正しければ、その人の運は、最初に配属された職場によって大きく決定付けられるといえるのではないでしょうか？　つまり最初の職場で仕事がバリバリできる優秀な先輩や上司に恵まれれば、仕事とはこういうものだとインプリンティング（刷り込み）され、その人自身も自然にそういう一員として振舞うようになる。逆に運悪くそういう環境に恵まれなかった人は、やはり同じようにインプリンティングされ、その人自身もなかなか芽がでなくなる。すべての人が環境だけに左右されるわけではないとは思いますが、割合的にそうなる人が多いのではないかと考えています。

一般に学生は、就職して実際に職場に配属されるまで、その職場の様子がわからない場合が多いと思いますが、実はそのときにその人の人生を左右するような大博打をしているのかもしれません。そういった意味では、インターンのような制度をもっと普及させるべきではないでしょうか？

今日書くことは、非常に当たり前のことなので、人によっては何でこんなこといまさら書くの？　という方もいらっしゃるかもしれません。テーマは設計書を書く前にやるべきこと、です。

昨日の「システム屋の書いた文章」にも多少通じるところがあるのですが、設計書を書く前にはまず「すり合わせ」をしましょう。（「にぎる」と言うこともあります）　非常に当たり前のことだと（少なくとも私は）思っているのですが、意外とやっていない人がいると聞きます。

ここはぜひ、ユーザ側の一人になったつもりで考えてみてください。例えばもしある日、システム屋があなたの前に最終的な設計書をいきなり持ってきて、「これでいいですか？」と言われたとします。そして読んでみたら、あれ、期待している動きとちょっと違う。でもそれを話したら「今さら設計を変えろといわれても、スケジュールがずれるのでできない」と言われたとしたら、あなたはどう思うでしょうか？

設計書を書いている側では、要求仕様（例えばRFP)に沿って設計しているから正しいはずと思い込んでいるかもしれません。しかし要求仕様の中にユーザ側の考えがすべて反映されているとは限りません。また曖昧さのために、期待されているものと違ったものを設計してしまうリスクがあります。もちろんその場合、要求仕様に問題があるといえますが、すべてにおいて完璧な要求仕様をつくることができないのは、バグのないシステムを作れないのと同じことです。（ここでバグのないシステムを作れない、といっているのは理論的な話ではなく、現実的にできないでしょ、という話です）

もちろん、システムのスケジュールや予算も要求仕様に合わせて確保されているので、そこから大きく逸脱することはありえないのですが、いきなり完成した設計書を持参するのではなく、要求仕様に対する解決策をユーザと一緒に考え、提案することが重要だと思います。そうすることで、ユーザの考えをうまく盛り込むことができ、満足度の高いシステムとすることができると思うのです。