Eight iOS アプリの申請作業はボタン一つ

Eight 事業部 iOS エンジニアの 河辺 です。Eight iOS チームでは、これまでアプリの申請作業を手動で行なっていましたが、昨年の12月より自動化しました。この記事では、そのアプリ申請作業の自動化の取り組みを紹介したいと思います。

これまでのアプリ申請に必要な作業

iOS アプリをリリースする際には Apple に申請する必要があるのですが、申請作業は手順が多く複雑です。Eight iOS では、アプリの申請作業を一部自動化していましたが、それでもなお作業手順が多い状態でした。当時のアプリ申請作業の手順は以下の通りです。

• Bitrise の Workflow を実行し、ipa ファイルを作成, App Store Connect に ipa ファイルをアップロードする
• Testflight でアプリを配信する
• App Store Connect でリリースバージョンを作成する
• Store 文言を変更する
• App Store Connect で、リリース時に配布する ipa ファイルを選択する
• 「バージョンのリリース」, 「自動アップデート用の段階的リリース」, 「 iOS 評価概要のリセット」の各項目でチェックを付ける
• 「輸出コンプライアンス」, 「広告 ID ( Advertising Identifier 又は IDFA ) 」の各項目でチェックを付ける
• 審査に提出する

審査に提出する際には、各設定項目が正しく設定されているかダブルチェックを行っていました。

人間がアプリの申請作業を行う課題

Eight iOS チームでは、約2週間に1回という高い頻度でアプリをリリースしています。高い頻度でアプリをリリースすることで、「ユーザーに速く価値を届けられる」という点においては良いのですが、「高い頻度でアプリの申請作業を人間が行う必要がある」という点においては課題感がありました。

アプリの申請作業は手順が多く複雑であるため、ミスをする可能性もありました。アプリ申請作業のミスを防ぐためにタブルチェックを行なっていたものの、人間が作業をしている以上、今後も必ずしもミスをしないとは言い切れませんでした。

これまではアプリ申請作業の一部を自動化していましたが、作業コストが低くはないという状況でした。今後も高い頻度でアプリをリリースする上で、アプリの申請に掛かる作業コストは無視できません。また、アプリの申請作業のような機械に任せられることは機械に任せて、人間はユーザーに価値を届けることに注力する構図を作りたいと考えていました。

非同期処理を理解する

はじめに

プロダクト開発部の荒川です。私事ではありますが、バックエンドエンジニアからiOSエンジニアへと転向しました。iOS開発は全くの未経験だったのですが、周りのメンバにも助けられつつ、なんとかやっていけています。サーバサイド、クライアントサイドの両側面から一つのアプリケーションを眺めることができて、非常に楽しく開発できています。

さて前置きはここまでにして、今回は非同期処理をまとめてみました。擬似コードはMDN Web Docsより参考にさせていただいております。

同期処理と非同期処理のキホン

非同期を説明する前に、同期処理について説明しておきましょう。 同期処理とはあるタスクを順番に実行する方式のことで、そのタスクが実行されている間は他のタスクが中断される方式です。*1

同期処理にはいくつかの欠点があります。最たる例としてディスクアクセスなどのI/O処理の場合、メモリアクセスと比べると非常に遅い事が多く、ファイルやソケットが読み出しを完了するまで処理を止める必要があるので、その間は他の処理をすることができません。

一方で非同期処理はある処理を実行する間に他の処理を実現することができます。JavaScriptやSwiftなどのいわゆるクライアントサイド開発に携わる方は日常的に利用するはずです。非同期の実現方法にはいくつかの方法があるので、図は後ほどの実現方法の箇所にてご紹介します。

なぜ非同期処理が重要なのか

I/O処理に限らずブロックというのは、クライアントサイドにおいては大きな問題となります。アプリケーションのメインスレッドとしてUI専用のスレッド、ユーザからの操作を受け付けるためのイベントループの処理が動作しており、開発者が同スレッドにて処理をブロックするとイベントが処理できなくなります。結果としてユーザから見ると画面が止まったかのような体験となるので、UI以外の処理を同一スレッド上で実行するのを避けなければなりません。

