neputa note

2021年5月31日(月)18:30、「たりないふたり」という漫才ユニットの無観客配信ライブを見た。

6月8日まではアーカイブ配信があるとのことなので期限を待って、ごくごく私的な感想ではあるが、思いの丈綴った長文駄文をネットの海に流したいと思う。

※祝・アーカイブ延長。6月13日(日)23時59分までアーカイブの公開が延長されるとのことで、この感想公開は6月14日(月)00時00分に変更した。

「たりないふたり」とは

「たりないふたり」とは、お笑いコンビ「オードリー」の「若林正恭」と、「南海キャンディーズ」の「山里亮太」によるお笑いユニットである。

2009年のお笑いライブで誕生したこのユニットは、2012年に日本テレビで番組放送が行われて以降、数々の素晴らしい漫才を披露してきた。

お笑い界、芸能界を全力で駆け抜けてきた二人が節目節目で再会しセンターマイクの前で披露してきたものは、「漫才」以上の何かであった。

しかし約12年続いてきた「たりないふたり」の活動は、今回のライブを区切りに解散となる。

これまでの集大成となる今回のラストステージは、3万5千人以上ものファンが見守る中、大きな笑いと感動の渦を巻き起こす素晴らしいものとなった。

「たりないふたり」との出会い

私はもともと「昭和のいるこいる」、「爆笑問題」といった関東の漫才師が好きで時折テレビやDVDで漫才を見てきた程度のお笑いにわかファンだった。

爆笑問題の太田光さんはその人間としての魅力にも興味をもつようにはなったが、お笑い芸人、漫才師としての枠を超えて、一人の人間の生きざまに魅せられるほどドはまりしたのはオードリーの若林正恭さんが初めてのことだった。

2008年にナインティナインの「おもしろ荘」という番組で初めてオードリーの漫才を見てファンとなった。

ただミーハーではないので週末の「オードリーのオールナイトニッポン」や、漫才を披露する番組のみを追いかける、ややストイックなスタイルでの追っかけ方ではあった。

そして、私は称賛を集めやすいパフォーマーよりも、ゼロイチで奇跡の種を生むクリエイターを好きになる傾向がある。
当然の帰結として若林さんを特に好きになった。

もちろん、若林さんの作る漫才を存分に演じ切る春日さんも素晴らしい。
時に誰もまねできないような特大ホームランをぶっ放す芸当は、若林さんとはまた違った魅力がある。

若林ファンとしては当然、南海キャンディースの山里さんと共に始まった「たりないふたり」の活動にも注目することとなる。

山里さんは、Ｍ１グランプリをキッカケにその存在を知ったが、彼の持つ本当のすごさや面白さは若林さんを通じてのものだ。

いよいよ終わってしまう「たりないふたり」、しかし始まってもう12年である。

12年という時間は人生において中々にして長い期間だ。

それを競争が激しい芸能界で活動する期間として考えた場合、私は外の人間なので詳細には分からないが、気が遠くなるほどの長い時間だと想像する。

それだけの期間、別々のコンビの芸人が活動を続けてこられたことは奇跡と言っても過言では無かろう。

実力や努力だけではいかんともしがたい世界であろうし、ましてや彼らは、ユニット名のとおり「たりない」二人である。

常にハンデ戦を強いられているようなものだ。

だが彼らは「たりない」を武器に、猛獣たちがひしめく芸能界を相手に果敢に挑戦し、12年の期間を走り続け、共に一線で活躍するまでにいたった。

「たりないふたり」が披露する漫才にはその時々の彼ら自身の人生が色濃く反映されている。
強烈な若林さんのボケと山里さんの鋭いツッコミに大いに笑い、彼らの関係性や生きざまに魅せられる。

こんなにも濃厚でおもしろい漫才は他では見ることができない。

満を持して、「無観客」というこれまでにない苛酷ともいえる環境で繰り広げられた漫才は、これまで以上に笑いも涙も止まらない内容だった。

「明日のたりないふたり」の感想

昨年の「たりないふたり秋」からラジオでの場外乱闘を聞き届けてからどれほど心待ちにしていたことか。

18時30分丁度、時間通りにいよいよ「明日のたりないふたり」が開幕した。

まずはこれまでの「たりないふたり」をダイジェストで紹介するVTRが流れる。

映像に映る彼らの姿を見つめながら、その時々の自分の人生で起きた出来事が重なって思い起こされる。

序盤にしていきなり「グッ」と来てしまった。

出囃子が鳴り無観客の中、センターマイク前に二人が登場する。

観客のいない独特な雰囲気が画面越しに伝わってくる。

若林さんはラジオで話すときのような落ち着いた語り口で、初っ端からこれまでの経緯をギュッと凝縮したようなボケをかましてくる。

山里さんはややかかっているような前のめり感がありつつも、小気味よくお得意のワードセンスで打ち返す。

いよいよ始まったなあと、早くも実感が湧いてくる。

しかし始まってモノの五分も経たたずに、これまでになかった無観客という未知の空間を自分たちのフィールドへと塗り替えてしまう。

なんというか 腕がえげつないなと圧倒される。

冒頭の「実力者二人がやるわけですから漫才になっちゃう」という言葉はボケではなく、真であることが証明され笑う。

ここ最近の「たりないふたり」は台本がほぼないとのことで、若林さんが繰り出すボケの千本ノックを山里さんが全力で受け止め打ち返すラリーがアドリブで繰り広げられる。

若林さんは、山里ノートを巧妙に封じ、じわじわと追い込むことで絶妙な切り返しをうまいこと引き出している。

これは二人の腕と、互いの分厚い信頼による賜物であり、見どころとなる大きなポイントである。
だが、何より最高に楽しそうであることが面白いし嬉しいのだ。

開幕からのトークでコンディションは上々であることがわかり、「カイジの一本橋」を使ったノックが繰り出される。
どれもこれも面白いが、個人的には「イ～ケ～ア」「バキバキっ！」、「イ～ケ～ア」「バキバキっ！」が好きだ。

余談だが、私は「あちこちオードリー」のグッズTシャツを着て近所のイケアによくご飯を食べに行ったり買い物に出かけたりするがまだ怒られたことは無い。

続いていまやMCとしての仕事をいくつも抱えるようになった二人が共演者を励ます設定に入る。

様々なタレントの名前を出していき、最後はトークがうまくできなかったアイドルを若林さんが演じ、山里さんがMCとして励ますネタは果たしてどうやって思いつくのか、腹が痛くなるほど笑った。

