2019年9月の所感

もう10月も中旬ですが、2019年9月の所感についてです。 仕事へのモチベーションが下がりつつあるので、適当な表現になってしまうかもしれません。

会社

あまり覚えていないのですが、、、 2〜3ヶ月くらい対応していたプロジェクトがリリースされました。 リリースされてからは大きなバグも見つかっていないのでよかったです。

フロントの大きな開発は初めてだったのですが、本当に苦労しました。 バグなのか?みたいなことも多くあり、またAPIと違ってブラウザごとの挙動の違いなどの対応をしていくうちに、フロントはやっぱり面白くないなぁと感じることが多くて少し悲しかったです。 まぁ詳細は今回は省きます。

上記のリリースが9月中旬くらいだったのですが、そのあとはAPIの小さな開発をいくつか対応しました。 まぁそこに関しては特記することもないです。 少し言えることとしては、テストコードを書く文化がない現場でしたが、私がテストコードを書くよう(今は私だけ)にしたので、そこで勉強になることがいくつかはありました。

APサーバを作り変える対応については、今まで私中心で進めていたのですが、急に上司からトップダウン的に対応が降りてくるようになりました。 よかったのか悪かったのかというと微妙ですが、動き出したことはよしとします。

が、最初上司から「新しいAPIサーバはPythonに決めたから」みたいに言われたときはイラっとしました。 実際にコードを書いているのは私たちなので、その辺りは相談しながら決めたかったので。。。

その次に急にNode.jsにしようと思うとも言われました。 が、そこは悪い判断だとは思わないですし、まだ一緒に決めていこうみたいな感じになったのでヨシとします。

個人的にはKotlinがかなり良いと思っているので、そこで推していこうかなと。

プライベートでの活動

参加した勉強会。

  • 8/29 JAWS-UGコンテナ支部#15
  • 9/3 kiitok 採用市場でモテるエンジニアとは
  • 9/6 JJUG ビール片手にLT大会
  • 9/20 JSUG AWSとspring

色々と感じることはありましたが、時間が空いてしまったので、、、 そろそろLT登壇したいなと思いました!

その他読んだ本

SQLパフォーマンス詳解、かなり良い本でした! インデックスについての話が多かったのですが、どういう仕組みなのか、パフォーマンス上、何が問題となりえるのかがわかりやすくてよかったです。

10月に身につけたいこと

Javaと向き合いたいです。 出来ればOSSにコミットしてみたいのですが、どれが良いか悩んでいます。

引き続き仕事で成長できていない危機感があって辛いです。

2019年8月の所感

まだ終わっていませんが、2019年8月の所感についてです。

8月

お盆休みもあったので、8月は前半、後半とせず1つにまとめます。 当初の予定では、8月前半は先月に引き続きインフラ設計とアーキテクチャ選定を行っていく予定でしたが、ほぼ着手できませんでした。 先月の前半に私が開発していた機能のテストが開始され、かなり多くのバグが見つかりましたのでその対応をほとんどしていました。

本来であれば、8/13〜8/16の期間はお盆休みだったのですが、お盆休み明けに社長に今回作成した機能を見せるからということでバグ対応のために2日ほど出社して対応もしました。 バグが出たのは私のせいなのですが、ある程度動く状態かつ、実際のリリースは1ヶ月後であるにも関わらず、社長に見せるからという理由でしかもそれを休みの直前に伝えて出社しなくてはいけなくなったという判断に納得が行きませんでした。 社長に見せるからどうしても直さなくてはいけないのであれば、もっと早くからその判断をしていれば、休日出社しなくても修正は完了出来ていたと思いますし、そもそも社長に実際のリリースは1ヶ月後であるということを伝えて今はまだバグがあるということが伝えられる関係性を作れていれば出社する必要はなかったと思います。

私は休日出社や夜間対応をしたくないというわけではなくて、本番障害対応などであれば積極的に関わりたいと思っていますが、そうではない社内政治的な理由や非効率な(無駄な)やり方に納得が出来ないということを強く感じました。 正直今の会社の、ベンダーさんが発言力がある組織になっていたり、非効率なことが多くあったりと自分にとって納得出来ない部分が多く出てきていている状況です。 色々と改善しようと例えばAPサーバを作り変える活動など動いている部分はありますが、制御出来ない部分の方が多くて色々と不満が溜まってきているかもしれません。