もちろんサーバサイドにおいてもCPUを遊ばせておく必要性が低いので重要なテクニックであることには代わりありません。

*1:厳密に定義することは難しい

CSS について復習する

こんにちは。Eight 事業部エンジニアの鳥山（@pvcresin）です。
業務では Eight Career Design の Web フロントエンドを担当しています。
Eight では様々な技術を使って、CSS によるスタイリングを行っています。

• PC 版 Eight
  • Sass（SCSS） + BEM
• Eight-UI: 社内向け React コンポーネントライブラリ
  • CSS Modules + PostCSS
• Eight のとある新規開発
  • styled-components

今回は、CSS にまつわる技術を復習し、Web におけるより良いスタイリングについて考えていきたいと思います。

CSS

CSS は文書のスタイルを定義することができる、スタイルシート言語です。
ここで言う文書とは、HTML をはじめとするマークアップ言語によって書かれた、構造化された文書のことを指します。

h1 {
  color: blue;
}

セレクタ（h1の部分）によってスタイルを適用する要素を指定し、{}ブロック内に実際のスタイルの定義を書いていきます。
Web サービスでは様々なページで統一的なスタイルを提供することが多く、文書（HTML）とスタイル定義（CSS）が分かれていることで、効率的にスタイルのメンテナンスを行うことができます。

AWS re:Invent 2019 にいってみた。（2日目）

こんにちは。
DSOC Infrastructure Groupの水谷です。

ヘヴィ・トリップ最高でした！
メタルを通って来た人で観てない人が居たら是非観ていただきたい最高の映画でした。ベース担当がホントにベース担当な性格だったのが良かったなぁ。

メタルついでですが、オジー・オズボーンさん、どうにか元気になってほしいです。

あ、お正月は如何お過ごしでしたでしょうか？
僕は元旦にインフルエンザを発症し、5日まできっかり寝てました。

で・・・・だいぶ、前の記事から時間がたってしまいました。
記憶を掘り起こすことがだいぶ難しい年頃なので、日付が前後した事を書くかもしれませんが内容に間違いは無いので安心してください。
それ、三日目のイベントだよと思っても、あ、この人おじさんだったわと思ってくれると幸いです。

それでは

2日目

2日目は現地時間9:30前（弊社エンジニアの始業は9:30です）には準備して軽く先週やり残した仕事をしたりしてました。
re:Invent、毎日8:00～夜中までセッションやらワークショップ漬けも可能なので、次回行く機会があれば体調整え仕事も片付けて頑張ってみたいところです。

「1on1を学びたいエンジニアのためのワークショップ」を開催しました

Sansanプロダクト開発部、関西支店maidoチームの光川です。

2020年1月23日に弊社関西支店で「1on1を学びたいエンジニアのためのワークショップ」を開催しました。

この勉強会は募集開始後すぐに予定人数が埋まってしまい、増枠した後もまたすぐ定員が埋まるという盛況ぶりでした。

勉強会の構成

勉強会は以下のような構成で行いました。

• セッション
• ワークショップ
• Q&A
• 交流会

セッションの講師、ワークショップのファシリテーターは弊社の谷内が行いました。

谷内は Engineering Management グループのマネージャーとして、Sansanプロダクト開発部のエンジニア組織と日々向き合っています。 また最近は人事部を兼務し、エンジニアだけでなく社内コーチとして多種多様な人たちへコーチングを実施しています。

遂に念願の「異体字入力」を開始しました

DSOC Data Management Group*1 の三原です。
2020年2月4日、多くのご要望をいただき個人的にも念願であった、Sansanサービスにおける「氏名の異体字入力」がついにリリースされたため、ご紹介させていただきます。

