アナリストになる

この記事は、時には難しいがエキサイティングなITアナリストの専門家に捧げたいと思います。 Habréでは、この分野に関する資料はそれほど多くありません。 たとえば、プロジェクト管理-桁違いに。 しかし、最近投稿された2つの記事（ 1つと 2つ ）は関心を呼んでいるようです。そのため、私も少し貢献したいと思います。 私はアナリストとして8年以上働いているので、無駄に時間を無駄にしないようにします。

私はこの理論を語るつもりはありません（Wigersの注目すべき本やBABOKにあります）。 私はこの問題の実際的な側面に焦点を当てたいと思います-私自身と私が一緒に仕事をして幸運だった他の人々の両方の「戦闘」体験の圧搾を説明するために。



ナレーションをすぐに構成します。

1. 簡単な紹介
2. アナリスト-誰ですか？ +テクニカルリトリート
3. なぜアナリストが必要なのですか？ （ハローキャップ）
4. 誰とどのようにアナリストになりますか？
5. アナリストは何を知り、できるはずであり、どのようにこれを学ぶべきですか？
6. おわりに

これらのトピックの一部は明らかです。 キャプテンを最小限にしようとします。



将来の注意：

パラグラフ5に加えて、当初考えられたボリュームでは、材料が大きすぎることに気付きました。 5番目の段落は、個別の記事、または複数の記事に値します。 これは将来の問題です。 この投稿では、このトピックについて表面的にのみ触れます。

簡単な紹介

インターネット上のシステムおよびビジネス分析に関する十分なドライ形式の定義および他の同様の資料があるので、私は繰り返しません。 また、本「The Way of the Analyst。」の内容をもう一度語るつもりはありません。 ITスペシャリストの実践的なガイダンス。」

最近、説明された知識の分野は非常にささやかな注目を受けています。 これはさまざまなもので表現されます。 たとえば、「System Analyst」という職業のデファクトスタンダードはまだありません。 もちろん、BABOKと独自の認証システムを備えた国際ビジネス分析研究所（IIBA）もあります。 しかし、特にロシアでは、（たとえば、プロジェクト管理の分野のPMI / PMBookのように）広い極性を使用していません。

ところで、IIBAのロシア支部は現在作成中です。 私は広告しませんが、LinkedInで誰でも簡単に適切なグループを見つけることができます。



IT分析に関する本の数も、他のIT分野よりも著しく少ない（この問題について間違いを犯すのはうれしいです。おそらく、この分野の重要な本のいくつかは私をすり抜けたでしょう）。 Habréでさえ、過去数年間の分析に関する記事は、ほとんど片手の指で数えることができます（ 1、2、3、4 ）。 まあ、はい、私たちは持っているものを持っています。 最後に、すべてが私たちの手にあります。

アナリスト-誰ですか？

概して、ITセクターでは、2つのタイプの専門分野を区別できます。

• システムアナリスト
• ビジネスインテリジェンス（この役割はITだけに適用されません）。

解決すべきタスクと必要なスキルが大きく異なるという事実にもかかわらず、ほとんどの場合、ITプロジェクトでは、これらの両方の役割は1人の従業員（または従業員のグループ）によって結ばれています。 分離が見つかることもありますが（たとえば、通常、金融機関のプロジェクトで）、そのようなケースは少数です。

正式な定義は簡単にグーグルで検索できますが、実際には：

• システムアナリストの主なタスク：システム要件の収集、分析、形式化、および調整。 つまり、ライフサイクル全体を通して要件を管理します。 通常、唯一ではありませんが、メインの出力ドキュメントは技術的なタスクまたはその類似物です。 これについては、以下で詳しく説明します。
• ビジネスアナリストの主なタスクは、ビジネスプロセスの調査、説明、分析、および（必要な場合）リエンジニアリングです。 メイン出力ドキュメントは、ビジネスプロセスの現状（必須）と今後（必要な場合）の説明です。

最初のものは、適切なITバックグラウンドを持っている必要があります。 第二に、それは望ましいことですが、必須ではありません。 多くの場合、ビジネスアナリストは経済教育を受けた人々です。 1つ目は開発者やビジネスユーザーと同じ言語に堪能である必要があり、2つ目はビジネスユーザーだけで十分です。

つまり、ITの複雑さを実際に理解することなく、大規模プロジェクトのビジネスアナリストを獲得できます（ロシア最大の小売業者の1つでこれを見ました）が、システムアナリストを獲得することはほとんど不可能です。クライアントのビジネスを理解したくない）。

短い技術的脱線

