フラーに入社して2年経った

入社して2年が経ちました。

ふりかえりたくなったのでふりかえってみます。久しぶりに書くので乱爛々筆です。

仕事内容とふりかえり

やってきた仕事内容をまとめると以下のような感じです。

• ずっとクライアントワークをやっています。他社様から依頼を受け、私は主にAndroidアプリ開発を担当しています。
• 今はエンジニア採用のお手伝い(スカウトメールの添削、良さそうな方のピックアップ、カジュアル面談の参加、採用担当の方への現場の情報のインプットなど)もしています。
• チームリーダーとして5,6つくらいのプロジェクトの開発メンバーのマネジメント、20人くらいのマネジメントも担当するようになりました。今の仕事はそっちがメインです。

ごちゃごちゃ書きましたが、1年間はAndroidエンジニアとしてがっつりと、2年目からは採用・マネジメントなど組織を俯瞰したり、中期的な目線で見ることが多くなりました。

以下のように、この2年の間にやりたいことを全部やらせてもらえたので忙しくも充実した2年になりました。

• 新規アプリをやりたい -> 1年目で2本担当

• コードレビュー根づかせたい -> 1年目で導入出来た

• 採用や教育もやりたい -> インターンシップのメンター、計画に関われたり、エンジニア採用に絡めている。来年度の新卒教育にも絡めそう

• マネジメントもちょっとやりたい -> 2年目で担当出来ている

フラーに2年いて感じたこと

雰囲気と文化

• 所属する共創事業部では「受託ではなく、共創する」という考え方があって、それは入社してから2年いる今も変わっていないし、全社員が一貫して意識していると感じています。大事にしている価値観として「当事者意識」というのがあって、関わっているお客様のサービスを利用したり、ものを使ったり、お店に訪問したり、一度では収まらないほどユーザー体験を重ねます。

• 私個人としては非常に飽きっぽい性格なので、自社事業にずっとではなくて、色々な企業さんのお話を聞いたり、事業ドメインを理解すること自体が楽しいです。

• 社長、会長が私の一個上、と若いので、時代とか世間への感覚が近いのと、単純に話しやすいです。また、管理職も手を動かして何かをつくり続けたりするタイプの人(社長がデザイナー出身です)が多いので、刺激を受けることが多いです。

変わったこと(ネガティブな方が面白いので敢えてネガティブなこと)

• これまで色々と自由にTwitterにもブログにも書けた感じがあるのですが、クライアントワークである以上、色々自由に書けなくなった感は感じています。技術的なことでも、「この設計にしたらこういう失敗がありました」って書いたとすると「おや、それは私たちの会社のプロダクトでやったことなの?」とあらぬ心配を生むかもしれないとかとか。これは単なる一例だし、考えすぎかもしれないけども、まぁ考えすぎて悪いことはないと思っています。
• 一度新潟県内のイベントで発表したことがあったのですが、当日発表した内容と公開したスライドとで誤解を生まないように内容を少し変えたりしました。そういう配慮を考えるようになりました。
• 最近はマネジメントとか社内のことをやるようになったので、書けることが増えていきそうな気がしています。

変わったこと(ポジティブ)

いっぱいあります

仕事

• 会社から2kmくらいの距離に家があるので、自転車通勤になりました。通勤時間が減り、電車で疲れることがなくなりました。午前中に割とパフォーマンスが出る方なので、とてもありがたいです。
• 人が少ないし、まだまだ儲かっている会社ではないので、カーテンを開けるとか、ゴミを出すとか、加湿器に水を汲むとかそういう雑務も含めて色々やるようになりました。コミュニケーション取る量も取る人の幅もめちゃくちゃ増えたと思います。私はそもそも手広くやりたい気持ちがあるし、そういう人間性なので、楽しかったです。今でも楽しく加湿器の水を汲んでいます。
• 新規アプリをつくるときもだいたい1プロダクト1Androidエンジニアで開発するので、とても自由にかつ責任は重めになって、それも楽しいです。

プライベート

