■ [開発]ゲーム開発におけるITアーキテクト的な仕事の重要性 
こうしたプログラマを取り巻く状況の悪化から、やはり単なる「いわれたことを淡々とこなす」プログラマであり続けるのは非常に困難となりつつある。IT投資が縮小していく可能性が高く長期で考えた場合、この惨状がより悪化することは目に見えている。
このため、プログラマ自身ができる自衛の策として、製造業などの他業種と同じく、より高度な知識や経験を基に、高品位のサービスを提供し、自らの立場を常に確保し続けることが考えられる。特にプログラミングを日々の糧としている腕に自信のある方ならば、それを基に高度な技術提供とそれに基づくビジネスを考えるのは何ら不思議な話ではない。
ITアーキテクトとは、こうした高い技術を保持し、顧客に対して最小の投資にて最大の効果を上げるための処方せんを提供できる「プロフェッショナル」としての活動が源泉であると筆者は考えている。これは特に「仕事で何となく（嫌々）プログラミングをやっている」プロフェッショナリズムに欠ける作業者の立場と根本的に対立する指向であるという点に注意する必要があるだろう。つまり、プロである限り、自らの仕事に対する重責と誇りから常に逃げず、真正面から取り組む必要があるということだ。
◆ より深いコミットメントを
さて次回以降ITアーキテクトの具体的な仕事についてもご紹介していくが、現場での重責を考えた場合、ITアーキテクトになるということは、仕事に対してより深いコミットメントが求められているということになる。
これは長い労働時間が必要、という話ではなく、自らの経験と知恵を絞り出して顧客からの信頼を得、多くの開発人員からなる現場を正しい方向に導き、長期にわたる運用の悩みをともに解決してゆく「現場と目線を合わせる」柔軟さと責任感が求められるということだ。
ITシステムは機械が動作するものであるにもかかわらず、非常に多くの人間がその構築・運用にかかわる。そうした人員は多少なりとも技術的に「こだわり」を持つ方々が多い。こうした中、ITアーキテクチャを武器として作業員を納得させながら開発し、正常運用に持ち込むためには、そうした現場とがっぷり四つに組み、ともに意見をぶつけながら解決策を模索する、粘り強い日々の取り組みが不可欠となる。
ITアーキテクトは、決して楽な仕事でも、おいしい立場でもない。かえって多くの情熱と労力を注ぐ必要のある、後ろ向きの考えであれば「厄介な」職業であるはずだ。それはプログラマが最も苦手とする「人間系」の技術と、それに似つかない「IT系」の技術の両輪が求められる、高い難易度を必要とする職種といえるだろう。
どれだけ難しい技術を導入しても、その技術が製品のクオリティ向上に貢献しなければ何もないのと同じだし、たとえ効率的なシステムやワークフローを設計したとしても、それを効果的に運用できる環境を維持できなければ意味がない。上記のようなITアーキテクト的な仕事は、システムを円滑に運用し、チームが最大限の効率で動けるようにしていくためには非常に重要であるように思う。
ゲームプログラマにありがちなパターンとして、システムやツールを作成して一度使い方を説明したらその後の運用はデザイナや企画側に丸投げしてしまい、問題が発生していてもシステム製作者の知らないところで騙し騙し回避しながら非効率な運用が行われ、ある日それが破綻して問題が表面化する時までそのまま放置される、というケースを何度か見かけたことがある。日ごろから自分の作ったシステムが効率的に運用されていることを確認し、新たな問題や改善点が発生していないか常に目を光らせておくのは設計者として当然の義務だ、という認識をみんなが持てればこのような問題も減っていくように思う。また、ゲームを面白くするために仕様が日々変わっていくのはある程度は仕方のないことなので、むしろプログラマ側が自分の無用な仕事を増やさないためにも率先して仕様の穴を潰し、より良くするための修正案を提案していくべきだろうと思う。プログラマに限った話ではないけれど、なぜか「それは自分の仕事ではない」という言葉とともに責任を放棄し、そのために後で自分が困ることがわかっているはずなのにあえて放置してしまう人もたまに見かける。
また、「無茶な仕様変更ばかりされて困る」と嘆く前に、「なぜそのような無茶な要求が来るのか？」「それを防ぐために自分にできることは何か？」と考えるべきだろうし、そのような状況にならないためにも、変更者に不満を言う前にある程度仕様をコントロールできるような状況に持っていくほうが精神衛生的にも良いと思う。問題が起こりそうな気配があれば放置せずにXP的に顧客を巻き込みつつこちらからも提案して積極的に解決していく姿勢が大切だろうし、十分に検討して実装した仕様が変更になったときにはそのような状況をあらかじめ想定できなかったプログラマ側のミスだと捉えることもできる。このような問題にはソーシャルな面も大いに関わってくるので、個々人の性格や考え方によって問題が起こりやすくなってしまう事もあるけれど、経験的にチーム内の雰囲気や空気が十分に前向きであれば人間関係のトラブルは大幅に減るように感じている。そのような状態をどうやって作っていけばいいのか、というのは難しい問題ではあるけれど、上手く機能している組織とそうでない組織の一番の違いはこのような「空気」の違いではないか、と最近思うことが多い。