しかし12年という時間は残酷だ。
若林さんの息切れがあまりにひどく、老いから感じる時間経過が沁みる一方で、老けた若様がめくちゃくちゃおもしろい。

12年前からはとても想像がつかないが、いまや二人とも結婚し奥さんがいる身となった。
だからこそできるようになった若林夫妻が、山里夫妻の家に招かれるという設定。

こんな設定が実現する日が来るとは目出たいじゃないかと思うのだが、いきなり風俗の話に脱線し盛り上がる次第。

ステージには二人だが、そこにいないはずの「にょぼばやし」がボケる姿が目に浮かぶ。
「バンクシーか！」「落書きするな！」
瞬時に状況を判断し的確にツッコむ山里さんもすごい。

ダメ出しに弱い山里さん、「ダメ出しを女王様の言葉責めだと思えば快感に変わる」という若林さんの提案から、桜木町で登場した女王様が登場。

「М」は山里を覚醒させる。

若林女王様のムチを合図に、いよいよ「たりないふたり」の核心へと入り込んでいく。
それにしても「Mの覚醒」を果たした山里さんの舌の滑らかさは尋常ではない。

何部作かわからないぐらい「クローズ！」を連発していた山里さんの、最もNGワードは「アップデート」だった。

序盤でちらりと顔をのぞかせていた、受口で歯が無いおっさんが客席に登場する。

観客に扮し客席にいる若林さんと、演者として舞台に立つ山里さんの掛け合い。
こんな光景、いまだお笑いライブで見たことない。
このあたりで、私の中に爆笑と感動のカオスが大きな渦を作り始めた。

「オレは、秋も好きだよ」

この「秋」とは、山里さんが若林さんにどっちが上か下か論争を持ちかけて拗ねるというクズっぷりを発揮した出来事であり、結構な騒動のキッカケともなった。

ふいに放たれた、その「秋」を肯定するこの言葉。
この言葉はデカい音を鳴らし私の胸に響いた。

若林さんが繰り広げるワールドはここで一気にギアが上がり加速していく。

「アップデート」というワードにピリピリしていた山里さん。
いよいよこれまで自分のメインウェポンであった「自虐の竹やり」を捨て去ることを迫られる。

後ろ髪を引かれる思いを断ち切り、無観客の客席という池へと投げこむ。

池から、若林さん、いや神様が顔を出し、「お前が捨てたのは『自虐の竹やり』か、それとも『人間力のマシンガン』か」、と問う。

山里さんは、迷いに迷いながら「人間力のマシンガン」を選択する。

自分で磨きに磨き愛してきた「自虐の竹やり」を捨て、女優さんと結婚しいまや大物MCへの道に片手をかけるところまできたこれからの山里亮太に相応しいのは「人間力のマシンガン」であると。

「お前、竹やり捨ててんじゃねーぞっ！！！！！」

観客のいない客席から、「若林正恭」という一人の剥き出しの人間が全力で叫ぶ。

このことは、ラジオで若干の伏線は引かれていたが、これほどまで深いものであったとは。
彼の心の底からの叫びに奮えた。

「たりないふたり」とは、「たりない」を「たりる」に変えていく成長のプロセスだと思っていた部分があった。

劣等感やネガティブは悪いもので、変えていかなければならないものだと、いつしか思い込んでしまっていた。

だが、若林さんがたどり着いたのは、「受容」という境地だった。

自虐を愛する山里亮太も、彼らのみならず全国にいる「たりない」たちの足りなさも、すべて肯定することが、芸人・若林、いや人間・若林正恭が導き出した答えだったのだ。

山里さんが投げ捨てた「自虐の竹やり」を、若林さんは山里さんの手に戻してやろうと客席をぶっ壊しながらステージへ帰還する。

無観客だと演者は客席を破棄することができる。
新たな知見を得た。

再び自虐の竹やりを、若林さんの手によって取り戻した山里さんは、これからの未来に向けて「竹やり訓練」を行う。

若林さんが「ネットを探して見つけてきた山里が返しづらいであろう文言」を、山里さんは見事に「自虐の竹やり」でことごとく打ち返す。

「自虐」は山里を覚醒させる。

「M」と「自虐」は、山里亮太を何倍もスケールアップさせる。

最後の訓練は「co-opのトラック」、と思いきや「ワカバヤ・シン」。

山里さんがエヴァの設定にいまいちピンと来てない感じがおもしろさを増す。
山里さん自身が「シンジ君」だから、そもそも縁がなかったのか。

ワカバヤ・シン、いや若林さんはここ最近の「たりないふたり」では見られなかった、強烈な自虐によって自らのコアを破壊しようと試みる。

人間力のマシンガンは、その実、モデルガンだった、という若林さんの独白。

「ロンギヌスの槍」と思いきや、「ワカバヤ・シン」が取り出したのは「自虐の竹やり」だった。

笑いと感動は完全なる均衡を保ち始め、鳥肌が止まらなくなる。
このあと下北沢を爆心地とした「フィフス・インパクト」が起こるのではないかと思う瞬間であった。

今回もまた、エンディングに向けて「汚いヘリコプター」が迎えに来る。

ブリブリ跳ぶヘリに二人が数珠つなぎにぶら下がり叫んでいた。

たりないふたりは、最高のたりないふたりを生み出しただけじゃないかと。

これまでもそうだし、今回もそうだった。

最高のたりないふたりが、最高のたりないふたりを生み出し、そしてその光景をこれから世に出てくる最高のたりないふたりたちが見つめている。

ステージ上で、漫才師二人ともが仰向けに倒れ、無言無音の時間が続く。

状態だけを言い表せば、大事故のような状況だが、ここの余韻は美しく愛おしい時間だった。

力尽きるように倒れる二人への羨望と感謝ともうすぐ終わってしまうのだという寂しさが入り混じる、何とも言えない感情だった。

座り込んで話し込みだす二人。

山里さんが直後のラジオで「若ちゃんがライブ終わりで近くの公園で漫才やろうって言っていた、あれを今回本当にやるんだと思った」と話していた。

公園でひとしきり二人きりで漫才を全力でやった後の光景が目に浮かんだ。

「空がきれいだ」とつぶやいた若林さんのその目には、近くの公園で寝転がって眺めた空が映っていたのかもしれない。

若林さんはもう完全に素になってしまっているようだった。

「たりなくてよかった」

否定ではなく、変化の強要でもなく、ただ受容する。

簡単なことのようで、とてつもないエネルギーと時間を必要とすることだけど、その道のりの先にどれだけ素晴らしいことがあるのか、二人は体現してくれた。