意識的にナレーションを中断し、要件自体に専念しましょう。 タイプ、属性、特性、要件の収集および実行のアプローチに関しては、おそらくより大きな「混乱」を見つけるのは困難です。 要件のあるドキュメントの構成と内容は大きく異なります（たとえば、GOSTとRUPを使用しますが、これは銃とパチンコの比較ではありません）。 各アプローチの要件属性のセットにも独自の、多くの場合非常に曖昧な（たとえばBABOKで）が与えられます。 さらに、分析と設計の段階の結果が混同されることが多く、実行者が分析図にクラス図の最終形式と完全なデータベース図を含めることを余儀なくされます（詳細は以下）。

最終的な真実や何らかのノウハウ（ほぼ同じことがWikipediaに記載されています）であると主張することなく、要件を分類する2つの重要な方法を策定します。



レベルごと：

ビジネス要件

ソフトウェア作成の目標を定義する最高レベルの要件。 そのような要件の例としては、コストの20％削減の達成や、管理の質の向上（たとえば、迅速な報告の可能性による）があります。

これらの要件は、通常、「ビジョン」または「ビジネス要件」という別のドキュメントで説明されます。これには、システムの将来のユーザーの主要な役割の決定とその主要な使用シナリオのリストも含まれます。 そのような強調表示されたドキュメントがない場合、多くの場合、これらすべてが技術的なタスクまたはその類似物に含まれます。



ユーザー要件

これらは、システムが解決すべき一連のユーザータスクと、これらの問題を解決するためのシナリオの説明を定義します。 ユーザー要件は、通常、システムとそれらの間の関係を使用するためのオプションのリストの形式で提示されます（通常はUML言語のユースケース図の形式で）。

ユースケース自体は、すべての可能な事前/事後条件と分岐を伴うアクションの構成シーケンスの形式で記述されます。 多くの場合、説明はテキストです（このトピックについては、Alistair Coburnの著書「システムの機能要件を説明するための最新の方法」に詳しく説明されています）。



機能要件

ユーザー要件に記載されているすべての使用シナリオを確実に満たすために、システムに直接実装する必要がある機能のすべての要素を詳細に説明します。

機能要件は最も詳細です。 入力/出力データとそのチェック、データ処理アルゴリズム、ユーザーインターフェイス要素（設計なし）などを記述します。

原則として、これらの要件は別のドキュメントの形式で作成されます（「参照条件」など）。 同じドキュメントでは、システムを使用するシナリオ（ユーザー要件）が詳しく説明されており、通常は機能要件が関連付けられています。

機能要件の例：「フォーム<フォームB>のボタン<ボタンA>をクリックすると、 <ウィンドウの内容 >を含むモーダルダイアログボックスが表示されます。」



タイプ別：

機能要件

システムによって実装される機能を直接説明します（「機能要件」の段落のレベルによる要件の分類の説明で上に例を示します）。



非機能要件

システムとその環境の特性、および課された制限を説明します。

非機能要件の例には、開発されたシステムでサポートされるハードウェアプラットフォームとオペレーティングシステム、パフォーマンス、セキュリティなどの制限が含まれる場合があります。



注：

上記の説明からわかるように、機能要件は、レベルとタイプの両方の点で要件のカテゴリです。 残念ながら、現時点では、このようなあいまいな用語が開発されています（多くのプロジェクトと複数の雇用主の経験に基づいています）。 他のアプローチがある場合は、共有してください。



投稿を膨張させないために、品質要件の特性（一貫性、完全性など）およびそれらのすべての属性（ステータス、ソースなど）については説明しません。 このトピックが面白い場合は、別の記事で喜んで取り上げますが、これらはすべて簡単にグーグルで書かれています。 同じ理由で、ここではステータス/バージョン/スライス（ベースライン）要件について説明しません。

ただし、要件を処理するためのいくつかの基本的な原則について説明します（このリストは完全にはほど遠い）。



一連の作品とその結果

分析および設計段階の結果は明確に区別する必要があります。 分析の段階で、システムの要件が形成されます。

システムの実装の詳細はすべて、次の段階である設計段階で決定されます。 したがって、必要に応じて、システムデータベースまたはクラス図のモデルを「参照条件」に含めます。この場合、次のことを理解する必要があります。

1. さまざまな人々（アナリストとアーキテクト）によって実行されたさまざまなタイプの作業の結果の1つのドキュメントにミキシングがあります。
2. 技術仕様の配信期限が延長されます。 その完成には、設計段階からのいくつかの結果が必要になります。
   
   システムのアーキテクチャを説明する別のドキュメントに設計段階の結果を作成する方が効率的です。

ただし、設計されたインターフェイスレイアウト（設計/設計なし）の "参照条件"に含めるなど、いくつかの逸脱は許容されます。 技術的なタスク自体を開発している同じ人々によって実行されます。



要件自体を収集する手順：

