IT業界では誰が誰ですか?

産業用ソフトウェア開発の現段階では、さまざまな制作上の役割が見られます。その数は増加し、分類は年々複雑化しており、当然のことながら、専門家の選定や人材との連携のプロセスも複雑化しています。情報技術（IT）は、高度な人材が必要な人材が不足している分野です。ここでは、人材育成のプロセスと人材の潜在力を活用した体系的な作業の必要性が、インターネットリソースを使用して直接選考するよりもはるかに効果的です。

この記事では、IT 企業の人事スペシャリストに関連する問題について説明しています。生産上の役割の進化における因果関係、人事業務全般における役割の内容の誤解がもたらす影響、さらには、生産部門の役割を高めるための考えられる選択肢などです。スペシャリストの採用の効率化。

初心者のためのIT製造業

IT 業界の誰が誰であるかは、さまざまなプラットフォームで議論の対象となっています。これは IT 業界全体と同じくらい長く、つまり前世紀の 90 年代初頭に最初のソフトウェア開発会社が消費者市場に登場して以来存在しています。そして、同じくらいの期間、この問題について共通の見解が示されていないため、困難が生じ、人事業務の効率が低下しています。それを理解してみましょう。

私にとって、IT 企業に入社して以来、IT 部門における生産の役割というテーマが関連性があり、興味深いものになりました。制作プロセスを理解するために、多くの時間と神経質なエネルギーを費やしました。これらのコストは私の予想を上回り、教育、資材生産、中小企業など他の分野のプロセスに適応するコストも上回りました。一般に人は仮想世界よりも物質世界に適応するため、そのプロセスは複雑で珍しいものであると私は理解していました。しかし、直感的な抵抗がありました。ここでは何かが間違っているように思えました。このままではいけないのです。適応プロセスにはおそらく 1 年かかりましたが、私の理解では、これは単に宇宙的なものです。その結果、IT 制作における重要な役割をかなり明確に理解することができました。

現在、私はこのテーマに取り組み続けていますが、レベルは異なります。 IT 企業の開発センターの責任者として、私は労働市場で雇用主のブランドを促進するために、IT 製品の開発に参加したい学生、大学教師、応募者、学童などとコミュニケーションをとらなければならないことがよくあります。新しい領土（ヤロスラヴリ）の。ソフトウェア開発プロセスがどのように構成されているかについて対話者の意識が低く、その結果、会話の主題についての理解が不足しているため、このコミュニケーションは容易ではありません。 5 ～ 10 分間会話を続けると、フィードバックを受け取らなくなり、自分のスピーチに翻訳が必要な外国人のように感じ始めます。原則として、対話者の中には、会話の中で一線を画し、「とにかく、IT スペシャリストは全員プログラマーである」という 90 年代の俗説を唱える人がいます。神話の起源は次のとおりです。

• IT 業界は急速に発展しており、このような状況ではすべての基本的な意味と原則が形成段階にあります。
• 不確実な状況で存在することは難しいため、人は神話を作り出すことで未知のものを理解しやすくしようとします。
• 人は仮想世界よりも物質世界の認識に慣れているため、自分の認識を超えた概念を定義するのは困難です。

この問題には対処する必要がある側面がいくつかあるため、この通説に対抗しようとすることは、風車に向かって身を傾けるように感じることもあります。 HR スペシャリストは、第一に、理想的かつ現実的な具体化における IT 企業における生産の役割を明確に把握する必要があり、第二に、企業の内部リソースをいつどのように最も効果的に使用できるかを理解する必要があり、第三に、実際の方法はどのようなものかを理解する必要があります。労働市場参加者の意識を高め、雇用主ブランドの発展に貢献します。これらの側面を詳しく見てみましょう。

本番環境の役割の基礎としてのソフトウェアのライフサイクル

一般に、IT 企業におけるすべての生産業務の役割がソフトウェア ライフ サイクルをソースとして持っていることは周知の事実です。したがって、IT 業界全体でこの問題についての統一された認識に同意するという概念的なタスクを設定する場合、誰もが受け入れ、明確に理解している意味論的な基礎として、特にソフトウェアのライフ サイクルに依存する必要があります。プロダクションロールの問題を実装するための具体的なオプションについての議論は、ソフトウェアのライフサイクルに対する私たちの創造的な態度の面にあります。