真っ白な灰になった二人が顔を上げると、そこには彼らが生み出した次世代のたりないふたり「Creepy Nuts」が。

もうこれで号泣しないわけがない。

全たりないが泣いた。
私の涙腺も完全崩壊した。

抑えきれない涙を流しターンテーブルを繰るDJ松永、渾身の力を込めフリースタイルでリスペクトを謳い上げるR指定。

そして、この瞬間をまた次の世代の「たりない」たちが見ていただろう。

無観客オンライン配信という環境での締めくくりとなったが、この2時間、いや12年間を私は決して忘れることはないだろう。

その身を投げうち漫才を披露し続けてくれた若林正恭さんと山里亮太さん、安島さんを始めとするスタッフの皆さまに、心から感謝を込めて拍手を送りたい。

ライブを見終えて

表現手段を持たない私のような市井の「たりない」は、日常で起こる「たりないジレンマ」をグッと飲み込み、「たりてる擬態化」をしながら日々を生きている。

いつか、「自分はたりてる側の住人」だと錯覚し、知らないうちに自分が何者であるのかを失っていってしまう。

そして、それが続くと人は死ぬ。きっと。

しかし私には「たりないふたり」との出会いがあった。

彼らの漫才を見るたびに、自分が何者であるのかを思い出し、取り戻すことができる。

そしてまた、明日を生きることができるようになる。

今回、解散となってしまったけれど、私は明日からもこの先をずっと生き続けられる勇気をもらうことができた。

ずっとたりなくてもいいし、それで戦っていくことを宣言した今回の解散ライブでの二人の姿を見て、同じことを感じた人は数多くいることだろう。

「たりないふたり」が表現してきた漫才は、確かに当初からの物語を知ることによって、何倍にも思い入れが増幅し、面白さが増す要素はあるが、それ単体としても素晴らしいものだと思っている。

冒頭でも書いたが、漫才を超えた何かだと思う。

洋の東西を問わず、すべての舞台芸術を見渡してみても、これほどのものはそうないのではないか。

同じ時代に生まれ「たりないふたり」を目撃できたことは、私の人生における大切な宝物だ。

できれば、ひとりでも多くの人に巡り会ってほしいと切に願っている。

「たりないふたり」を見るには

■公式サイト ■Hulu

過去の放送は、Huluで見ることができる。

また解散ライブとなった今回の「明日のたりないふたり」も、いずれ何らかの形で公開されると思う。

今回見ることができなかった方も、辛抱強く待ってぜひぜひ見てほしい！

他の「お笑い」に関する記事

以前、漫才コンビ『Dr.ハインリッヒ』に関する記事を書いた。

興味がありましたら読んでくれたら嬉しい。

今日の昼頃、父から電話があった。

「明日の納骨、お母さんに確認してあるか？きっと忘れてるからちゃんと言っておかないと。」

ちなみに両親は同居している。

いまの時間帯は近くにおらずとも、夕方か夜になれば帰ってくるだろう。

そうしたら直接言えばいいではないか。

そんなことはもう長年に渡り繰り返し伝えたし、もう随分前に二度と言うまいと誓ったのだ。

だから私は、「おととい、コロナワクチン予約のことでお母さんから電話があって、その時に伝えてあるよ」と話し電話を切った。

ちなみにもうひとつ、「納骨」というのは、３月に亡くなった妹のお骨を家族の墓に入れる予定が明日の１３時であるという話しだ。

そしてつい先ほど、母から電話がかかってきた。

「簡保(終身医療保険)の満期支払の通知が来たんだけど前回と比べて大幅に少ない」という話しだった。

この商品は、最終払込みから85歳まで5年おきにお祝い金が支給されるものであることを私も承知していた。

ちょうどパソコンを開いた状態で電話に出た私はソッコー検索した。

減額要件は２つ、入院手術等で保険金支給を受けたか保険を担保とした借り入れをしたか。

あなたは４年前に脳梗塞で入院したではないか。

また、以前父がその借り入れを勝手に行ったことを愚痴っていたではないか。

いずれにしても、まず確認する相手は父ではないか。

この時間なら近くにいるだろう。

そんなことはもう長年に渡り繰り返し伝えたし、もう随分前に二度と言うまいと誓ったのだ。

だから私は、「減額の理由を近くの簡保窓口に行って確かめるといいよ。説明がわかりにくかったり納得できない場合は後日一緒に行くから」と伝え電話を切った。

両親はまったくということは無いであろうが互いに口をきこうとしない。

その光景を目の当たりにするたび、私は絶対にこうはなるまいと心に誓う。

そして妻に「ずっと仲よくしよう」と唐突に伝え、不思議そうな顔をされるのだ。

両親も若いころは今の私と同じように、「問題があったらちゃんと話し合おう」「ずっと仲よくしよう」と思っていたのだとしたら、キツイ。

若いころはどうだったのか、私は絶対に両親に確かめることはないだろう。

本記事の概要

『Xamarin.Formsで開発したAndroidアプリのパッケージサイズを圧縮しようと「Linker」「d8/r8」コンパイラを駆使したが、敗北する』、です。

アプリのパッケージサイズが気になる

先日、初めて個人開発したスマホアプリ(Android版のみ)をリリースしました。

こちらでインストールできます
※アンドロイド版のみです。iPhoneユーザの方すみません。

色々と不具合問題で話題となっている「COCOA - 新型コロナウイルス接触確認アプリ」の影響もあり、すっかり悪いイメージがついた「Xamarin.Forms」で開発しました！！

Xamarin.Forms は直接Android、iOSのAPIを叩いて実行するアプリを作れるので、ネイティブ開発と比べて特別に劣るということも無いとは思うのです。

思うのですが、monoランタイムを抱えていることもあり、パッケージサイズが大きくなりがちです。

現在リリースしているバージョン1.0.4の時点で、ダウンロードサイズは34MB、インストールしたアプリサイズは49.45MBと、アプリの内容を考えると「で、でかいぞ……」と感じるわけです。

これをどうにかできないかと悪戦苦闘し、敗れる(つまり未可決)という、残念な内容な記事となります。

情報価値はゼロと思いますが、もしよろしければ暇つぶしにどうぞお付き合いください。

Xamarin.Forms だってダイエットしたい

参考にしたサイトはこちらになります。
Xamarin.Forms - Android App Performance and Package Size Reduction
Reducing iOS and Android App Size in Xamarin

サイズを小さくする方法はいくつかあります。

1．R8 Shrinker を使用する

2．Linker を使用する
Android でのリンク - Microsoft Docs

