この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

第6章の冒頭に、

「プラクティスとは、XPチームが日常的に行うものである。…」

という説明があって、その後に「…、機械的な作業になってしまう。…」
読書会の時にこの部分を読んで、過去に関わったプロジェクトで、テスト工程をペアで手作業で行うというなかなか残念なプロジェクトを思い出しました。のちの改修とか機能追加などを考えれば普通に自動化すべき部分だと思うのですが、リリース前のテストは手をかけて苦労することがルールみたいな感じでした。。。

さて、読書会の議論のなかで「どのプラクティスが導入しやすいのか？」という話があって、いやおそらくそういう方法から入るんじゃなくて、何に困っているかという具体的な問題の洗い出しが必要で、それに対して、じゃあこのプラクティスをやってみれば、というようなやり取りがありました。

あと、全員同席の部分。

過去の仕事場を振り返ってみると、個人スペース、もしくはオープンスペースのどちらかはありましたが、両方を使い分けるような環境はなかったと思います。あと、オープンスペースといっても、単に机が並んでいるだけのごく一般的な職場なので、本に書かれている会議室を占有する感じのオープンワークスペースというのは心に刺さる部分でした。

個人が集中して作業できる環境と、チームメンバーが集まってコミュニケーションをしながら作業できる環境。両方があるのがポイント。

そして「チーム全体」の終わりのほうにある「タスクの切り替え時間」。
いろいろ忙しくて、あれもこれもみたいな状況になるのを仕方ないとするか。いや、その切り替えにはどうしても時間がかかるので、できるだけ一つの仕事に集中できるようにスケジュールなり人員なりを調整するなど。

この回の終わりは「いきいきとした仕事」でした。
長時間働くのは良くないですね。以前は当たり前のように毎日遅くまで仕事をしていましたが、単に時間をかけてコードを書くよりも、できるだけ短時間で切り上げて、環境を整えるとか、こういう本で手法を学ぶとか、プログラミングのスキルを学ぶなど。それと、健康に配慮して体を動かすとか、そうやって生活の質を上げることで結果として仕事の成果も上がるようにしていきたいですね。

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

私自身、Agile459のコミュニティに参加して8年ほどになります。
おもに @kkd 氏が中心となって、県外から講師を招いてセミナーを開いたり、Agile Japanのサテライトを開催したり、読書会（アジャイルサムライ、エクストリームプログラミング）を開催したりしています。

参加するまではアジャイル開発についての知識がなく、キーワードとしては知っていたかも知れませんが、どう実践するとかそういうノウハウがない状態でしたが、毎年の様々なイベントの中で少しずつですが、自分の知識として身について、仕事の中で実践できるようになってきました。