そこで、RUP 手法を例として使用して、ソフトウェア ライフ サイクルに含まれる段階を見てみましょう。これらは、コンテンツと用語の点でかなり成熟したリンクです。制作プロセスはいつでもどこでも、ビジネス モデリングと要件の形成から始まり、(もちろん条件付きで) ユーザーに相談し、ユーザーの「要望」に基づいてソフトウェアを修正することで終了します。

前世紀の終わりまで歴史を遡ってみると (ご存知のとおり、この時代は「アイランド オートメーション」の時代でした)、ソフトウェアを作成するプロセス全体がプログラマー兼開発者によって実行されていたことがわかります。すべての IT スペシャリストはプログラマーであるという神話の根源はここにあります。

生産プロセスの複雑さの増大、統合プラットフォームの出現、およびビジネスプロセスのリエンジニアリングに伴う対象領域の複雑な自動化への移行に伴い、ライフサイクル段階に関連付けられた専門的な役割の出現は避けられません。これが、アナリスト、テスター、テクニカル サポート スペシャリストの登場方法です。

アナリストの役割を例にしたポジションの多様性

アナリスト (別名分析エンジニア、別名ディレクター、方法論者、ビジネス アナリスト、システム アナリストなど) は、ビジネス タスクとその実装のためのテクノロジを「友達にする」のに役立ちます。開発者向けの問題ステートメントの説明 - これは、抽象アナリストの主な機能を特徴付ける方法です。彼は、要件の形成、分析、ソフトウェア設計のプロセスにおいて、クライアントと開発者の間の橋渡し役として機能します。実際の生産条件では、アナリスト機能のリストは、生産を組織する方法、専門家の資格、モデル化された対象領域の詳細によって決まります。

一部のアナリストは顧客の近くにいます。ビジネスアナリスト（ビジネスアナリスト）です。彼らは対象分野のビジネスプロセスを深く理解しており、彼ら自身も自動化プロセスの専門家です。このような専門家を企業のスタッフに配置することは、特に方法論的に複雑な主題領域を自動化する場合には非常に重要です。特に、国家予算プロセスの自動化を行う私たちにとって、分析者の中に対象分野の専門家がいることは単純に必要です。これらの従業員は、優れた金融経済教育を受け、金融当局での勤務経験があり、できれば第一線の専門家としての役割を果たした、高度な資格を備えた従業員です。 IT 分野ではなく、特にその分野での経験が非常に重要です。

アナリストのもう 1 つの部分は開発者に近いです。システムアナリスト（System Analyst）です。彼らの主な仕事は、クライアントの要件を特定、体系化し、それが満たされる可能性を分析し、技術仕様を作成し、問題点を説明することです。彼らはビジネスプロセスだけでなく情報テクノロジーも理解しており、クライアントに提供されるソフトウェアの機能をよく理解し、設計スキルを持っているため、クライアントの関心を開発者に伝える最善の方法を理解しています。これらの従業員は、ICT 分野の教育を受け、エンジニアリングおよび技術的な考え方を持っている必要があり、できれば IT の経験を持っている必要があります。このような専門家を選択する場合、最新のツールを使用した設計スキルを持っていることが明らかに有利になります。

アナリストのもう 1 つのタイプはテクニカル ライターです。彼らは、ソフトウェア開発プロセスの一環として文書化に携わり、ユーザーおよび管理者のマニュアル、技術的な説明書、トレーニング ビデオなどを作成します。彼らの主な任務は、プログラムの動作に関する情報をユーザーやその他の関係者に伝え、技術的に複雑なことを簡潔かつ明確に説明できるようにすることです。テクニカル ライターは、ほとんどの場合、ロシア語に優れており、同時に技術的な教養と分析力を備えています。このような専門家にとって、標準に従って明確で有能で詳細な技術文書を編集するスキル、および文書作成ツールの知識と習熟が最も重要です。