3．AOT＆LLVM コンパイラを使用する
アプリケーションを保護する - Microsoft Docs

この中で、３番目のAOT＆LLVMは、Visual StudioのEnterpriseエディションライセンスが必要なので、わたしは残念ながら利用できません。

では、最初の２つを使用すればいいじゃないかとなりますが、そうは簡単にはいかないのですね。

まずは、「R8 Shrinker」と「Linker」について、調べてみたことを簡単にまとめたいと思います。

R8 Shrinker

これは、Javaバイトコードを対象に未使用コードを削除してくれる機能です。
（ネイティブ開発と異なり、Xamarin.Forms では難読化の恩恵は得ることができません）

※ちなみにこれを書いている2021/3/12時点では、「R8」の他に「ProGuardを有効にする」という選択肢があります。 R8はProGuardを置き換える目的で開発されたもので、ProGuardを選択するとビルドで「R8」を使えと怒られます。

軽量化に役立つなら使えばいいじゃない、そう思うことでしょう。

なんの備えもなくこいつを選ぶとあら不思議、わたしのアプリは見事クラッシュします。

いろいろと対処をいないと使えないことがわかったので、必要事項を後述します。

Linker

これは、静的解析により不要と判断したコードをばっさり切り捨てることで軽量化を図る機能です。

オプションとしては、「一切使用しない（なし）」「SDKのみ対象とする（SDKアセンブリのみ）」「すべて対象（SDKおよびユーザアセンブリ）」の３つがあります。

現在は、SDKのみを対象としており、わたしが書いたコードおよび追加したNuget Packageについては対象外となっています。

で、SDKとユーザアセンブリすべてを安易に選ぶとあら不思議、わたしのアプリは見事クラッシュします。

R8 Shrinker、Linkerどちらも何もせずに使えるわけではなく、導入するにはそれなりの準備が必要となります。

R8 Shrinker を使うために行った作業

まずは、Visual Studioのツール→Android→Android Device Monitorで、クラッシュ原因を見てみましょう。

「FATAL」があるあたりを見てみると、こんなメッセージがあります。
java.lang.ClassNotFoundException: Didn't find class "com.google.android.gms.ads.MobileAdsInitProvider"

わたしのアプリには「Google AdMob」という広告表示用のプラグインがあるのですが、起動時にそんなもん見つかんねーよと言われておるのですね。

つまり、「R8 Shrinker」さん、「軽量化するため余計なコードぶった切ったけど、お前が追加したパッケージとかも切り捨ててやったよー」ということでしょうか。

R8 Shrinkerを使用していると、Androidプロジェクトフォルダ配下の「obj\Release\XXX\proguard」に「.cfg」拡張子のファイルがあります。（XXXは、お使いのエミュレータのバージョンが入ります)

これらのファイルを見てみると、「-keep class XXXX」という記述がずらりと並んでいます。

これは、コンパイル時に切り捨てずにキープ対象となるライブラリ名がずらりと書かれているのですね。

obj配下にあるファイルは自動生成されたものです。

これとは別に自分が追加したパッケージ等をkeepするために設定ファイルを用意する必要があります。

例えば「my_proguard_xamarin.cfg」というファイルをAndroidプロジェクトに追加し、「ビルドアクション」を「ProguardConfiguration」にしておきます。

こうすることで、ビルド時にこの設定ファイルを読んでくれるようになります。

ちなみに、自動生成された.cfgファイルをコピーして設定ファイルを作る場合、ファイル内のBOMがビルドエラーの原因となるので対応するエディタ等でBOMを削除する必要があります。

あとはひたすら、トライ＆エラーです。

エラー原因となったライブラリを設定ファイルに追記し、Android Device Monitorで確認、また別のエラーが出たらそれを追記、そしてまた……。

わたしの場合、最初のAdMobに続いて、AdMobに関連する「com.google.unity.ads.UnityAdListener」、そして「androidx.work」、が原因ではじかれ、そのつど、ファイルにKeepを追加しました。

一番厄介だったのが、Splash screenのファイルに問題があるとエラーが出て、いろいろ調べた結果「Calligraphy」をアップデートしろという情報を見つけ対応したことです。

R8を使用していなければ特に問題は起きていなかったので、R8に関連してCalligraphyのバージョンが問題となるのかいまいち原因ははっきりせず。

Crash on Android 10 - stack overflow Calligraphy.Xamarin

結果として以下のような.cfgファイルを作成し、何とかアプリが起動するところまでたどり着きました。

-keep class com.google.unity.** {
  *;
}

-keep public class com.google.android.gms.ads.**{
public *;
}

-keep public class com.google.ads.**{
public *;
}

-keep class androidx.work.** { *; }

-keepattributes Annotation

R8については以上となります。

Linkerでユーザアセンブリも対象にする

続いて、Linker。

もっともパッケージ圧縮の恩恵が大きいのは「SDKおよびユーザアセンブリ」を選択すること。

しかしこちらもR8 Shrinker同様、必要な設定を施さないと、わたしの場合はアプリが見事にクラッシュしました。

行う作業も同様で、Linkerで切り捨ててほしくないライブラリ等を設定ファイルに追加していきます。

Linkerの設定はXMLファイルに記述します。

とりあえず「LinkerSettings.xml」という名前のファイルをAndroidプロジェクトに追加し、ファイルプロパティのビルドアクションを「LinkDescription」にしておきます。

わたしの場合はこんな感じになりました。

使用しているNuget Packageと、作成したプロジェクトアセンブリが対象となっています。

