ID:26402さん

## プロジェクトのチーム構成 プロジェクトマネージャー：１ リームリーダー：１ プログラマー：１（私です） ※プロジェクトは機構設計、HW、SWと多岐に渡るため、私のチーム構成だけ書かせていただきます。 ## ROVの概略 ROVは、施設のメンテナンスマシンとして開発が企画されました。 ROVは壁面などのメンテナンス対象を録画することが目的になります。 また、その録画データを解析することで**補修が必要な個所を可視化**したり、ログとして保存して**施設の老朽化傾向を見る**ことを目的としています。 ## マップ作成ソフトウェアの開発 ROVの録画したデータを画像合成し、ROVの軌跡マップを作るソフトウェアを担当。 私は画像処理未経験だったため、OpenCVというライブラリを使って実装する運びとなります。 ### サンプル実装 OpenCVのステッチング技術を調査し、特徴点を検出・合成する手段を用いることになりました。 暫定データとして居室内をハンディカメラで撮影したデータを用いて、それなりの画像が繋がり一枚の絵になっていました。 ### 本番では しかし、実際にROVが撮影してきた本番データでは画像を連結することができませんでした。 まず、ROVが撮影してきたデータが濁水だったため綺麗な特徴点がなかなか取れなかったことが挙げられます。特徴点が数件しか検出できず、業務が難航しました。 チーム内で議論を行い、特徴点を出す前に前処理を行うことになりました。 - **エッジ強調**で特徴点を強調 - **画像をぼかす**ことでノイズを除去 しかし、結果は変わらず。 その他にも、２つの画像の移動差分を検出する「位相限定相関法」などの別手法を用いたり、ROVの動作ログ（ROVの姿勢情報など）で補正するなどを行いましたが、良い結果を得られませんでした。 ### その結末 最終的に、研究チームに巻き取られてしまいました。 研究チームは、私の結果から特徴点検出ができないことから特徴点検出を避けて「ブロックマッチング」という手法で画像合成を行って問題を解決していました。 ## 失敗の原因 - ベストなデータを元に実験を行い、それなりの結果が出て安心したこと。 - ワーストなデータで実験していなかったこと。 - 保険として、別の実装を考えなかったこと。 いくつもの原因が考えられますが、当時から今も主な原因だと思っているのが **実装に使った画像処理アルゴリズムを説明できないこと** 研究チームに引き継ぐ前に、課全体で対策会議を行ったことがあります。 しかし、その際に画像処理部分のアルゴリズムを説明できず、他のエンジニアの理解を得ることができませんでした。その時になって、自分は技術を使っている気持ちで使われていたことに気付きました。 ライブラリに安心し、**仕組みの理解を疎かにしたこと**が一番の問題だったと考えています。 このプロジェクトの失敗が、 今の私の目標である「**なぜ/Whyを説明できるエンジニア**」を作り上げています。

## チーム構成 チームリーダー：１名 プログラマー：２名（**内の１名が私です**） ## チームの概要 TVにはH265やVP9といった動画ファイルをデコードする機能があります。 そのHWを制御するデコードプロセスの開発・改修を行っているチームに所属しました。 業務としては、以下を担当しました。 - 外部サービスの会社（以下、OTT会社とします）からの新規要件の開発 - ビデオドライバの既存バグの対応 - デコードプロセスの既存バグの対応 ※OTT...Over The Topという意味で、インターネットでの動画配信を行う会社群 # OTT会社からの新規要件の開発 動画にはI/P/Bフレームといった３種類のデータが存在します。基本的には完全なデータを管理しているIフレームからしか再生できません。しかし、OTT会社「フレームの種類に関係なく、指定したフレームから再生できる機能」を要望されました。「技術的な制約でユーザーの体験を少しでも損ねる訳にはいかない」という理由に賛同し、またその会社からの認証を得るため、我々もこの機能の開発に着手します。 # ビデオドライバの改修 Linuxの開発は何もやったことがありません。 しかし、**画像処理プロジェクトという新しい挑戦に失敗した経験**があるため、まずは仕組みを理解するところから始めました。Linux Kernelがドライバをどう扱うか等といった深い部分まで掘り下げる時間はありませんでしたが、今回の対象ドライバが**どう作ればどう動くのか**を説明できるようにしてから取り掛かりました。 ## デコードプロセスの改修 このプロセスはドライバに比べて巨大な規模でしたが、同じくチームリーダーに質問を重ねてキモの部分を手助けしてもらい、その中を調査・質問を重ねて「仕組みの理解」から始めました。 早送り機能が目的のIフレームまで検索できるので、追加で**検索したIフレームから指定されたフレームまで出画しない**という今までに無い処理を実装することになります。「出画しないことを目的とした機能」は存在しませんでしたが、「デコードしたフレームの出画タイミングが既に過去だった場合は出画処理をスキップする」というエラー復帰処理を利用し実現しました。

