A Day In The Boy's Life -73ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

同僚と飲んでいて「今の若い子達は開発をしていても、もっと自分がこうしたいというような意思を示さない」みたいなことを言っていて、それもそうだなと思いつつも現在のように何でもかんでも存在する世界ではなかなか自分の意見を言う状況にも無いのではないかなと思ったりもしました。



「ある世界」で見つける隙間とアイデア


今のようにどの企業でもIT投資が盛んに行われていて整備しきった環境では何が足りないのかというは、作るという視点だけではなかなか見つけづらい状況です。

それは10年自分がこの業界で働いてきた状況でも、なかなか今企業にとって必要なものなんて視点では見れてなかったりもします。

逆に何もない状況であれば、現場で困っている人たちから意見を聞いて、例えそれがExcelに毛の生えたようなシステムであっても自分たちの意思を吹き込むことが出来る環境がそこにはあったりしました。


クラウドビジネスの流行で自分たちが直接一からものづくりを出来るという環境は少なくなってきたりもしていますし、不況の影響でIT投資の削減やエンジニアとしての教育に力を入れないというところも多くなってきてたりもするので、出来合いのものをどう組み合わせるかや、早々に上流工程に回されてものづくりの楽しさを覚える前にスケジュールの管理や外注をどう扱うかのリソース管理に注力させられたりというのも多い気がします。


環境がそろっていて、それを築いた人たちが幅を利かせていれば、経験の浅いエンジニアから見ればそこに何か自分の意思を差し込む隙が見当たらないのかもしれませんし、自分たちが消えれば必然的にやらざるを得ない状況に追い込まれることにもなるので、個々の意思を示すようになるかもしれません。

なので、一つの理由には自分たち経験豊富なエンジニアが教育の効率化と銘打って、知らず知らずのうちにそういった経験の浅いエンジニアの意見を否定してしまっているような気もします。


また、すでに完成されたシステムがそこにあると、前人たちの意思が強かったりよくわからないルールを強要されて、自分たちの意思というものも薄れてしまうかもしれません。

そもそも他人の作ったものにどこまで愛着をもてるのかというところもあります。

それは自分とて同じ事で、やはり他人が作ったシステムを保守するよりは、自分が一から作ったシステムの方が愛着も強く、今後それをどう発展させていこうかなんてことの考えもめぐったりもするものです。



自分が構築したサービスのファンたるか


システムへの愛着が増せば当然そこに自分たちの意思を吹き込もうという行動は見られると思います。

それは開発期間や規模なんかに依存するものではなく、単に自分たちがどこまでの割合を任せられたとか、提供したものの反応なんかで決まってくるのでしょう。


開発規模が大きかったというのは、どちらかというと経験として今後の支えになるとか、履歴書に載せられるぜっていうような捉え方が大きい気がしますし、そんな大規模開発ってスケジュールがタイトで死にかけたとか、今となってはいい思い出ってレベルで、それが愛着にまで繋がるかというと必ずしもそうではない気がします。

それよりは規模が小さくても自分で要件のまとめから設計・構築までの一連のタスクに携わったという方が愛着をもてるでしょう。


愛着とかは関係ないから言われた仕事をしろという人もいるかもしれませんが、自分たちが夢中で作るようなサービスでなければ他人も夢中で触るということも無いでしょうし、本質を理解していないで設計書どおりに作ったシステムもまた他人は熱中しないと思います。

これは、エンジニア自身のモチベーションだけでなく、サービスを提供する上で死活問題になってくるものでしょう。

スケジュールに追われて残業しましたというのと、夢中で作ってたら終電前になってたいうのは全然違いますし、それを作るエンジニアでさえ、作ったシステムのファンでないなら客を一人取り逃していることにもなっているわけで。


それは何も大きな役割を与えてやるということだけでなく、例え一つの機能であっても自分たちで作るということが出来たなら、それが自信につながるでしょうし全体への印象も大きく変わってくると思います。

よく聞いたりすると、コードの実装方法や技術上の課題への解決方法は熱心に調べたり工夫してたりもするので、意思が無いというのは経験の差からくる見ているレイヤが異なっていたりするだけで、求めていることが多くなってしまっているだけかもしれませんし。

それさえ否定してしまっては、自分たちの意思を示せというのではなく、自分たちの手足となることを強要しているだけ軒がします。





経験が浅いエンジニアの作ったシステムのテストをしていると、やはり品質が悪いなと感じることがあります。

本人からしてみれば出来ましたって感覚なんでしょうけど、少し異常系のテストをしてみるとバグが顕著化したりして、まともに動くのはごくごく一般的なケースでのテストしか通らなかったりもします。