<?xml version="1.0" encoding="utf-8" ?>
<linker>
  <!--
      For more information see the docs on creating custom Linker Settings
      https://docs.microsoft.com/en-us/xamarin/cross-platform/deploy-test/linker
  -->
  <assembly fullname="Essential.Interfaces">
    <type fullname="Xamarin.Essentials.Implementation.AppInfoImplementation">
      <method name=".ctor" />
    </type>
  </assembly>

  <assembly fullname="Prism.Forms">
    <type fullname="Prism.Common.ApplicationProvider" preserve="all" />
    <type fullname="Prism.Services.PageDialogService" preserve="all" />
    <type fullname="Prism.Services.DeviceService" preserve="all" />
    <type fullname="Prism.Ioc*" preserve="all" />
    <type fullname="Prism.Modularity*" preserve="all" />
    <type fullname="Prism.Navigation*" preserve="all" />
    <type fullname="Prism.Behaviors.PageBehaviorFactory" preserve="all">
      <method name=".ctor" />
    </type>
    <type fullname="Prism.Services.DependencyService" preserve="all">
      <method name=".ctor" />
    </type>
  </assembly>

  <assembly fullname="Prism">
    <type fullname="Prism.Navigation*" preserve="all" />
    <type fullname="Prism.Logging.EmptyLogger" preserve="all">
      <method name=".ctor" />
    </type>
  </assembly>

  <assembly fullname="Unity.Abstractions">
    <type fullname="*" />
  </assembly>

  <assembly fullname="Unity.Container">
    <type fullname="*" />
  </assembly>

  <assembly fullname="Prism.Unity.Forms">
    <type fullname="*" />
  </assembly>

  <assembly fullname="System">
    <type fullname="*" />
  </assembly>

  <assembly fullname="mscorlib">
    <type fullname="*" />
  </assembly>

  <assembly fullname="OneThird.Core">
    <type fullname="*" />
  </assembly>

  <assembly fullname="OneThird.Application">
    <type fullname="*" />
  </assembly>

  <assembly fullname="OneThird.Domain">
    <type fullname="*" />
  </assembly>

  <assembly fullname="OneThird.Infrastructure">
    <type fullname="*" />
  </assembly>

  <assembly fullname="Microsoft.Identity.Client">
    <type fullname="*" />
  </assembly>

  <assembly fullname="Realm">
    <type fullname="*" />
  </assembly>

  <assembly fullname="System.IdentityModel.Tokens.Jwt">
    <type fullname="*" />
  </assembly>

  <assembly fullname="Xamarin.CommunityToolkit">
    <type fullname="*" />
  </assembly>

  <assembly fullname="Xamarin.GooglePlayServices.Ads" >
    <type fullname="*" />
  </assembly>

</linker>

よし、これでしまいかと思いきや……。

見事にクラッシュします。

で、色々と調べているとLinkerの対象から外すために「Preserve属性を追加せよ」という情報を目にします。
Using The Linker In Xamarin Projects

たいへん面倒ではありますが、以下のように属性を付けて回ることにします。

Androidプロジェクトのすべてのクラス
[Android.Runtime.Preserve(AllMembers = true)]

共通プロジェクトのすべてのクラス
[Xamarin.Forms.Internals.Preserve(AllMembers = true)]

ここまでやって、ようやく、ようやくアプリが起動しました。

だが、これでは終わらない……

無事起動しました。

しかし物語は常にハッピーエンドとは限りませんね。

動作確認をすると、CosmosDBの接続でエラーが出る、広告が表示されない、などいくつかの不具合が見つかります。

「ンあーーーーーーっ」と叫びたい気持ちを抑え、またひとつひとつ潰していくかと思いました。

冷静にこの時点でどれほどパッケージサイズは小さくなっているのだろうと確認すると、わずか「3MB」……。

これだけやって、こんな程度かとまず脱力します。

そして、「エラーを潰す = 削除されたコードを残すようにする」わけです。

ここから更にパッケージサイズは大きくなります。

また将来的なことも考えてみます。

この先、きっと機能追加等でコードやNuGetを追加したりするでしょう。

そのたびに今回の作業を忘れずに行う必要があります。

アプリサイズが少しでも小さいほうが、ユーザにとって良いことです。

ですが、コストやリスクに対しメリット少なすぎやしませんか。

涙の結論

ということで、「R8 Shrinker」および「フルLinker」は、たいっへん残念ではありますが、めっちゃ頑張りましたが、すんごく悔しいですが（しつこい）、あきらめることとしました。

ダウンロードしてくれるユーザの皆さまのギガを奪ってすいません。

wi-fiがある場所でダウンロードしたりアップデートしてくれることを祈っています。

技術の話なのに最後はお祈りですよ。

Visual Studioのエンタープライズエディションゲットして「AOT＆LLVM」使えば楽にちっさくなったりするんですかね。
でも$250/月とか無理っすよ……。

それとも何かいい方法があるのでしょうか。

もしご存じな親切な方いらっしゃいましたらコメントやTwitterなどで教えていただけますと、朝晩そちらに向かって毎日かかさず感謝の祈りを捧げたりします。

以上、プログラミングは祈りだ、の巻きでした。

記事の概要

こちらの一覧の７つ目、「保守フェーズ（公開から現在まで）」の記事となります。

はじめてスマホアプリを作ってみた 記事一覧

1. 検討フェーズ（どんなアプリを作るか）
2. 要件フェーズ（どんな要件のアプリにするか）
3. 調査フェーズ（どんな技術を使うか）
4. 設計フェーズ（どうやって作るか）
5. 開発フェーズ（実際に作りはじめる）
6. 公開フェーズ（アプリを公開する）
7. 保守フェーズ（公開から現在まで）

こちらでインストールできます
※アンドロイド版のみです。iPhoneユーザの方すみません。

全７回に分割して書いていますが長いので、ダイジェストで読みたい方はこちらの記事をご覧ください。

はじめてのスマホアプリ開発 保守フェーズ

前回は、アプリをGooglePlayでリリースする工程で行ったことをまとめました。

今回は、リリース後に見つけたバグや追加したい機能などをどのように管理し、実装しているのかについて書いてみたいと思います。

個人開発なので、自分が把握できる方法であれば何でもよいとは思います。

こういうやり方してる人もいるんだ、という感じに温かい目で読んでもらえるとありがたいです。

作業で使用しているツール

まずは、どのようなツールを使用して作業を行っているかについてです。
現在の作業環境を図に書き出してみました。

図中の各ツールをどのような目的で使用しているのか説明したいと思います。

Visual Studio と Git

開発ツールは「Visual Studio Community」を使用しています。

ソース管理ツールの「Git」を操作する機能が統合されているので、作業時に起動するのはVisual Studioと次に説明する各Webツールのためにブラウザぐらいでしょうか。

Azure DevOps

わたしの場合は記憶力に自信がないので、ひとつひとつの作業を経緯を含めて記録しておかないと、後から見た際に「なんのこっちゃ」となることが多いです。

この作業を記録するために、Azure DevOpsが大いに役立っています。

最初の５ユーザまでなら無料で利用できます。

.NETに限らず、Node.js、Python、Java、PHP、Ruby、C/C++など多くの言語に対応しています。

Azure DevOpsで主に使用している機能は以下となります。

Boards
「Basic」「Agile」「Scrum」の３種類から管理方法を選択し、プロジェクト管理を行うことができる機能です。
個人開発ではありますが、検索して分かりやすい情報が多かった「Scrum」を選択して使っています。

Repos
これはリモートリポジトリです。
Visual Studioからpushしたコミットをここで管理しています。
主にmainブランチに開発ブランチをマージする作業をここでしています。

