ヤフーでは、エンジニアとデザイナーの突出した知識とスキルを持つ優秀な人財を称賛し、新たな活躍の場を提供するために「黒帯制度」を設けています。2021年度第11代黒帯がそれぞれの専門分野での技術動向やキャリアを語る黒帯LT会から、今回はJava、iOSアプリ、Androidアプリ、OSSデベロッパーに関する発表をご紹介します。
【1】黒帯になってわかったこと、エンジニアのキャリアについて考えた
──プログラミング言語（Java）黒帯 高見 拓也
Java黒帯の高見拓也が、今回LTのテーマにしたのは「黒帯になってわかったこと、エンジニアのキャリアについて考えた」。いま以上に成長したいエンジニア、黒帯を目指しているエンジニアに向けて、技術との向き合い方やプロとして結果を出すということについて語りました。
- 高見 拓也
- COO メディア統括本部 統合プラットフォーム本部
- 「Yahoo!広告」における広告主、広告代理店が広告を出稿するプラットフォームの開発、運用を担当。また、プログラミング言語（Java）黒帯、Javaサポートチームのメンバーとして、全社のJava開発の支援を行っている。
１．体系的に学ぶ
体系的に学ぶとは、つまり収集した情報を整理して把握するということ。そのために大切なのは、まず「公式リファレンスを必ず確認すること」だと高見は言います。
「たとえば、Qiitaなどの技術ブログなどで情報収集をしたらそれで終わりではなく、必ず公式のリファレンスを確認することが重要です。なぜならば、ブログの情報は断片的であったり、根拠が不十分だったりする場合があります。また、時間の経過で古くなり、結果として正確ではなくなってしまった情報が含まれていることもあります」
一方、公式リファレンスでは最新技術の目的・方式などが整理されているので、体系的にまとまった情報を収集できます。高見は自身がよく参考に見ているという「JavaのAPIの公式リファレンス」や「Spring Frameworkの公式リファレンス」を紹介しました。
もう一つのおすすめは「書籍で学ぶ」こと。書籍は情報が整理されて書かれているので、公式リファレンスの情報をわかりやすく学ぶことができます。
２．コードを読む
高見が最も学びが得られると感じているのは「コードを読む」こと。とはいえ、読むだけで理解できるのか、どこから読み始めたらよいのかわからないなど、難易度の高いタスクでもあります。そこで高見は、自身が実践しているコードの読み方を紹介しました。
「まずは、動かしながら読むこと。サンプルのアプリを実装してデバッグ実行しながら読んでいきます。業務で開発保守しているコンポーネントをサンプルに見立てるのもよいと思います」
実装したサンプルアプリは、統合開発環境でデバッグ実行します。
「コードを読む場合は、使用するOSSのクラス、関連するクラスを把握するために、デバッグで停止させて、コールスタックの部分を念入りに読み込みます。これがしっかり理解できると、シーケンス図が書けるようになります」
主要なクラスが特定できたら、次は「テストコードを読む」ということをやります。テストコードは、仕様が正しく実装されているかを検証するコードなので、自然と仕様が集約されます。
また、テストフレームワークはパターンが定着しているので、業務で実装しているコードと同じ構造です。そのため、自然に読むことができます。テストコードにも複雑なものもあるので、その場合はテストコードもデバッグ実行しながら読んでいきます。
技術との向き合い方と同様に大切なのは、「プロとして結果を出すこと」。仕事で成果を出して評価をされることで、新たな挑戦につながるチャンスも増えます。個人よりチームの方が大きな成果を出しやすいため、チーム能力の向上が重要です。
「チームの能力を向上するためには、チームにも知識ではなく知恵を共有することが重要です。チームに情報発信するときは体系化して、収集した情報を整理して発信することを意識しましょう。私は、技術文書を作成してチームに発信するときは、必ず書籍の目次構成を参考にしています」
もう一つ重要なのは、課題感を一致させること。メンバーが同じ課題認識を持つことで、より効果的な対策ができ、チーム全体の能力向上につながります。
「同じ課題認識を持つには、チームのコミュニケーションを密にして、各メンバーの考え、思いに触れることが重要だと考えています。たとえば会話を増やし、技術書の朗読会をチームで開催したり、ペアプロをしたりするなど。重要なのはそれらを継続するということです」
最後に高見は「黒帯をエンジニアキャリアのゴールと捉えるのではなく、次の目標としてヤフーから優秀なエンジニアを輩出する土壌をつくり、Javaを盛り上げていきたい」と語り、セッションを締めくくりました。
【2】iOSアプリ開発のトレンド
──iOSアプリ黒帯 田中 達也
iOSアプリ黒帯の田中達也は、「いまのトレンドを知ることで現状を見つめ直し、未来につなげてほしい」といった思いから「iOSアプリ開発のトレンド」をテーマに発表を行いました。
トピックとしては「UIフレームワーク」「ライブラリ管理」「Swiftの非同期処理について」「WWDCで紹介されたiOSの新機能」が紹介されました。
- 田中 達也
- CTO室アプリ統括部
- Yahoo!乗換案内やYahoo!カーナビアプリの開発に携わり、現在はアプリにおける技術課題の解決や新規技術の検証と開発をしている。最近はメタバースに注目し、趣味でアバターアプリを開発。
1．UIフレームワーク（UIKitとSwiftUI）
ヤフーのアプリは長く運用されているアプリが多いため、古くからあるUIKitが使われています。UIKitはさまざまなUIを実現できる柔軟性があり、動作が安定しているという特徴があります。
一方、SwiftUIは2019年のWWDCで登場。当初は動作が不安定で機能も不十分でしたが、iOS 14以降は多くのことが実現できるようになりました。UIKitとも連携可能なので、一部分だけをSwiftUIでつくることも可能です。
SwiftUIのメリットとしては、UIの開発コストや運用コストを下げられることが挙げられます。たとえば、UIコンポーネントやUIの変更がかなりやりやすくなりました。そしてSwiftコードで書くので、コード差分がわかりやすいという特徴があります。
「アクセシビリティー機能やiPadへの対応、横画面やマルチタスク対応などもやりやすいので、利用者の窓口を広げるきっかけになると考えています」
ヤフーではiOS 14で導入されたウィジェットという機能を実装しているアプリに一部SwiftUIが使われています。また、最近リリースされたアプリには、ほぼすべての機能がSwiftUIでつくられているものもあります。
一方で、SwiftUIには苦手なことがあります。それはAppleのデザインガイドラインに沿わないデザインを実現しにくいということ。これまでのUIKitに比べて開発コストがかかる、もしくはSwiftUIでは実現できず、UIKitを使う必要が出てくることもあります。またiOS 13のような古いOSでは動作が不安定な場合もあります。
「古いOSにおける動作環境に関しては、今後のOSのサポート終了とともに改善できる問題ですが、デザインの問題に関しては、デザイナーとの協力が非常に重要になってきます」
そこで田中は、デザイナーもぜひAppleのドキュメントをぜひ読んでみてほしいと呼びかけます。
「AppleのHuman Interface Guidelineには、iOSやiPadOSなどのさまざまなOSに向けたデザインのガイドラインが記載されています。WWDCというカンファレンスでは、デザイナー向けのセッションも多く、技術の知識がなくても理解ができます」
さらに、「独自のデザインを考える前に、デザインガイドラインやセッションで提案されているデザインでやりたいUXを実現できないか検討してほしい」と続けます。そうすることで、iOSのユーザーが使いやすいデザインになり、開発や運用の工数削減が可能となります。
「エンジニアはデザイナーに実装の知識からデザインを提案してみたり、デザイナーは実現したいUI/UXにかかる開発コストをエンジニアに確認してみたりすることで、より早くユーザーに有益なアプリ開発ができると思います」
2．ライブラリ管理
ヤフーでは、Carthgeというライブラリ管理ツールの移行を以前に進めていたので、多くの社内SDKがCarthgeに対応しています。しかし今後は、新しくSwift Package Manager（SwiftPM）に集約されていくと予想されます。
SwiftPMはOSSですが、主にAppleがメンテナンスをしているので、最新の機能に追従できます。もし何かが非推奨になっても、マイグレーション方法が提供されるはずなので安心して使えます。
「iOSアプリの設計に関しては、SwiftPMを使ってモジュール化していく設計がはやっています。最近のAppleのサンプルコードもこうした構成になっていることがあります。SwiftPMに対応していないライブラリを使う場合は、対応コストが発生してしまうため、SDK側はSwiftPMでの提供を検討し、アプリ側もSwiftPMに移行していきましょう」
3．Swiftとの非同期処理について
これまではCompletion Handler、いわゆるクロージャーを使った非同期処理が一般的でした。結果が非同期でコールバックされるので、コード上の並び順と実際のコードの実行順に差が生まれて、特に連続した非同期処理の可読性が低かったのです。
それがSwift Concurrencyのasync/awaitによって、フローが短くわかりやすい表現で書けるようになりました。Swiftに最適化された機能が入っており、とても便利です。
排他制御のためのActorという仕組みが入っていることも大きなポイントです。これまでは、配列や辞書などに同時に書き込むと、データ競合が発生してアプリがクラッシュしてしまうといったことがありました。
Actorを使うことにより実装で安全を保障できるので、アプリの持続的な品質改善につながります。いわゆるテストを書いているような状態に近くなります。将来的にはDistributed Actorという機能が使えるようになり、端末間の状態共有もしやすくなるので、非常に重要な機能です。
「これらを活用していくためには、アプリ側は積極的にSwift Concurrencyを利用して、アプリの土台をつくっていく必要があります。SDK側は、async/awaitのインターフェースをサポートしていきましょう」
4．WWDCで紹介されたiOSの新機能
WWDCで発表された新機能の中で、田中が目玉機能の一つとしてまず紹介したのは、iPhoneのロック画面にウィジェットをおけるようになったこと。ウィジェットをタップすると、直接アプリに遷移できます。
続いて紹介されたのは、テキストの認識と対象物の抜き出し機能です。画像や動画内のテキストを翻訳したり、そのテキストをコピーしたりできるようになりました。日本語にも対応しています。
続いては、クリップボードの読み取り防止機能。iOS 16からは、右のような形で読み取ろうとしたときに、全面を覆う許可ダイアログが出てきます。プライバシー改善の対策に活用できそうです。
最後に田中は、iOS 16の新機能開発で協力できそうなことがあれば、ぜひ声をかけてほしいと呼びかけ、セッションをまとめました。
【3】AndroidのBottomNavigationの理想と現実
──Androidアプリ黒帯 森 洋之
続いて登壇したAndroidアプリ黒帯の森洋之は、「AndroidのBottomNavigationの理想と現実」をテーマに発表。主に、大きな変更が行われたBottomNavigationViewについて解説を行いました。
- 森 洋之
- コマースグループ ショッピング統括本部 プロダクション2本部
- Androidアプリの個人開発などを経て、2012年にヤフー入社。ヤフオク!のアプリ開発などに従事、2014年にAndroid分野での黒帯に認定。 Droid Kaigi、Droidcon Berlin、Droidcon Transylvania、Devoxxx Moroccoなどに登壇。
新しいアプリを開発するときは、まずmulti-moduleで開発することが多いのではないでしょうか。ただモジュール間の相互参照ができないため、画面遷移のためにはナビゲーションのための機構がどうしても必要になります。その際、多くのアプリ開発者は公式のJetpack NavigationライブラリとBottomNavigationViewを使うのですが、このやり方には課題もありました。
たとえば、これまでFragmentはバージョン1.4になるまで、Multiple back stacksをサポートしていませんでした。BottomNavigationViewでmenuを移動すると、それまでのback stacksが全部消え、また新しくback stacksが積まれていきます。
つまり、長いフォーム画面で入力途中だったとしても、間違ってメニューボタンを押してしまうと、全部消えてしまって復帰できませんでした。それが大幅に改善されて、Multiple back stacksがサポートされるようになったのです。
しかし実際には、まだiOSのようなユーザーの期待する動作になっていないと森は指摘します。Home menuからのMultiple back stacksは復元されるようになりましたが、以下の画面でバックキーをクリックした場合、直前に表示されていたabout画面に戻るはずが、実際にはなぜかWelcome!画面が表示されます。
なぜ新しいBottomNavigationViewがこのような動きをするのか。森はMultiple back stacksでの画面遷移と情報保存の仕組みを以下のように解説しました。
仮にmenuAに行って、Backstackに画面A1A2が積まれていたとします。この状態でmenuBを押すと、それまでのBackstackはmenuAのラベルが付けられ、SavedStateというFragmentの保存領域に保存され、その後menuBの初期表示画面である画面B1がstacksに積まれます。
その後menuを押すと、menuBのBackstackがSavedStateに保存されて、代わりにmenuAのBackstackが復元されます。これがMultiple back stacksの仕組みです。
問題は、いまいるmenuへ来る前にどのメニューにいたのかという情報は保存されていないということです。従って、menuA・menuBのどちらのBackstackを復元すればいいのかがわからず、バックキーを押したときにSavedStateからの復元は一切行われません。
そうなると、Backstackは空になり、表示すべき画面が存在しないので、ナビゲーションは初期表示のmenuへと移動します。ただし、SavedStateに該当するメニューのBackstackが存在したとしても、それを復元することはせず、新規に生成します。この状態でもう一度menuAを押すと、SavedStateにmenuへのバックアップがあるため、それが復元されてしまうのです。
また、森は理想的なBottomNavigationについても言及しました。よく挙げられるのは、YouTubeのような動きですが、ZOZOTOWNも似たような動きをします。ただし、両者は考え方が少し違います。
YouTubeはmenuを押したときにBackstackを復元しますが、ZOZOTOWNは最後に開いていた画面を新しくBackstackに追加しているのです。
最後に森は以下のように呼びかけ、セッションを締めました。
「FragmentがMultiple back stacksをサポートするようになり、以前よりはつくりやすくなりましたが、BottomNavigationViewはまだまともに動作しません。でも理想的なナビゲーションは自分でつくることができるので、一緒にがんばっていきましょう」
【4】Apache PulsarとYahoo! JAPANの取り組み
──OSSデベロッパー認定者（Apache Pulsar） 栗原 望
OSSデベロッパー認定者（Apache Pulsar）として活躍する栗原望は、「Apache PulsarとYJの取り組み」と題して、Apache Pulsarとはどのようなものか、ヤフーがやってきたこと、OSSデベロッパー制度について語りました。
- 栗原 望
- テクノロジーグループ システム統括本部 / OSSデベロッパー認定者（Apache Pulsar）
- 2012年ヤフー新卒入社。社内向けユーザーデータプラットフォームの開発/運用、ヤフオク!の基盤刷新プロジェクトなどを経験し、2016年から社内向けPubSubメッセージングプラットフォームの開発に従事。当時Yahoo! Inc.の内製プラットフォームであったPulsarのOSS化に協力し、2017年にApache Software Founcation配下のプロジェクトとなった後は、Apache PulsarのPMCとして活動。
Apache Pulsarとは
Apache Pulsarとは、pub sub messagingとかstreaming platform、message queue （MQ）などと称される類のソフトウェアです。競合としてはApache KafkaやRabbitMQなどが挙げられます。
もともとはYahoo! Inc.で社内向けのプラットフォームとして開発されていましたが、2016年9月にOSSとして公開。2017年6月にApacheSoftwareFoundationに移管されて、2018年9月にApacheのトップレベルプロジェクトに昇格しました。
Apache Pulsarの特徴には、以下が挙げられます。
- スケーラブル：データ量の変化に応じたサーバーの増減が容易
- 高スループット・低レイテンシ：大量のデータを高速にさばくことができる
- マルチテナント：一つのクラスターを複数の利用者が共有できる
- ジオレプリケーション：クラスター間のレプリケーションを設定一つで簡単に実現
最近のApache Pulsarの盛り上がりを象徴する二つのグラフがあります。2021年のApacheプロジェクトにおけるコミット数では、Pulsarは5位にランクインしており、Apache全体の中で見てもかなり活発にコード修正が行われていることがわかります。
右側の折れ線グラフは、PulsarとKafkaの月間アクティブコントリビューター数。Pulsarの月間アクティブコントリビューター数は、OSSとして公開されて以来順調に伸びています。
Yahoo! JAPANがやってきたこと
Pulsarは、ヤフー社内で全社MQというメッセージングプラットフォームのコアとして使われています。各サービスの利用者が一つのMQ、メッセージキューを共有して使っており、サーバーサイドの運用はクラウドプラットフォーム本部のMQ Team専用チームが行っています。
MQ TeamがPulsarクラスターを運用し、それを各サービスが利用することでリソースを集約しています。そして各利用者はサーバー側の運用を気にすることなく、サービス開発に集中できます。
社内で全社MQとして運用しながら見つけたバグをissue報告、あるいは修正しており、これまで400件以上のPull Requestを出しています。
Node.js Clientの開発も行っており、OSSとして公開しています。公開後も週1～2件程度、issueやPull Requestの確認や調査、レビュー作業を行っています。新バージョンのリリース作業なども業務の一環として、数カ月に一度程度の頻度で実施する予定です。
また、Pulsarの知名度向上とヤフーのプレゼンス向上を目的に、イベント出展や登壇、技術ブログなどでの発信も積極的に行っています。
OSSに関わって得られたこととして、栗原はこう語っています。
「さまざまな社外の優秀なエンジニアとの交流を通じて、個人の技術スキルを高めることができました。コミュニケーションで使われる英語力も向上したと思います。また、OSSとしてどうあるべきかという視点も得られました。たとえばプルリクのレビューを行う際も、取り込んでよいか、破壊的なバグはないか、汎用的な機能かなどを意識するようになりました」
OSSデベロッパー制度について
ヤフーが戦略的に採用しているOSSを対象としたコミッター活動の支援制度では、カンファレンスミーティングへの参加、直接業務と関係ないOSS関連の作業などを業務扱いにできます。また、イベント企画や運営に参加する交通費や出張旅費、物品購入など、年間100万円の活動予算が支給されます。
現状はコミッター限定の制度ですが、今後は対象者をコントリビューターまで拡大すると、より使いやすい制度になるという提案を語り、セッションをまとめました。
今回のLT会では、社内外問わず、専門技術の動向や取り組みについて発信する黒帯たちを紹介しました。興味を持った方は、ぜひ黒帯たちが登壇するセミナーやSNSでの発信情報などをチェックしてみてください。
