IDCフロンティアのUI/UXチームです。
IDCフロンティアが提供するクラウドサービス「IDCFクラウド」では複雑なインフラ技術を直感的なユーザーインターフェースを通してお客さまに簡単に使ってもらえるように工夫しています。
データセンターやクラウドサービスの運用となるとインフラエンジニアの方が活躍されているイメージを持たれるかもしれません。しかし、弊社にはUI開発を中心に担当するフロントエンドエンジニアも在籍しており、UI開発も自社で実施しています。
今回と次回のブログでは、IDCFクラウドのフロントエンド領域に関する業務内容をご紹介します。
具体的なイメージを持ちやすいように、実際に業務を進める際に使っているツールやドキュメントのスクリーンショットを載せています。個人名や社内情報は白塗りでマスキングしていますが、それ以外の部分は可能な限りお見せしています。
業務内容
UI開発と言っても、ただプログラムを作るだけではありません。イメージしやすいように簡易的な業務フロー図を載せます。
UIを作る対象の技術調査
IDCフロンティアのクラウドサービス画面を設計するためには、操作対象のインフラやミドルウェアの動作や仕様を理解する必要があります。分からない状態でUI仕様を作ってしまうと、技術的に不可能な操作をUIで表現してしまう可能性があるためです。また、他領域のメンバーからの提案が技術的に実現できない場合があっても気づくことができず、リリース後に問題が発生してしまう可能性があります。
これを防ぐため、まずは対象のインフラやミドルウェア自体の仕様について理解を深めることを行っています。
まずは対象のリソースを操作し、不明点は調査や問い合わせ等を通じて「自分なりに技術的な説明ができる」状態にします。
UI仕様の提案・策定
IDCフロンティアではエンジニアが中心になってUI仕様を決めることが多いです。これはインフラやミドルウェア技術は専門的な知識が要求されることと、技術検証の結果をもとにUIを設計する必要があるためです。プロダクトごとに各領域からメンバーが集まっているため、そこで合意を取り次第設計・開発に移ります。
フロントエンドエンジニアが中心となり、調査内容を元にどのような設定が必要か、画面はどうするか案を出します。リソース設定や操作はバックエンドエンジニアの担当領域となるため、フロントエンド⇔バックエンド間の連携方法もこのタイミングで話し合います。連携方法はREST APIを使うことがほとんどです。
設計
UIを確認しながらコンポーネントに分解します。状態管理が複雑になると不具合を生みやすいため、可能な限り依存を減らし単純なステート設計にするようにしています。テスト駆動開発で開発を進めるため、テストが書きやすいか？という観点でもコンポーネント分割を行っています。ある程度構造を考えた後、作業を分解してひとつずつ実装を進めます。Pull Requestは作業単位で作成し、レビュー時の負担を減らすようにしています。
設計や実装内容はIssueやPull Requsetに都度書き込みます。 特に重視している点は「なぜそうするのか」という経緯を詳細に記載することです。リリース後に保守対応を行う際、なぜその実装にしたのかが分からないと改修して良いか判断できません。すると改修が中々できず、コードが放置されてしまいます。こうなると変更難易度が上がり、改修に時間がかかってしまいます。これを防ぐため、経緯やそのときの考えを詳細に残すようにしています。
過去はUI仕様から実装を起こしていました。しかし、実装後に考慮漏れが出ることが多く、やり直すことが多くありました。そこで、実装前に次の内容を検討し、ドキュメンテーションするように変更しました。整理することで、UI仕様検討時に考慮が漏れていた部分に気づけます。また、メンバー同士の相互レビューにも活用できます。
コンポーネント設計
UI仕様の決定時点である程度実装イメージがついているため、作図を使ってコンポーネント設計を行います。後ほど技術要素は紹介しますが、コンポーネント指向のライブラリを用いているためステート管理も重要です。
作図に詳細な仕様を書き込みすぎてしまうと仕様変更時にメンテナンスする必要が出てしまいます。継続して取り組むのは現実的に難しいので、作図では次の内容を整理する程度に留めています。作図と実際のコードが乖離してしまうと後から入ってきた人が参考にできる情報が減ってしまうためです。
- どのUIパーツをコンポーネント化するか
- 太字の枠線で表現
- APIレスポンスパラメータ
- 黒枠線とレスポンスパラメータ名で表現
- 特殊な挙動がある場合は追記
- 吹き出しで表現
作図はCacooを用いて行っています。シンプルな機能で多彩な表現ができるため、重宝しています。
処理方式や状態管理方法の設計
APIレスポンスパラメータをどのように加工するか、コンポーネント同士の状態管理はどのようにするかあらかじめ文章化します。指定がなければIssueやREADMEにまとめています。レビューができそうであれば、このタイミングで一度相互レビューを行っています。
開発
コード管理はGitHubで実施しています。Pull Requsetはひとつの意味が通る範囲で分割することを心がけています。これはレビュアーの負担を下げるためだけでなく、後から調査をする際にPull Requestの内容を追いかけやすくするためです。
Pull Requestには次の内容を記載しています。
対応Issue
過去の実装経緯を調査する際、git blameでコミット番号を調べ、GitHub上で対象コミットを確認すると対応Pull Requestに飛べます。この際、Pull RequsetからIssueにリンクしておくことで過去の設計経緯を確認しやすくなります。
Pull Requestの対応が終わればIssueが終了する場合、紐づけ機能を用いてPull RequsetとIssueを自動で紐づけています。
対応内容
このPull Requsetではどのような対応を行ったのかを簡潔に説明します。設計方針はCacooやIssueコメントで説明しているため、リンクを貼ってレビュアーが探し回らなくても良いように工夫しています。
動作確認事項
これはとても力を入れて書いています。実装者とレビュアーが同じ条件で動作を再現できないと、QA段階で戻し作業が出てしまうためです。また、動作確認事項を説明できないということは、何を実装するのか理解できていない状態だと考えています。
レビュアーが記載通りの操作をそのまま再現できるように手順を明確化し、どこを確認すれば良いかを説明します。画面の変更であればスクリーンショットも取得し、お互いの認識齟齬が出ないようにしています。
レビュー時点で動作確認に時間をかけることで、QA段階で出てくる不具合を減らせています。
申し送り事項
実装に迷っている点やわざと対応していない内容等、レビュアーに伝えたいことを整理して記載しています。これがない場合は考慮点なしと判断してコードレビューを実施しています。
コードレビュー
レビュアーがどのような点に注目しているかを記載します。
長くメンテナンスすることになるため、「別の人が見たときも理解できる状態か」を最も重視しています。 例えば対応内容をコードで表現できているかを確認しています。対応内容に書かれていることと実装コードに矛盾があったり、より良い手段がある場合は修正提案を行っています。
他には関数や変数の命名と処理内容がずれていないかも確認しています。ずれがあるとコードの処理まできちんと確認する必要があり、後から変更するときに変更ミスが発生しやすくなってしまうためです。
動作確認事項通りに動作するかも確認しています。実装者の考慮漏れがないか、エラーハンドリングのように忘れやすい内容が考慮されているか、等を確認します。 申し送り事項やコメントに相談事項があれば、そちらの内容に回答することもあります。
テスト
Pull RequsetがApproveされ、全ての開発が完了した後はステージング環境で仕様通り動作するかテストを行います。IDCフロンティアではテストは開発者が担当することが多いです。表示速度が遅すぎないか等、UXに関する問題がないかもこのタイミングで確認します。
場合によってはUIを操作した結果を確かめるだけでなく、操作対象のインフラリソースやミドルウェアの設定状態も確認します。この作業を怠ってしまうと「APIリクエスト結果は200 OKなのに実際の挙動には設定が反映されない」事態に気づけないためです。これではサービス仕様を満たせていないため、リリース前に検証し修正する必要があります。
経験が浅いメンバーがテストを担当する場合、レビュアーもテストを行い品質を担保しています。
リリース
テストが完了した後、社内規定の手続きを経て本番環境へリリースします。リリース後、お客さまや社内からの問い合わせ等があれば回答することもあります。
ここまで終われば開発業務はおしまいです。次の開発内容を確認し「UIを作る対象の技術調査」に戻って業務を進めます。
今回は業務フローを中心にご紹介しました。次回は利用技術や普段工夫している取り組みについて詳しくご紹介します。