Wiki
アプリの仕様をここに書いておくようにしています。
「仕様書」というほど厳密なものではなく、変更頻度が低いアプリの仕様上のルールなどを書くようにしています。

この他、「Pipeline」というビルドやデプロイを自動化する機能がありますが、この部分は別途「App Center」というツールで行っているので使っていません。

「Test」という機能は有償プランでフルに利用できるようになります。わたしは限定的にしか使用できないので、UIテストのチェックリストを「Test Case」として作成する機能などを使っています。

チーム開発であれば、Reposでテスト用のブランチを切って、Pipelineでビルド＆検証環境へリリース、Testでテスターが作業みたいな流れが実現できるのだと思います。

App Center

Azure DevOpsで管理しているリポジトリを参照し、ビルド＆リリースを自動化できるブラウザで使用するツールです。

毎月のビルド数などに制限がありますが無償で使用できます。

接続IDなどシークレット情報を管理して、ビルド時に差し込んでくれる機能などがあります。

わたしはAzure DevOpsのReposでmainブランチのコミットを行い、App Centerが更新を検知して自動でビルド、Google Play Consoleへリリースしてくれるように設定しています。

Google Play Console

Google Playの公開情報をここで管理します。

アップデートをApp Centerでリリースしたら、審査中の間にここで多言語用のリリースノートを書いたりしています。

ダウンロード状況などを分析してくれる機能もありますが、まだユーザも多くないのでそれほど役立てることはできていません。

Google Cloud Platform

これは、App CenterからGoogle Play ConsoleへリリースできるようにするためのAPI Serviceを提供してくれるプラットフォームとして利用しています。

Azure

ユーザ認証の機能を提供してくれる「Azure AD B2C」と、サーバDBとして利用しているドキュメントDB「CosmosDB」を使用しています。

サインイン画面のカスタムテンプレートを使用するために「Azure Blob」も併せて利用しています。

AWSなどの方が情報も多くユーザも多いとは思いますが、.NET開発者向けの情報やライブラリが充実しているので、いまのところ不自由なく利用することができています。

この他、Google Admobや、Admob用にadd-aps.txtをホストするためにFirebaseを利用しています。

作業の流れ

続いて、ここまで書いたツールをどのような手順で使用しているか書いてみたいと思います。

1. (Azure DevOps)Boardsに、Bug・Product Backlog Item を登録する。（随時）
2. 優先度を整理し、次回リリース対象をBoardsのSprintsに登録する。
3. Visual Studioで開発を行う。
4. 作業内容をBoardsに記録する。
5. 開発完了後、ローカルGitから、Azure DevOps ReposにPushする。
6. Reposでmainブランチに開発ブランチをマージする。
7. mainブランチの更新をApp Centerが検知し、Build → Distributeが行われる。（自動）
8. App Centerから配布されたaabをGoogle Play Consoleが受け取りリリースが行われる（自動）
9. BoardsにCommit IDを記録しStatusをDoneにする。
10. 一連の作業が完了。

現在は、こんな感じで作業を繰り返しアプリのアップデートを行っています。

初回リリースをするまでは、開発とこれらの環境構築を併せて行っていたのでかなり大変でしたが、おかげで今はコーディングに最も時間を費やすことができる環境となっています。

まとめ

ざっとではありますが、わたしの作業環境についてまとめてみました。

各ツールの使い方や設定方法などは、個別に別途記事を書きたいと思います。

すべて我流なので、使い方がおかしかったりするものもあると思います。
わからない部分や、もっといい使い方がある、いいツールがあるよーなど指摘いただけますととっても嬉しいです。

10年以上前、かつて知っていた開発環境とは大きく変わり、今では便利なツールがたくさんあることに驚くとともに、ツールを作ってくれた方々に感謝しながら使わせていただいています。
いずれ費用を捻出できるぐらいになったら、有償のさまざまな機能も使ってみたいなーなどと夢見ています。

ここまで、初心者がはじめてスマホアプリを開発し、リリースするまでを７回に分けで書いてきました。

独学で実践してきた偏ったものかもしれませんが、どなたかのお役に少しでもなれれば幸いです。

プログラミングはほんっとうに楽しいですね。

どうぞよき開発ライフを！

長文にお付合いいただき、ほんとうにありがとうございました！

はじめてスマホアプリを作ってみた 記事一覧

1. 検討フェーズ（どんなアプリを作るか）
2. 要件フェーズ（どんな要件のアプリにするか）
3. 調査フェーズ（どんな技術を使うか）
4. 設計フェーズ（どうやって作るか）
5. 開発フェーズ（実際に作りはじめる）
6. 公開フェーズ（アプリを公開する）
7. 保守フェーズ（公開から現在まで）

記事の概要

こちらの一覧の６つ目、「公開フェーズ（アプリを公開する）」の記事となります。

はじめてスマホアプリを作ってみた 記事一覧

1. 検討フェーズ（どんなアプリを作るか）
2. 要件フェーズ（どんな要件のアプリにするか）
3. 調査フェーズ（どんな技術を使うか）
4. 設計フェーズ（どうやって作るか）
5. 開発フェーズ（実際に作りはじめる）
6. 公開フェーズ（アプリを公開する）
7. 保守フェーズ（公開から現在まで）

こちらでインストールできます
※アンドロイド版のみです。iPhoneユーザの方すみません。

全７回に分割して書いていますが長いので、ダイジェストで読みたい方はこちらの記事をご覧ください。

はじめてのスマホアプリ開発 公開フェーズ

前回は、実装作業の工程で行ったことについて書きました。

今回はいよいよ作ったアプリをGoogle Playでリリースするまでに行ったことをまとめてみたいと思います。

リリースで行った作業メニューです。

• アップデートを見据えたリリース環境の設計
• リリースに向けたアプリの準備
• Google Play デベロッパー アカウントへの登録
• Googl Play Store API の準備
• Google Play Console にアプリを登録
• Visual Studio App Center の準備

ようやく開発を終え、一息付けたと思ったらリリース作業は思った以上に大変でした。

この記事では、大まかにどのような作業が発生するのかを記していきたいと思います。
それぞれの項目の細かい手順などは、後日、別途記事を書きたいと思います。

アップデートを見据えたリリース環境の設計

単純に作成したアプリをGoogle Playに公開するだけであればローカルでビルド・アーカイブを行い、Google Playに手動でアップロードすれば済みます。

しかし、リリース後にバグを発見したり、機能を追加するたびに慎重な作業を強いられるのは何かと面倒です。