したがって、同じ役割 (ちなみに、人員配置表での位置) はアナリストですが、その具体的なアプリケーションの具体例は異なります。それぞれの専門家の検索には独自の特徴があります。このようなタイプのアナリストは、一人では両立できないスキルや知識を持っている必要があることを知っておくことが重要です。 1 人は人文科学の専門家で、大量のテキスト文書を扱う分析作業に従事し、発達したスピーチとコミュニケーションのスキルを備えています。もう 1 人は、エンジニアリング的思考と IT 分野への関心を持つ「技術者」です。

外部から取り入れるのか、それとも成長するのか？

IT 業界を代表する大企業にとって、プロジェクトが成長するにつれて、インターネット リソースから直接選択する効果は低下します。これは特に、社内の複雑なプロセスに迅速に適応することが不可能であること、特定のツールを習得する速度がプロジェクト開発の速度よりも遅いことなどの理由で発生します。したがって、人事スペシャリストは、社外で誰を探すかだけでなく、社内リソースをどのように活用するか、誰からどのようにスペシャリストを育成するかを知ることが重要です。

ビジネス アナリストにとって、対象分野の実際のプロセス内で働いた経験は非常に重要であるため、社内で人材を育てるよりも「外部から」採用する方が効果的です。同時に、人事スペシャリストは、この人材の供給元となり得る組織のリストを把握し、選択する際には、その組織から履歴書を探すことに重点を置くことが重要です。

逆に、システムアナリストやソフトウェアアーキテクトなどの欠員を補充するには、社内でのトレーニングのプロセスが非常に重要です。これらの専門家は、現在の運用環境と特定の組織の特性に基づいて形成される必要があります。システム アナリストは、ビジネス アナリスト、テクニカル ライター、テクニカル サポート エンジニアから発展します。ソフトウェア アーキテクト - デザイナー (システム デザイナー) とソフトウェア開発者 (ソフトウェア デベロッパー) が経験を積み、視野を広げます。この状況により、HR スペシャリストは社内リソースを効果的に活用できます。

生産上の役割の交差、統合、進化

生産プロセスでの実装の観点からは、役割間の明確な境界を確立するという別の困難な問題があります。一見すると、すべてが明白であるように思えるかもしれません。実装は完了し、ソフトウェアの商用運用に関する文書に署名され、すべてがテクニカル サポートに引き渡されました。そうです。しかし、システムがすでに実装されているにもかかわらず、クライアントが習慣からアナリストと緊密に連絡をとり、彼を「魔法の杖」とみなして、積極的にコミュニケーションを取り続ける状況がよく発生します。そして正式なサポート段階が進行中です。しかし、クライアントの観点から見ると、システムの操作に関する質問に、一緒にタスクを設定したアナリストよりも上手に、より早く答えられる人は誰でしょう。ここで、テクニカル サポート エンジニアとアナリストの役割が部分的に重複しているという疑問が生じます。時間が経つにつれて、すべてが改善され、クライアントはテクニカル サポート サービスとの通信に慣れてきますが、ソフトウェアを使用し始めたばかりの段階では、このような「内部移行」は、双方にストレスを与えることなく常に完了できるとは限りません。

開発要件のフローがサポート段階の一部として発生する場合にも、アナリストとテクニカル サポート エンジニアの役割の交差が生じます。ソフトウェアのライフサイクルに戻ると、実際の製造条件と、要件分析と問題の定式化はアナリストのみが実行できるという形式的な態度との間に矛盾があることがわかります。もちろん、HR スペシャリストは、ソフトウェアのライフサイクル内での役割の理想的なイメージを理解する必要があり、役割には明確な境界があります。しかし同時に、交差点が発生する可能性があることを必ず念頭に置いておかなければなりません。応募者の知識とスキルを評価するときは、関連する経験の有無に注意を払う必要があります。つまり、テクニカル サポート エンジニアを探すときは、アナリストの経験を持つ候補者が考慮される可能性が高く、その逆も同様です。

重複に加えて、生産の役割が統合されることもよくあります。たとえば、ビジネス アナリストとテクニカル ライターは 1 人の人物として存在できます。大規模な産業開発ではソフトウェア アーキテクト (ソフトウェア アーキテクト) の存在が必須ですが、非常に小規模なプロジェクトではこの役割がなくても問題ありません。そこではアーキテクトの機能は開発者 (ソフトウェア デベロッパー) によって実行されます。