1. 最初に、システム作成の目標（ビジネス要件）が特定されます。 これらの要件を修正することは開発に必須ではないように思われるかもしれません。 しかし、この場合、請負業者は、開発されたシステムが作成された目標への準拠を制御できず、システム開発の目標とその使用シナリオとの間にセマンティックな依存関係を確立することもできません。
2. 次に、システムのユーザー（人と他のソフトウェアシステムの両方）の役割が決定されます。 その後、これらの各ロールのシステムを使用するシナリオを特定して説明します。 これが、ユーザー要件の形成方法です。
3. 次に、ユーザーの要件に記載されているすべてのシナリオを実行できるように、システムの機能に対する要件の完全なセットが開発されます。 システムとその機能環境のパラメーターの制限も修正されています。

要件の説明に重複はありません

要件を管理するための鍵は、重複がないことです。 各要件は、このドキュメントの1つの場所にのみ1つのドキュメントに記録する必要があります。 この原則から逸脱すると、これらのドキュメントをサポートするための人件費が大幅に増加し、それらの整合性が避けられない違反になります（複雑なソフトウェアシステムでは、すべてのドキュメントですべての新しい要件のすべてのニュアンスを同時に考慮することは困難でリソース集約的なタスクであるため）。

必要に応じて、要件の説明を複製する代わりに、この説明のオリジナルへのリンクを使用する必要があります。 これにより、要件間の関係を考慮し、上記の問題を回避できます。



変更管理

最新のソフトウェアシステムを開発する場合、多くの場合、分析段階の最後に要件を変更する必要があります。 ここでは、当事者が次の原則を理解し、受け入れることが重要です。

• 請負業者は、プロジェクトの初期段階で顧客が完全かつ正確に要件を作成できるとは限らないことを理解しています。 したがって、プロジェクトの過程での要件の変更は許可されます。
• 顧客は、要件の変更が人件費と納期の増加を伴うことを理解しています。

情報リソース、利害関係者、主題の専門家、技術専門家の利用可能性

システムの要件の完全かつ正確なリストを作成するには、請負業者のスペシャリストが次のものに十分にアクセスできる必要があります。

• ソフトウェア開発に関連するすべての資料。
• すべての主要なメディアおよび必要な権限を持つ人に

2番目のケースでは、次のことを意味します。

1. 利害関係者
2. ドメインエキスパート
3. 要件の調整と承認に関与する人
4. 顧客側の技術専門家またはその他の請負業者/下請業者。

これは、おそらく、この小さな余談の終わりです。 物語の言葉は乾いたものになった、私は悔い改めた。 しかし、トピックは非常に形式化されています。

なぜアナリストが必要なのですか？ （ハローキャップ）

アナリスト（プロジェクトマネージャー、プロダクトマネージャーなど）がビジネスに役立つだけでなく、単に「邪魔になる」という開発者からの声を聞くこともできます（現在では非常にまれですが）。 。 彼らは、プロセス、紙片、およびその他の官僚主義で、あなたが知っているように登ります-彼らは単純な開発者が冷静に働くことを許しません（笑）。

過度の官僚化は確かに悪ですが、「ひざまずく」大規模なプロジェクトを実現すること、そして現代世界で唯一のプロファイルの専門家の努力でさえ非現実的です。 開発者の重要な役割に異議を唱える人はいませんが、彼らは販売し、関連するドキュメントの束を作成し、顧客の固有の言語を理解しようとしますか？ 私は、彼らの多くが興味を持つことはありそうもないと思い込んでいる。



ところで、上記の仲間（アナリスト、マネージャーなど）がすべて普通の寄生虫であった場合、彼らは激しい競争の世界でそのような量で雇われず、その種のお金を支払わなかったでしょう。 エンタープライズプロジェクトについて話していることだけを予約します。 成功したモバイルアプリケーションを作成し、今すぐ（まだ？）一人の力で理解できるお金を稼ぎましょう。

実際、アナリストの役割に戻ります。 ツリーに考えを広めないために、実際のプロジェクトで直面しなければならない主要なポイントをリストします。

• お客様の声に耳を傾けます。 時にはこれはすでに困難です-何人かは何時間も文字通り何も話せず、コミュニケーションを建設的な方法に変換することは必ずしも容易ではありません。 ここで重要なのは、アクティブなリスニングです。
• 顧客の「鳥」言語を理解し、明確な言語で要件を完全に矛盾なく策定します。 つまり 顧客意識の流れを一連の正式な要件に変えます。
• 場合によっては、顧客が「自分が何を望んでいるかわからない」ときに、最適なソリューションを提供するか、顧客を「連れて来る」ことができます。
• 既存のアーキテクチャと機能に対する新しい要件の影響を分析するため。 多くの場合、建築家に相談することが役立ちます。
• 必要な形式のドキュメントまたはドキュメントのセットの形式のドキュメント要件。 次に、それらを調整して承認します。
• 税追跡システムでクーポンを作成し、その困難な運命をさらに追跡します。 アーキテクトまたは開発者も入手できます。 TKをリードしますが、より頻繁にアナリストがそれを行います。
• 実装された機能が要件に準拠していることを高度に制御します。
• 要件の変更を管理します。
• 要件に関する顧客とのすべての対話を実行します。
• 多くの場合、顧客への製品の配達に参加します。

