とある元SEの思考を探る

ひょんなことからとあるICT企業ではたらくことになったなんちゃって元SEがしたためるブログ。主に、政治・経済・社会問題・日常の出来事について発信していきます。お読みいただけたら、感動にむせび泣くほど嬉しいです。よろしくお願いします。


Webエンジニアの苦手な仕事3選

エンジニアリングに関する話題は別のはてなブログで書くこととが多いですが、今回は読み物ということで、このブログで書いて見たいと思います。

 

Webエンジニアの仕事は多岐に渡ります。私はアプリケーションよりのエンジニアなので、主にソースコードと呼ばれる英単語の羅列(ときたま日本語)を書いたり、営業やサポートからの要件を聞いて設計をしたりしています。

その中でもWebエンジニア歴1年半弱の私が苦手とする仕事を3位から順に3つ上げていきたいと思います。

 

第3位 環境構築

第3位は環境構築。私はアプリケーションよりのエンジニアなので、設計やプログラミングに対する苦手意識はあまりないのですが、開発環境を作るための環境を整備したりする必要はすべからく全てのエンジニアに求められるスキルです。

あらゆるライブラリはバージョンが違うだけですぐに動かなくなるのが常です。設定ファイルの置き場所が変わっていたり、なぜか相性が悪かったり、原因は様々です。エンジニアがまずやるのはそのエラーメッセージで検索することです。しかし、同じエラーメッセージでも原因が違い、自分の環境には当てはまらないこともありますし、当てはまる場合でも、多くは英語で書かれている場合が多いので読み飛ばしてしまう場合もあります。最終的に本家本元のドキュメントを読みに行く場合でもやはり英語なので、読み解くのには労力が入ります。

同じ環境を構築しようと思っても少しの違いで動かなくなるので、毎回環境構築は怖いのです。

 

第2位 レビュー

エンジニアはお互いの作業が正しいかどうか、リリースに足る品質かをチェックし合います。これがレビューです。このレビューほど頭を使うものはありません。

そもそも、他人がやっている仕事がどういうものかを十分に理解しなければレビューなんてできません。そこから把握する必要があるわけです。時には、ソースコードを読むだけでなく、自分の環境で動かして見たり、直接聞きに行くなどして背景を把握します。それだけでもそれなりの労力だと言えます。

加えて品質についても担保しなければいけません。テストが十分に書かれているか、コーディングガイドに乗っ取っているかなども大事な要素です。先輩のレビューをするときも、自分が試されているような気がしますし、あえて指摘が必要なプルリク(レビューを出すために作る)を出してくるかもしれません。後輩のレビューをする場合でも、やはり自分の環境に持ってきて、うまく動くかどうかをチェックする必要がありますし、「あれ?」と思ったところを修正して実際に動かしてみるまでは指摘なんてできないので時間がかかります。また、いかに相手を深いに思わせず、気持ちよく修正してもらえるかというコミュニケーション能力も必要です。デール・カーネギーの「人を動かす」も読んでおく必要があります。(半部冗談・半分本当)

自分のエンジニアとしてのレベルが一番分かるのがレビューだと思います。それゆえに苦手なのです。

 

第1位 デプロイ(リリース作業)

映えある第1位は何と言ってもデプロイでしょう。新しく機能を追加したり、バグを修正したりしたあとは、本番環境に反映させなければいけません。そのためには様々な手順を踏む必要があり、その一連の作業のことをリリース作業と言ったりします。本番環境に反映させる前には諸々の前作業があったりするわけです。そしてそれらが一通り終わり、実際に本番環境にソースコードを反映(展開)させるのをデプロイと言います。(厳密には違うかもしれません。この業界は用語の使い方に厳しいので優しい目で見てください)

この作業は、基本的に単純作業で、一度身につけてしまえばスキルの上達はありません。しかし、本番環境に反映させるということは、それだけ不具合が発生したり、負荷が高くなってしまってサーバーが落ちたりする確率が高いということです。そのため、一瞬たりとも気が抜けません。

不具合があれば、サポートとも連携を取らなければいけませんし、どの修正で不具合が発生したのかを見極め、適切に対処しなければいけません。必ずしも自分の修正した箇所のみをリリースするとは限らないため、日頃から、どの人がどのような作業を行なっているかを大まかに把握し、発生したエラーから修正してもらうべき人に連絡する必要があります。取り返しのつかない不具合であれば切り戻しを行う必要も出てきます。その判断力も必要になってきます。

デプロイ作業はエンジニアリングのスキルとは別の総合的な人間力が試される作業と言って良いでしょう。

