ここで紹介するのは、インフォテックのホームページの人材募集記事のひとつです。もともと人材募集のための記事で、開発プロジェクトにおいて技術者がよく遭遇する状況 (悩み) をあげ、インフォテックではこのように対応しているという、いささか、手前味噌な記事です。
ただ、内容的には一般のプロジェクトにもあてはまるケースが多く、実際にプロジェクトに関わっている現役の技術者やこれからソフトウェア技術者になることを目指しているかたにも参考になるのではないかと思います。以下にそのまま掲載します。
インフォテック人材募集のページ
どんな人でも今の仕事に多少の不満を持っているものです。それが深刻なものと感じたときにはその不満にきちんと向かい合うことが大切です。
あなたの不満が、現在の待遇にあるのか、仕事の内容や位置づけにあるのか、人間関係にあるのか、あるいは会社そのもののビジネス状況や将来性にあるのか。さらにその不満は本質的なものなのか、一時的なものなのかなどを冷静に考えてみる必要があります。
あなたが信頼できるひとに相談してみるのもよいでしょう。
中途半端な気持ちや一時的な不満で安易に会社を代わると、かえって事態が悪くなり、後悔することになりかねません。一般に会社を代わるのは大きなリスクです。できればいまの会社でキャリアを築いていくのがベストです。
特にあなたがまじめなエンジニアであればあるほど新しい会社のやり方と合わない場合にはさらに大きなストレスを抱え込むリスクがあります。
こんなことを言うのは、仮に当社で働くことになっても、中途半端な気持ちで決めたのでは、結局長続きはしないからです。私たちは皆さんが当社での仕事をよく見極めたうえで前向きな動機で入社していただくことを望んでいます。
以下では、IT技術者が不満を抱く典型的と思われるケースについて記述しています。さらに各ケースについてインフォテックではどのように対応しているかを説明しています。あなたが開発に真剣に取り組んでいる技術者であればきっと思い当たる点があるでしょう。
仕様が決まらない・ころころ変わる
直接交渉していても仕様の決定は常に遅れがちになります。これは「そもそも顧客が自分のやりたいことがわからない」、「顧客が仕様を理解するのに時間がかかる」、「仕様変更に伴う費用負担でもめる」といったことがよくあるからです。
立場が下請けの場合にはもっとやっかいなことになります。元請と顧客の間では下請けの知らないさまざまな事情や経緯があります。また元請の営業、SEなどの対応力が必ずしも十分であるとは限りません。
「決まった」はずの仕様があいまいだったり、技術的な不整合や無理があることもよくあります。下請けの技術者の立場で一度決まってしまった仕様を変更するのはほとんど不可能です。
立場が元請のSEの場合でも営業や上司が営業的観点などから顧客の希望を丸呑みにしたり、不利な条件を請け負ってしまうケースもあります。顧客との会議に同席していたとしても営業などへの遠慮から技術的に正しいことをなかなかストレートに言えません。良心的な技術者ほど大きなストレスを抱える原因となります。
このような状況であってもまじめな担当技術者であるあなたは与えられた条件の中で残業やときには徹夜をして納期や品質を守るよう必死の努力をすることでしょう。
最悪なのは、せっかくがんばって仕様通りのシステムに仕上げたのに、最終確認で顧客の要求と違うことが判明したり、根本的な仕様変更が行われることです。残念ながらこのようなケースは珍しくありません。
インフォテックの場合
インフォテックでは担当技術者であるあなたが顧客と打ち合わせの上、全ての仕様を決めることになります。「誰か」が決めた仕様に悩まされることはなくなりますが、これは同時に決定の最終的な責任はあなたが負うことを意味することに注意してください。 もう「誰か」のせいにすることはできません。これをやりがいがあると思うか、責任が重すぎると思うかはあなたの仕事に対する考え方によります。
システムや仕事の一部にしか関与できない
情報技術はクラウドやサービス化、アジャイル開発の方向に進展しているのにシステム開発の組織や役割分担は昔ながらの階層構造が維持されています。元請／下請けの受注構造の階層化に加え、サブシステム毎にプロジェクトマネージャー、シニアSE、SE、シニアプログラマー、プログラマーなど仕事の階層が設定されます。
階層の下にいるプログラマーは設計書やSEの指示に基づいてひたすらコーディングとテストに専念することになり、なぜそのような仕様になったのか、システムはどのように動くのかといったことが理解できないまま作業を進めることになります。
一方、階層の上にいる技術者は顧客との折衝や進捗管理などの管理業務に忙殺され、システムの細部や技術的なポイントに目が届きづらくなります
規模の大きなシステムでは開発組織も分業化や階層化されるのは自然なことですが、元請/下請けを前提とした受注構造や優秀な技術者の偏りなどの影響により 少人数でできるプロジェクトでも必要以上に仕事を細分化しメンバーを増やす傾向があります。この結果、開発費用やオーベーヘッドがふくらむとともにトラブ ルが発生するリスクが高まります。
開発の全体のプロセスに責任を持ち、経験することは、モーチベーションの維持やスキルアップに重要なことですが、実際の開発現場では、技術者は見通しの悪い分断された仕事を次から次へとこなす状況に追い込まれます。
また発注側は仕様･概要設計、受注側はプログラミングといった具合に所属する会社により技術者の役割が特定の業務に固定されてしまうことも業界としての技術者層の形成や個々の技術者の流動性やキャリア形成上障害となっています。
インフォテックの場合
インフォテックでは担当技術者がヒアリングから、見積・提案、設計、開発、テスト、設置、保守までの全ての開発プロセスを担当します。顧客との打ち合わせを踏まえてシステムの方向性や目的から個々の開発ツールまであなた自身が設定することができます。 このような仕事に積極的に取り組めば、比較的短期間で多くの実践的な知識や密度の高い経験を得ることができます。
自分の技術力が生かせない
メーカーや大手SIでは業務提携やビジネス上の事情から、たとえばデータベースはA社製、アプリケーションサーバはB社製といった具合に選択肢が事実上固定されているケースが少なくありません。
このためCという製品が今回のケースでは従来扱っているDという製品より技術的、経済的観点から適切だと判断される場合でも、顧客にはDを勧めるというケースが発生します。このような状況はシステム構築のさまざまな局面で起こり得ます。
最近のソフトウェア製品の寡占化の傾向も手伝い、大手サプライヤーやSIerであればあるほど冒険を避け、定番の製品に傾き、結果として技術的選択の自由度が小さくなっているように見えます。また下請の場合は、使うべき製品は既に決定されているので、そもそもそのようなことを検討する余地もないことになります。
技術者の方はよくご存知のようにシステム構築のツールやミドルウェア選択において多くのオプションがあり、これを適切に評価、採用することによりシステム性能や開発効率を改善することができます。また少し仕様を見直すことで工数やリスクを大幅に減少することもできます。
困難な要求にさまざまな工夫を加えエレガントな方法で解決したり、新規の技術に挑戦し成功することは技術者にとって大きな喜びです。営業的な理由や政治的な理由で技術的判断の自由度が狭まったり、軽視されるのは、日ごろ研鑽を積み、常によりよいシステムを目指している技術者にとって大きなストレスとなります。
インフォテックの場合
提案における技術的な判断も担当技術者の重要な仕事です。顧客の要求とシステムの特性に合わせて最適のシステムを提案、開発するのはあなたの仕事です。インフォテックでは経済性や信頼性を担保できるのであれば技術的な可能性になんの制約もありません。
ソフトウェアが作れない
「ソフトウェアを作る人」であるプログラマーは日本の伝統的なIT業界では階層的に低い立場に置かれています。ソフトウェア技術者のキャリアにおいてもSEやコンサルタントになる、言い換えると「ソフトウェアを作らなくなる」立場になるのが最終の目標とされています。
この結果、現実にはソフトウェアをちゃんと作った経験が無いSEやコンサルタントがたくさん存在し、そのことが問題を起こすケースも少なくありません。
このような業務の進め方は、仕様がしっかりしていればプログラムは誰が作ってもちゃんと同じように作れるという前提に立っています。よい設計図があっても自動的によい建物が立つわけでないのと同じで、よい仕様があってもよいプログラムが自動的にできる訳ではありません。
(注)少し古い記事ですが、日本最大のSIerであるNTTデータの社長もインタビューでプログラミングの重要さを反省を交えて指摘しています。こんな記事もあります。
現実には不完全であいまいな仕様を元に個々のプログラマーが「解釈しながら」開発を進めることが多いのではないでしょうか。つまり実態としてシステムの質は大いにプログラマーの質に依存していることになります。
また元請/下請の受注構造がこのような分業を助長している面もあります。優秀な技術者が多くの案件をこなすために仕様決定や概要設計に専念させ、詳細設計、コーディングについては外注に任せるというのが一般的な形態になっています。
このような事情で、本来プログラムが好きな技術者がもっと自分でソフトを作りシステムの隅々まで意図通りに実装したいと思っても、その技術者が優秀であればあるほど仕様のとりまとめの仕事が増え、実際のプログラミングに従事するのが難しくなるというジレンマが発生します。
インフォテックの場合
インフォテックではコーディングもテストも基本的にあなたの仕事です。顧客が最終的に望むのは立派な仕様書でもテスト報告でもなく顧客の要求を満たしてきちんと動くソフトウェアです。インフォテックはこのことをよく理解しプログラミングを大切にしています。
お客様のメリット
インフォテックのこのような開発スタイルは顧客にとっても大きなメリットとなります。顧客は担当者であるあなたに要望を伝えればよく、プロジェクトの階層化によるオーバーヘッドや遅延、コストを負担する必要がありません。
プログラムを実装するあなたは顧客の要望を実現する上での問題や工数を正確に予測できるので、顧客に対し迅速かつ的確に回答することができます。また特定の処理系やミドルウエアに制約されることもないのでライセンス負担の少ないシンプルで効率の良いシステムの開発が実現できます。
実際、当社の開発では高価なミドルウェアや処理系を利用することは少なく、その結果、システムの軽快な動きにお客様から驚きとお褒めの言葉をしばしばいただきます。
当社の技術者にとっては当たり前に設計、開発しただけなのですが、業界では供給側の都合に基づいて充分な検討を行わないまま開発が進められるケースが多いのです。
また万が一不具合が発生したときも迅速な対応が可能です。当社の場合は、担当者が自らプログラムを修正するので、ほとんどのケースで一両日以内に問題を解決しています。大手SIerの場合は、実際にプログラムを直すのは外注先であることが普通なので、かなりの日数が必要となります。
お客様にメリットがあるということが当社にビジネス的な優位性をもたらすことになります。一般に大手企業ではコンピュータメーカーや大手SIベンダーに基幹システムの開発や運用を依頼しています。
一方で部門システムや戦略的システムなど比較的規模の小さいさまざまなシステムの開発需要があります。これらの需要のうち実はかなりの部分が当社のようなスタイルで開発可能です。
大手ベンダーは手間のかかる小規模なシステムは避けがちで、またオーバーヘッドが大きいため割高な見積を提示します。当社はメーカーや大手SIと同等以上の単価を維持していますが、効率の良い開発スタイルにより、お客様に提示する開発コストは十分な競争力を持っています。
あなたは技術的に面白い仕事を通じお客様の満足を得ることに加え質の高いビジネスに貢献することができるのです。
この点はあなたのような意欲の高い技術者に安定した職場環境を確保し、お客様に質の高いサービスを継続的に提供していく上でとても重要なことだと認識しています。
あなたの参加により当社のビジネスはさらに拡大し、強固なものになるのです。