「ユビレジのチーム開発」についてお話しました #railsdm2019
2019/3/22〜23の2日間、Rails developers meetup 2019が開催され、
「ユビレジのチーム開発」というタイトルで初日に登壇しました。
発表資料はこちらです。
主催のカルパスさんからお声掛けいただいた時は思わず「なぜ私に…？」と聞いてしまったのですが、
ユビレジのメンバーが現場の話みたいなのをしてきたことって今まであんまりなかったので、そこら辺をお話できるとよさそうな雰囲気を感じたのと、
一方で現場の話となるとRailsよりもiOSの話の方がたくさんネタはある気がしたけど、Railsの話じゃなくてもOKな雰囲気を感じ、
かといってRailsdmでiOSの話するのも全然違うので、
個人的にめっちゃいいと思っているユビレジの開発環境について話してみることにしました。
結果、話し終わったあとの皆さんからいただいた反応をみるに、チームの良さみたいなのは伝えられたかなぁと思います。
あくまで個人の感想になってしまう「いいチーム」感を話して、聞きたい人はいるのか？と不安になりながら準備をしていましたが、
登壇一週間前に練習会をしたり、
社内でスライドのレビューをしてもらったりするなかで、
皆さんの前で話せる内容に成長できたかなと思います。
はじめての登壇はめっちゃ勉強になったしいい経験になったし本当に声をかけてくださった @yoshi_hirano 、練習に付き合ってくれた @youchan @rllllho @sinamon129 @_risacan_ 、スライドのレビューしてくれた @watson1978 @pomu0325 、そして当日聞きに来てくださった皆様に感謝の気持ちでいっぱい文字
— かとりえ (@katorie) March 23, 2019
残念ながら私は初日しか参加出来なかったのですが、
イベント自体とてもとてもとてもいいものでどのセッションも全部聴きたい内容だったので動画配信がめちゃ楽しみです。
特に初日一発目のDHHのリアルタイムでの登場には興奮しましたね！！
すでに各セッションの動画配信がはじまっています。
今回も1人振り返りしました。
全体的な所感としては、RailsGirls.rbでの反省点は改善することができました！
Keep
- 時間内に収まった
- 小話できた（時間内でおさまるか不安なだったから飛ばそうかと思っていた）
- 発表練習でのフィードバックを反映できた
- 社内でレビューしてもらえた
- Watsonさんのレビュー++
- Pomuさんのレビュー++
- 質問時間ちょっととれた
- 発表者ノートやめたことで柔軟に対応できた
- 皆さんの反応を感じながら話ができた
Problem
- 質問の意図間違えて答えた
- POの説明忘れた
- 普段の当たり前を言葉にして伝えるのむずい
Try
- 技術ネタで話す（まずはLTから）
- 登壇上から会場の写真を撮る
今回、練習会で小話が好評だったのですが、小話をしてしまうと発表時間内におさまらない危険性があって、それだけは避けたい…と思い、当日朝の時点で小話はすっ飛ばすつもりでした。
ですが直前に練習会メンバーにそのことを話したら、小話は是非するべき、とアドバイスをもらい、精一杯の早口で小話もして、時間内にどうにかおさめることができました。
あとでTwitterをみてみたら小話の部分も好評だったようで、よかったです。
Tryにも書きましたが、あらためて技術ネタで話せるようがんばりたいと思いました！
開発者？テスター？QA？ プロダクトの品質を向上させたい人🙌
年初めに「初めての自動テスト」という本を読んだんだけど、それまでに紆余曲折して読んだテスト関連の本のまとめと、今週のJaSST'19 Tokyo*1に参加するぞ！という話です。
- 作者: Jonathan Rasmusson,玉川紘子
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/09/21
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (2件) を見る
オライリーの書籍にはめずらしく、表紙がかわいい。
開発者だけじゃなく、テスターの方々にも向けた書籍だからかなぁ？
なんでこの本を読もうと思ったかというと、テストについて「なんとなく書いている」という状態が続いていたので、「きちんとテストについての考えなどがまとまっているものを読んでみよう」という気持ちがきっかけです。
個人的に2018年は「品質」について考えるようになった年だったので、まず最初にこちらを読みました。
こちらはこちらで知らないことがたくさんあって勉強になったのですが、どちらかというと視点が「テスターから」のもので、なんとなく「開発者 vs. テスター」みたいな書かれ方が多くて違和感を覚えていました。
一般的にどうなのかわかりませんが…ユビレジでの開発スタイルとはあまり合わない印象でした。
次にRubyの本を読んでいたらTDDに出会いました。
「テスト」という観点からこの本を選んだわけではないので偶然の出会いであり、意図した流れではなかったのですが…
プロを目指す人のためのRuby入門 言語仕様からテスト駆動開発・デバッグ技法まで (Software Design plusシリーズ)
- 作者: 伊藤淳一
- 出版社/メーカー: 技術評論社
- 発売日: 2017/11/25
- メディア: 大型本
- この商品を含むブログを見る
言葉としてのTDDは知ってはいたのですが、実際にどうするんだ？というのはよくわからなくて、この本を読み写経しながらTDDを体験しました。
それで、次はちゃんとTDDの本を読むことにしました。
実際に第1部をRubyで書いてみたりして、その技法を学びました。
そのうち、UIテストのことが気になりだして手に取ったのがこちらです。
Selenium実践入門 ―― 自動化による継続的なブラウザテスト (WEB+DB PRESS plus)
- 作者: 伊藤望,戸田広,沖田邦夫,宮田淳平,長谷川淳,清水直樹,Vishal Banthia
- 出版社/メーカー: 技術評論社
- 発売日: 2016/02/02
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (4件) を見る
これを読んで実際にUIテストを書きまくってみよう！と思ったのですが、そもそも自動化されたユニットテストや統合テストがしっかりあればUIテストはそんなにいらないのでは？（アプリの構成にもよると思いますが）
…と少し迷走しつつ、最初の本に行き着きました。（長い前置きでした）
で、最初に挙げた「初めての自動テスト」は、
まだ自動テストがない状態においてどんなテストを追加していくのがいいのか、小話を読み進めながら理解していくような、とても読みやすい本になっています。
プログラミングを始めたばかりの頃だったり、仕事として開発者やテスターになったばかりの頃に読むととても参考になるのではないでしょうか。
で、結局いろんな本を読んだ結果身についたことと言えば、「テストから書くようになった」ですかね👍
これまで結構デバッガを使って確認しながら開発して、期待通りの動きをするようになってからテストを書いてしまうことが多かったのですが、それが格段に減りました。
（TDDまでは出来てないのが現状です）
さて、今週はJaSST'19 Tokyoが開催されます！
私は職種としてはテスターでもQAでもありませんが、「プロダクトの品質を向上させたい人」として、初参加する予定です。
他の会社ではどんなことが起きているのか？
他の会社ではどんな方法で開発しているのか？
いっぱい吸収してきたいと思っています。
RubyやRails界隈の勉強会をメインに参加しているのでほとんど知り合いがいない状況なのがちょっと心配ですが…皆さん仲良くしてください🙇♀️🙏☺️
TokyoGirls.rb Meetup vol.1 で初めて登壇を経験した #tokyogirlsrb
2019/3/2に開催された TokyoGirls.rb Meetup vol.1 という素晴らしいイベントで、人生初の「登壇」を経験させていただきました。
登壇者は全員女性Rubyistということで、タイムテーブル見ていただくとわかるのですが、4人みんながいろんな方向から話をしていてバラエティに富んでいたと思うし、
託児スペースが設けられていて子育てしているエンジニアにも優しく、
勉強会参加自体が初めて！という方からエンジニアn年やってます！という方まで多様な方々が集まり、
控えめに言って最っ高なイベントでした！！
次回はスタッフとして関わりたいなぁ…
イベントがどんなに素敵だったかはみなさんのTweetからにじみ出ています↓
感想ブログもいくつか投稿されているので、 #tokyogirlsrb で検索してみてください！
いつもは関西にいらっしゃる伊藤さんにお会いできて感動した方も多かったのでは…
私もその一人です。（翌日のよちよち.rbも行きたかった〜！！）
私のスライドはこちらになります。
エンジニアとして仕事するようになってから今まで、会社やチームの変化はいろいろあったのですが、それをチャンスと捉えて私も変化してきたよ！という話でした。
発表テーマについては随分悩んだのですが、エンジニアになってからチーム開発によってたくさん学んだり助けられたので、そこらへんの話が出来たらいいなと思ってこのテーマにしました。
「子育てしながらエンジニアのお仕事している」というところの話を時間の関係で端折ったのですが、懇親会の時に声をかけてもらったり、Twitterの反応を見たりしていたら、そこがもっと聞きたかったという声がありました。
ここら辺は自分としてはモヤモヤしていたところで、子育てって特別なことじゃないから私が話す必要があるのかな？て思ったりしていたので、あんまり前面に出して話したくないという気持ちがありました。（それでちょっとブレてしまったかな）
でも参加者の方のブログを読んで、そうか！なるほど！と思いました。
こちらに森博嗣さんの文章が引用されていたのですが、これを読んでちょっとモヤモヤが晴れました。
（引用の引用になってしまうのでそれは避けますが、真っ直ぐ走るためには今まで右に寄っていたハンドルを左に寄せる必要がある、というようなことです）
今はまだ、ここで言う「ハンドル」を真っ直ぐにしたままでは足りない状況なのかな、と。その意味でも、とても意義深いイベントだったと思います。
またこういうテーマが求められる機会があったら、もっと振り切って話してみようかなと思います。
ちなみに、懇親会でいろんな方とお話させていただきましたが、多かった質問は
- 勉強時間どうやって確保していますか？
- 仕事復帰して大変だったことはなんですか？
でした。
とにかく「初めての登壇」という経験からいろいろ学んだので、登壇したことにフォーカスした一人振り返りをしました。
Keep
- 無事参加できた😂
- 初めて登壇した😆
- 懇親会で「前向きな気持ちになった」と声をかけてもらえた（めっっっっちゃ嬉しい）🙌
- 懇親会でたくさん質問してもらった🙏
- 子育てしながらエンジニアしてる人の話が聞きたい人がけっこういることがわかった（たぶん母側の話）👶👩
Problem
- 発表持ち時間を間違えていた😱（あらかじめすごく丁寧な登壇者向けの案内をいただいていたにも関わらず…本当に申し訳ございません…）
- 発表時間守れなかった🙇♀️
- 参加者の反応をみたりする余裕がまったくなかった😇
- 発表メモばかり見て話してしまった😔
Try
- 人前で話す練習時間をとる🎤
- 持ち時間確認する👀
- 発表メモはやめてみる🙅♀️
今まで発表を「自分が話す」という視点で見てこなかったので、いざ自分が話すとなるとどんなことに気をつけていいのかわからず、テーマを決めてスライドを作るので精一杯だったなぁと思います。
今回他の登壇者の方々がとても上手にお話されているのを見て、たくさん勉強になりました。
昨日登壇してみてわかったのは、やはり「人前で話す」という経験は人前で話さないと得られないということ。数こなしたらじょうずになるのかなぁ。
— かとりえ (@katorie) March 3, 2019
なんかこんな反省点ばっかり書くと温かく聞いてくださった参加者の皆さん、運営の皆さんには申し訳ないのですが、これから「初めての登壇」を控えている方々の参考になるかもしれない…と思ったのと、自分のために書きました🙇♀️
この経験を次の発表*1に活かしたいと思います！！
ユビレジのプロダクトをご紹介します！
Ubiregi Advent Calendar 2018 の最終日です！
このアドベントカレンダーは、私が「もっとユビレジ開発チームのことをみんなに知ってもらいたい！」という気持ちからはじめました。 開発チームに所属している人全員が記事を作成したわけではありませんが、「こんな人もいるんだ〜！」と垣間見えたらいいなと思っています。
というわけで初日は
という記事にしたのですが、そういえばユビレジのプロダクトについての説明がないな〜と（最終日になって）気づきました。
株式会社ユビレジは、 「サービス産業のためのデータインフラを整備する」というミッションを掲げ、
- ユビレジ（POSレジアプリ）
- FlickOrder（オーダーテイク用ハンディアプリ）
- StockScan（在庫管理アプリ）
の3つのプロダクトを主に提供しています。 アドベントカレンダーの最終日はあらためて、ユビレジの主要プロダクト３つをご紹介しつつ、どんな技術を使用しているか、一部をご紹介したいと思います。
なお、2018年12月25日現在の情報です。
ユビレジ（POSレジアプリ）
- iPad向けアプリ
- Objective-C / Swift
- Web管理画面およびサーバーサイド
- Ruby on Rails / React.js
- Heroku
- MySQL
- Ubiregi for Salesforce
「世界初のiPadレジ」として2010年8月よりサービスを開始しました。 iPad初代の製品発表が2010年1月だったので、着想からリリースまでが短時間だったことがうかがえます。
ユビレジは個人経営のお店はもちろん、複数店舗を運営・管理する場合にもご活用いただけるような機能開発を行なっていて、 メニューを一括更新できたり、顧客情報を同期できたり、管理画面から売上データを共有できたりと便利な機能がたくさんあります。 また、Salesforce と連携することができる Ubiregi for Salesforce でより強力な多店舗管理・分析が可能となっています。
iOS開発については、アドベントカレンダーの20日目の記事「ユビレジのリファクタリングについて」にもあるように、新機能を追加しつつ既存のコードのリファクタリングも継続的に行っています。
ユーザーの業態はやはり飲食系が多いですが、もちろん小売やその他の業態にも適応できるような汎用的な機能となるよう心がけて開発しています。
また、ありがたいことにサービス開始当初よりずっとユーザーも増えているので、パフォーマンス面での改善についても日々取り組んでいます。
FlickOrder（オーダーテイク用ハンディアプリ）
- iPhone / iPod touch / iPad向けアプリ
- Objective-C / Swift
- サーバーサイド（ユーザーが操作する管理画面はありません）
- Scala
- Google App Engine
- Google Cloud Datastore
ユビレジと連携して使用できるハンディアプリとして2012年12月にサービスをスタートしました。 複雑なメニュー設定にも対応していて、特に飲食店でご活用いただいています。
個人的な感想ですが、FlickOrderは飲食店のオペレーションをよく考慮されていて、ユーザーのニーズがたくさん反映されていると思います。 複雑なメニュー設定ができることや、オーダー時の伝票印刷の出し分け設定ができることがなどがあげられます。 あまりここでは詳しい操作について説明しませんが、ほんとうに豊富な機能をもったハンディなんですよ…！！
FlickOrderの開発をはじめたのは17日目の記事を書いた@pomu0325さんで、現在はCPOとしてユビレジのプロダクト全体を統括しています。 たまにランチなどで開発秘話を聞くことがあります！
StockScan（在庫管理アプリ）
- iPhone / iPod touch / iPad向けアプリ
- Web管理画面およびサーバーサイド
ユビレジと連動して在庫管理ができるアプリです。リリースは2013年3月です。 会計が完了するとその商品の在庫が減って、設定した個数になるとアラートがあがったり、 複数店舗で使用していれば、商品の移動を依頼したり、依頼された側から出庫した連絡をしたり、 管理画面からは発注先への書類が自動作成できたり、 …と、機能豊富なサービスです。 おそらくこのアプリを使わないで在庫管理しようとすると、たくさん「紙の書類」が必要になると思います。 それをアプリだけで完結できるようになります。
個人的にいいな！と思う点は、「倉庫などにインターネット環境がない場合」を想定したサービスになっているということ。 オフラインでも動作して、オンラインになったときにきちんとデータが反映されるようになっています。
まとめ
最終日にふさわしく（？）サービス産業のためのデータインフラを整備したいユビレジの主なプロダクト3つをご紹介させていただきました。 これらを開発・運用しているのがユビレジの開発チームです。
ある程度はチームのメンバーがオペレーションを想像して開発しますが、基本的には現場の声をCSや営業の方々からヒアリングしたり、データをもとに予測・検証したりしながら、より現場のユーザーが使いやすいプロダクトを目指して開発・運用しています。
例えば新しい機能を追加するときには、UI案を全社員が見ることができるホワイトボードに貼り出し、自由に意見を付箋に書いて貼ってもらったりして、全社員からフィードバックを受けられるようにしています。 …この辺の話もユビレジの開発フローのとてもいいところだと思うので、機会をみてご紹介できるといいなと思います。
最後になりましたが、こんな感じのユビレジ開発チームでは、一緒にプロダクトを成長させるメンバーを募集しています！ おもしろそうだなーと思ったらぜひ一度ご連絡ください！
追伸：開発チーム、Webチームのみなさん
私の「やりたい！」ではじまったアドベントカレンダーに、記事を書いたり、画像を用意したり、レビューしたり、Twitterでシェアしたり、みなさんがたくさん協力してくれました。本当にありがとうございました！
投稿記事：[続] iPadの見分け方 mini編
今日はクリスマス・イヴですね🎄
今日は Ubiregi Advent Calendar 2018 24日目の記事として、あの iPadの見分け方続編として、iPad mini の見分け方をお届けします！
私はどちらかというと mini 愛用者で初代と4を持っています。
なので iPad よりは見分けられそうな気がする！！
iPad miniの見分け方
iPad mini
https://support.apple.com/kb/SP661?locale=ja_JP&viewlocale=ja_JP
- この後のベースとなる機種で、この後筐体のデザインに大きな変更はありません。
- Retinaディスプレイではありません！
iPad mini 2 (Retinaディスプレイモデル)
https://support.apple.com/kb/SP693?locale=ja_JP&viewlocale=ja_JP
- Retinaディスプレイになりました。
- マイクがデュアルマイクロホンになりました。
- カラーバリエーションがスレートからスペースグレイに変更されました。
iPad miniと見分けるには
- 暗い色はスレートからスペースグレイに変更されて明るくなっている
- 背面左右中央にマイクが付いている（従来はイヤフォン端子の近く）
iPad mini 3
https://support.apple.com/kb/SP709?locale=ja_JP&viewlocale=ja_JP
- Touch IDが採用されました。
iPad mini 2と見分けるには
- ホームボタンがTouch IDに対応している（素材がガラスになっている）
iPad mini 4
https://support.apple.com/kb/SP725?viewlocale=ja_JP&locale=ja_JP
- スペックの底上げがされました。（現行モデル）
- マルチタッチ・ディスプレイのガラスが薄くなったため、タッチスクリーンのフィーリングが変わりました。
iPad mini 3と見分けるには
- サイレント/画面回転ロックスイッチがない。
「BugMashプロジェクト」という取り組みについて
Ubiregi Advent Calendar 2018 13日目の記事です。
昨日の利きiPadの記事はいかがでしたか？
写真がなくてよくわからなかった？
はい、そうですね。
これを読んでもとても見分けられる気がしない？
はい、そうですね。
そもそも見分ける必要があるのか？
長い人生、もしかしたらそんな時もあるかもしれません！
利きiPadサイコー。身に付けたいスキル。: "iPadの見分け方" - katorieのブログ https://t.co/tapxWmYJSn
— kishikawa katsumi (@k_katsumi) 2018年12月12日
なるほど！ iPad mini や iPad pro についての続編が楽しみです。
今日は、開発チームで最近はじめた「BugMashプロジェクト」についてご紹介します。
「BugMashプロジェクト」とは
ユビレジ開発チームでは GitHub の issue を使ってバグのレポートや機能改善の提案を管理しています。
issue にはバグレポート以外の内容（例えばUIデザインやAPIの設計についてなどなど）も投稿されており、議論したいことがあればひとまず issue を立てる、という文化です。
なので各リポジトリの issue はけっこうな数になっています。
（他の会社さんでどうやっているのか聞いてみたい）
そして、スクラムチームには「バグマッシュデー」があります。
2 週間のスプリント期間で機能開発しています。この期間内にはバグマッシュデーという「普段の開発では見落とされがちな軽微な不具合の修正や技術的な調査をしたり、メンバーが自由にプロダクトに貢献」できる日が用意されています。
（RMagick の ImageMagick 7 対応の進捗 - @watson1978 の日記 より引用）
このバグマッシュデーに取り組む内容については個々人に委ねられていますが、
issue から取り組む課題を探すというメンバーももちろんいて、
そんな時に「どの issue にしよう？」と思い悩まなくてもいいようにある程度優先順位がついていると嬉しいなと思いました。
そこで、GitHub の organization にある Projects に「BugMash」というプロジェクトを作りました。
ちょうど Bug triage というテンプレートがあったので、こちらを利用しています。
プロジェクトやテンプレートについて、詳しくは公式ヘルプをご覧ください。
About project boards - User Documentation
カンバン形式なので見渡しやすく、organization 配下に作成するとすべてのリポジトリの issue を扱えるので、とても便利です！
この機能で issue の優先順位をつけて消化を促すことを「BugMashプロジェクト」と呼んでいます。
運用方法
まずプロジェクトにカラムを用意しますが、テンプレートを使用すると Needs triage、High priority、Low priority、Closed というカラムがあるのでほぼそのまま使用しています。
（四半期ごとにクローズされた issue の数がわかるといいかなと思ったので、期が変わるタイミングで Closed カラムを追加していく予定です。）
「これはバグマッシュデーにやると良さそうだな」という issue のページで右カラムにある Projects で「BugMash」を選択すると、自動で Needs triage カラムに追加されます。
バグマッシュデーまでに、担当者（現時点では私がやっています）が優先順位をつけておきます。
Bug triage カラムから Row か High か判断してカードをググッと移動させ、High priority カラムのなかでも、特に早めに対応したほうがいいやつをググッと上に移動させておきます。
（このへんはさすがにちょっと画像でお見せできなくてすみません）
バグマッシュデー当日は、「これやるぞ！」という issue の Assignees に自分をセットすれば、カードにアイコンが追加されるので、誰がやろうとしているのかすぐ把握できます。
あとはPRを作るときに issue の番号をコミットコメントに入れるのを忘れずに！
PRのマージとともにクローズできれば、カンバンも自動更新されます。
効果はあるか
この運用をはじめたのが2か月くらい前で、バグマッシュデーが2週間に1度（そして祝日があった）なのでまだ消化された数は多くないのですが、
今まで issue をたてた個人に頼りがちだった進捗をチェックするようになったり、
過去に立てられて埋もれてしまっていた issue が動かせたりと、
少しずつ効果を感じています。
今後の目標としては、優先度をつけるにあたっての根拠となる情報を集め、
より効率のよく品質向上に結びつけていけるといいなと思っています。
「うちのチームこういう取り組みしているよ！」とか
「もっとこうしてみるといいかもよ！」とか
コメントいただけると嬉しいです。
投稿記事：iPadの見分け方
こんにちは！
Ubiregi Advent Calentder 2018 12日目の記事です。
今日は某iPad芸人さんから投稿いただきました「iPadの見分け方」を転載します。
いわゆる「利きiPad」という技の伝授ですね。。
はっきり言ってこの記事を読む皆さんに需要があるのかよくわかりませんが、ひろ〜いインターネットの世界でどなたかの役に立つこともあるかもしれません…！！
先に言っておきますが、ユビレジの開発チームで仕事するのに利きiPadは必須スキルではありません！！
iPadの見分け方
BtoB向けのiPadアプリ開発をしていると、様々な世代のiPadを利用されているお客様のサポートが必要となります。
その際に、電話対応やお客様から送られてきた写真から、iPadがどの世代かを見極める、いわば鑑定士のスキルが求められるのです。
iPadの電源が入るとは限りません。筐体で見分けられるようになりましょう。
では、iPadの違いを見ていきましょう。
iPad(初代)
- Steve Jobsが掲げていた、あの形を思い浮かべてください
- 初代のみ大きく形が違うので、これは簡単です。
- 今から振り返ると驚きですが、なんとフロントカメラがありません！
iPad 2からiPad 第4世代の見分け方
iPad 2
- この後のベースとなる機種です。
iPad 第3世代
- Retinaディスプレイになりました。
- iPad 2よりも分厚くなっています。
iPad 2と見分けるには
- カメラの形状が異なる。
- レンズの中の開口部の大きさが違う。
iPad 第4世代
- 端子がDockからLightningになりました。
iPad 2と見分けるには
- Lightningコネクタがある。
iPad AirからiPad第6世代の見分け方
iPad Air
- CPUのアーキテクチャがarm64になりました。
- ベゼルが細くなり、この後のベースモデルとなりました。
iPad Air 2
- 筐体がさらに薄くなりました。
- マルチタッチ・ディスプレイのガラスが薄くなったため、タッチスクリーンのフィーリングが変わりました。
iPad Airと見分けるには
- カメラが出っ張っている。
- 筐体のエッジに加工がある。
- サイレント/画面回転ロックスイッチがない。
iPad 第6世代
- 新しいiPadという名前を掲げて、廉価モデルとして登場しました。
iPad Airと見分けるには
- マイクが背面中央にある。
これで、iPad初代から、第6世代までが見極められるようになりましたね！
iPad mini, iPad Proなどはまた後日。