## 開発体制 スクラム開発 メンバー数：９名 ## インフラの構成に用いた技術 アプリケーション基盤 - ECS/Fargate ... API-GWのインフラ - DocumentDB ... API-GWが管理するルーティング情報などのデータ管理 - ElastiCache(Redis) ... 流量制限などの計算インフラ - ElasticLoadBalancer ... ALBとNLBによる負荷分散 - ElasticFileSystem ... アプリの書き出すログなどの管理ストレージ リリース基盤 - CodeBuild ... CodeDeployによるBlud/Greenが使えなかったためCodeBuildで代用 - CloudFormation ... 構成管理とリリース作業に使用 監視基盤 - CloudWatch/Zabbix ... 監視用途に使用 - S3 ... CloudWatch以外のログ保存用 ## スクラム開発らしいトライ＆エラーとその事例 AWSやGo言語などを用いて構築・開発していますが、精通したメンバーはおらず、常にトライ＆エラーを繰り返しながら行っています。 多数の問題を抱えていましたが、特に大きな問題になった３点を紹介します。 ### Blue/Green Deployが使えない問題 システム断を発生させずにリリースする要求を満たすためBlue/Green Deployの利用を考えました。 しかし、この手法の条件はBG Deployの用件はロードバランサー一台に紐づくことでした。今回のシステムはALBとNLBの両方の経路を持つため使えなかったのです。 しかし、ECSを利用していたことが幸いし、別のリリース手法を使うことで回避できました。 ### ログが救出できない問題 あらゆるソフトウェアで問題を解析するときに用いられるモノはログです。初めは、ログをfluentdを使ってS3に送信することを考えていました。しかし、基本的にFargateは外からシステム内に入ることができず、システムが止まってしまった時ログが救出できない問題に直面。 EC2を使えば開発側で責任を持つことにはなりますが解決できます。しかし、チームで協力することでEFSとの連携を見つけ出すことができ、無事に回避できました。 チームのみんながみんな、自分ごととして捉えて調査して、考え抜くことができたのが何より楽しかった仕事です。 ### ログの保存処理 ログは基本的にはCloudWatchを使いますが、EFSやs3に多重化することで欠損を失くすようにしています。 この多重化システムは運用通知として5分間転送処理の成功メトリクスが取得できなければ再実行命令を出しており、連続で15分間に成功メトリクスが取得できなければ運用部隊に通知が発呼されます。 しかし、このEFS→S3の転送が遅い……！！30分もかかっていたのです。。。 Bashでのスクリプトで実行していますが、リリース直前ということもあり高速言語に切り替えることはできませんでした。 しかし、そこでTV開発でLinuxを使ってきた知識が役に立ちました。 並列化されていないコマンドを並列化したり高速化を行いました。また、チームの大黒柱がAWSに詳しく転送処理を並列化してくれたため、スペックは倍用意するハメになってしまいましたが、最終的には１分で処理を終えることができ、実に処理時間を1/30に高速化できました。

会社の月次定例会を利用して機械学習の発表をさせてほしいと相談したところOKをもらいました。 そこでパーセプトロンの動き方をアニメーションで説明したところ、周囲から高い評価を得ました。 そこで今後流行る機械学習を担うエンジニアが欲しいので半年間機械学習の勉強をしてほしいということでこの仕事を行うことに成りました。 # JDLAのE資格の勉強 機械学習を行うにあたってライブラリだけ使えても使い物にならないという気持ちがありました。 ロボットの仕事でライブラリを使いこなせなくて失敗した経験があるからです。 そこで、社長等の役員に数学・統計から機械学習を学ぶメリットとを周囲で盛り上がっているライブラリを使えるだけではダメな理由を説明しました。 そして、JDLAのE資格を受けるだけの資金と時間を用意していただきました。 数学は微積分・行列などの基礎から。 統計も回帰分析などの基礎から。 また機械学習自体もパーセプトロンからCNNや強化学習・深層学習。 数学・統計・機械学習の浅い部分を一通り行いました。 せっかく時間と資金を用意してもらったにもかかわらず肝心の資格に不合格になってしまったのが会社に申し訳が立たない状態ですが、数学・統計の部分は合格基準を満たし、Python実装に落ちてしまったので、当初の目的である数学・統計から理解するということの一部分は達成できたと感じています。 また、実力自体も大学院で研鑽を積んでこられた研究者などには遠く及びません。しかし、彼らを目指して粛々とレベルを上げていこうとしています。 目下の作業としてはCourseraというプラットフォームのスタンフォード大学の入門授業を受講しているところです。