本人の頭の中にはとりあえず動くものが出来たからOKだろうという考えで、ちゃんとテストをしろよとか思ったりもするんですが、経験の違いで生まれる品質の差は作る作業そのものの視点の違いのような気もします。



やった動いた!の感動が打ち消す視点


それはどのエンジニアにもあることだと思いますが、作ったコードが動いたときの感動や快感ってあるわけですよ。

私も一応動くコードが書けたときは口癖のように「完璧!」と唱えたりして、後からぼろぼろ出てきたバグを潰しては同じように「完璧!」って口走ってたりもしました。

まずは、動くものが見たいって感覚に駆られますし、最初は動くものを見ないとなかなか作っているという感覚を得られなかったり、どの辺を作っているのかというマイルストンが頭の中で定まらなかったりもします。


ただそれが強くなりすぎると動いたというところで満足感が得られてしまって、その他のところに気を配れていなかったりもするわけです。

元々、”動かそう”と考えてコード書いているわけなんで、”これやったら動かないだろうな”って視点は頭に無かったりします。

いつの間にか仕様書や設計書の要求を忘れ、自分の中で組み立てた動くシステムそのものが仕様に成り代わってしまったりするわけで。


いや、頭にあってもあまり気にせずにまずは動くものをという視点が先に来てしまいます。

解消しないバグが出てイライラするよりは、すっきり動くものを見たいという方が頭にあるのは当然かもしれません。

ただ、その視点にとらわれることでシステムの正常形だけを見て、くさい物に蓋をするように異常系の観点を見落とすということは多い気がします。



脱初心者エンジニアのための品質管理の視点


品質を上げるにはテストを重点的にするってことはありますけど、やっぱりそれはつまらないものだったりもします。

テストケースやテストプログラムを書くことって、動くものを作るというところからかけ離れている気がしますし、自分の頭の中にはそんなものが無くても正しいコードがかけるって変な自負があったりもしますし、まずは動くものを作ってみてみたいという衝動はそんな地味な作業をすることの感覚を超えてしまうことも多々あります。


よくテストケースやプログラムを先に作らせようとすると、技術的にどうすればよいかわからないのでとりあえずプログラムを書いてみましたって言う人がいますけど、視点がまったく逆転してしまっていたりします。

そもそも、どうやって動くコードを書くかや何が正しいかをしっかりと検証するためにテストケースを作ったりしているのに、先に頭の中にある曖昧なコードを書いてしまっているわけです。

テストケースやプログラムは仕様を正しく理解していないと作れませんが、その効能を忘れてひたすらに自分の頭の中で正しいと思われるコードを書き続けているわけですから、仕様漏れや正しいコードがかけていないというは当然出てきたりもします。


あと、バグなんて出たときに直せばいいという考えの人もいるかもしれませんが、実際に運用開始後に出たバグの修正ってリリース前に作業するよりも格段に面倒なステップを踏まないといけなかったりもしますし、バグが出たときにというのはバグが出ないことを願っているという不確かな願望が込められてたりもしています。

明らかに設計ミスであるのに「そんな使い方しないでください」って逆ギレしているエンジニアを見たこともありますけど、こうなってくると全くあべこべで、自分の頭の中で考えた動くシステムそのものが仕様になっちゃってたりするわけです。


コードを書くって行為も、コードが動いたって感動も、正常に処理できるシステムを作った場合も、異常な処理に対して例外処理を正しく返すように作るって行為も、システムを構築するって行為の中の1つの要素であり、1つのタスクではあります。

ただ、作る楽しさは目に見えて動く(しかもよりユーザー視点に近いところ)にとらわれがちになりますし、利用者の立場からブラックボックスになるところって、エンジニア視点でも曖昧にとどめておくようになってしまいます。

それがシステム全体のパフォーマンスに影響したりセキュリティなどより重要な要素に影響したりはするんですが、そういったところを考える楽しさというものは最初の方はあまり気にしません。


システムそのものを動かすって視点とレイヤーの違いにより、その品質そのものに関連する意識も大きく異なってくると感じます。






システム屋さんやってる人のブログ見ると「なんでも屋」って表現している人を結構見かけたりします。

実際、昔からシステム屋やっているような人は、ITに強い人と疎い人の割合が極端だったりしたため何でも面倒を見るように頼まれたり、今でも人材不足から様々なレイヤーの仕事を一人でこなしているというような人は多くいますし、そういった人はまさに何でも屋って表現が板につくのでしょう。


ただ、この表現ってあまり良い意味で使っている人がいないんじゃないかなと思ったりもします。

多分、中途半端な存在って印象があるからもしれません。



何でも屋って表現の危うさ


エンジニアといっても様々なレイヤーのエンジニアがいて、それぞれの分野で深い知識を掘り下げられたりもするんですが、要は何でも屋ってそんないろんなレイヤーの初めの方をかじり倒したような人を想像されたりもします。