バグとしては、色々な種類がありますが以下のような理由が多かったのかなと。

  • APIの仕様理解不足
    APIによって同一目的のパラメータなのにパラメータ名が異なっていた、出力内容が異なっていたなど)
  • 既存のコード理解不足
    既存のコードが多重継承されすぎていて、よくわからない。
  • 単純にコードミス フロント側の間違えやすいポイントなど理解出来ていなかった。経験不足。JSのコード間違い。
  • 仕様が曖昧で認識相違 実装者(私)と要件定義者が異なるので、認識相違が発生していた。

色々と思うことはありますが、自分が気をつけていれば出なかったバグも多いと思うので、そこは反省する必要があるかなと思います。 と同時に、言い訳になってしまうかもしれませんが、既存の仕組みがダメな部分も多くあり、そこをどのように改善していくのかという課題があるのかなと思いました。

APサーバを作り変える対応について、初回で対応するスコープがあるプロジェクトに対してだったのですが、それがなしになってしまい、スケジュールも未定になってしまいました。 私の今のモチベーションはこの対応を行うことで、1日も早く着手したかったので、少し残念です。 ちょっと様子を見ますが、成長したくて転職したのに仕事で成長が実感出来ない日々が続いているので、ここの対応が遅れてしまうようであれば色々考えたいなと思います。 ひとまずは現状分析を改めて行うことになっています。

プライベートでの活動

まず以下の勉強会へ参加しました。

  • 20190807 Cloud Native Meetup Tokyo #9特別編 feat.Kaslin Fields
  • 20190814 Scramble! #3 FOLIO流 複雑なドメインとの戦い方

Cloud Native Meetup

Kubernetesについての内容が多く、勉強不足の状態で参加したので、内容的に身につけられた部分は多くなかったのかなと思います。 反面、Kaslin Fieldsさんの内容では、クラウド前提の色々なサービスについてわかりやすく説明いただけたので、色々と興味を持ちました。 特にTerraformについては、理解して利用していきたいと思います。今のインフラはコード化されていないので・・・

APサーバを作り変える対応では、コンテナ利用で考えているので、色々と勉強しなくてはいけない部分が多いのですが、今後もこのコミュニティについては ウォッチしていきたいなと思います。

Scramble! #3

EventStormingについての内容がメインでした。 こういった活動をしていきたいなと思いつつも、今の職場ではまだ早く、それよりも先にやるべきことが多くあるのかなと感じました。 具体的にはクリーンアーキテクチャやDDDを私自身が理解するのはもちろん必要ですが、同時に周りにも伝えていく、意識を浸透させるということが重要だと思うので、学びはありましたが、活用は出来ないかなと思います。

FOLIOさんではMVPを作るフェーズからKPIに向き合うフェーズへなってきているとのことで、EventStormingを活用し始めているとのことでしたが、今の職場も同様でKPIに向き合うべきフェーズなのに、KPIがない状態もしくはそれが開発者へ連携されていない状態で、組織としてのちぐはぐ感があるなぁと思います。 私個人としては、KPIを立てて開発者含めて組織として共有して、成長・成功しているという実感が欲しいです。 また、FOLIOさんではAPIごとにレイテンシを出力して常に見える状態にしているとのことで、すごく参考になるなと思いました。

私は社会人になってからずっと金融系のシステム開発に関わってきて、今回の転職では違う業種のシステム開発に関わっているのですが、改めて証券システムの開発って面白そうだなと思いました。 ドメイン知識を深く理解していないとシステム開発も出来ないので、システム開発の難しさがありそれが面白さになっていると思うので、もし機会があればそういったところに関わりたいなーと思いました。

言語・フレームワーク選定

その他はAPサーバを作り変える対応のためにいくつかの言語・フレームワークを触れてみている状況です。

現時点では以下のようなものを触りました。

  • Kotlin SpringBoot
  • Go echo
  • Node.js(TypeScript) Express

今後触りたいなと思っているのは、以下のようなものです。

  • Java or Scala PlayFramework
  • Node.js(TypeScript) Nest.js