一番精神的に疲弊する仕事がデプロイと言って過言ではないと思います。エンジニアでデプロイ作業を好んでやる人はあまりいないのではないでしょうか。

 

いかがだったでしょうか?(久しぶりにこのフレーズ使った!)Webエンジニアの生態が少しは垣間見れたのではないでしょうか。

私たちは、どんな手強い環境構築にもめげず、どんな鋭い指摘にも動じず、多発するデプロイ時の不具合にも平常心を保てるエンジニアを募集しています!

We are hiring!

いけてるベンチャー起業の技術ブログならこうなりそうですが、私は一個人なので、残念ながら募集はしません悪しからず。

逃げ恥にみる現代の結婚感

逃げ恥(逃げるは恥だが役に立つ)が好調だ。

ここ数年リアルタイムでドラマを見ることがなかったが、久しぶりに毎週見るようになった。今クールは「家政婦のミタゾノ」など久々に当たりの多いクールではないだろうか。

※ ちなみに時間が合えば、「警視庁 ナシゴレン課」も見ている。察しが良い人は気づくと思うが、古田新太が好きなようだ。

 

私も仕事ではエンジニアをしており、平匡さんと同じくデータベーススペシャリストの資格も持っているので、非常に共感をもって見ていた。

 

最初は「契約結婚」という名の下で一つ屋根の下に共同生活。しかし、一緒に生活している間に、お互い惹かれあっていく。

私は、これが人間のあるべき姿だと思う。

世間では、恋愛恋愛と言うがそんなものは幻でしかない。結婚は現実である。その現実の中で惹かれあってこそ本当の愛である。最初好きではなかったとしても一緒にいるうちに好きになるのである。

この世界の片隅に」でも、主人公のすずは一度しか会ったことのない、結婚するまで忘れていた男性と結婚をした。最初は新しい環境・家庭で慣れていなかったが、夫を愛するようになった。幼馴染である哲と夜にそのことを語るシーンでは見ている人は皆安心したことだろう。観客はすずが嫁いで幸せなのかどうかがずっと気になっていたのである。

 

話を戻そう。

恋愛。恋愛をすると感情が高ぶってしまう。これは非常にストレスフルなことである。エネルギーを使う。結婚は日常。恋愛で日常を過ごすことはできない。

※ だから恋愛結婚は離婚率が高い。

 

ドラマでは雇用主と被雇用者という関係で2人は生活を始める。いたってドライな関係だ。主人公である森山みくりは仕事が見つからずやむを得ない形で給与をもらって家事をする。しかし、まさしく、ドラマのタイトル通り、“逃げ”で契約結婚をして結果的に幸せを掴み取る。

今は自由恋愛の時代だから、付き合う前からこの人は違う、あの人は違うとあれこれ理由をつけて恋人を作らなかったりする。もし彼氏・彼女がいなければ“逃げ”でも良いから無理にでも付き合えば良い。そこから幸せにたどりつけるかもしれないし、ダメだったら別れれば良い。

 

ただし、平匡さんのように高収入・イケメンのハイスペック男性は皆無と言って良いので、異性に期待をしてはいけない。感情の高ぶりをまったくせずに付き合うのである。そこから見えてくるものもある。

 

逃げるは恥だが役に立つ」は私の恋愛・結婚観に近いドラマだ。これまでの恋愛ドラマとは一線を画す。驕った言い方をすれば、ようやく世間が私に追いついたと言えるかもしれない。 

 

今は結婚の形は多様になってきた。

私の知り合いには、ネット上で堂々と結婚相手を募集している人もいる。

契約結婚と言わないまでも、なんとなく安心したいから結婚したいとか、ただ1人でいるのが寂しいから結婚するだとか、現場の最前線でバリバリ働くのが嫌で家庭に入りたいという理由で結婚するのも良いだろう。

そもそも元来結婚というのは恋愛して結婚するという形では必ずしもなかった。文明が始まる前であれば、ムラの中で丁度良い年頃の男女がいれば結婚をするしかなかった。それがムラを守るために必要なことだった。

そろそろ恋愛結婚から脱する時期に差し掛かっているのではないだろうか。

誰も笑顔にしないクラウドソーシング

Welqの問題が発覚して、各キュレーションサイトで記事の非公開がさかんに行われている。中には一時的に非公開にし、精査をした上で再度公開する場合もあるであろう。とは言え、こうしてインターネットの情報からゴミ情報が消えていくのは非常に良いことだと思う。

www.nikkei.com

