エンジニアのコミュ力を高める事に貢献し、日本の価値向上とエンジニアの幸福度向上に貢献する
IT業界におけるよくある課題、案件の炎上・マサカリ文化・日本から世界に誇るサービスが中々現れない・鬱・過労働・結婚率の低下。
これらは全て「コミュ力不足」が引き起こしていると考えています。
技術力としては結構高い人も多いと思うが、隣の人の気持ちも汲み取れない人に、価値あるサービスを生み出す事は難しいと思っています。
生産性や働きやすさにも結局最も影響するのは同僚との関係性。
そしてパートナーができて守る者がある人の方が、根性もやらなきゃならない理由もあるので、結果的に良い結果に結びつくことが多いのではと考えます。
仕事柄パソコンと向き合う事がどうしても多くなってしまってコミュニケーションが減ってしまうため、
何かしら意図的に行動しないと中々コミュ力を向上させることは難しいです。
私自身も日常的に業務内外関わらず自身のコミュ力向上に努めつつ、
仕事柄関わる人やライフワークとしている恋愛コーチやITサポートを通じて、
その人自身の内面と向き合い、共に人として前進していく事をしていきたいです。
既存サービスの改修・新規サービスの設計・実装を行う。
主にサーバ側にてAPI実装(swagger・rspec含む)を行う。
[規模]10名前後
[役職]バックエンドエンジニア
[ポイント] 0ベースからのシステム設計&環境構築&開発を一人で行う
多国籍メンバーが在籍しており、かつ、メンバーの入れ替わりも比較的多い環境でした。
そのため、情報共有や残すドキュメント、実装コードやコメントなどにおいて、認識の齟齬が発生しにくいよう・理解しやすいよう努めました。
具体的な一例としては、複雑なロジックやコンポーネントはより多くの人が理解しやすいようなるべく実装をシンプルにし、lintツールによる整備を徹底することで、保守性を向上しました。
どうしてもシンプルにしきれない部分や仕様上どうしてもわかりにくい所は別途仕様や実装背景などを積極的にコメントやドキュメント化しました。
また、ISSUEやPRも第3者が見ても状況がわかりやすいよう、「How」だけでなく「Why」を残す事を徹底しました。
新しいアプリケーションを0ベースで実装を任された際、技術選定に悩みました。
自分のスキルセットや流行・会社全体の開発メンバーのスキルセット等を鑑みて、
この会社において管理がしやすく長期的に運用しやすいよう選定し、実装しました。
当初単一のAPIアプリケーションとしてrailsで実装していましたが、
社内に多種多様なアプリケーションが存在しており、
深く状況を確認すると将来的に機能の一部は他アプリケーションからも呼ばれる可能性が見えてきました。
そのため、単一アプリケーションではなく、「旅程アプリとしてのみのアプリケーション」と「他アプリケーションとの連携も考慮される部分」と切り分けるシステム構成にする事を提案し、採用されました。
その切り分けたアプリケーションの方を、今後TSに寄せていきたいという会社側の希望に則り、NestJSを採用する事にしました。
また、仕様的にDBはGraphQLが良さそうと選択肢に上がりましたが、会社全体的に若手エンジニアが多く、GraphQLの実績も無く、他アプリケーションとの連携も当分先になりそうとの事から、実装速度や保守性を考慮してRDBMSを選定しました。
管理業務として地図スポットの画像を収集する事を他の作業部隊と連携して行っていました。
その管理業務がgoogleドライブに画像をまず保存して、それをエンジニアが入稿処理を行うという形で手間がかかっていました。
そのため、作業部隊の方が直接入稿処理を行えるよう、管理ツールを作成しました。
その機能自体とても喜んでいただけましたし、
小さな管理ツールだったために少しチャレンジできると思い、許可を頂き未経験のSvelteKITを用いて実装しました。
このように、積極的により良い提案を行い、常に状況把握しつつスキルアップを意識して取り組んでおります。
主に楽天市場の店舗さん向けの販促ツールを提供するサービスの開発。
商品やカテゴリ等の各種ページにランキング情報や期間で切り替えるバナー、PCページからスマホ用ページを作成するツール等の多種多様な販促ツールを提供するサービス。
そのバージョン1がCakePHPで書かれていたものを、Laravelにリプレイスするプロジェクト。
新しい開発環境を作る上で、
等を考慮して、開発環境とAWS上のステージング・本番環境を構築した。
楽天サーバへの接続が日本IPからしか受け付けないという特殊仕様のため、AWS上の環境は全てNATで日本IPに変換するようにした。(1サーバ1日本IPと結びつけてしまうと、サーバ台数分日本IPを取得する必要があり、オートスケーリングに対応できないため、NATを利用)
元々jqueryで書かれていたものに対して規模が大きくなってきたため、jsフレームワークを適応することを提案。
複数のフレームワークを社内メンバーのスキルや導入コスト・運用コスト等を考慮し、Vue.jsを選択。
初期導入も含めて行う。
Vue.jsの知見を持つものがおらず、jquery脳だったので概念から学び、他メンバーに横展開を行う。
元々知識の豊富なメンバーがおらず、修正に修正が重ねられ、属人的で複雑なコードになっていた。
それに対して、他メンバーが理解しやすいよう、修正コストが下がるよう、
コーディング規約に則り、仕様も把握しやすい実装になるよう導いていった。
具体的には、PHPMDやCodePHP_SnifferをsiderによりPR単位に指摘されるように導入したり、
毎回のレビューでわかりにくい点や複雑なロジックを指摘し、改善していった。
工夫した点としては、実装者は結局人間であるため、闇雲に指摘するのでなく相手をきちんと見るということ。
一度身に付いた実装方法をすぐ変更して修正するか、頑固に今までの書き方に拘るかは人によって異なる。
そのため、なぜこのような書き方が必要なのか、なぜそのような書き方だとわかりにくいのかを相手の技術や仕様への理解度にに合わせて説明したり、軌道修正を段階的に適応したり、一方的に決めつけるのでなく相手の意思や判断を尊重して指摘したりと、
相手の人間性を尊重しつつ着実にストレスが少なく着実に前に進んでいくよう工夫をした。
楽天市場ではデイリーランキングやリアルタイムランキングがあり、その受賞結果の画像を店舗ページに販促ツールとして設置するニーズがある。
ただ受賞したかどうかを探し、販促画像を作成するのはとても手間なため、それらを自動化する機能を実装。
受賞結果を自動で収集し、リスト表示。
任意の結果を用意したサイズから選んで販促画像をシステム側で作成する。
工夫した点としては、ランキング結果は非常に多くなる場合があるため、
読み込みを非同期で段階的に行い、
ソートもフロントだけで完結させてソートのたびに通信が発生しないようにして操作性を下げないようにした。
WEB広告の結果をinputとし、機械学習等を用いて効果測定を行い、
次の広告の適切な設定値をoutputするシステム。
なお、このプロジェクトはこの期間に所属していた会社での業務ではなく、
個人で受けた案件である。
要件定義を確認し、本システムにおいて適切なシステム設計を行った。
(アウトプットはシステム構成図)
工夫した点としては、
などから通常のインスタンスではなくlambdaを用い、デプロイも運用を考慮してコマンドベースで行えるよう設計した。
flaskはrailsのようにデフォルトのディレクトリ構造が無いため、
実装開発を考慮して独自にディレクトリ構造を策定し、
loggerやexception周り、ORMもファイル分割を行い、規模拡大に耐え得る構成で作成した。
本プロジェクトは自分が長く入り続けるわけではないのは決まっていたので、
自分がいなくてもちゃんと開発運用が続けられるよう、コメントやREADMEもしっかりと残していった。
実装優先にしていたためカバレッジが網羅できておらず、
他の方が想定と異なるtestの組み方をしていて複雑化していたので、
カバレッジの網羅とテストコードの整理を行った。
他の方が組まれていたテストがテスト同士密結合になっており、実装を修正した際のテストの修正が非常に困難となっていたため、
疎結合として分解し、修正も容易となるよう調整していった。
ただ、完全に分解して書き直すにはコストがかかりすぎると判断し、適度な所で切り上げ、
それ以上被害が広がらないようにだけ考慮し、理想と現実の折り合いを付けていった。
女性のための就活・転職相談としてユーザ同士をマッチングし、
やりとりを促すサービス。
途中まで開発が進んでいたがその時の実装者による開発が進まなくなってしまったため、
開発をバトンタッチし、リリース・運用まで受け持つ。
なお、このプロジェクトはこの期間に所属していた会社での業務ではなく、
個人で受けた案件である。
実装は基本自分一人で進め、デザイナーにデザインはサポートしてもらう。
どこまでができていてどこからができていないのか、
最終的にどんなイメージかを確認し、設計を進めていった。
依頼者も資金的に余裕のある方ではなかったので、追加したい機能とコスト感・工数を都度比較検討し、
互いに納得する仕様を設計し、進めていった。
リリースが伸び伸びになっていた事もあり、「早くリリースしたい」という点の優先度が高かったため、
とりあえずリリースできるミニマムの形の設計と理想形の設計を行い、段階的にリリースするようスケジュールに落とし込んでいった。
リリース後、ユーザの反応によって実装の変更が入る事がちょくちょく発生していた。
結果的にうまくいった点ではあるが、最初の実装の段階で依頼者の思いを理解し、
変更の可能性をある程度考慮して変更に耐えられるよう疎結合で実装していた。
そのおかげもあってか変更があってもスムーズに変更していくことができた。
システム全体としても修正によってツギハギだらけの複雑化させることなく、属人化させずにシンプルでわかりやすいコードを維持することができた。
互いに承認したユーザ間でリアルタイムチャットができる機能。
また、互いに希望があればビデオチャットもできるよう実装。
ビデオチャットは外部サービスを埋め込む形とし、低コストで実装。
リアルタイムチャットができるようrailsのAction Cableを使用。
LINEなどの見慣れたUIになるようイメージを合わせ、既読機能も付与。
外注者の作業
期待通りのアウトプットを期限内に出させる
◯依頼して実装してもらった処理がやたら複雑になってしまうことがあった
確かに伝えた内容としては実現はできているが、実装された処理が複雑で他の人が修正し難い場合があった。
なので、
・仕様を伝える段階でロジックやクラス構成等もある程度こちらで考えて伝える
・粒感が大きい場合は特に途中段階でもレビューを入れる
・悩んだ部分や気になる点があった場合はなるべく多くチケットにアウトプットしてもらうように促す
という工夫で、なるべくこちらが想定した形で実装してもらうよう寄せていった。
新規機能開発のリリースまでのスケジューリング
予定通りにリリースまでもっていくこと
各タスクにおける具体的な工数は人によって変わるので、ストーリーポイントの設定と各実装者の能力を鑑みた実装能力倍率を設定し、ストーリーポイント×実装能力倍率 でより高精度な工数スケジューリングを可能としました。
ただ、それでもずれる部分はあったので、
・クリティカルなポイントで滞らせないよう着手順番を逐次考える
・最初の段階で余白の無いスケジュールにしない(多少のずれはその余白で吸収する)
・初回リリース段階で絶対落としたくない部分と2回目以降にまわしても良い部分を相談し、結果的に初回リリースに間に合わなくなりそうな部分は次回に回す
というような工夫により、「初回リリースの日程はずらさない」という点は死守しました。
メンタル・モチベーション(メンタリング・キャリアコーチ・恋愛コーチ)
勉強や活動に前向きに取り組める状態にすること
得たい未来とそこに辿り着くために必要な事に、自分の意思と自分の考えをもって取り組んでいる状態になっているか。
というのが自ら積極的にアクションを取る状態になる為には必要だと考えています。
疑問や不安などを自ら口に出してくれれば楽ですが、
本人が言語化できていなかったり我慢したり気が向いていなかったりしているけど、
口に出すには至らない場合も多々あります。
そのような場合でも、行動や言動・表情から変化がある場合が多いので、
そのような些細な変化を見逃さず、こちらから寄り添っていく事で、
大事に至る前に調子を立て直すよう注力しました。
営業力・コンサルティング力・金を生み出す力、組織を作る力、再現性を生み出す力
スタンディングデスク、HHKB、目線が平行な位置にディスプレイ、天井が高い、ポモドーロタイマー、肘の角度は90度、怖い人や怒る人がいない、未来に繋がっている感覚がある、頼られている、リミットが決まっている、その問題を解決できる人が他にいない