読者です 読者をやめる 読者になる 読者になる

とある元SEの思考を探る

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

スポンサードリンク

エンジニアがもつべきは「思いやり」ではないだろうか

オピニオン

最近、常々思うことがあります。

Webエンジニアに必要なのは、思いやりなのではないだろうかと。

 

エンジニアはつねに改善するように常日頃から心がけることが必要な職業です。だからこそ、エクストリームプログラミングスクラムといった手法が考案され、実行されているのだと思います。

スクラムのふりかえりには、KPTといってよかったこと(Keep)、問題点(Problem)、改善したいこと(Try)を振り返ります。社会人1年目が習うPDCAサイクルを回すといったことに近い事象でしょう。

その中で、今日は、思いやりにかかわるWebエンジニアがやるべき3つのことを述べたいと思います。

 

1.テスト

エンジニアはテストを書きます。これは、昨今は当たり前となっていることです。「テスト書いてないとかお前それ@t_wadaの前でも言えんの」などと言われるこのご時世。テストのないシステムは、自ら破滅へ向かいたいのかと言わんばかりの自殺行為とも言えます。

しかし、中には様々な事情をつけて、テストを書きたがらないエンジニアもいます。その理由は様々です。「リリース優先で時間がなかった」「動作確認しているからテストはいらない」などやらない理由はたくさん出てきます。

私は、テストは必ず必要なものだと思います。いちばんの大きな理由は、このシステムが自分の手から離れたとき、後から参画するエンジニアの開発効率に大きく影響するからです。

テストは、いわば仕様書といって過言ではありません。後から参画するエンジニアは業務要件がわかりません。ソースコードを読んだり、業務がわかるエンジニア、サポート、経理等々に聞いて要件を理解していきます。その大きな手がかりとなるのがテストです。不具合があって初めてコードを見るということは良くあります。その時にそのケースが事前に考慮されていたものなのか、意図したものなのかということは、理解する上で、そして修正する上で大きな手がかりとなります。意図しているのであれば、そもそもの実装が間違っていたということですし、意図していないのであれば単純に考慮漏れということもありうるでしょう。それを開発した前にいたエンジニアがどこまで考慮したかを知ることは、当時の開発の様子を把握する上で非常に貴重な資料となるのです。

それだけではありません。多くのソフトウェアは、常に修正が繰り返されます。後から参画したエンジニアは自分がした修正が既存の仕様を破壊していないかに常に気を配らなければなりません。自信を持てなければ、開発なんてできませんし、破壊しないようにするために冗長なコードが多数生み出されることもあります。そうすると、保守性が著しく低下し、同じ内容の修正をしなければいけない箇所が複数存在して不具合の温床となります。後世のエンジニアが自信をもって機能開発するためにも、テストは必ず必要なものなのです。

テストに関して、必要性を2つほど述べました。まだ他にもあると思いますが、一旦ここまでにして、この2つに共通することは何かを考えてみます。

それは「思いやり」です。最初に作った人がいなくても、後から入ってきたエンジニアは、テストによって仕様が理解でき自信を持って開発ができます。会うかどうかわからない人に思いを馳せ、テストを書くのです。

なぜソフトウェアを開発するのでしょうか?それは、ユーザーに価値を提供するためでしょうか?私は、違うと思います。いっときだけ価値を提供すれば良いのではありません。ソフトウェアによって、ユーザーに価値を継続して提供し続けるのです。いっときであれば、なにもシステム化する必要などないのです。ユーザーに価値を提供し続ける。これが、経営陣も望むことでしょうし、ユーザーが望むことでしょう。それこそが私の思う思いやりです。

 

2つ目は、コードの品質です。

私が仕事で使っているRuby on Railsであれば、Rails newと同時に行うことの一つにGemfileにrubocopを入れ、.rubocop.ymlを置くということがあります。rubocopは、コードの静的解析をしてくれ、コードに改善すべき点があれば、指摘してくれます。また、CodeClimateというサービスを使ってソースコードの品質を評価してくれるサービスもあります。こうしたツールを使うことで、テストコードと同様に不具合の芽を摘むことができます。品質が良いコードというのは、保守・運用性に優れたコードであるとも言えます。

こうしたツールを利用することは、技術的負債を後世になるべく残さないようにという意図が明確になります。ソースコードは生まれた瞬間から多かれ少なかれ技術的負債となります。それをなるべく軽減しようとする意識は、後から参画したエンジニアからみれば、とてもありがたいものと言えます。

例えば、100行ぐらいあるメソッド(関数)と遭遇したらどう思うでしょうか?