また、アナリストは、テストへの参加、ユーザー文書の実装および開発など、自分にはあまり関係のないタスクによってしばしば「固定」されます。 それと戦うか、それに耐えることは、概して、誰にとっても個人的な問題です。 さらに興味深いのは、完全にプロファイリング活動ではありませんが、プリセールスへの参加です。 ところで、多くの場合、このアクティビティは非常に刺激的で開発中です（非常に時間がかかります）。

誰がどのようにしてアナリストになりますか（労働の観点から）？

ITプロジェクトに関与する純粋なビジネスアナリストはそれほど多くありません。 ほとんどの場合、それらのタスクはシステムアナリストによって実行されます。 そして、私は彼らがどこから来たのかを判断する代表的なサンプルを持っていないことを認めます。

システムエンジニアに関しては、経験から得たものです。通常、アナリストに「すぐに」なることは不可能です（ITの以前の経験がなければ）。 少なくとも私の仕事のすべての時間の間、私はそのような人に会うことができませんでした。 どうやらこれは候補者の要件と責任の両方が最初は高いという事実によるものです。



実際には、成功したテスターや時にはテクニカルライターはしばしばアナリストに成長します。 また、開発者は多くの場合アナリストになります。開発は自分のものではないことに気付いた人、本当にアナリストになりたい人、これはPMへの短い方法です。

システム管理者から育ったアナリストに会ったのは一度だけです。 ここでは、結論を引き出すことを約束しません-繰り返しますが、サンプルが小さすぎます。 分析に切り替えたPMも知っていますが、これはかなり例外です。

アナリストは何を知っている/できるはずであり、どのようにこれを学ぶべきですか？

この本を読んだ人たちは「アナリストの道。 ITスペシャリストの実践的なガイダンス」、特にITのキャリアを始めたばかりの同僚は、著者が不幸な読者のために学ぶために提供する知識とスキルの量におそらく少し驚いたでしょう。 要するに、この本に続いて、アナリストはこの分野で人類が蓄積したすべての経験をすべての方法論、技術、ツールで習得し、同時に人間に固有のすべての肯定的な個人的資質を最大限に所有しなければなりません。



私の謙虚な意見では、それにもかかわらず、あなたが努力することができる（しかし、あなたが必要とするという事実ではない） 真空の理想のある特定の球状のアナリストが記述されています。 すべての知識とスキルを一度に獲得したいという熱狂的な欲求は、おそらくカシチェンコにつながるでしょう。 Talisker 16 yoのボトルに賭けています（誰か一人で、時間は不均等です、シェルドン（笑顔）があります）。本で宣伝されている画像に完全に対応する人は一人もいません。スキル）、本の著者を含む。

そこで提供されるスキルは重要ではないと言っているのではなく、優先順位を付けることができればよいだけです。 ところで、アナリストにとってこれは重要な品質です。 そして、私がここに書くものは何でも、この本は間違いなく読む価値があります。



ただし、冒頭で述べたように、アナリストの知識とスキル、およびそれらを取得する方法は非常に大きなトピックです。 そして、この投稿を膨らまさないために、ここでは詳しく説明しません。

そして、簡単に言えば、もちろん、考えてみる価値はあります。

• ソフトウェアのライフサイクルについて
• いくつかの主要な開発方法について（ウォーターフォール、RUP、アジャイルの何か、スクラム、州の顧客向け-GOST 19（プログラム用）および34（自動化システム用））;
• システム分析の基礎について（Wigersは完璧です）;
• 表記法、設計およびモデリングツール（市場で最も人気のあるもの、おそらく：Sparx Enterprise ArchitectおよびRational Rose;およびUML / Aris / IDEF0およびIDEF3）;
• リレーショナルデータベースの理論。
• など

私は、Wordやそのアナログに堪能である必要性についても書いていません（笑）。 ただし、インターフェイスレイアウトを設計するためのツールを少なくとも1つ所有する必要があることは、言及する価値があります。 専任のインターフェイスデザイナーは珍しいので、この作業は多くの場合アナリストに当てはまります。 ここでは、明らかなVisioの他に、シンプルで便利なEvolus Pencilをアドバイスできます。

さらに、責任、社交性、細部へのこだわりなど、いくつかの個人的な資質は、活気づける価値があります。 これには特別なテクニックがあります。

おわりに

同僚の皆さん、この投稿が役に立てば幸いです。 発生した質問について話し合うか、できる限り詳細に関心のあるトピックを取り上げます。 何かに同意しない場合は、書いてください。 学びましょう。 そして、生涯学習を長く続けましょう！