ということで、リモートリポジトリから自動でビルド＆リリースができる環境を構築しながら初めてのリリースを目指したいと考えました。

イメージとしてはこんな感じです。

では順を追って書いていきたいと思います。

Google Play デベロッパーアカウントへの登録

AndroidアプリをGoogle Playで公開するには、「Google Play デベロッパーアカウント」に登録する必要があります。

登録は、上記リンクの「ステップ１」にある「デベロッパー アカウントに登録」のリンクから行うことができます。

この作業自体は簡単です。
注意としては、$25の登録料がかかることぐらいでしょうか。
これは一度支払えばよい初期費用のようなものです。

ちなみにiPhoneアプリの場合は年間サブスクリプションで11,800円かかるそうです。
(2021/3/5 時点 Apple Developer Program)

リリースに向けたアプリの準備

Xamarin.Formsでの開発用には一応、このような公式ドキュメントがありますので、ひと通り試してみました。
リリースに向けてアプリケーションを準備する

アプリケーション アイコンを指定する
わたしは「Prism」というXamarin.FormsをMVVMで実装するためのパッケージを使用したので、アイコンはデフォルトを置き換えるだけで済みましたが、イチから作った場合やAndroid Studioで開発した場合には設定が必要かと思います。

アプリケーションのバージョン
Android Manifest にバージョンを管理する項目があります。
ここのバージョン番号は、Google Playのリリースノートに表示されます。
デフォルトでは「1.0」となっていますが、とりあえず「1.0.0」と番号を区切ることにしました。
定義としては、大幅なリニューアルはメジャーバージョン番号、機能追加などマイナーアップデートは真ん中のマイナーバージョン番号、バグ修正などは一番右の番号をインクリメントすることとしました。

APK を圧縮する
これはですね、非常にやっかいです。
Android Studioでネイティブ開発をした方は、快適にリンカーや難読化を利用できるのでしょうか。

わたしの環境は、「Visual Studio Community 2019」です。

