トランプ兵の記憶と記録

普通のアプリケーションエンジニアの備忘録

2021年前半の振り返り

前半が終わるまでには2週間弱あるが、仕事の契約上切りが良いので前半を振り返ることにする。

仕事の記録

普段の仕事先は事業会社とSIerを主にしているが、ご縁あり異業界でWebサービスの企画/検証/技術支援のお仕事をすることになった。

バックグラウンドがハードウェア、制御、デスクトップアプリ(C/C++)多めで、総合的にWebができる人が欲しいとのことで引き受けた。

前半・ElectronでNext.jsは茨の道

前半はMVPにあたる機能をチームで決めて、ElectronアプリケーションのPoCに取り組んだ。

結果、特に問題なく実現できた。それはそうだ。OSSを利用したので実現できることに制約は少ないからだ。

ソフトウェアではOSSを使えば大概のことは出来るので、出来るかよりも何を達成したいか、どういう価値をユーザに届けられるかの方が大事を連呼した日々だった。

このPoCはメンバー間で『ターゲティングが曖昧・やる意味があるかわからない』など非難轟々に終わり、MVP分の開発を経た後KPTを経て終了となった。残念なオチだがやめる勇気を持てただけでも意味はあったと思う

技術ベース

ElectronでNext.jsが使えるNextronを使った。

これは自分が決めたわけではなく適当なコードを丸投げされたので、他の担当者が適当に決めたアーキテクチャを実運用に耐える体に持っていく普段の仕事形態に落ち着いた。

別現場でフロントエンドのアーキテクチャに取り組んでいた知人と情報交換もしながら、フロントエンドの知見を得た。

あとは協力会社がPyhtonで開発した機械学習エンジンの構成分析、デプロイメントの検討にも手を出してみた。

これに関しては、12 Factor Appに則っていないPythonスクリプトなので、AWS EC2などLinuxベースのVMに載せるしかなかった。

外注する場合はアーキテクチャも要件にしっかり組み込みましょう。 としか言えなかった。

後半・開発プラットフォーム支援とサービス企画

後半は下記に取り組んだ。

  • 開発プラットフォーム検討
  • AWSのキッティングと管理
  • 諸々の検討

開発プラットフォーム検討

前半のKPTを通じ、まだまだ組織として必要な開発プラットフォームがないことが分かった。

具体的にはGitベースの開発サービスが無料版で放置されていたり、各所とのコラボレーションに問題がありそうだった。

KPTでProblemを提起したら、私に検討の仕事が回ってきた。言い出しっぺに仕事を投げる体質が良くないと思ったが、文句は控えて前に進むために建設的に引き受けた。

改めて有名どころを洗い出し、特徴を整理してみた。

  • Github, Github Enterprise
  • Gitlab
  • Azure DevOps
  • BitBucket
  • Backlog
  • GitBucket

改めて見るとCI/CD、情報共有、Issueはどれでも使えるし、どれを使っても遜色はない。

開発しているプロダクトの性質上GitBucketを使ってイントラでセキュアに利用するのが良さそうだったが、スキル上・体制上構築運用が出来そうにないのでサービスを使う方針にした。

最終判断はマネージャーに委ね、既存で利用していたBitBucketを正規に決済して利用できるようにした。

発注元でプラットフォームはオーソライズしましょう。

AWSのキッティングと管理

後半の検証ではできるだけリアルな状況を再現するため、AWSにデプロイできるものを開発することにした。

インフラはAWSで統一されているようだが、組織上の都合で新規に申しこんだため、AWSのキッティングと管理を担当した。

特に大事にならず無事に管理を終えた。

諸々の検討

詳しくは省略するがいわゆる企画。先を見越してAuthleteかAuth0を使う方向に倒したかったので、これらとOpenIDの基礎にも触れた。

自分は他社とのコラボレーションや新機能開通を複数手掛けていたので特に問題はなかったが、仕様が決まっていないまま放置などプロダクトサイドの問題が露見した。