開発アプローチやテクノロジの歴史的な変化は、必然的にソフトウェアのライフサイクルも進化するという事実につながります。もちろん世界的に見て、その主な段階は変わっていませんが、より詳細なものになってきています。たとえば、Web ベースのソリューションへの移行とリモート構成機能の拡大に伴い、ソフトウェア構成スペシャリストの役割が浮上しています。歴史の初期段階では、これらは実装者、つまり作業時間のほとんどをクライアントの職場で費やすエンジニアでした。ソフトウェアの量と複雑さの増加により、ソフトウェア アーキテクトの役割が出現しました。バージョンのリリースを加速し、ソフトウェアの品質を向上させるための要件は、自動テストの開発と、QA エンジニア (品質保証エンジニア) などの新しい役割の出現に貢献しました。生産プロセスのすべての段階における役割の進化は、方法、技術、ツールの開発に大きく関係しています。

ここまで、ソフトウェア ライフ サイクルの観点から、ソフトウェア会社内での制作の役割の配分に関する興味深い点をいくつか見てきました。明らかに、これは各企業に特有の内部関係者の見解です。 IT業界の労働市場の参加者として、また雇用主のブランドを促進する責任者としての私たち全員にとって、外部からの視点は特に重要になります。そしてここには、意味を見つけることだけでなく、この情報を対象者に伝えることにおいても大きな問題があります。

IT 職の「動物園」の何が問題なのでしょうか?

HR スペシャリスト、生産マネージャーの頭の中の混乱とアプローチの多様性により、IT ポジションは非常に多様で、まさに「動物園」になっています。面接や単に専門家との接触の経験から、人々は役職名から得られる意味を明確に理解していないことが多いことがわかります。たとえば、私たちの組織では、「分析エンジニア」という用語が含まれる役職は、これがタスク設定者であると想定しています。ただし、これはどこでも当てはまるわけではないことがわかりました。分析エンジニアが実装者である開発組織もあります。全く異なる理解ですが、同意しますか？

第一に、IT 職の「動物園」は間違いなく採用の効率を低下させます。すべての雇用主は、自社のブランドを開発および宣伝する際に、自社の製品に存在するすべての意味を簡潔な形で伝えたいと考えています。そして、彼自身が誰が誰であるかを明確に言えないことが多い場合、彼が外部環境に不確実性をブロードキャストするのは当然です。

第二に、IT 職の「動物園」は、IT 人材のトレーニングと育成において大きな問題を引き起こします。現場の「搾り出し」ではなく、人材の形成と育成を目的とする本格的な IT 企業は、遅かれ早かれ教育機関との交流の必要性に直面します。高度な資格を持つ IT 人材にとって、これは大学の一部であり、その中で最も優秀な大学、少なくともランキング TOP 100 に入っている大学です。

IT スペシャリストの継続的なトレーニングプロセスを構築する際の大学との統合の問題は、大学が IT 企業内の誰が誰であるかを理解していないことの約半分です。彼らはこれについて非常に表面的な理解をしています。一般に、大学には名前に「コンピュータ サイエンス」という言葉が含まれる専門分野がいくつかありますが、入学キャンペーンを実施する際に、すべての専門分野は本質的にほぼ同じであるという理論に頼ることがよくあります。そして、それは、IT スペシャリストは全員プログラマであるという通説に依存しているのと同じように見えます。

私たちの大学との緊密な協力の経験から、「応用情報学（業界別）」という専門分野は、開発ではなく、方法論と技術サポート部門に人材を提供してくれることがわかります。 「基礎情報学」とともに、「ソフトウェアエンジニアリング」は開発者のための優秀な人材を育成します。応募者を最初から自分に合わない道に誘導しないためには、IT制作を取り巻く「霧を晴らす」必要がある。

すべてを共通点に近づけることは可能でしょうか？

社内外で制作の役割を統一し、共通認識を得ることができるか？