今の時代に対しては、自分の進歩のスピードに多少（？）問題があるかも知れませんが…(^^;

少し残念なのは、その年々で参加者が入れ替わっていく感じで、継続して参加している運営スタッフもそれぞれ興味分野が違ったりするので、なかなかコミュニティとしての運営がまとまらない状況があります。例えば特定のプログラミング言語や技術に特化したコミュニティだと、わりと継続的にあるいは定期的に勉強会が開催されるようになってきてはいますが、アジャイルというキーワードだと、対象とする範囲が広すぎるのか、具体的な必要性が見えにくいのか、内容によってはたくさんの参加もあるのですが、イベントが終わると一気に疎遠になってしまう感じがします。

前のエントリー 今年(2018)のAgile459のふりかえり の最後の部分にも書きましたが、自分の仕事の中ではなかなか変えることができない、あるいは気がつかないことが、外のコミュニティに参加することで気がついて改善につながったりすることもあると思います。仕事の進め方とか、開発方法とか、日常の仕事の中で何か疑問に感じるけれど、何となくそのままやり過ごしていることなど、もしあればAgile459のコミュニティに参加して議論してみると、何か発見があるかも知れません。

あと、コミュニティの運営ですが、8年も経つとウェブサイトまわりもいろいろと変わってきて、見直しが必要な時期になっていると思います。ただ、これも仕事や家庭とは別の活動になるので、なかなか時間を取って進めるのは難しい。それと、中に時間が取れる人がいたとしても、その人ばかりが手をかけてしまうと、その人じゃないとわからない（弄れない）状況になってしまって、時間とともに破綻してしまう可能性もあります。このあたりも、せっかくのアジャイルのコミュニティーなので、うまくチームとして回せる環境を作ることができればと、ぼんやりですが考えています。

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

XP本読書会の5回目は5章の後半でした。

機会と失敗はつながる部分があって、失敗とか何か問題があった場合にネガティブになるんじゃなくて良い方向に向かせるための機会ととらえることがポイント。反省も必要だけどそればかりではしんどいですし、さらに大きな問題につながる可能性もあるわけで、そうならないうちに気がつけたと思えば良いんじゃないかと。テストケースを追加してみるとか、テストの仕方を変えてみるとか、機能自体を見直してみるとか。

あと、失敗したら急いで対処するんじゃなくて、まず失敗した状況を共有。対処できたらまた共有。そうすることで落ち着いて対応できるし、時間がかかったらかかったでエビデンスにもなるし、のちの教訓とかノウハウにもつながると思います。

次に品質について。

仕事の中で品質を求めることができなくて（あきらめて）、プライベートで品質に対する欲求を満たしていたという話の中で「盆栽」というキーワードが上がって、「盆栽」といえば波平の「ばっかもーん!!」ですよね、みたいなところから脱線。まぁそれはそれで面白かったです。面白かったというか、オンライン読書会の中で一番脳が活性化した瞬間だったかもです。

で、品質と責任の部分もつながると思います。誰かの成果物の品質がどうとか、誰かに責任を押し付けたところで、プロジェクト全体としては何の解決にもならないわけで、解決にならないどころかそれこそ時間の無駄。それよりも、プロジェクトのチームとして品質を良くしていくとか、責任を共有することが大切。そうすれば信用とか期待につながりますよね。

本の内容とは少し外れますが、この頃に自分の課題として「リファクタリング」というキーワードがあって、なかなか進めることができていなかったのですが、

【質問紹介】#Csharp #ASPdotNET #MVC #EntityFramework
Q. MVCの考え方がいまいち噛み砕けないので教えて頂きたいです。

⇒https://t.co/gvJSesTvDJ

— teratail【テラテイル】 (@teratail) September 4, 2018

このコメントがすごく良いヒントになって、仕事のタイミングと重なってリファクタリング進行中です。

読書会に参加したことで、そういう課題意識を持てたし、継続的に考えることで実践にも繋がったと思います。

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

XP本読書会の4回目は5章の途中でした。この頃は参加者がわりと多くて、その分あまり進まなかった様子。
それと、ディスカッションのまとめもSlackのタイムラインをWikiへコピペしていたので、ログがちょっとわかりにくい。後日、記録用にHackMDを使うようになりました。

さて、自己相似性の部分ですが、あらためてその部分を読んでみると、わかりやすくて重要と思いました。

• 四半期単位：テーマを選んでストーリー単位で組み立てていく。
• 週単位：ストーリーを選んでテストを組んでいく。
• 数時間単位：テストを書いて、実装していく。

小さなループ(TDD)を繰り返して、ストーリーとして組み立てて、テーマとして完成させるような流れ。
なので、小さなループがちゃんと回る（動く）のがポイントですね。

あと、「ふりかえり」のところにあった「ソフトウェアプロセスばかり考えている」の部分。方法論にとらわれ過ぎて、生産性に繋がらないのはよろしくないですし、開発のことを考えるのは良いけれど、管理するために資料を作らないといけないとか、プロダクトとは直接関係のない物に対してリソースが消費されるのは避けたいですね。フラットなチームとかフラットな組織であれば、そのあたりの無駄も少なくなると思います。

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

XP本読書会の3回目は4章から5章あたりでした。

このあたりで思いつくのは人間性(Humanity)の達成感について。

以前、VBとかC#で業務用アプリを開発していた頃、設計書を読みながらプログラムを書き進めていたわけですが、リビジョン管理やTDDができていない頃で、ソースコード中にコメントを書いて、今日はこの辺までできてこのあたりが未実装とか、プロジェクトフォルダをzipに固めてファイル名に日付を入れてアーカイブとして残したりとか、よろしくない仕事の仕方でした。

そういうやり方だと、最終的にプログラムが完成するまで、ただただ不安な状況が続きます。「〇〇の機能ができていない」とか「△△はどうやって実装すれば…?」とか、そういうモヤモヤしたことがたくさんあるまま、中途半端な状態で切り上げて帰る日々。

完成に近づいて、一通りテストができる状態になって、やっとそういうモヤモヤした雰囲気から少し解放される感じです。なので、仕事の中で達成感を感じることがとても少ない状態でした。

それが、アジャイル開発を学ぶようになって、さらにTDDを経験することによってずいぶんと仕事の仕方が変わりました。比較的小さい単位で課題を設定して、テストコードを書いて実装して red -> green を繰り返す。課題が完了したら commit(push) して close して次の課題へ。

こういうサイクルで仕事ができるようになったので、greenにするとかcloseするタイミングで都度達成感を感じることができます。課題管理の中で、必要になりそうな技術資料などメモっておくこともできますし、テストコードを仕様書と思えば、ソースコード内に必要以上にコメントを書くこともありません。

もちろん、完成にたどり着くまでのプレッシャーとかストレス的なものは多少ありますが、それよりも従来と違って、日々の仕事の中でサイクルを回した分だけ小さな達成感を得ることができるので、気持ちよく仕事を終えることができますし、翌日のモチベーションにも繋がります。

さらに、テストコードで何がどこまでできているかがすぐにわかるので、翌日とか翌週とか時間をおいてもスムーズに作業を続けることができます。以前のやり方のままだったら、今頃どうなっていたんだろうと。おそらくコードを書くのは難しくて、他の仕事をしていたと思います。

とはいえ、まだまだ仕事の仕方について改善できることはいろいろあると思いますし、XP本を読んでいくらか理解できたとしても、実践はまだまだこれからです。なかなか自分だけでは実践までたどり着けないと思うので、コミュニティに参加しながらできることを進めていきたいと思います。

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

4章のコミュニケーションについて。

どんどん成果が上がらないが時間が過ぎていく。悪循環を思い出す。
経験が浅いとコミュニケーションがうまく取れない。

与えられた仕事は自分の責任でやらないといけないと思って、ディスプレイに向かってコーディングを進めようとするものの、スキル不足や課題の理解度の問題などで一向に進まない状況。
最近であれば、バックログによる課題の管理やTDDで必要なものを小さく切り出して積み上げていくなど、仕事の進め方がずいぶん変わりましたが、昔はそのような方法を知らず、大きな課題を丸ごと完成させようともがいていたような気がします。そういうときは遠慮とかしている場合ではなくて、とにかく自分の手が進むようになるまで相談するべきと思いました。先輩はもとより後輩の新人がサクサク仕事を進めていたりすると、余計に自分で頑張らないと、と思ってしまいますが、上下関係なく、少しでも仕事の成果を出すにはどうすれば良いかを割り切って考えるべきだったのだろうと思います。

コミュニケーションを取りすぎる人がいる。

自分にも当てはまることではあるのですが、コミュニケーション重要、といってもそればかりで肝心の仕事が進まないのでは意味がなくて、程度の問題とは思います。ただ、昨年(2017)のアジャイルのサテライトで実践した Mob Programming をふりかえってみると、コミュニケーションの取りすぎも問題なくて、どちらかというと、チーム全員で議論しながらプロダクトが仕上がっていくような、そういうスタイルもあるので、コミュニケーションで問題になるのは１対１の場合かもしれません。１対１だとすべて問題、ということではなくて、１対１のコミュニケーションが長い時間続くと本筋から外れていることが多いですよね。

と書いていると、このような記事のお知らせがメールで届きました。
アジャイルなチームを改善するアイデア集「101 ideas for agile teams」で僕が学んだこと
元の記事と合わせて読んでみようと思います。

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

昨年(2017年)秋頃からAgile459で開催されたオンライン読書会1回目のログ。
https://github.com/agile459/reading-circle/wiki/XP2ndBook-1st-20171018

この内容をふりかえって思うのは、これまでに関わった仕事にはソーシャルチェンジという文化があまりなくて、硬直していたものが多かったということ。

もちろん仕事の種類とか現場によって様々ですが、例えば、あるプロジェクトでは仕事の進め方のルールがあって、そのルールに沿っているかどうかのチェックがあります。ルールに沿っていなければチームのリーダーから叱責されて修正を求められて、ルールを確認して修正して提出。でも、まだリーダーとしては納得のいくものになっていなくて修正を求められる。これを数回繰り返してなんとか完了。

でもですね、このやりとりってプロダクト（ソースコード）じゃなくて、プロダクトをコミットする際の関連ドキュメントやメールの文面の話だったりします。なので、（今後ほぼ使うことがないであろう）関連ドキュメントがボトルネックになって、コミットがなかなか進まない。モチベーション的にもちょっとしんどい状況なわけです。

しかも、そのようなドキュメントの不備が続くと、さらにルールが上乗せされて、足かせが二重、三重になっていきます。

で、XPを学ぶことで「あー、そういうところでものすごいリソースを消費していたんだなぁ」と感慨に浸ったりできるわけです。

管理する立場から言えば、すべてあたりまえに必要な作業、と言われるかもしれませんが、いや、だったらもっとプロダクト自体にリソースを割けば間違いなく好循環が生まれるわけで。

そういった、何かしんどいなぁとか、モチベーションが上がらないなぁ、と感じるときに、その原因に気づかされて、さらっと解決につながるような、そういう学びのある読書会でした。

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

先月開催したGDCRですが、このイベントを開催することになって、あらためて練習をし始めたこと、新たに学び始めたことが3つほどあるので書いてみます。

まず最初にタイピングの練習。
インターネットでタイピング練習 – e-typing
スコアはA+（ローマ字タイピング）でまだまだです。前に練習していたのがいつ頃だったか忘れましたが1年以上はブランクがあると思います。なぜタイピング練習かというと、GDCRが1台のPCを共有してペアプログラミングをするイベントなので、少しはスマートにキーボードが打てればと思いまして。

練習の成果としては、以前練習していた頃のスコアにやっと並んだ程度で、要するに練習をしないとフォームが崩れて正しいタイピングができなくなっていたんだと思います。ただし、今回の練習で頑張っていることがあって、それは英語タイピング。最近まで気がつかなかった（気にしていなかった）のですが、e-typingに英語タイピングのメニューがあって、主にそちらで練習しています。英語タイピングはローマ字と違って大文字を入力するために左右のシフトキーを正しく使わないといけなくて、自分にとってはその分、ローマ字入力よりもハードルが上がる感じです。

プログラミングだと大文字や小文字、記号など使いますので、単にローマ字でスピードをあげるだけでなく、英語タイピングの練習もおすすめです。

次に語学の勉強。

同じく先日のGDCRですが、イベントの直前にスペインから中継のオファーをいただいて、Hangoutで英語で打ち合わせをして、イベント終了時にHangoutで松山会場で実施した制約の説明と、時差の関係でこれから始まるスペイン（バレンシア）の参加者にエールを送ってバトンを渡す、というやりとりがありました。

普段、海外のテレビドラマで英語を聞く程度で、会話で英語を使う機会はないので、なかなか思ったことが言葉に出ない状況でしたが、せっかくスペインとやりとりするので、あいさつぐらいはスペイン語でできれば、と思い、勉強方法を調べたところ、Duolingoを見つけました。

まだ2週間ほどですが、スペイン語、とついでにイタリア語、英語を勉強しています。とても良いと思ったのは、スペイン語を勉強するのに問題が英語で出されるので、英語とスペイン語をまとめて学べるところ。ただ、スペイン語とイタリア語は単語の雰囲気が似ていたりするので、全くの初心者が両方を同時というのは無理がありそうです。

ところで、Duolingoで学んでいるうちに思ったのですが、そもそも言葉って読み書きよりも、聞いて話して覚えるものですよね。もちろん学校の授業で国語を習いますが、国語を学ばないと日本語での日常会話ができないということはなくて、日常の会話の中で自然と身に付くものだと思います。スペイン語を学ぶのも、Duolingoだけじゃなくて教科書とか参考書を使って、読み書きもしながら学ぶのも良いのですが、Duolingoで聞いて話すだけでもそれなりに身に付くんじゃないかと思っています。

あと、ちょっと気になったのが、英語の発音。講師の発音を聞いて、自分で同じように発音しているつもりですが、どうも子音が弱い。かなり意識して子音を強く発音しないと、母音ばかりで英語らしく聞こえない感じです。あー、そういえば、スペイン語で巻き舌が必要なのですが、全然できないのでそれはそれでぼちぼち練習します。（今さら…）

まぁ、どれくらい続くかわかりませんが、今のところ面白いので楽しみつつ。

3つ目の勉強ツールはプログラミングのKATA。

KATAの必要性に気がついたのは、先ほどのスペインの中継がきっかけです。スペインのバレンシアにはソフトウェアエンジニアのコミュニティがあって、そこではKatayunosという朝食の時間にペアプログラミングでKATAの練習をするイベントが定期的に開催されているようです。

で、自分の周りを考えてみると、プログラミングのスキルアップって個人で勉強するかしないか、あとは仕事の中で上司とか先輩がそれなりにスキルを持っていれば、ある程度伝授してもらえるかもしれませんが、仕事の中でじっくりとプログラミングのスキルを磨く時間は取れないのではないかと思います。というか、プログラミングのスキルが足りないまま日々の仕事をこなしているのが現実では？

ということで、じゃあKATAを学ぶにはどうすれば、と思って探してみたところ、Codewarsというサイトが見つかりました。以前、CheckIOとかCodecademyで問題を解いたりレッスンを受けたりしていましたが、しばらく何もやっていなくて、いろいろプログラミング言語も選べるのでちょうど良いと思って練習をはじめました。今のところ、Python、Kotlin、Swiftで進めています。問題によるのか、Swiftのバージョンが3だったりするので、ちょっと混乱することもありますが、サンプルテストは自分でテストコードを付け加えることもできるので、TDDの練習にもなります。

以上、最近オススメの勉強ツールについて簡単ですが紹介してみました。

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

四国各地でのイベントの開催を通じて、運営側に回ってくれるスタッフが少しずつですが増えてきました。
で、Agile459の活動の中で、情報の共有や発信のために利用するサービスも変わってきているので整理してみます。

旧サイト

Agile459 – Google Sites
2011年から2012年頃のイベント報告など

Doorkeeper

DoorKeeper – Agile459
イベント開催（2012年から2016年）

Connpass

connpass – Agile459
イベント開催（2017年から）

GitHub Pages

Agile459 – GitHub Pages(Jekyll)
Agile459について。参加方法。各種サイトへのリンク。
2011年から2015年頃のイベント報告など

HackMD

HackMD
読書会の事前メモやオンラインミーティングの議事録用。
議事録はHackMDよりはDoocle Docsを使う場合が多いかも。
読書会のログはあとで下記のWikiへ転記するなど。

GitHub 読書会Wiki

Agile459読書会用Wiki
Extreme Programming Explained 2nd Edition オンライン読書会のログ

Scrapbox

Agile459 – Scrapbox
主に、コミュニティ内向けの情報共有

Trello

trello.com
課題の共有、管理
※アカウントが必要

Twitter

@agile459
イベントのお知らせ

Facebook

Facebookグループ – Agile459
イベントのお知らせや開催報告など

Slack

Slack – Agile459チーム
日常のやり取り（雑談、運営について、読書会の相談、イベントの準備など）
※アカウントが必要

この記事は Agile459 retrospective for 2018 Advent Calendar 2018 のエントリーです。

Agile459は四国でアジャイル開発について学ぶコミュニティです。主な活動としては、毎年開催される Agile Japan のサテライトや、プログラミングのスキルアップを目的としたイベント開催、オンラインの読書会などです。
これまでのイベントについてはAgile459 – connpassをご覧ください。

さて、2018年のふりかえりですが、ほぼ半分は読書会でした。

ページ数は180ページほどで比較的薄い(?)本ですが、一人で読んだだけではなかなか頭に入ってこないというか腹に落ちないというか。で、それを参加者数名で１章ずつ読んで意見を語りあうことで、いろんな気づきがあったり、そこから派生して自分の仕事と照らし合わせたりしつつ読み進めるこtができました。

次はTDDBC。講師として@t_wadaさんに来ていただいて高松で開催。

これまで自分の仕事の中でTDDを実施していますが、いわゆる自己流になっていて、テストの書き方とかテストコードを使ってのリファクタリングの進め方など、まだまだ学ぶことが多いなぁと気がつくイベントでした。
あと、懇親会の際に@t_wadaさんのサインを求める人だかりができたり。

そして高知サテライト。今年の夏は災害が続いたこともあって、高知にたどり着くのになかなか苦労するような状況でした。その中で、ついに高知で開催できたこと、さらに、講師として いえぴょんさん(@haru01) に来ていただいてフィードバックループについて学べたのは大きな収穫でした。

で、先月開催したGDCR2018 in 松山。
GDCR 2018 in Matsuyama – togetter
会場の3rd floorさん、ランチやおやつのスポンサー各社にはあらためてお礼申し上げます。
@ramusara さんがイベントの企画からファシリテーターまでやってくれました。忙しい中大変だったと思います。次回開催する際は、皆さんのご協力をお願いします。それと、イベントが終わった後、懇親会場からハングアウトでバレンシア（スペイン）の会場にバトンを渡しました。

こんな感じの1年でした。今年の一番の学びは、組織の中（自分の仕事の中）だけでは気づかないことが多く、こういったコミュニティーに参加して実際に会って話すことが重要ということです。そして、小さなことでもできることから実施してみて、またコミュニティーで議論して、というフィードバックループの繰り返し。

来年は読書会から始まるのかなぁ、という感じでまだ具体的には決まっていませんので、ご興味のある方はぜひ参加していただいて一緒に学んでいければと思います。

“I’d like to run automated tests with reCAPTCHA. What should I do?”
https://developers.google.com/recaptcha/docs/faq

There is a set of keys for testing purpose.
On the first time, the reCAPTCHA widget will show a warning message. And verify with check “I’m not a robot”, completed message will appear.

機種名は Huawei nova lite です。
原因の特定はできていませんが、いくつか気になる点があるので今後の対応のためにまとめておきます。

症状としては、掛かってきた電話の通話中に突然切れる。通話時間1分47秒。
その後、先方から着信があるものの通話ボタンを押すと切れる。
しばらく時間を置いて（約6時間後）電話を受ける。この時は問題なく11分ほど通話。

最初に通話が切れた時は、アプリの更新の通知が3個ほどあって、更新はまだ実行していない状態。
この日以外にも頻繁ではないけれど、これまでに何度か通話が中断されて掛け直すことがありました。

あと、以前に、特定の電話番号から着信できない問題があって、その時はYmobileさんに調べてもらって、先方の交換機だかの問題と特定できた経緯があって、同じような問題なのかとYmobileさんに問い合わせてみたところ、そのような調査はできないとの回答で、

(A)SIMの抜き差し
(B)Safeモードでの起動
(C)場所を変えてみて着信できるかどうか

など試すようにアドバイスをもらいました。
結局、時間を置けば通話ができたので(A),(B),(C)は関係なさそう。

他に要因はないかと調べてみると価格.comに気になる書き込みがありました。

『着信できない。助けてください。』 のクチコミ掲示板

端末の不具合（ハードウェアの問題）の可能性もあるかもですが、APNの設定について書かれていたので確認したところ端末のデフォルトの設定（Application: plus.acs.jp.v6）しかなかったので、Y!mobile APNの設定を追加してそちらに切り替えておきました。

ワイモバイルスマホの初期設定方法 – APN未設定の場合（新APN作成）
これでしばらく様子を見ます。
この設定にすると、4Gの接続ができなくなりました。デフォルトの設定に戻します。
ユーザー名とパスワードを間違えていました。
ymobileのページの説明が

ユーザー名: ｙｍ<br>パスワード: ｙｍ

となっていて y と m の間にスペースがあるように見えるのですが、ここだけ全角文字になっていました。正しくは半角で間のスペースは不要でした。

ユーザー名: ym<br>パスワード: ym

上記の初期設定方法ですが、Ymobileが販売しているAndroid端末では追加のAPN設定は不要（デフォルトの設定でOK）とのことでした。