落ち着いて必要なことと課題を整理して見える化し、周囲への説明とQ&A対応に取り組み、『こう見ると決まっていないことがたくさんあるのが分かった』という評価を頂いた。

自社プロダクトの検討なのに、一連の流れがまるでSIerとエンドユーザがコンサルで向かい合うコミュニケーションのようで、アーキテクトとして久しぶりの不思議な違和感に襲われた。課題を見える化するのはやりがいがあった、ということにしておく。

当たった壁の数々

諸々を踏まえ6月で支援終了に至ったが、いろいろ取り組んでいく中で、組織的な構造問題にあたることが多かった。覚えているだけでもこれだけある。

  • 課題や目標を交通整理する人がいない
  • 工程カットで組織が分断されているので、上流工程スキルが付かず開発エンジニアが新しいアイデアの検討に立ち向かえない
  • 主任クラスのエンジニアがいないため、技術改善やアップデートができず開発組織の知識が遅れている
  • 開発ツールやインフラ、ISMSが整備されておらず、モダンなツールの導入にルールの検討が必要

立場上、フリートークやチャットの雑談チャンネルでの会話くらいしかできることがなかった。何か知っておくだけでも将来違うので役に立てたらいいのだが、未知数だ。

最後に2点フィードバックして終了した。

  • 工程カットで組織を分断しない。Webサービスでは上流工程から運用まで有機的に取り組むのが重要
  • ゴールの管理や課題整理をするプロジェクトマネージャーが必要。大きな計画を開発エンジニアに丸投げしない

『耳が痛い話』とのことだったが、良いwebサービスには欠かせないと思うので頑張って欲しい。

学んだことのまとめ

個人的なこと

Github活動の頻度を上げられた

本当はGithubでガンガン仕事できる現場にありつければいいが、働き方の形態上そうも行かないので悲しい。

f:id:zoosm3:20210620190532p:plain
Githubの草・2021年前半まで

まだまだ少ないが、Githubに毎月何かしらのコントリビューションや写経を出せるようになった。

増やしすぎて疲弊しても仕方ないので、後半もこれくらいのペースを維持したい。

主な貢献

dbflute-springboot-example

dbflute-springboot-exampleはSpring BootとDBFluteのバージョンアップ、依存性バージョンアップの自動化に取り組んだ。

dependabotで依存性更新を見える化したので誰でもメンテナンスできるようになった。

デプロイの勉強に使いたいのでこのまま全機能完成させてしまいたい思いもあるが、後進に譲っている。

Spring Bootへのコントリビューション

https://github.com/spring-projects/spring-boot/issues/26207

Twitterで目に入ってきたので飛び込んでみた。ドキュメントだけでもコントリビューションは勉強になる。

Qiita書いた

Reactの特定のライブラリの使い方に悩んだので覚書を書いた。ストックなども少ないがあり役に立てた模様。

Qiitaのポリシー改訂の次第で今後の覚書の運用を検討したい。折りを見てQiitaの記事はここに移動することになるかもしれないが、現在は様子見中。

技術コンファレンス、勉強会への参加が増えた

オンライン開催に切り替わったので技術コンファレンス、勉強会への参加が増えた。

オフラインだと仕事帰りは体力も気力もないのでオンライン開催はありがたい。

今年前半はJavaともMySQLとも離れていたので知識のアップデートができ、やる気の維持にも役立てた。

体力づくりが軌道に乗った

恥ずかしい話だが、就職してから運動不足やストレスによる過食拒食で20キロ近く太ってしまい、健康診断での数値が悪化する事態になった。

改善のため2020年1月からパーソナルジムに通っているが、通い始めて1年半経過し、10kg痩せたので全体が縮んで元の見た目に戻った

成果が目に見えた形で出せるようになってきたので、毎週・毎日の継続を大切にしたい。