少ししか触れておらず浅い理解ですが、簡単な所感を。 Kotlinについては、始めて触りましたが、前評判通り良い言語だなと思いました。 Javaで冗長に感じる部分が簡単にかける、immutable(val)、Nullセーフ、関数でかけるなどJavaからKotlinに変えるだけの理由は十分にあると思います。

Goについては、シンプルな言語でわかりやすいし、デフォルトでフォーマットやテストがあり良いと思いました。 しかし、言語として用意されていないもの(例えばRound系)がいくつかあったり、フレームワークデファクトスタンダード的なものがあまりないのかなと思いました。 開発力が強い組織であれば採用して良い言語だと思いますが、今の現場で採用するには難しいかなと思いました。 すごく残念です。

Node.js(TypeScript)・Expressについては、確かにフロント側に慣れている人にとっては良い言語だろうなと感じました。 TypeScriptは型があるので、動かさなくてもある程度チェックしてくれて便利だと思います。 しかし、Date型がないとか、ORMの種類が少ないとか、大規模なシステムでがっつりサーバーサイドで採用となるとまだ難しいのではと思いました。 Expressについても薄いフレームワークすぎて、色々と作りこむ必要があり、難しいなと言う印象です。

Nest.jsを触りたいという理由は、Expressよりも充実していると思われるので、BFF前提で採用できるかもなぁと思っているからです。 今、フロントで新しい機能はAngularで作っていて、既存機能も作り替えようとしている中で、BFFもそれに似たNestにすることで効率的に開発できるかなという意図があります。

PlayFrameworkは念のためという感じです。 今のJavaであればSpringBootほぼ一択かなと思うのですが、色々社内的に言われているので・・・ もしくは最近出てきたフレームワークでもいいかも。

9月に身につけたいこと

あまり見えてこないです・・・ とりあえずは色々な言語・フレームワークを触って技術選定すること。 あとはDBはそのうち勉強しようと思っていたのですが、今なにすべきかわからない状況なので、先に勉強しようと思います。 SQLパフォーマンスについて理解できればなぁと思います。

入社して半年が経とうとしていますが、先が見えてこない不安が・・・

2019年7月の所感

ちょっと時間が空いてしまいました。 2019年7月に職場・自宅で取り組んだことと、いくつかの所感についてまとめておきます。

7月前半

7月前半は6月から続いていたフロント側(主にJavaScriptPHP)の実装を主にしていました。

6月はタスク分解が十分にできておらず、なんとなく気になったところから実装みたいなことをしていたのですが、進捗が悪くだらだらと進めている感覚でこのままじゃいかん!と思い、7月に入ってから改めてタスク分解をして一つ一つ終わらせていくことで、かなり進みがよくなりました。

人ってタスクの粒度が大きすぎるとやりたくなくなっちゃうんだなーと。今まで自然にやっていたことがなぜか出来ていなかったのでタスクを細かく設定する重要性を再認識しました。

技術的な部分では、食わず嫌い感があったJavaScriptについて、まぁ書けるという状態になったなぁと思います。 普段はJavaを書いていたので、最初は設計どうするんだ?ファイル多くなるよね?いいの?クラスって・・・?みたいな状態だったんですが、もう気にせずJava風に書こうと思ってガンガンファイル作ってクラス(prototype)も書いてなんとか書くことが出来ました。 あとは直前で関数型プログラミングの本を読んだので、コールバック関数使ったり高階関数みたいなことはしてみました。 関数を変数に格納できるというのは便利だなぁという印象を受けました。

参考:JavaScriptで学ぶ関数型プログラミング

フロントを開発してみて改めて思ったことは、バックエンドの方が向いているなぁということです。 画面の開発をしていると、次から次へと気になることが出てきて、これも直したい。あれも直したい。という状態になってしまうので、いつまでも終わらないなぁと。 ある程度で妥協も必要なのだと思うのですが、私的にはある程度ゴールが決まっているものをかっちりと開発したいのかもしれないです。

あと思ったのは、フロント側が利用しやすいようなAPIを作らなきゃと感じましたね。 今回は既存のAPIを利用するのみだったんですが、なんで同じようなAPIで同じ検索条件なのにパラメータ名違うの!!(GAZOとIMAGEみたいな)とか出力結果に期待したものが入ってこない。みたいなことがありました。 なのでフロント側に見える透明性の高いAPIを作るべきだなと感じました。