非エンジニアから見ればそれでも凄いじゃんみたいな事を思われたりもするんですけど、同じエンジニアからみれば、どこにも得意分野を持たないって目で見られたりもするわけです。


実際、全てのレイヤーでプロとして働けるような人はエンジニアの中でも一握りですし、そういった人は特段自分のことを何でも屋のような表現をとったりもしないでしょう。

ギークの人から見れば、自分の興味を拡張させていった結果、多岐のレイヤーにわたって深い知識を得られたってことだけだったりして、自らなんでもやろうって意思を持って取り組んでいるというより、気が付いたらそうなっていたって結果だけのような気がします。


いろんな分野で仕事をしてみて知識を得ることは悪いことではないと思いますが、ただそれをひたすら繰り返していると、結局自分が思うように中途半端な存在として成り立ってしまって、どっちつかずの存在にもなってしまいます。

一方で、ある一つの分野に特化して極端に偏ったエンジニアって言うのも活躍の場が限られたりもして、それは実際に仕事をするうえではレイヤーにまたがって仕事をしたり話をしたり、能力を活かさないといけなってことがあったりするわけで、偏屈に自分の領域というものを固定してしまうと、扱いにくい人材として孤立してしまう可能性もあります。


一般企業としてうまくやっていくには何でも屋の存在の方が都合がいいことになります。企業側から見た視点として。

脱何でも屋でやっていこうとしたら変に箱の中で役割の変化を求められる一般企業よりは研究職とかについたほうが幸せになれるかもしれません。


何でも屋が都合が良いのは与える仕事に替えが利きやすいのと、分野を横断して話がわかる人材の方が応用しやすいからです。

良くも悪くも、いろんな仕事を振ることができるというオールマイティの存在として扱われますから、特定の分野で秀でたほかのエンジニアがいたとしても、他の分野のタスクをこなせる分つぶしが利きますし、1つの分野だけで施策を成し遂げることも出来ませんので、横断的に話が出来る人材というのは貴重になったりもします。


それが何でも屋である強みではありますが、その何でも屋としての存在はあくまでその閉じた世界の中だけであって、外に出れば同様に能力を発揮できるとは限りません。

そもそもアピールとして何でもやりますっていうのはポイントになりませんし、何でも出来ますというのはあまりにも誇張した表現になりすぎたりもします。



なんでも屋のその先


都合よく扱われがちな何でも屋ですが、そういった人たちに何でもかんでも仕事を振っていくことがベストとは限りません。

都合の良い存在を確立してしまうと当然仕事は集中します。

そして、リソースは限られますのでオーバーワークになってパフォーマンスが低下する事にもなります。


マネジメントする側から見ても、何でも出来るからという理由だけでタスクの割り振りを正しい判断を下していなかったりもします。

何でも出来るといっても得意分野があるでしょうし、与えたいタスクと使えるリソースを見れば誰が対応するのが最も能力が高いのかって判断を見落とすことがしばしばあります。

仕事には前後関係がありますから、シームレスに対応が出来る人物の方がポイントが高く見えがちなのもあるかもしれません。


ただ、そういう人を多く育ててしまったときに、高い専門分野が必要になってくると対応できなくなってきたりしますし、長年そういった仕事をさせることでエンジニア自身のモチベーションの低下を招くかもしれません。

何でも屋って表現を好まないエンジニアが多くいればそれはなお更です。


35歳定年説のように、何か別のキャリアパスを描かせようとするIT企業も多かったりするので、何れにせよ何らかの進路変更を求めるように仕組まれたりもします。

下積み時代はエンジニアとしての何でも屋を育てて、マネジメントをしだしたら分野が変わっただけで何でも屋の仕事が待ってたりもするわけです。

結局、レイヤーは違えど何でも屋を仕立てる方向に企業内の教育やキャリアパスは動いていったりもするので、それまでに如何に様々な経験を積みつつも自分の中の強みを伸ばして理解しておく必要もあるかと思います。


あいつは何でも出来るからという視点で見られているのは、ある意味で特化した分野能力を持ってると思われていないという裏返しがあったりもします。

経験を積んで、アプリケーション開発やインフラ構築など技能のレイヤーから、開発と運用という業務のレイヤーなど様々な切り口で経験を積んでいたとしても、プロジェクトを遂行する体制の1ピースとしてどこに当てはめるのがもっとも自分の能力が発揮されるのかという印象を持たせておかないと、リソースが足りないからという理由以外で都合よくいろんな仕事を押し付けられる存在となってしまいます。


何でも屋であることが強みとなってしまっては、いつまでも都合の良い存在を抜け出せないのではないかなと思ったりするわけです。