• コロナ状況の前から週一リモート制度があったので、積極的に利用していました。なので、コロナ状況になってもあまり影響が無かったです。幸い新潟は感染者も少なく、お出かけもそれなりに気をつければ大丈夫なのかなぁと過ごしております。
• 会社から2kmくらいの距離に家があるので、通勤時間が減り、家族との時間は大幅に増えました。
• 幼稚園戦争に巻き込まれないようになりました。第一希望の幼稚園に入れて良かったです。
• 家賃が3万円減り(近距離手当てが会社から2万円出るので実質マイナス5万円)、家の広さは3倍になりました。
• 自動車生活になりました。
• 新潟オフィスは人も少なく、とても静かです。家族を持っている人もいるので、飲み会は1次会で軽く飲んで、2次会はオフィスに帰ってきて水を飲むなどして静かに少人数で話して23時くらいになったら自然に帰る感じが私は好きです。

良いことばっかり書いて恥ずかしくなってきました。公開するのもちょっと恥ずかしくなってきたのですが、書くと言ってしまったし、この辺で。

フラー Androidとかでググるとプロのライターが書いた良い感じの記事が出てくるとは思うので、もっと知りたい方はそちらからどうぞ。

最後に宣伝ですが、GolangとAWSをがっつりやりたいサーバーサイドエンジニアと、クライアントさんのブランディングとかとか全部やりたいデザイナーを大募集しています。 気になった方はググってみてください。

マネージャーになった

(ただのお気持ちです)

今年の7月くらいにちょっとしたマネージャーになった。クライアントワークの開発に携わるエンジニアとデザイナーのマネージャー(20人くらい)として、1on1など主にピープルマネジメントをしている。

さらっと「ピープルマネジメントをしている」なんて書いたけど、そんな風に自分の仕事を思ったことはあまりない。ただ、カテゴライズして世間の言葉に直すとしたらそういうことをしています。

今年はコロナ影響もあったり、組織体制も変わったり、そもそも社長が会長になって、いままで上長だった人が社長になったり、人が倍以上に増えたりして異常にバタバタしていて、その中で私にその役割のバトンが渡されたので、3ヶ月くらい経ったけど、いまだに模索しながら仕事に臨んでいる。

新卒の会社の時に新卒研修のマネジメントをしていたり、派遣社員の方のマネジメントをしていたりはしたけど、やっぱり人数も人数だし、使う筋肉が全然違う感じがする。

と、少しだけふりかえる時間が出来たのでお昼休みにブログを更新してみた。新潟に来てから書いていなかったなー。

地方のITベンチャーに入社して1年と1ヶ月が経った