# 旧態依然の体制を刷新 派遣先では残業の常態化、デグレの増加傾向から「作業の効率化」が常々叫ばれていました。 その場で使われていたBTSはBugzillaと呼ばれるツールで、要件定義をバグとして登録し、各チームに振り分け、担当者が開発し、各チーム内でレビュー、Gitにバグ番号と共に登録する、バグチケットにSHA1を記載する。という内容をすべて手入力で行われていました。 もちろん、ミスはいくらでも存在します。 - touchコマンドで作られた空ファイルをレビュー議事録として添付してレビューを誤魔化すこと - コミットメッセージに書くバグ番号が間違っていて追跡できない - バグチケットに書くSHA1の転記ミスがあって修正コミットが追跡できない - レビューのための会議室待ち もちろん、出来るだけの効率化が実施されていたのは知っていますし、それらが効果を出していたのも知っています。しかし、これ以上の効率化を望むとなれば、この状態を改善しない限りは騙し騙ししていくしかないような体制でした。 # Gitlabの導入 これらを自動化、少なくとも半自動化することで効率化できるはず。 また、今使われているツールも来年言語のサポートが切れる、プロジェクトも大きく変化し体制を変えるチャンスだったなど、奇跡的に大きな変化が起きていたので「やるなら今」という気持ちで自身の指揮命令者にGitlabの導入を提案しました。 自分の指揮命令者は最新のツール群にも詳しく、自分もある程度はできていたため、Gitlabの運用を受け入れてくれました。Gitlabを選んだ理由は、高セキュリティのコードが多数ありGithubエンタープライズを使うことが難しい中、プルリクエスト（Gitlabではマージリクエスト）などの機能が充実しており、何よりBugzillaやRedmineとの連携機能が存在していたからです。 指揮命令者と業務の半自動化を議論していく上で重要になったのは、このGItlabへの置き換えを別の部署を巻き込んでしまわなければ効果が薄いということです。 しかし、現状に効率化を叫ばれていたとはいえ「慣れてしまったツールを手放せ」「最新のシステムを学べ」と言うには如何せん大きすぎる会社でした。そのため、できるだけ現状の制度を壊さず、かつ衰退するまで面倒を見切れる仕組みが必要でした。 そのほとんどをGitlabは持ち得ていたのです。 結局は、企画部まで巻き込んで成果が得られるまで業務を続けることができませんでしたが、制度を開発部の各課に説明したところ別の開発チームから「使わせてほしい」という声をもらい実際に運用されるまでには至りました。

# チーム構成 - プロセスチーム プロジェクトマネージャー：1 チームリーダー：1 プログラマー：5 - WEBチーム チームリーダー：1 プログラマー：3**（ここに私がいました）** # 開発環境 Eclipse 3.7 Java / Struts2 ※今ならSpring Bootなどを使うと思いますのでかなりレガシーな環境です。 Windows Server 2012 Internet Exproler10 (IE5 Quirksモード) # フロントエンド - JSPでWEBページの作成・改修 - ## 出会ったのは構造が動的に変わるページ 最初に担当したページには以下のような問題点がありました。 - 古き良きテーブルレイアウト - buttonタグ１つにつきformタグ１つを使う - formの終了位置が動的に変わる HTMLの良い点は、**コードから見た構造が静的であること**だと思っています。 一部分を特定のユーザーに見せないなどの構造が可変なページは分かりますが、それは主に「構造の単位で隠す」ことをしている訳です。しかし、出会ったコードはbutton毎にformを用意していることがあり、お客様によって終わりのタグの位置が変化するかなり複雑な構造になっていました。 このコードの発端は、ボタン判定の手法に**buttonにそれぞれformを設けていること**だと判断しました。 ボタン追加作業を受けた私は、「**可読性・保守性の向上**」を理由にページ全体の改修をリーダーに相談。 以下の条件・方針でページを改修を行う運びとなりました。 - テーブルレイアウトは全ページのルールだから変えないこと - formを必要最小限に絞ること - ボタン判定には、JavaScriptを使って実現すること この方針にすることで、ボタンのON/OFFでformの範囲を変える必要はありません。 ユーザーに見せる見せないについては、JSPのif文で制御するものをbuttonそのモノに変えたため非常にシンプルで直感的な形になりました。 **変更は大量になりましたが、保守性と可読性を持った良いコードになった**とレビュー時に評価されました。 # バックエンド - Servletでページ制御とJavaでDB操作 - **ページの遷移時には必ずServletを経由すべし**とのルールがありました。 それには「**ページ遷移毎にユーザーの状態をチェックする**」というセキュリティ上の理由があり、とても勉強させて頂きました。 ## DB操作と冗長なコード 実際にDBへの書き込み操作を行うのはC言語のプロセスチームの役割でしたが、彼らに電文としてプロセス間通信を行う前に事前チェックを行うのが私のチームの最後の役割でした。 DBにはレコード上限があるテーブルがあり、これをチェックする関数が複数存在しました。 理由は、関数設計にあり、引数で渡すテーブル名のレコードが10件あることにtrue/falseを返す関数といった具合に、無数の関数が定義されていました。 これでは一つのチェック関数にバグが見つかった場合、似たコードすべてを調査する必要があります。 そこで、レコード数のみを返し、各if文で数的チェックを行うように変更しました。 レコード上限の変更がIT中に降りてきましたが、他のページに影響させずに該当ページのif文のみを変更することで対応でき、最小限の変更と時間で済みました。