7月後半

7月の後半も多少フロント側の開発をしていたのですが、それ以外ではAPサーバを作り変える件の対応を進めていました。

新しいAPサーバを作成するにあたって、具体的にどのような基盤のうえで動かすのかという部分を優先して検討中です。 いわゆるストラングラーパターンをちょっと意識しつつ現在設計中です。

今回はAWSでコンテナ(ECS)を利用して動かそうとしているので、AWSの勉強とコンテナの勉強をしているところです。

本を読んでEC2 立ち上げをやってみたのと、そのあと会社でCloud WatchとかECSとか1週間触り続けたことで苦手意識はほぼなくなりました。

参考:Amazon Web Services 基礎からのネットワーク&サーバー構築

IAMとかCLIの部分がまだ理解出来ていないので、これから身につけていこうと思います。

Dockerについても本を読んでなんとなくの理解は出来たので、これから構築する際にどのように構築するのがベストか検討していこうと思います。

参考:Docker/Kubernetes 実践コンテナ開発入門

アーキテクチャー選定なんて初めての体験で毎日成長出来ている感覚があるのですごく楽しいです。 先月までは成長出来ない環境に軽く憂鬱を感じていましたが、今はそれがやっと改善されました。

8月の予定

8月は引き続きインフラ部分のアーキテクチャ設計とアプリケーションのアーキテクチャ選定を行う予定です。 言語・フレームワークの選定なので一番美味しいところですね。 いくつかの言語について、お盆休みで試して評価していきたいと思います。

あとはチームで今後どうしていきたいのかとか考えながら、最適なものを選べればと思います。

7月に身につけたこと

  • タスク分解の重要性
    • なるべく一つ一つのタスクを細かくして作業している感を出すこと
  • 利用者にとって使いやすいAPIの重要性
  • AWSになれた
    • 色々触って苦手意識が現象
  • AWSWebサービスの公開
    • EC2ベースでVPC とかサブネットの設定をしてサービス公開まで出来た
  • コンテナの理解

8月に身につけたいこと

  • インフラ設計能力
    • ネットワーク構築や運用設計などを身につけたいというか身につけないといけないとと思います。
  • CI/CD環境の構築能力
    • なるべく自動化したいので、この辺りをもっといい感じでできるようなスキルを身につけたいと思います。
  • 言語選定基準を作る
    • 言語を選定するための方法論を身につけたいと思います。

自社サービスの会社に転職して4ヶ月の所感

初めましてワイサイです。

SIerから自社サービスを運営している会社(いわゆるWeb系企業)に2019年3月入社しました。転職して4ヶ月が経って色々と思うことがあるので気持ちの整理も兼ねてこの記事を書こうと思います。

成長のためにも今後定期的に目標や成長具合の確認、技術的な部分もQiitaに載せるようなものでもないものはこちらに記載していこうかなと思っています。

ちなみにQiitaアカウントはこちらになります。

 

転職理由

それまではSIerにいたわけですが、ユーザー企業の言う通りに開発するしかなくシステムに対してこうした方が良いのでは?と感じることがあっても改善出来なかったり、実装がよくないからリファクタリングしようと思ってもユーザーからお金が出るわけもなく対応出来ないなどの葛藤がありました。*1

また、技術的な要素でもプログラミングはオフショアが行うレベルの低いものという意識が根付いてしまっていて、全員PMを目指そうという考え方になっていました。 私自身将来的にPMになることは問題ないかなと思っているのですが、そのためにはある程度の技術力がないといけないと考えているので違和感を強く感じていました。

実際、コーディングのバグが多かったり可読性が低かったりして、開発に時間がかかったり手戻りが発生したりということがあり、このままではやりたいことが実現出来ない。エンジニアとして成長出来ないと感じて、自分が企画段階から口を出せてコーディングにも関われる成長できる環境へ転職しようと考えた結果、今のWeb系企業へ転職しました。

転職してからの成果

転職してからこの4ヶ月でやったことと技術的に経験出来たことをざっくりと。