1行に1000文字ぐらい書かれていたらどうでしょうか?

if文が10回ネストされたコードを見たらどう思いますでしょうか?

それを見た瞬間にまともなエンジニアならば拒絶反応を起こすと思います。これを書いた人は、これを読んだ人がどう感じるかを考えなかったのだろうかと思ってしまいます。

上記に挙げたツールでは、こうしたとんでもないコードに対して警告を発してくれます。静的な解析であるにせよ、警告は、統計的に不具合が起こりやすかったり、保守・運用性の観点から一般的に許容されない箇所に対して行われます。

後世のエンジニアが読んで拒絶反応を起こさないようなコードをを書くためにも、品質を向上させるためのツールの利用は、リポジトリを作成した直後から利用する必要があるでしょう。これも思いやりがあれば、自然と行うことでしょう。

 

3つ目は、コードレビューです。

信じられないことに、世の中には、コードレビューなしでリリースされるコードがまだまだあります。

第一に言いたいのは、エンジニアはコードレビューなしでリリースしても良いと絶対に思ってはいけないということです。エンジニアとはそういう職業ではありません。人間は間違える生き物です。それは古今東西当てはまる真理です。

そうした前提に立てば、その間違いをいかに最小限に留めてリリースをするためには、コードレビューは不可欠です。前述のテストコードを書くことや解析ツールを利用することも間違いを未然に防ぐための方法の一つですが、コードレビューも同様です。静的解析では発見できないミスや業務知識が必要とする箇所などは、レビューによって発見しえます。

そして、コードレビューにおいてもう一つ重要なのが共有です。システムは1人で作るものではありません。自分のプライベートなプロジェクトである場合を除き、システムは複数で作り上げるものです。コードレビューをすることで、知識の共有することができます。

エンジニアの中には、1人で作り、他の人に共有しない人がいます。いわゆる属人化です。これはエンジニアに限った話ではないかもしれませんが、仕事を他人に教えず自分しかできないようにして自分の存在意義を高めようとする人は一定数います。そうした属人化は、百害あって一利なしです。もし、1人しかできない仕事だとしたら、その人がいなくなったらどうなるでしょうか?その業務が滞ってしまいます。それは会社にとっては大きなリスクでしかありません。そして、そのような社員はそうしたリスクを考慮しないという点でプロとは言えません。プロフェッショナルは常に様々な状況に対応できるように準備をします。その一つが業務知識の共有であり、エンジニアにとってはコードレビューがその形態の一つです。

人は突然いなくなります。交通事故かもしれません。急に病に侵される場合もあるでしょう。身内の突然な不幸で、1週間出社できないということもあるでしょう。本人が健康でも、他のことで仕事に打ち込めない場合は十分に考えられるのです。

共有ができていれば、仕事ができる状態であっても、他のタスクで手一杯で、他のメンバーの方が余裕があるのであれば、その人に任せることも可能になり、より柔軟なチームを作ることができます。

これも全て「思いやり」があれば容易に想像ができることです。会社への思いやり、経営者への思いやり、突然任されることになるかもしれないまだ見ぬあなたへの思いやり。

 

エンジニアは、すべからく「思いやり」を持つべきだと私は思います。

それがエンジニアとしての矜持なのではないでしょうか。

自分への自戒も込めて。

 

本日も、ここまでお読みいただき、ありがとうございました。

新しいことを学ぶのが怖い

2月は全く記事を書きませんでした。おそらくブログを始めて2年、初めてのことだったのではないでしょうか。

仕事もほどほどに忙しく、仕事外もほどほどに忙しかったためまったくブログを書くモチベーションがあがりませんでした。

ここ一ヶ月は3つぐらいのことを同時並行で進めていました。

 

一つ目は確定申告。去年は前職にいるときに会社以外の仕事もしたりして、10万円ほどの売り上げが立ったので、確定申告をしようと思います。医療費控除は毎年やっているのですが、今回のケースは初めてなので、支払調書をもらったりして少し時間がかかっています。幸い母は経理、姉は地方公務員、親戚筋に会計事務所勤務の人がいるので、助けてもらえます。

 

二つ目はDeepLearning。ゼロからはじめるDeepLeaningという書籍があるのですが、CTOが買ったからやろうとチャットで募集し、「僕も買ったのでやりましょう」と安易に返事したところ、週に2回やることに。しかも担当制なので、自分の担当の時はそれなりに読んでから出ないといけません。CTOはAndrew NgのMacineLearningのコースを一通りやり終えたらしいので、大学での専門が電気化学の私にはつらいメンバーでの勉強会です。とは言え、教えてもらえる環境にあるのはありがたいことなので参加しています。