この記事は [フラー Advent Calendar 2019] (https://adventar.org/calendars/4155)の8日目の記事です。

前のふりかえりの記事から更に半年ほど経ちました。

namaninotiteti1026.hatenadiary.jp

この半年でやってよかったなということをふりかえりたいと思います。

全般

コードレビューの導入

• フラーの共創スタジオAndroid開発チームは千葉県柏市と新潟県とで拠点が別れていて、 正社員はそれぞれ2人ずついます。それぞれ担当プロダクトが異なり、新規開発と運用フェーズのプロダクトとでも別れたりしているので、プロジェクトのコンテキストを追うのが大変ですが、誰かにコードレビューをもらい1Approve以上でマージするルールを今年の4月ごろから導入し、継続出来ています。

• 正直、案件を跨ぐコードレビューって仕様レビューになってしまうかもしれない、であるとか、工数がかかり過ぎてしまうかもしれないと思った時もありましたが、当時2人だったメンバーが4人になって倍になったからこそ効果が発揮されている感触があります。また、議論の痕跡があることで、新しく入った人が入りやすいといったメリットもあります。

AndroidチームKPTふりかえりの主催

• Androidチームだけでふりかえりをやりました。部全体でのふりかえりやプロジェクトメンバー全員でのふりかえりは開催されていましたが、Android開発メンバー、という括りで開催するのが重要だと考えました。

• 結果的には今後の技術的な方針であるとか、リファクタリングの優先度付けにも繋がり、非常に有意義な会だったと思っています。

外部

• Mobile Crew Niigataというイベントでお話させていただきました。新潟にこんなにエンジニアがいるのか、、、という気持ちになるほど会場が埋まっていて、とても盛り上がったイベントになりました。来年もやりたいですね。

mobile-crew.hatenablog.com

• DroidKaigi 2020にCFPを提出しましたが、落選しました。今年やったことの中から制限マックスの3つを提出しましたが、ダメでした。今年は業務で色々な新しいことを学べましたし非常に成長したという自覚がありつつ、世間的に今何が注目されているのかとか、新規性へのアンテナが鈍かったなぁと反省しました。

droidkaigi.jp

まとめ

• 子供がいると、プライベートの時間が皆無で、最近は土日を諦めて、最近は出社1時間を書籍を読む時間に充ててます。久々にブログをこうして書いていますが、やっぱり辛いですね。そろそろお父さん業務について何か書きたいです。

今日はそんなとこで。

フラーで SingleActivity + MVVM + DI + Repository 構成で1年間Androidアプリを作って感じたメリットと課題

この記事は フラー Advent Calendar 2019 の7日目の記事です。

個人的なことですが、今年初めてお仕事として新規Androidアプリ開発に携わり、今年の5月にリリースしました。 そして現在も、来年にリリース予定の別のプロダクトを開発しています。

新規でアプリを作るときにまず間違いなく通る道は「どのような設計パターンにするか」だと思いますが、 現在、フラーで新規に開発しているAndroidアプリは 「SingleActivity + MVVM + DI(Dagger) + Repository」 という構成を取ることが多いです。

そもそもなぜ設計パターンを導入したのか

これは16日目に登場予定の "Daiki Okumura" が2018年の夏頃に導入したことが発端ですが、それまでのプロダクトにはこれといった設計パターンがありませんでした。

ここからは内情的な話になりますが、2017年から発足した弊共創事業部の創成期は「来年にはもしかしたらプロダクト毎死んでいるかも分からない」 「一人が短期間で作り上げる」「そもそもAndroidエンジニア足りなすぎた、時間が足りなかった」と聞いています。

そもそもアプリ自体もミニマムなものが多く、導入に至らなかったことは容易に想像できます。その状況から一気に割とモダンな構成になった訳ですが、結論から言うと、非常に開発がやり易くなっていると感じます。

それぞれのメリットと課題感

昔話はこの辺にして、現在弊チームが採用している「SingleActivity + MVVM + DI(Dagger2) + Repository」について1年間使ってみて感じた良い点と 現在抱えている課題感を共有したいと思います。

また、構成についての説明はほぼしないのですが、同じ構成のサンプルアプリが、 Googleが紹介しているarchitecture-components-samples`のGithubBrowserSampleとしてGitHubにあがっているのでそちらをご覧ください。 色々なMVVMのサンプルを読みましたが、このサンプルが簡素すぎても複雑すぎてもなく丁度良いサイズ感で、参考にしています。

横道に逸れますが「GitHubのリポジトリ一覧を表示する」アプリって何万回作られているんでしょうね。もしかしたら一番多いアプリかもしれません。

「SingleActivity + MVVM + DI(Dagger) + Repository」の良かった点と現状の課題

Single Activityについて

「Android Single Activity」でGoogle検索してもなぜかあまり日本語の記事が出てきませんが、SingleActivityとはその名の通り、アプリケーションにActivityを 一つしか持たないようにするものです。Fragment間の画面遷移は Android Architecture Component(以下、AAC)のNavigationに頼っています。

良かった点

• Activityのライフサイクル管理を考えず、Fragmentのみに集中できること
• AAC Navigationをフル活用できること
  • SafeArgsを使うことで型安全に画面間の値渡しが可能になる 今まで値を渡されるActivityに createIntent()のようなメソッドを書いていたのが不要になった

fun createIntent(
  context: Context,
  param1: Int,
  ...

• 画面遷移のアニメーション定義もxml管理できるようになる

課題

• 単一のActivityが唯一全てのFragmentの状態を知り得るため、処理が多くなりがちになる
• 処理が多くなるなら、Singleであることにこだわる理由はなさそうなので、分割もあり?
• Fragmentのバックスタックの理解など、Fragmentへの理解がだいぶ必要になる。というか一度はハマる　
• みんな本当にGUIのNavigationEditorで管理してるのだろうか、、、ぐちゃぐちゃになっているので見れたものじゃないが

MVVMについて

MVVMパターンはGoogleも推奨しているパターンの一つですね。もちろん以下のような注釈付きですが。

1 つの方法であらゆるシナリオにそれぞれ応じるアプリを作成することは不可能です。 しかし、ここで紹介する推奨アーキテクチャは、多くの状況やワークフローで利用できる優れた出発点になります。

https://developer.android.com/jetpack/docs/guide?hl=ja

良かった点

• それなりに古くからある考えなので、情報量が多いことがありがたい。参考になるコードの実例も、解説記事も
• Jetpack(AAC ViewModel、LifeCycle、LiveData)をフル活用できる
• 適切な分離が出来れば、Viewをスリムに保つ事が出来て、かつViewModelのUnitTestを書くことができる

課題

• 例えば自分は、MVPパターンの開発経験しかなかったのでMVVM自体の習得と共に、DataBindingやJetpackも同時に把握しなければならず、慣れるまで時間がかかった。 Android設計パターン入門でもMVVMは習得にコストがかかる、と書かれているが、本当にそうだと感じる
  • 特に初学者などには間違いなくハードルが高いので、「それぞれのコンポーネントが出来ること」と、「MVVMでやりたいこと」とを丁寧にフォローしないとパンクする。
  • 「最近のAndroid開発、初学者に厳しすぎないか問題」は正にこれのことだと思っている。

DI(Dagger2)について

DIパターンはUnitTestを書く時に便利なので、採用しています。Dagger2を使用しています。

良かった点

• 複雑そうだし、実際最初に書く時は辛いが一度書いてしまえば、後は便利
• UnitTestが容易に書けるようになる。寧ろ無いと本当に辛い

課題

• やはり一番の課題はここも学習コストだと感じる
  • MVVMとDaggerのダブルパンチだと相当辛い。(正直、納期のために雰囲気コピペで乗り切ることもあった。今は無い。)
• Daggerを捨てて、Koinに移行?という手もあるが、以下のようなデータを見るとまだまだDaggerで良いのかなという感じ https://github.com/Sloy/android-dependency-injection-performance

Repositoryパターンについて

MVVMパターンでは特に Model をどのように組むかについて指示は無いので、 サンプルや記事を眺めてみてもプロダクトによってUseCaseを挟んでいたりInterfaceを挟んでいたりいなかったりとバラバラですが、 弊チームでは、APIやローカルDBまでの仲介役としてRepositoryを利用していて、UseCaseは使っていません。

良かった点

• 具体的なデータ取得の方法に依存しないように出来るため、APIが直前まで出来ない問題に対応出来ること
  • モックデータを用意しておいて、直前に差し替える、ということを行える
• DIパターンの恩恵に預かって、だがビジネスロジックのUnitTestを書く事ができる

課題

• Repositoryに処理が寄りがちになる
  • まだそこまで大きくなっていないが、もっと大きくなったらUseCaseを導入した方が良いなと感じている

全体:今後やりたいこと

• Multi Moduleの導入
  • やっと最近上記の構成に慣れ始め、また人も増え始めたところなので、また新しいことを導入するには早い、と思い導入に至っていないが、 次に新規で作る際は入れない理由が無さそう。

後半駆け足になりましたが、今日はこの辺で。

明日はまた私で、「エンジニアリング全般で何か」書きます。

インターンシップをやっつけてきた話

南魚沼でインターンシップをやっつけてきた。

(勢いで書きなぐっているので良く分からん感じになってるかも)

note.mu

インターンシップの詳細は、スーパー高専3年生の成田さんが書いた上記の記事たちにお任せるとして、個人的なふりかえりを書いていこうと思う。

個人的に、どうでした?

一言でいうと、得られるものが多かった。

フラーに入って新規で1から色々ものづくりしてきたけど、その経験を活かし、今回、学生からあがってきた詰まりポイント、ハマりポイントに対してほぼ全て即時に対応出来た。それは今後の自信になった。

また、学生からの相談にも、「現場ではこうするね」と全てキッチリと回答出来たと思う。そういったことも含め、今までしっかりと腹落ちするまで意思決定を繰り返してきたのだな、間違っていなかったな、とふりかえることが出来た。

 

学生達は、どうでした?

素直過ぎるくらい、みんな素直だった。

こっちの言った事に対してめちゃくちゃ真に受けて吸収する、という印象。良くも悪くも、そういう感じだった。むしろそういう意味では、「もう少し自分で考えてやってみてもええんやで」というオーラを出したら何人かそういう方向に行動していた人も見えて、いやだから素直だなぁ!!となった。

 その素直さを活かしてもっともっと行動して、いろんな大人と話してって欲しいなと思った。色んなことを吸収して大きくなれそう。

一番印象に残った事

 エンジニアの子は二人いて、基本的に自分と常にペアプログラミングで行なっていた。基本的に「あ、これ分からないでしょ。調べてみて。やってみて」ってやって、それでも迷宮入り(といっても時間が無いので3分とか詰まってそうならすぐタオルを投げていた)しそうな時に助け舟を出す、というのを繰り返していたんだけど最終日あたりに多分段々と学生も勘所が分かってきて、メンターよりも早く解決策を出しちゃうっていうのが見られた事。

 つまりは、ペアプログラミングは最強。特にAndroidアプリ開発はAndroid Studioを如何に上手く使うかみたいなところの勝負でもあるので、そういう意味でもこの形式は間違いないな、と思った。

特徴は「田舎の古民家で、学生と6日間寝食を共にするということ」

 やってみて個人的に、このインターンシップの特異性は、その一言に尽きると思った。寝食を共に隔離された環境下で行うことで学生同士や学生とメンターとの距離が急速に近づくこと。だからこそテーマに沿った誰でも考えそうな上辺だけの議論ではなく、「本当にこの企画で良いのか?面白いか?向こうのチームに負けてないか?(もちろん全然勝ち負けではないけど、多分意識してたと思う)」といったことを真剣に本音でぶつけあうことが出来ている、と感じた。

で、またやりたい?

もちろん。 今回参加してくれた学生達にもどっかで会いたいし、その時までにもっと僕も成長しないとなと思ったし、そう心から思える仕事は中々無いので、こういう機会を大事にしていきたいです。

おつかれさまでございました。おそらくこれを読んでいるであろう参加してくれた学生達へ。また会いましょう。

「田舎の未来」を読んだ。

僕は、まぁ車で20分くらいの距離にイオンがあればどこでも良いっすね、と思うくらいには地方創生とかそういうものに興味が無い。無かった。

「田舎の未来」という本を読んだ。これは、衰退していく筆者の北海道の地元の現状と、それでも諦めずに何か出来ないかとしぶとく可能性を探り続けて戦っている事や調査の7年間をまとめた本だ。

元々、筆者と仕事で少し関わりがあるので知っていて、あと僕の出身地の滝上町と遠軽は距離にして62kmくらいと近いのでいつか読もうとは思っていた。また、会社のインターンシップのテーマと被ることも多そうだし、お盆休みだったしで良い機会だなと思って、読んだという感じ。

結論を言うと、とても面白かった。同じような地元の僕から見て、共感出来ることだらけだった。

 例えば、「地方と都市」という対立構造(地方での丁寧な暮らしvs都市での刺激的な暮らし)をやめませんかという話。

丁寧な暮らし。ハッキリ言うと僕の大嫌いなキーワードだ。僕の地元は冬になると、年によっては一晩でドアを開けることが出来なくなるまで雪が積もったり、-40℃まで気温が下がったりする。正直、丁寧な暮らしどころではない。一晩うっかりしていると死ぬんだから。だからどうしても違和感を感じてしまう。

地方と都市という対立構造に持ち込むこと自体がナンセンスで、益々溝が生まれていくからやめろ、という筆者の意見に賛成だ。

そんな感じで、自分の中のモヤっとしていたことや、それへの回答を述べていて非常にスッキリとした。

今、僕は妻の実家が近いから新潟にいる。良い意味で特に場所に対してのこだわりがないので、別に自分の地元に戻りたいとも思っていない。その土地に対しての面白さって特に無いものだと思っているからだ。

しかし、今所属しているフラーが長岡花火アプリ、佐渡汽船公式ページといった地元に密着した仕事をしていることや、この周辺の土地で本気でやっている人に会ったりして見て、ちょっと気持ちが変わってきている。

どういう風に変わったかというと、「地方に面白い人なんていないんだろうな」とどこか偏見を持っていたのが、「自分が面白い人を探していないだけ。面白い人はちらほらいる」という気持ちに変わった。

例えば、この前南魚沼市で6日間インターンシップをやったのだけど、そのインターンシップの協力をしてくれた市役所の人がバリクソ面白い人だった。僕の中の公務員のイメージが変わった。

そして、この筆者のように。地方にも面白いことをやっている人は、多分他にもいる。インターネットによってその熱量が伝わりやすくなってきている。

何が言いたいかというと、僕は「地方創生」という難しい言葉はちょっと意味が分からないけど、「地方でやってる地方にしか出来ない面白いことや、そこにいる面白い人」に対しては単純にワクワクするし、人々も結局そこに惹かれるのでは無いか。ということだ。

まとめると、地方創生って、その土地にどれだけ熱量が高く面白い人がいるかで決まると思っている。僕はそれになろうとは思わないけど、そういう人の熱量を伝えられるように、ふわっと他の人に波及させることが出来たら面白いなぁと思ったりしている。

今日はそんなとこで。

(参考)

http://sanokazuya0306.hatenablog.com/entry/20120922/1348323875 

田舎の未来 手探りの7年間とその先について (SERIES3/4 4)

地方のITベンチャーに入社して5ヶ月が経った

ふと朝5時に目が覚めて、頭も割とスッキリしてるので久々に軽くブログでも書く。

 
去年の退職エントリーが軽くバズって、「あの記事の人ですね」と良く言われるようになった。正直なことを書くと、それ以降なんだか多くの人に見られる気がして書き辛くなって
「どんな人に何を伝えたいのか明確にしないと」みたいな風に考えてしまい、いや仕事かっってなっていた。
 
なので会社のSlackに何でも書くことで発散していた。具体的には毎朝、分報のような感じで自分用のスレを立てて、そこに色々書いたりすることが多い。
まぁあと、クライアントワーク(他社と協力して開発)が多くなって書きにくい事も増えたのでSlackがちょうど良かった。
 
久々なので、あまり構成とかは考えず、この5ヶ月を雑にふりかえってみる。
 

2018/11

大きな出来事

新規案件のAndroidアプリ開発にjoin

 

感想

詳しくは言えないが、ターゲット層も何もかも今までとまるで違うアプリの開発。新規開発も初めてかつ、千葉オフィスにチームのほとんどのメンバーがいて、新潟オフィスにはその案件に関わるメンバーがほぼ僕ひとりという感じだったのでちょっと戸惑った。でもgit-flowに則った開発フロー自体は前職と変わりなく、ちゃんとコードをpushすればメンバーとして認められるような気がして、最初から居心地は悪くなかった。
 
 

2018/12

大きな出来事

引き続き新規案件の開発、開発、開発

 

感想

0->1の開発に慣れ始めた頃。思えばどんどん大胆に、悪く言うと雑になっていた。この頃の自分が作った負債に今でも苦しめられることが多い。でも考え過ぎても仕方ないし、正直今でも正解が分からない。すぐアウトプット出来るからこそフィードバックを貰える訳で。まぁこの辺のバランスは一生悩み続けるんだろうな、と思った。

2019/1

大きな出来事

新規案件からちょっと抜けて、初めての他社からの引き継ぎ

感想

初めて、他社が書いたコードの運用・保守を行なった。新鮮だった。前職のアプリ規模と変わらないくらいのものだったけど、MVPなりMVVMなりの設計パターンがほぼ適用されておらず、「おぉ、、、お久しぶりです fat activity、、、」という気持ちになった。「先人に敬意を払いつつ、技術負債を洗い出す」というissueを立てて、一つずつ技術負債を摘んでったけど我ながらあれは良いissueのタイトルだったと思う。
 

2019/2

大きな出来事

新規案件に戻される 

感想

色々あって新規案件に戻る。やることとか役割も増えてしまって、2・3月は社会人人生で一番忙しかった。コードを書きつつ、調整業もしつつ、家庭内の治安を維持していた。後はあんまり覚えてない。0時頃に家で会社の人とZoomしてた時は自分でも「盛り上がってんなぁこいつぁ!!」と思った。
 

2019/3

大きな出来事

引き続き、新規案件。初めての「嫁、実家に帰る」事案が発生する。
 

感想

中旬くらいに区切りが付いて、一息ついた頃に体調を崩してしまった。この仕事終わったら、あれしようこれしようと約束していたことがそれで出来なくなって嫁がブチギレて実家に帰る。今は大丈夫です。
 

 
やっぱり全然詳しく言えないけど、こんな感じです。新規案件をやることで決断力や判断力もついて成長したけど、前よりもインプットが減ってしまって、技術を荒く使っている感が否めないので、このリリース終わったら丁寧に復習しておきたい。まぁその前に妻に色々あれするのが先だけども。ありがとういつも。調理師免許持ってるだけあって、いつもご飯が美味しいです。
 
 
まぁ、そんな感じです。楽しくやってます。