特集:.NETアーキテクトの実用プラクティス.NET開発のITアーキテクトになるための極意クロノス 亀野 弘嗣2008/08/27 |
|
|
■.NETアーキテクトのチェック・ポイント
実際に作業を進める際には、作業自体以外に常にチェックしておかなければならない事項がいくつもある。
例えば、プロジェクトで使用する言語を決定する際も、自分の好みだけで決めるわけではない。納品先の別プロジェクトで使用している言語に合わせて選択する場合や、プロジェクト・メンバーが慣れている言語を選択する場合など、さまざまな背景が存在する。
以下のようなさまざまな内容を考慮し、プロジェクト全体を見通して作業に取り掛かる必要があるのだ。
.NETアーキテクトのチェック・ポイント |
●要件
要件に合っているか? |
⇒ 要件からそれていないかを常に確認しよう。当たり前のように感じるかもしれないが、技術面にとらわれると、顧客の存在を忘れ、本末転倒になりがちである。
例えば、何かの検索結果を表示する業務アプリケーションで、大量の件数がヒットしたときの処理はどのように実現するのがよいだろうか? 技術的にいかに効率よく表示するかを検討する前に、業務上必要な上限を決めて表示を制限することを検討した方が、工数を削減できる場合がある。
●規模
規模を無視していないか? |
⇒ 規模に見合った設計をしよう。超大規模向けのアーキテクチャを小規模案件に適用すると、小規模案件では意味のない設計まで持ち込んでしまうことになり、非効率となる場合が多い。必ずしも「大は小を兼ねる」ではないことに注意しよう。
●決定事項
すでに決定した内容を覆していないか? |
⇒ 議事録を読んだり、プロジェクト・マネージャーなどに確認したりして、決定事項を常に確認しよう。すでに決定しているアーキテクチャなどがある場合、本当は最適なアーキテクチャであっても、採用されない場合もある。
例えば、すでに購入済みの帳票ツールの使用が決定している場合や、オープンソース・プロダクトの使用を禁止することが決定している場合などがある。
●費用対効果
トータル・コストを考慮しているか? |
⇒ イニシャル・コストとランニング・コストを意識しよう。運用で代用できないか、既製のコンポーネントを採用することなどで、トータル・コストを抑えられないかを考えよう。
●施策のタイミング
施策のタイミングを考慮しているか? |
⇒ 実施しようとしている施策が、最も効果的に行えるタイミングを意識しよう。例えば、静的解析を行う場合は、製造フェイズ以前に、静的解析を考慮したコーディング・ルールや品質基準を設定しないと効果が薄れてしまう。
●データ移行の有無
データ移行が必要な場合を考慮しているか? |
⇒ データ移行が必要な場合、移行手順や移行要件などを考える必要がある。アプリケーションの設計やシステム・リリースの難易度に影響する場合があるため、移行の有無は常に確認しよう。
●他システムとの連携
他システムとの連携が必要な場合を考慮しているか? |
⇒ 他システムとの連携が必要な場合、I/F(インターフェイス)の調整や、相手側システムの改修などが必要なこともあるため、常に確認しよう。
●プロジェクト・メンバーのスキル
プロジェクト・メンバーのスキルを無視していないか? |
⇒ プロジェクト・メンバーのスキルや経験を考慮し、効率的な開発ができるようにしよう。メンバーの経験が浅いなどの場合、勉強会を開いたり、コード・サンプルや、コード・レビューを増やしたりするなどを考えよう。
●開発効率
開発のしやすさ、デバッグのしやすさなどを考慮しているか? |
⇒ 特にRIA(Rich Internet Application)の採用などを考える場合に、開発効率を無視したアーキテクチャの採用に陥りがちな傾向にある。要件の実現とともに、開発効率についても考慮しよう。
趣味で開発を行っている場合は、技術のみを考えていればよいが、仕事で開発を行っている限り、常に利害関係を考慮する必要がある。プロジェクトを成功へ導くにはどうすればよいかを考えて、広い視野で考える必要がある。
「自分は技術担当だから、プロジェクトの利害関係なんて知らない」という考えではいけない。もし、アーキテクトのポジションで、このような考えでいるとプロジェクトは失敗するだろう。
■.NETアーキテクトの心構え
アーキテクトに限らず開発現場ではバランス感覚が重要であるため、一概に「こうすれば成功する」というものはないが、アーキテクトとして常に心掛けたい作業時の心構えを最後にいくつか説明する。
●何事にも「決定」が付きまとう
アーキテクトは、複数の選択肢から最適な1つを選択して決定しなければならない場面が多い。まずは、自分で決めなければいけないことと、ほかの人に決めてもらうことを切り分けよう。
具体的には、技術面の問題と業務内容の問題が混ざった状態でプロジェクト・メンバーから質問などを受けることがある。こういった場合には、まずは切り分けから始める必要がある。そして、アーキテクトが決めなければいけないことについては、メリット、デメリットをまとめ、選択する。選択した理由をきちんと述べることができるようにしておく必要がある。
また場合によっては、まとめたメリット、デメリットを、ステーク・ホルダー(=利害関係者)やプロジェクト・マネージャーに説明し、決定してもらうこともある。
状況によって、その時点で決定しがたい場合は、待機工数と手戻り工数を天秤(てんびん)にかけて、決定するかどうかを考えよう。
●要求管理、タスク管理がキーになる
アーキテクトに依頼される要求は「あいまいかつ複雑かつ広範囲」な場合が多いため、アーキテクトにとっては特に要求管理、タスク管理が重要である。
「要求」「タスク」「対応」をできる限り分かりやすく履歴管理する必要がある。あいまいな内容を仮決定することなどが多々あり、二転三転することも多く、経緯を手繰ることが多いためだ。
●ルールの維持
コーディング・ルールなどを制定した場合は、制定するだけでなく、それが守られているかきちんと確認しよう。
また、プロジェクトの背景は常に変化しているため、ルールがプロジェクトに合わなくなってくることがある。そういった場合は、改定して周知しよう。
●プロジェクト・メンバーから信頼を得る
技術面での問題が発生したときに、プロジェクト・メンバーがアーキテクトに相談しやすい環境を作るため、日ごろからコミュニケーションを取り、プロジェクト・メンバーから信頼を得られるように努めよう。
●プロジェクト・マネージャーを最大限に利用する
常にプロジェクト・マネージャーと情報連携を行い、意見があれば積極的に話し合おう。
また、雑務的なタスクや長期間を要するタスクが増えないようにプロジェクト・マネージャーに守ってもらおう。アーキテクトはほかのプロジェクト・メンバーより技術レベルが高いため、「素早くこなせるだろう」という考えから、雑務的なタスクを振られることが多い。
しかし、アーキテクトは突発的な問題などに急いで対応しなければならないケースが多く、スケジュールの余裕の幅は日々変化するものである。雑務や長期間固定されてしまうタスクでスケジュールを埋めてしまわないように、周囲にも協力してもらおう。
●ナレッジを管理する
.NET開発のアーキテクトとして仕事をするようになれば、.NET Frameworkを軸とした経験が、すべて次のプロジェクトにも確実に生かされる。きちんと自分でナレッジ管理をして、迅速に問題解決ができるように心掛けよう。
■まとめ
.NETアーキテクトがどのような役割を持つのか、また、どのように役割を果たせばよいのか説明した。アーキテクトは、広範囲な役割を担うため、作業も多く責任も重いが、やりがいのある役割である。
あとは、常に新しい技術を勉強し、要件に対してより良い提案ができるように日々心掛けていただきたい。
INDEX | ||
[特集].NETアーキテクトの実用プラクティス | ||
1..NETアーキテクトの開発現場での役割 | ||
2..NETアーキテクトの具体的な作業 | ||
3..NETアーキテクトのチェック・ポイント/.NETアーキテクトの心構え | ||
- 第2回 簡潔なコーディングのために (2017/7/26)
ラムダ式で記述できるメンバの増加、throw式、out変数、タプルなど、C# 7には以前よりもコードを簡潔に記述できるような機能が導入されている - 第1回 Visual Studio Codeデバッグの基礎知識 (2017/7/21)
Node.jsプログラムをデバッグしながら、Visual Studio Codeに統合されているデバッグ機能の基本の「キ」をマスターしよう - 第1回 明瞭なコーディングのために (2017/7/19)
C# 7で追加された新機能の中から、「数値リテラル構文の改善」と「ローカル関数」を紹介する。これらは分かりやすいコードを記述するのに使える - Presentation Translator (2017/7/18)
Presentation TranslatorはPowerPoint用のアドイン。プレゼンテーション時の字幕の付加や、多言語での質疑応答、スライドの翻訳を行える
|
|