以前の会社ではコーディングする機会が0だったので、1日の大半をコーディング出来る環境というのは大きいかなと思っています。 家でしかコーディング出来ていないと技術的な成長スピードが遅くなってしまうので、業務としてコーディング出来るというのは転職してよかった点だと思っています。 あとは以前まではオンプレ環境だったので、AWSを普通に使っている環境というのは成長出来る良い機会かなと思います。 クラウドの利点が実際に利用することで見えてきてオンプレでは出来なかったことややりにくかったことが出来るようになって、アプリケーションとして可能性が広がるなぁと感じました。 今後バックエンドエンジニアとして成長していくには、ここの理解は必須かなと思いました。

最近について

強い不安感

最近強い不安を感じています。 具体的には以下2つの観点で、当初4ヶ月くらいの自分に期待していたレベルに達していないと感じるからです。

  • 技術的な成長レベル
  • 中心人物になれていない

どちらの点においても定量的で具体的な目標値はありませんでしたが、漠然とした不安感が段々と出てきて最近ちょっと辛いです。 なのでここの不安を解消するために、具体的にどういう状況なのか、どう改善していけば良いのかをまとめておきたいなぁと思ってこの記事を書いています。

技術面での不安感 

上記二つのうちエンジニアとしては特に技術面での不安感の方が重要だと思うのでこちらから。

転職理由を改めて考えたいのですが、技術的に成長したいと思って転職してきました。 以前の環境では、Javaは6でフレームワークは独自のものでかつ、DI/AOPもなく、POJOでもないフレームワークにベッタベタでテストコードも書いていないような環境でした。

現在はJava8ですがラムダも一切使っていない、フレームワークSeasar2単体テストも書いていないという状況です。

環境だけだと若干現在の方が良い気もしますが、各人のスキル的には以前の環境の方が能力のある方が何人かはいたと思います。 今の現場だとトランザクションもまともに考えられてなかったり、SQLインジェクション出来てしまうようなロジックになっていたりなど正直エンジニアとして疑うスキルの方が多数でそこがすごく気になっています。

スキル面については、Web系企業の方は全員高いと考えていたので、転職したら尊敬出来る人のもと色々と教えていただこうと思っていました。ですのでこのような状態であることがかなりショックでした。*2

またそういう方々が書いたコードですので、可読性や拡張性が低いコードがそこら中に蔓延しています。 共通ロジックをスーパークラスで書いていて、しかもスーパークラスの中でサブクラスによって処理を変えるようなロジックもあったりとこれぞスパゲッティコード!!という状態になっていて笑えます。

その他、APIがフロントをガッチガチに意識されていたり、WebサーバにPHPを利用してAPIで返却した値を色々加工しまくっていたり、DBが正規化されていなかったりと気になるところは盛りだくさんです。

こういう状況ですので、新任者がキャッチアップに苦労したり、ちょっとした修正をするだけでも影響が大きくなりすぎていて対応に時間がかかったりとしている残念な環境になっています。

私がスーパーエンジニアであればそういった状況であってもすぐにキャッチアップして、改善する方向性についてすぐに決めて進んでいっていると思うのですが、残念ながら私にはそこまでのスキルがないので、躓いてしまって思っている以上にコードをかけていないと悩んでいるという状況です。

中心人物になれていない不安感

もう一つは中心人物になれていないという不安感についてです。 上にも書いたように今いるメンバーのスキル面があまりよくない状況なので、その方々が色々決めると技術課題を蓄積していくということから改善するためにも色々と口を出したいのですが、それが出来ていないというストレスがあります。

その理由としては、やはり目に見える成果をみんながわかる形で出していないこと、中途採用がすぐに活躍できる環境がないこと、最後は現状社員ではなく協力会社の方が中心で開発してしまっていることかなと思います。

目に見える成果を出していないというのは自分自身のスキル不足が原因だとは思っています。スキルがあれば渡されたチケットを予定よりも速く完了させてどんどん新しい課題を進めるということが出来たはずですが、それが出来ていないので・・・ ただこういった現場なので、可読性とか拡張性とか意識したオブジェクト指向なコーディグをするというよりは、手続き型な再利用出来ないような(同じようなロジックが至るところにあるような)コーディングを適当にコピーして書いている方が速くて評価されている感が若干あるので、自分だけのせいとも言えないのかなと思います。