パッケージサイズを小さくできるならと、なんの準備もせずにリンカーを「[SDK およびユーザー アセンブリ」に設定すると、見事にリリースしたアプリは起動しませんでした。

このリンカーは、未使用と判断したコードを削除することで軽量化を行ってくれるツールのようですが、削除対象から外す設定をしっかりしておかないと、必要なコードまで削ってしまいます。

最初は「SDK アセンブリのみ」を選択しておくのがよいと思います。

これでも、リンカーをオフにするよりパッケージサイズはかなり小さくなります。

もうひとつ、Java バイトコード レベルで最適化をしてくれる「ProGuard」の説明がありますが、ドキュメント通りに設定するとビルドが通りません。

ProGuardは非推奨で「R8」を使えとなります。

で、R8を選択してリリースビルドするとあら不思議、またもやアプリは起動しません。

これも、必要なライブラリや自分のコードを設定ファイルで「keep」しておく作業が必要です。

これも、とりあえずは未選択としておきました。

※追記：2021/03/13
後日談として、APK圧縮にチャレンジし敗れ去る話をまとめています。

アプリケーションを保護する
仮にR8を使用したとしても、Xamarin.Forms の場合はコードの難読化はされません。
必要があれば「Dotfuscator」なるものを使えとあります。

Integrating Dotfuscator's Protection into Your Xamarin Apps in Visual Studio

こちらも試してみましたが、ビルドが通るようにするまでにかなり苦労しました。

しかし、コードの難読化はなされず……。

Root Checkは入れておきたいと思っているので、いずれまた挑戦するとして、今回は諦めることにしました。

AODコンパイルやLLVMコンパイラは、Visual Studioのエンタープライズエディションが必要なのでパスです。

パッケージング プロパティを設定する

わたしのAndroid.csprojのリリース用PropertyGroupはこんな感じになりました。

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
  <DebugType>pdbonly</DebugType>
  <Optimize>true</Optimize>
  <OutputPath>bin\Release</OutputPath>
  <DefineConstants>TRACE</DefineConstants>
  <ErrorReport>prompt</ErrorReport>
  <WarningLevel>4</WarningLevel>
  <AndroidUseSharedRuntime>false</AndroidUseSharedRuntime>
  <AndroidLinkMode>SdkOnly</AndroidLinkMode>
  <AotAssemblies>false</AotAssemblies>
  <EnableLLVM>false</EnableLLVM>
  <BundleAssemblies>false</BundleAssemblies>
  <AndroidDexTool>d8</AndroidDexTool>
  <AndroidPackageFormat>aab</AndroidPackageFormat>
  <MandroidI18n />
  <AndroidSupportedAbis>armeabi-v7a;arm64-v8a</AndroidSupportedAbis>
  <AndroidEnableProfiledAot>false</AndroidEnableProfiledAot>
  <AndroidEnableSGenConcurrent>true</AndroidEnableSGenConcurrent>
</PropertyGroup>

ターゲットアーキテクチャはインテル系はいまやモバイルではほぼ無いということで対象外としました。

ABIごとにパッケージを分けるは、APKではなくバンドルを選択したので選択の必要はありません。

Multi-Dexは64Kを超えるメソッド制限の対象となるコードがないのでチェックしていません。

App Bundleは、次期必須となることをGoogleがアナウンスしているのでapkではなくバンドルを選択しています。
Android App Bundle について

Compile

発行のためのアーカイブ
ビルドとアーカイブはApp Centerで行うのでスキップします。

Googl Play Store API の準備

とりあえず、Visual Studioで行う準備作業は完了しました。

続いて、App CenterからGoogle Playに直接リリースする導線を貼る作業です。

詳しい手順はこちらのサイトを参考にさせていただきました。

App CenterからGoogl Play StoreのAPIを通じてアプリをリリースするには、「Google Cloud Platform」を使用します。

そして、上記ブログにある通り、初回のリリースはGoogle Play Consoleに直接アップロードしておく必要があります。

Google Play Consoleで一通りアプリの登録・公開が完了することで、App CenterからGoogle Play Consoleのアプリを検索し設定を行うことができるようになります。

Google Play Console にアプリを登録

これがハイライトと言えるボリュームのある作業となりました。
色々と準備するものが出てきます。

この作業も、先ほどと同じブログの別の記事を参考にさせていただきました。

意外と面倒だったのは、アプリのスクリーンショットや1024×500指定のフィーチャーグラフィックという宣材画像を用意することですね。

高度な画像レタッチアプリは持っていないので、すべてWindows純正アプリを駆使して用意しました。

また、埋めていかなければいけない項目は、Google Play Consoleのサイドメニューにわかりやすく表示されるので、がんばってオールグリーンを目指しましょう。

Visual Studio App Center の準備

App Centerはとても簡単に利用できるWebツールです。

強いて言うならば、Environment variables を使った部分がやや面倒でした。
DBの接続キーなどシークレット情報をApp Centerのビルド時に差し込むように設定しました。

これも別途記事を書こうと思いますが、基本的にシークレット対象の情報は、デバッグはMobile.BuildToolsというNuGetパッケージを使用し、リリースは上述したようにApp CenterのEnvironment Variablesを使っています。

Environment Variablesは、値を差し込むスクリプトを「appcenter-post-clone.sh」というファイル名でAndroidプロジェクトに用意しておく必要があります。

appcenter-post-clone.sh
#!/usr/bin/env bash

echo "Environment Variables data replace"

##################################################
# variables

# (1) The target file
DirName=$BUILD_REPOSITORY_LOCALPATH
FilenameVariables="$DirName/OneThird.Core/Constants/Variables.cs"
FilenameCosmosdb="$DirName/OneThird.Infrastructure/CosmosDb/CosmosDBConstants.cs"

##################################################

echo ""
echo "######################################################################"
echo " Variables.cs"
echo "######################################################################"
echo " Working directory:" $DirName
echo "       Target file:" $FilenameVariables
echo "######################################################################"

# APP_ID_ANDROID
echo ""
echo "APP_ID_ANDROID - " $APP_ID_ANDROID
sed -i -e "s/\[APP_ID_ANDROID\]/$APP_ID_ANDROID/" $FilenameVariables

# TENANT_ID
echo ""
echo "TENANT_ID - " $TENANT_ID
sed -i -e "s/\[TENANT_ID\]/$TENANT_ID/" $FilenameVariables

# CLIENT_ID
echo ""
echo "CLIENT_ID - " $CLIENT_ID
sed -i -e "s/\[CLIENT_ID\]/$CLIENT_ID/" $FilenameVariables

# SIGN_IN_POLICY
echo ""
echo "SIGN_IN_POLICY - " $SIGN_IN_POLICY
sed -i -e "s/\[SIGN_IN_POLICY\]/$SIGN_IN_POLICY/" $FilenameVariables

# PASSWORD_RESET_POLICY
echo ""
echo "PASSWORD_RESET_POLICY - " $PASSWORD_RESET_POLICY
sed -i -e "s/\[PASSWORD_RESET_POLICY\]/$PASSWORD_RESET_POLICY/" $FilenameVariables

# AD_UNIT_ID_BANNER
echo ""
echo "AD_UNIT_ID_BANNER - " $AD_UNIT_ID_BANNER
sed -i -e "s|\[AD_UNIT_ID_BANNER\]|$AD_UNIT_ID_BANNER|" $FilenameVariables

# AD_UNIT_ID_INTERSTITIAL
echo ""
echo "AD_UNIT_ID_INTERSTITIAL - " $AD_UNIT_ID_INTERSTITIAL
sed -i -e "s|\[AD_UNIT_ID_INTERSTITIAL\]|$AD_UNIT_ID_INTERSTITIAL|" $FilenameVariables

# print out for reference
echo ""
echo "######################################################################"
echo "show result"
cat $FilenameVariables

echo ""
echo "######################################################################"
echo " CosmosDBConstants.cs"
echo "######################################################################"
echo " Working directory:" $DirName
echo "       Target file:" $FilenameCosmosdb
echo "######################################################################"

# COSMOSDB_ACCOUNT_URL
echo ""
echo "COSMOSDB_ACCOUNT_URL - " $COSMOSDB_ACCOUNT_URL
sed -i -e "s|\[COSMOSDB_ACCOUNT_URL\]|$COSMOSDB_ACCOUNT_URL|" $FilenameCosmosdb

# COSMOSDB_ACCOUNT_KEY
echo ""
echo "COSMOSDB_ACCOUNT_KEY - " $COSMOSDB_ACCOUNT_KEY
sed -i -e "s|\[COSMOSDB_ACCOUNT_KEY\]|$COSMOSDB_ACCOUNT_KEY|" $FilenameCosmosdb

# print out for reference
echo ""
echo "######################################################################"
echo "show result"
cat $FilenameCosmosdb

あとは、mainブランチを自動でビルド、リリースするように設定しておきます。
こうすると、Visual Studioで作業ブランチをmainブランチにマージしてリモートpushすると、自動でAzure DevOpsのリポジトリを経由してリリースまで行ってくれます。

まとめ

駆け足ではありましたが、リリースにおいて行った作業全体を書き出してみました。

個々の作業詳細は、それぞれ別途記事で分かりづらかったポイントなどを書きたいと思います。

１日当たりの作業時間が少ないのもありますが、なんだかんだで着手してからリリースまで半年以上の時間を要してしまいました。

ただかかった時間を将来にわたって回収できるような準備をそれなりに出来たと思います。

それは、ドメイン駆動設計、テスト駆動開発、Azure DevOps、App Centerといった素晴らしい手法やツールのおかげです。

バージョン1.0.0で2月13日にリリースをしてからこれを書いている3月4日現在では1.0.4なので、4回バグ修正や細かい追加などでアップデートを配布しています。

まだまだ改善の余地はあると思いますが、それなりの準備のおかげで修正や機能追加もコーディングに集中できるような環境となっています。

それにしてもリリースできたときは本当にうれしかった。
またGoogle Play Consoleから「公開されました」の通知が来たときは一人飛び上がって喜んでしまった。

タイトルの通りではありますが、この度なんとかアプリをリリースするところまで漕ぎつけました。大変だったけど楽しかった。 / “アラフォー初心者だけどスマホアプリを開発～リリースまでがんばってみた | neputa note” https://t.co/owLYbmgUwH

— neputa (@h_neputa) February 13, 2021

これからアプリ開発を行う方にとって、少しでも役立つ情報がありましたら幸いです。

次回は最終回、これまで構築した環境を利用して運用保守をどんな感じで行っているかをまとめてみたいと思います。

長文にお付合いいただきありがとうございます。

はじめてスマホアプリを作ってみた 記事一覧

1. 検討フェーズ（どんなアプリを作るか）
2. 要件フェーズ（どんな要件のアプリにするか）
3. 調査フェーズ（どんな技術を使うか）
4. 設計フェーズ（どうやって作るか）
5. 開発フェーズ（実際に作りはじめる）
6. 公開フェーズ（アプリを公開する）
7. 保守フェーズ（公開から現在まで）