三つ目はReact.jsを勉強です。

React.jsは1年以上前からできるようになりたいと思っていて、ES6ですらすら書きたいと切に思っていたのですが、ほとんど進捗していませんでした。厳密に言えば、React.jsのチュートリアルは2016年の正月に写経したり、昨年の10月にも改めてやっていたのですが、なかなかに理解したという気分になれませんでした。

ここまでくると、数を打つしかないと思い、インターネット上にあふれているReact.jsのサンプルを5つぐらい写経してみて、ちょっと分かり難ところは紙にも書き出して理解するようにしました。

それが2月の2週目。仕事から帰って夜はなかなか時間がとれないので、通勤電車の中でパソコンを開いて作業するなどして、時間を捻出しました。

 

ひとまずの最終的な成果として、このようなものを作ってみました。

独りよがりになると良くないので、jsの神と呼ばれる知人に食事をご馳走してレビューもしてもらいました。初めてのReact.jsなのでなかなか修正箇所が多かったですが、とても勉強になりました。

ひとまずはそれなりに人に見せれるレベルにはなったのではないかと思います。今後はきちんとテストを書いたり、Reduxを使ったりしていきたいと思います。また、サーバーサイド側との連携(データを永続化するなど)も予定してRailsに乗っけてあるので、そのあたりもやれたらいいなと思います。

 

私は、新しいことを学ぶのが非常に怖いです。分からないことを学ぶということが怖いのです。

そのため、React.jsの勉強にもここまで放置してしまいました。

しかし、Webの業界にいると、新しい技術に対して誰よりもいち早くキャッチアップし、サンプルアプリをサクッと作って記事を書けてしまうような人がたくさんいます。そういう人に対して、私は劣等感を抱かざるを得ません。やはりスピード感が圧倒的に早いです。

今、Webエンジニアといえば、以下のようなスキルセットを持つ人が当たり前となってきています。*1

  • Railsができる
  • ES6を使ったモダンなJavascriptが書ける
  • React.js, Angular.js, Vue.jsといったフレームワークを使いこなせる(正しく設計ができる)
  • ファイルの構成や管理も正しくできる*2
  • もちろんjQueryなども対応でき、各ブラウザごとの違いも把握している
  • Swiftなどを使ってネイティブアプリが開発できる
  • ユーザーやお客さんからの無茶な要望にも笑顔で対応して即日リリースできる
  • AWSのサービスを組み合わせて機能を開発できる
  • ネットワークの知識もあり、オフォスのネットワーク設計等もできる
  • OSSの開発にも貢献し、フレームワークの高速化等もできる
  • etc...

こうしたWebエニジニアが当たり前に求められる時代になってきました。私はかろうじてRailsができる程度なので、周りを見て成長の早さに焦らずにはいれません。

特に新ことを学ぶことに対して異常なまでに抵抗を感じるのですから、変化の激しいこの世界で生きていけるかが不安になる日々です。

日々是精進ですが、なんとか精神を保ちながら生きている日々です。

 

もう少し気軽に新しいことに挑戦できるようフットワークを軽くしていきたいです。

*1:インフラやサーバーサイドのフレームワークなどはそれぞれ異なっているかもしれません

*2:トランスパイルしたファイルをgit管理しないなどは当たり前で、その場合、デプロイ時にトランスパイルを走らせる必要があるがそうしたjsのエコシステムも詳しい

掲げた理念とは異なる社内を月間総務の記事から垣間見た

月間総務を見ていたら、こんな記事を発見。ピクスタという、インターネットで写真やイラストの売買ができるサイトを運営している会社の人事部長のインタビュー記事だ。

【総務の現場から】ベンチャーから上場企業への成長を 人と組織作りから支える戦略人事 - 月刊総務プラス | 月刊総務オンライン

ピクスタは、比較的低価格で写真やイラストを購入できるので、私が勤めている会社でも利用している。また、2年ほど前に株でもやってみようと思ってマネックス証券のマイページにログインしたときに、IPO株を募集していたので記憶に残っていた。SIerからの転職しようとした際にも考慮に入れたことがある会社だったので、多少の企業研究もしていた。

 

この月間総務の中でおどろいたフレーズがあった、

制度ルール面では、フラットにやっていた意思決定の在り方や、情報の流れを見直し、会議体などの全体設計をした。 

 の部分だ。つまり、ピクスタ内部はフラットではないということらしい。