Sansanではこれまで、スキャンされた名刺の氏名に異体字*2が含まれていた場合、該当する文字は「●」と表示される仕様となっていました。たとえば、はしごだかを含んだ「髙橋たろう」という氏名であれば「●橋たろう」となります。それが今回のリリースにより氏名がそのまま「髙橋たろう」と表示できるようになりました。
以下で詳しく説明していきます。

異体字対応の背景

前述したとおり、これまでは氏名の異体字に該当する文字は「●」で表示するというサービス仕様になっていました。

土に口のいわゆるこの つちよし は「●田」に置き換えていたわけです。

「●」と表示する仕様だと、ユーザーがメール配信や名刺検索などを行う際に利便性が落ちる為、定期的に改善の要望が上がっており、これまでも何度も対応しようとしてきました。
しかし、様々なシステムに関わる改善となるため、かなり影響範囲が大きく、なかなか手が付けられずにいました。（ほんとにごめんなさい。）

「異体字を表示できないのなら常用漢字に置き換えて欲しい」という声を頂いたこともあり、それなら影響も大きくないのですぐに対応できる...と飛びつきそうになったこともあったのですが、「御礼状などをお送りする際に本来と異なる漢字の宛名では失礼にあたる。それであれば●のままにして、手動で修正できる方が良い」というご意見を頂き、何とか踏み止まったこともあります。
あの時、「常用漢字に置き換える」という対応をしていたら、恐らく異体字入力への対応は先延ばしになった可能性が高かったと思います。（ご意見に感謝！）

*1:Data Management Group は、DSOCで唯一フロント職のメンバーで構成されているグループです。

*2:異体字については様々な見解があり、明確に定義づけはされていません。ですが、ここでは「同じ意味・発音であり、対となる常用漢字が存在する文字」と定義したいと思います。そして異体字の中には、旧字・略字・俗字 が存在するとされていますが、それをひっくるめてここでは 異体字 と呼びます。

re:Invent 2019 に参加したら Chaos Engineering を実践したくなったという話

はじめに

こんにちは。
Sansan事業部プロダクト開発部に所属しておりますインフラ領域のリードエンジニア兼プロダクトマネージャーの岩下です。

先日12月に開催されました re:Invent 2019 に今回も参加させていただきました。
相変わらず圧巻としか言いようのない規模でしたが、前回より15000人ほど増え、65000人ほどの人々が参加されていたと Keynote で発表されていたことを覚えています。

Monday Night Live の様子

参加にあたって、以下の2点を個人的なテーマとして設定してみました。

• 今取り組んでいることは正解なのか答え合わせをする
• レベルアップのためのインプットを得る

上記を念頭に置きつつ事前にイベントカタログを眺めてみると、 Resiliency という単語が目に付いてしまう自分に気づきます。
昨年発生した AWS の AZ 障害の経験から Chaos Engineering の実現性を模索していたという背景もあり、この手のセッションには必ず参加しようと心に決めたのでした。

結果どうだったかといういうと、表題の通り Chaos Engineering の実践に本気で向き合おうと考えるに至っています。

Chaos Engineering とは

Chaos Engineering とはシステムの一部に偶発的な障害を発生させ、復旧作業を行うことでシステムや組織の不備を洗い出し、システムの信頼性を向上させる取り組みとして知られているように思えます。
Netflix 社が2015年に公開した文書 Principles of Chaos Engineering から広く認知されはじめたものと認識しておりますが、この文書によると Chaos Engineering は以下の様に定義されています。

経験に裏打ちされたシステムベースのアプローチは、分散システムの混沌な状態を大規模に対処し、現実的な条件に耐えるシステムの高い信頼性につながります。 私たちは、制御された検証においてそれを観察することによって、分散システムの動作について学びます。私たちはこれをカオスエンジニアリングと呼んでいます。

以上より、とりあえず破壊しても壊れないシステムを構築しよう！という意味ではなく、学びを得ることに軸足を置いているということがわかります。
本質が何であるのか、そのヒントを自分は re:Invent で得られたように思います。