もちろん、すべての開発企業の集合的な経験の蓄積により、生産プロセスを組織するための共通の統一コンセプトの存在が証明されているため、これは可能であり、必要です。これは、ソフトウェア ライフ サイクルの概念が依然として独自に解釈されているという事実の結果であり、新たに登場した運用上の役割 (データサイエンティスト、QA エンジニア、機械学習エンジニアなど) は、ソフトウェアのライフサイクルそのものは、テクノロジーやツールの改善、ビジネスタスクの開発と拡大に伴って発生します。

同時に、IT は経済の中で最も新しく急速に成長している部門の 1 つであるため、生産の役割を統一することは困難です。ある意味、これは宇宙が誕生した混沌です。 IT は知的ではありますが、非常に創造的な分野であるため、明確な組織構造はここでは不可能であり、不適切です。 IT スペシャリストは、一方では「物理学者」、つまり高度なアルゴリズム的および数学的思考を備えた知識人ですが、他方では「作詞家」、つまりアイデアの創造者、担い手、推進者でもあります。芸術家と同じように、彼も絵を描くための明確な計画を持っておらず、イメージを部分に分解することもできません。彼は情報プロセスの支配者であり、情報プロセス自体は抽象的で無形であり、測定するのは困難ですが、迅速です。

IT 生産における効果的な人事業務を構築する方法

では、IT 制作の役割の多様性の中で効果的な人事業務を構築するために、人事スペシャリストが知っておくべき重要なことは何でしょうか。

まず、IT 企業の人事スペシャリストは、自分の企業に特有の状況、つまり誰が何をし、誰が何と呼ばれるか、そして最も重要なことに、状況下でこれらの役割が何を意味するのかを理解しておく必要があります。特定のプロダクション。

次に、人事担当者は生産の役割を柔軟に理解する必要があります。つまり、最初は彼は彼らについて理想的な理解を形成し、それによって彼はすべてを自分で理解できるようになります。次に、生産の実際の全体像がなければなりません。役割がどこでどのように交差して結合するのか、生産マネージャーの間でこれらの役割についてどのような認識が存在するのか、ということです。人事スペシャリストにとって難しいのは、現実の状況と理想的な状況を頭の中で組み合わせることであり、理想的な理解に合わせてプロセスを強制的に再構築しようとするのではなく、リソースの必要性を満たす生産を支援することです。

第三に、特定のスペシャリストの成長の可能性のある軌道についてのアイデアを必ず持っておく必要があります。どのような場合に外部からの選抜が効果的であるか、いつチーム内の従業員を成長させ、成長の機会を提供するのが良いか、どのような資質があるかなどです。候補者の数が多いと、特定の方向に成長できるようになります。これは、1 人の人間では両立できない資質であり、これは成長の軌道を選択する上で最初に重要です。

第 4 に、IT は高度な能力を備えた人材を育成する分野であり、人事業務をより効果的に行うためには大学の教育環境と早期に統合することが避けられないという定説に戻りましょう。この状況では、すべての人事スペシャリストは、直接検索、アンケートや面接の操作などのスキルを開発するだけでなく、どの大学が企業向けに人材を準備するか、特定の大学のどの専門分野が専門であるかなど、大学のスペシャリスト養成環境を確実にナビゲートする必要があります。人材のニーズとその背後にいるのは誰か、大学で専門家を管理し、訓練するのは誰であるかが重要です。

したがって、すべての IT スペシャリストがプログラマーであるという通説を意図的に暴くのであれば、この方向に向けていくつかのステップを踏み、将来の職業に対する認識の基礎が築かれる大学に特別な注意を払う必要があります。言い換えれば、私たちは教育環境との継続的な交流が必要です。たとえば、コワーキング センターでのコラボレーション、「沸点」、集中教育への参加といった最新の形式を利用することが必要です。これは、IT 企業に関する誤解を打ち破り、人事業務の効率を高め、業界のさまざまな専門家のトレーニングにおける共同活動の条件を作り出すのに役立ちます。

この記事の準備と関連性のサポートに参加してくれた同僚、Valentina Vershinina とYuri Krupin に感謝の意を表します。

出所： habr.com