ところが、私のかすかな記憶ではピクスタの企業理念は

インターネットでフラットな世界をつくる

出典:企業理念|ピクスタ株式会社

だったので、フラットな世界を目指しつつも、会社の中は上意下達・ピラミッド型なのだろうかと訝しく思った。要するにダブルスタンダードなのではないかと。「インターネットでフラットな世界をつくる」に共感して入社した人は社内もフラットであることを当然期待するであろう。しかし、入社するとその実はピラミッド型だったとしたらどう思うだろう。理念として「フラットな世界をつくる」を掲げるのであれば、社内もフラットにしていくべきであろう。

そういう意味で、この月間総務は理念は「インターネットでフラットな世界をつくる」だけれども「社内はフラットではなくピラミッド型」であるということを明確にしたという点で、ピクスタに転職を考えている人にとっては有意義な情報であろう。人事部長自ら述べているのだから間違いない。

 

フラットにやっていた意思決定をやめながらも

自律自走できる人材を評価

するとある。 そういう人材を求めるなら、意思決定も積極的にフラットにしていくべきだろう。事業責任者のみならず、一社員にも経営上の意思決定に関わらせるべきであろう。ここに歪んだ組織設計を垣間見てしまうのは私だけであろうか。

経営陣が決めたことを現場の社員が意見も言えずに淡々と職務をまっとうする。そんな社風を想像した。

 

また、目安箱に関するくだりで

回答は、ほかの経営陣に共有されたいか否かを選択でき、されたくなければ私のところで止まるようになっています

とある。これは人事部長が全情報を掌握するということを指している。人事部長に知られたくな場合はどうすれば良いのだろうか。情報を1人だけが持つというのは、企業にとってはリスクだ。良い情報であろうと悪い情報であろうと、である。もし仮に人事部長が不慮の事故で仕事ができなくなった場合を仮定してみれば容易に想像がつく。これはどの場面でも同じだ。2、3人のスタートアップなどの特殊の場合を除き、情報はなるべく複数人で共有しておくべきである。なので、人事部長は見れないけど経営陣には見えるというルートもきちんと作っておくべきであるが、その辺りはどうなのだろうか。このインタビューを読む限りでは、人事部長が情報を掌握する構造が想像できる。

 

最近、How Google Works という本を読んだ。そこには企業組織がどうあるべきかについて、

組織はフラットに保つべきだ

出典:How Google Works p68

 と書かれている。本書でいうスマートクリエイティブは、仕事をやり遂げるためにトップの近くにいたいと思うとある。意思決定者と直接折衝する必要があるからだ。

また、

組織は機能別にすべきだと考えている

出典:How Google Works p70

ともある。冒頭の月間総務の記事では

組織の骨格は、機能別組織から、事業部別組織に変更

したそうだ。How Google Worksでは、

事業部制にすると、それぞれの事業部が自分のことだけを考えるようになり、情報や人の自由なが流れが阻害され

出典:How Google Works p70 

てしまうとある。もちろん、Googleのやりかたがすべて正しいわけではない。ただ、YoutubeをはじめとしたGoogleのプロダクトによって「インターネットでフラットな世界をつくる」に貢献している代表的な会社といって良いであろう。(もちろん「インターネットでフラットな世界をつくる」はGoogleの理念ではないが)

その点からもピクスタにとってGoogleの組織は参考になる部分は大きいのではないだろうか。(余計な御世話だと思うが・・・)

 

理念を声高に掲げる企業の中には社内がその理念に従っていない場合がある。むしろ、社内でできていないからこそ、わざわざその理念を掲げなければならないのかもしれない。今回の事例はその例なのかもしれない。

 

今回、ピクスタという一企業の組織について月間総務の記事とコーポレートサイトの情報を元に考察をしてみた。現在、一ユーザーであるという程度の関わりでしかない私がここまで書くのはピクスタというサービスがなくなってしまうと、私の会社の事業にも少なからず影響を与えることになってしまうからだ。できれば末長く続けて欲しいという思いで、少ない情報から垣間見える問題について述べた。本当に余計な御世話であるのは重々承知している。

少ない情報なので、中で働いている人の印象は異なるかもしれない。素晴らしい会社なのであれば私の指摘は単なる杞憂に過ぎないし、上で述べた指摘がある程度的を得ているのであれば、それは改善すべき点なのだと思う。

 

※ あくまで、月間総務とコーポレートサイトという少ない情報源からの推測なので、事実とは間違っている可能性も十分にあります。その2つの情報源からこのように考察できうるというのも事実であるのでこの記事を書かせていただきました。