headlines.yahoo.co.jp

これらのニュースによると、キュレーションサイトの記事の非公開化は、記事のコピペだけでなく、画像の不正使用などもあるという。

昨年、東京オリンピックの盗作問題も大きな社会問題化したが、今回の騒動もそれに続く系譜だと思う。情報が速やかにアクセスできる現代では、自ら創作をするよりも、コピペしてしまった方が手っ取り早い。しかも、自分でやるのではなく、クラウドソーシングで格安で雇った人に作業をしてもらうことで、低価格で記事を量産する。記事の内容ではなく、SEO対策などのポイントをきちんとおさえて書くようにライターに指示をすれば、どれだけでたらめな内容でもGoogle先生は良質なサイトだと判断して検索結果を上位にしてしまう。

キュレーションサイトは、Googleの弱点を逆手にとって自サイトの検索結果を上位にし、アクセス数を荒稼ぎする。そこには世の中を良くしようという理念もへったくれもない。自分たちだけが良ければ良いという人たちなのであろう。

 

今回の一件で各社の対応を注視していたが、クラウドワークスは一枚上手だと思った。

クラウドソーシングサイトの大手2社といえば、ランサーズとクラウドワークスだ。今回、ランサーズは、ランサーズ経由で採用されたライターも信憑性の低い記事を大量生産させてしまったとして、品質向上委員会を設置し、管理体制の強化を行うという。

japan.cnet.com

一方、クラウドワークスの対応は違った。

私も以前、少しクラウドワークスを利用する機会があったのだが、先日のクラウドワークスからの連絡には大変驚かされた。

なんと、記事の信憑性に関する問題があるということで、監修者を紹介するというのだ。

自分たちで駄記事を大量生産させる仕組みを作っておき、そして自分たちでお掃除をする。今回のような事態は、クラウドソーシングサイトが存在しなければ起きなかったことであるから、まさしく、「自分の仕事は自分で作る」を体現したと言える。

しかし、クラウドワークスの理念は『「働く」を通して人々に笑顔を』である。

今回の一件で誰が笑顔になっただろうか。嘘八百を並び立てた記事をインターネットの大海に撒き散らして閲覧者を騙した。一番問題があるのはいうまでもなく、キュレーションサイトの運営者であるが、運営者にも笑顔を届けられなかった。直接的な問題となっていないサイトの運営者にも、過去の記事をチェックして問題のあるものは非公開にするという余分な仕事を増やしてしまった。

笑顔になったのは、ライターを仲介し、ゴミを除去するための監修者まで紹介することで手数料を取るクラウドワークスだけであろう。

その監修者がクラウドワークスで受注したとしても、監修した記事で何か問題があれば責任を取らされるだろう。「運営者には問題はありませんでした。監修してもらっていたので、監修者の責任です」こう言い逃れするために利用されるのであろう。発注者の品格には十分に気をつけるべきだ。

ランサーズのように過ちを認め、謙虚に品質向上に努めるのであれば、まだ許せる。しかしクラウドワークスはこうした自分たちが犯した問題ですらビジネスに変えようとする。それは商売人としては良いかもしれないが、倫理的には少なくとも私は許さない。

 

私は、クラウドソーシングというのは、働き方のバリエーションを増やすという意味では良いことだと思う。しかし、それは、発注者の働き手への敬意があってこそ成立するものだと思う。

実態は、格安で駄記事を量産するプラットフォームでしかなかった。ライターだけではない。エンジニアに関しても同様の場合があるということは、288日前に経験者が語ったブログが有名になったことからも伺える。今読み返せば、このブログの作者も今回の問題を予見していたように思える。

 

もうクラウドソーシングでお金を稼ぐという幻想はやめた方がいいのではないだろうか。誰も笑顔にならない仕組みなど存在する価値はない。

もしそれでもクラウドソーシングサービスを運営し続けるのであれば、品質が向上しつづけるために不断の努力を行うべきであろう。それは、クラウドソーシングサービス経由で生産された記事の品質だけではない。発注者の品質、発注内容の品質も含まれる。受注者は言わずもがなだ。安易に低価格の案件を受けるべきではない。そして、そうした案件は運営会社が積極的に削除していくべきなのだ。そうしないとまた同じ過ちを犯してしまう。

 

今回の件で、Googleの検索の弱点とクラウドソーシングサービスと発注者の低品質が招いた誰も笑顔にしない世界の扉を、ようやく開いたといえよう。クラウドソーシングで笑顔になれなかった人は積極的にその扉をくぐってみるのも一考であろう。