中途採用がすぐに活躍出来る環境にないことというのは、どちらかというとのんびりした会社かつ、後述しますが社員の立場が低いので、中途採用であっても即座に中心にはなりにくいのかなと思います。 機会があるたびに自分から色々と口を出したりしていますが、あまり聞いてくれないのと、結局重要な打ち合わせに呼ばれないとか色々あるので、こちらもモチベーションが下がって余計言えなくなっているという感じです。 ここはなんとかしないといけないと思うので、上司と相談ですかね・・・

最後は協力会社の方が中心と言う話ですが、最近まで全ての開発を協力会社さんにお願いしていた状況で、今いる社員も新入社員から協力会社さんに教えていただいたような方なので、社員の立場が低く、技術的なことはすべて協力会社さんが決めているみたいな感じになっています。 ここは会社としても問題だとは多分思っていて、だからこそ私とか中途採用の人を採用してどうにかしようとしているのだとは思います。

今後どうするかどうしたいか

技術は自分で身につける

技術面ですが、他のすごい人から教えてもらうというのは難しそうなので自分で身につけていくしかないと思います。*3 ただし今のままの環境だと成長スピードがかなり遅いと思うので、色々と環境を変えていきたいと思います。

入社してから今のAPIを作り変えることを進言してきたんですが、入れ替えようって話が進み出したので中心となって大改革したいと思っています。

これが進めば技術的にも比較的新しいものを取り入れられるし、自分としても技術選定から立ち上げという重要なフェーズに関われるので成長できるかなと思っています。 *4

ただそこで得られる知識は浅く広くという部分だと思うので、深さをどこかで身につけないといけないなと感じています。 具体的には、デザインパターンなどを身につけて保守性の高いコードを理解したいです。 業務で身につけたかったのですが、独学になってしまうので、OSSを読んで身につける方法に切り替えたいと思います。

また、既存の部分についてはなるべく関わらないようにした方がいいかもしれません。 幸か不幸か協力会社の方々で保守していただいているので、新しく作る部分から関わっていった方が精神衛生的に良いと思うので。 それで許されるならですが、、、

中心人物になるのは諦める

正確にいうと諦めるというかタイミングを待つといった感じでしょうか。 新しくAPIサーバの作り変えがあるはずなので、一旦は既存の部分は無視して無理に関わらなくて良いかなと思います。 一人で変えられることは限られるし、私自身新しい部分に力を入れていきたいので、しょうがないと思うしかないです。

おそらく色々成果を出し続けて入ればそのうち中心人物にはなってくるでしょうし、気長に待とうかなという感じです。

なので周りの雑音を聴かないようにするという今までの経験だとあまりないことをしなきゃいけないのがストレスになりそうですが頑張ります。 難しそうであればまたその時に考えようと思います。

今は技術力を身につける方が優先で、他の人のお手伝いをしている場合ではないことを意識します。

まとめ

入社して4ヶ月が経って余裕が出てきたためか、色々と考えることが多くなりました。 入社前に考えていたよりも自分の成長スピードが遅くて焦っていましたが、自分ができることを一つ一つ解決して成長していこうと思うので、今は焦らずできるところからやっていこうと思います。

あとは見ないフリ聴いていないフリをして雑音を消そうと思います。雑音を聞くことは今回の転職目的とは異なるはずなので、気にしないように意識しようと思います。

また定期的に振り返りをして今年1年間での成長度合いを重要視していこうと思います。 今回は定量的な部分は書きませんでしたが、思う部分はあるので、次回とかにまとめられれば。

*1:ユーザー企業に提案することは出来ますが、利用者の状況が見えにくかったりするので確度の高い提案が出来ないなどの問題で改善しにくいのかなと思います

*2:正直なんのために転職したんだっけ?って考えることがままあります

*3:ただしAWSなどは詳しい方がいらっしゃるので教えてもらいたい

*4:ここに今いる協力会社の方が大きく口を出してきて、思うように進まないようであれば個人としての成長が見えなかったり、会社としての成長もないと思うので、転職も考えようかなと思っています