【IT×他業種インタビュー】第3回：銑鉄鋳物製造業 日本海電化鋳造株式会社 工場長 立中得男様

こんにちは。Beta Computing株式会社の吉村です。
今回は、皆様がどのような業務をこなし、どういった課題に直面し、どんな対策や取り組みを行っているのか直接お伺いして取材させていただく企画の第3回目です！

IT×製造業インタビュー

第3回目の取材は、建設機械のカウンターウェイトを鋳物で製造する 日本海電化鋳造株式会社 工場長であり鋳造技士の立中得男さんと、若手社員の池田さんです。
本日はよろしくお願いします！

何十キロから何トンの鋳物を取り扱い、高い要求基準をクリアした高品質な鋳物が得意

──事業内容を教えて下さい

立中さん:
鋳物とは高温で溶かした鉄を型に流し込み、冷えて固まったあとに取り出す製法で作られる金属製品です。
鋳物の起源は古く、メソポタミア文明の時代からあったと言われています。鋳物は自動車、航空機、工作機械、産業機械から、身近なところで言えばフライパンやエクステリア製品などさまざまな場所に使用されています。
当社は鋳物でカウンターウェイトと呼ばれる重りを製造しています。カウンターウェイトとはパワーショベルやホイールローダーなど建設機械のお尻につき、重たいものをもったときでも前に倒れないようにするための部品です。

カウンターウェイトは鋳物と製缶ウェイトの2種類作り方が存在します。
鋳物は溶かした鉄を型に流し込むので丸い形、くり抜いた形など自由な形で作ることができます。また比重も製缶ウェイトと比べて高いので、薄くて小さい製品が容易に製造できます。
製缶ウェイトとは、鉄を曲げたり溶接などを行い、箱型の器を作った後に、鉄くずやコンクリートを入れて蓋をします。10トン20トンなど重いものを安いコストで製造できますが、形が箱型となるためどうしても直線的な形となりやすく、形状の自由度は鋳物に比べると劣ります。

──お客様はどういった業種でしょうか？

立中さん:
当社は建設機械を開発する企業様がメインの取引先になります。
数kgから数tのものまで幅広く製造しています。

──大量に発注されることが多いですか？

立中さん:
建設機械1台にカウンターウェイトが最低1つ必要です。
自動車部品は毎月数千から数万ロットとなりますので、建設機械はそこまで多くありませんが、少なくもありません。

鋳造業会社によっては同一製品を何十万個つくる体制の会社があったり、1品のオーダーメイド形式の会社もありますが、弊社は数十から数百ロット程度の微妙なロット数を得意としています。

弊社は万単位ではありませんが、1,2個ほど少ないわけでもなく、他の会社が嫌がるような微妙なロット数の中間部分、そこをターゲットにしています。

──御社の強みはどういったものでしょうか？

立中さん:
当社は自社の工場で製造する以外に、海外から相当量の鋳物を輸入しています。また他社（グループ会社など）が輸入をした鋳物の保管、検査及び手直しも行っており、当社で取り扱う鋳物の量は年間15,000t（自動車に換算すると1万台以上）程となります。カウンターウェイトのような大型の鋳物製品をここまでの量を取り扱える企業はなかなかないと思っています。

次に他の鋳物メーカーと大きく違うのは成形技術に特化していることです。鋳物は中に組み込まれることが多く、表面がざらざらのイメージがあると思います。 弊社では目に触れる場所の製品を作ることが多いため、ざらざらではなくつるつるのものを作ります。 高品質な鋳物を作る会社は多くありますが、外観に気を使う会社は少ないですね。

グループの強みを活かし、幅広い事業を展開しつつ、高い技術力や高品質な製品を提供する

──他業種との連携ありますか？

立中さん:
弊社は製造、建設、リース、機械加工、環境と幅広い事業を展開している音頭グループの1社です。
グループ内で連携をとることが多く、例えば、グループ会社の音頭金属には建設や建物の修繕を依頼することがあります。
音金機械には社内の部品加工用に鋳物の加工を、大和環境分析センターには工場の作業環境測定を依頼しています。

──グループ連携での良い面と課題など教えてください

立中さん:
グループ間の社員の仲が良いのでお仕事は頼みやすいです。価格や納期なども配慮してもらえることが多く、良い連携が取れていると思います。

課題については、あたりまえですが、業種や社風が違いますので、グループ全体で大きな物事を進めていくことが難しいと感じます。
実務担当だけでなく、マネージャークラスの横のコミュニケーションが活発になると、グループ全体で今以上に成長できるのではないかと考えています。

──現場の基本的な業務の流れを教えて下さい

立中さん:
鋳物はたい焼きをイメージすると分かりやすいと思います。
まず、たい焼きはたいの形をした鉄の型に生地を流し込みますが、鋳物も同様に型を作ります。当社ではそれを砂で作っています。砂には樹脂と硬化剤が混じっていて、時間がたつと固まります。そこから木型を取り外すと、砂でできた型ができます。
この型に、たい焼きでは生地となる液状になった鉄を流し込みます。鉄は1500度くらいで溶かします。冷えて固まった後、砂型を崩して中身を取り出します。

砂がこびりついているので、ショットブラストという小さい鉄の玉を打ち付ける機械で表面についた砂を取り除きます。
バリ(たい焼きの端のみみ)をグラインダーと呼ばれる工具(高速で砥石が回る)で削っていきます。
弊社の製品は大きくて形状もさまざまなので手作業で行います。この削り加減などが重要な部分です。
外観にできた凹凸やざらざらな面をすべすべにするため、パテと呼ばれるものを塗ります（ファンデーションのようなもの）。その後、サンドペーパーで均一になるように磨いていきます。 最後に色塗って完成です。

──出来上がりまでの期間はどれくらいになるのでしょうか？

立中さん:
製品によりますが、木型があれば3.4日程度で完成します。大きい製品は冷めるのに時間がかかったりするのでもう少し長くなります。平均して1週間から2週間程度となります。

──高温の鉄・・・特に夏場だと辛そうです

立中さん:
ほんとに現場の皆様には頭が下がります。
作業環境をよくしていくのは永遠の課題です。

鋳造は古くからある技術だが、データ化できない部分が多い

──現場ではどういった課題があるのでしょうか？

立中さん:
鋳造はメソポタミア文明の頃からある古くからの技術ですが、暗黙知的な箇所が多くあります。
一番は砂型の中から取り出したときに初めて製品の状態が分かるということです。逆に言うと取り出すまでは過去の経験などの予測で作っているということになります。

また、気温や湿度といった日々変化するさまざまなことを考慮して、機械の設定や、薬品の混合などを調整します。
道具の使い方についても目、耳だけではどうしても伝えられず、体で覚えなければいけない部分がありますので、後継者の教育にも苦労しています。

ノウハウをしっかりとデータ化し共有していくことが今後の課題と考えています。

──データ化ができないと後継者の教育も難しくなるのですね

立中さん:
安全管理の面でもデータ化はしなければいけないと思っています。
弊社は重量物や高温のものを扱うので安全が第一ですが、どうも今の若手社員たちは危険に対する意識が低いように感じます。
もちろん私達ベテランがもっと教えていかなければいけないのですが、過去の事例を語り部のように伝えていったところで、なかなかピンとこない部分があると思います。
そこで、過去の事故、怪我などをデータ化、見える化し事前に警告できる仕組みなど作れないかと考えています。

──その他意識していることはありますか？

立中さん:
毎日の朝礼で、私自身が日々感じていることから現在の会社の業績、お客様の動向などさまざまなことを伝えるようにしています。
昔は簡単な業務連絡や誰が今日休みかなど他愛のない話が多かったのですが、売上や利益など自分給料に影響の出そうな話をすることで、耳を傾けてくれる人が多くなったように感じます。

──以前kintoneを導入されているとお聞きしました。kintoneを選定した理由を教えてください

立中さん:
他社に比べ、導入費用が圧倒的に安かったこと、カスタマイズが容易だったことが理由です。

弊社は従業員45人の内、事務メンバーは5,6人になりますが、その人数ですら情報共有ができておらず、業務が属人化していました。
確認事項も各自のメモ帳の手書きキーワードを基に話をしていたり、古い紙のファイルを引っ張りだしてきたりととても非効率でした。
現場への伝達事項も人数分の紙を印刷して配っていたのですが、変更があった際に担当者に伝え忘れたりしてお客様に迷惑をかけてしまったこともあります。
これらの問題を解決するため、ITツールを使用し情報を共有していくことが喫緊の課題でした。
その中で様々なベンダーと相談しkintoneを選定しました。
これらの課題を解決するためにいろいろなベンダーと相談し、結果kintoneの導入を決めました。

Kintoneを使用し、売上、品質、図面などさまざまな情報が共有できるようになりました。まだ利用し始めたばかりですが、概ね満足しています。

──業務上でスマートフォンは利用しますか？

立中さん:
よく利用します。
基本はLINEを使用しています。口頭では忘れてしまうようなことでも記録として残りますので便利です。また不良品や設備トラブルがあった際も写真を送ってもらうことで、判断がスピーディーになりました。

──IoTの活用があれば教えてください

立中さん:
砂型に使用する砂を出す機械に活用しています。砂、樹脂、硬化剤の温度や使用量を把握できます。また機械のエラーが起こった際は症状などがすぐさまメーカーに連絡がいくようになっています。
自分たちが気づかないようなエラーも検知してくれます。
また、在庫状況もメーカー側で把握できるため、こちらが在庫を把握せずとも適切なタイミングでメーカーから注文の確認の連絡を頂けるので非常に便利です。
IoTが一段と進むと、流通だけを担っているような商社様は生き残っていけないのではないかと感じています。

ITを活用したいという思いはあるが知識がない。導入費が大きいとハードルも高い

──IT活用に抵抗はありませんか？

立中さん:
1年前から給与明細をクラウド上で見られるようにし、年末調整も従業員自身がWEB上で入力する仕組みを導入しました。導入検討時は、年配社員の混乱、抵抗があるのではないかと心配しましたが、まったくなかったです。
年配の方たちも、ITが便利なことは分かっていても使い方が分からないだけなんだと思います。そこは導入時に丁寧にフォローすることにより、とてもスムーズに進めることができました。

今後は生産管理システムの導入などを検討しています。現場の人たちがいつでもタブレットなどで、生産計画、納期、図面、品質の注意事項など見ることができるようにしたいと思っています。

──ITの知識や活用について我々ももっと提案できるようになる必要を感じています

立中さん:
IT、特に何かシステムを導入しようとした場合、初期投資が大きい割に、費用対効果がダイレクトで見えにくいと感じます。
業務において、煩わしさを感じてはいるものの、そこまで費用をかけてやる意味ある？と思われることが多いです。
更に導入費用も数百万を超えるものもあり、失敗したときのリスクを感じるとなかなか導入に踏み切れません。やはり小さく初めて育てていく方が当社の規模のような会社には合うのではないかと感じています。

その点、kintoneのようなサブスク形式のものはすごく助かります。もし合わないようなら簡単にやめられますので。
あと、ITベンダーの方には補助金の情報やサポートをもっとしてほしいなと思います。IT導入補助金などありますが、自分たちで資料を揃えて一から申請はなかなか大変です。費用がかかっても手続きを代行してほしいというニーズは多いのではないでしょうか。

──最後に、読者の方へのメッセージをお願いします

立中さん:
弊社は国内外の多数のネットワークで数kgから数tまでの鋳物を年間1万5千トン取り扱っています。今後はIT活用をさらに進め、デジタルとアナログの融合を果たすことで高品質、低価格、短納期を実現させ、さらなる成長と発展を行っていいます。
鋳物のことでお困りごとがございましたらぜひ弊社にご相談ください！

──以上になります。ありがとうございました。

立中さん:
ありがとうございました。

日本海電化鋳造株式会社様　連絡先

〒929-0319 石川県河北郡津幡町能瀬ホ68
日本海電化鋳造株式会社
代表者　音頭　栄美子
http://www.nihonkaidenka.jp/

日本標準産業分類

大分類：製造業
中分類：鉄素形材製造業
小分類：銑鉄鋳物製造業

【IT×他業種インタビュー】第2回：ガラス工事業・金属製建具工事業 有限会社岡本アルミガラス 代表 吉野茂樹様

こんにちは。Beta Computing株式会社の吉村です。
今回は、皆様がどのような業務をこなし、どういった課題に直面し、どんな対策や取り組みを行っているのか直接お伺いして取材させていただく企画の第2回目です！

IT×建設業インタビュー

第2回目として取材させていただきましたのは、窓や玄関に関する工事・販売を津幡町・かほく市で提供されている 有限会社岡本アルミガラス 代表の吉野茂樹さんです。
よろしくお願いします！

商圏を津幡・かほくに絞り、高品質のサービスと充実したアフターサポートを提供する

──事業内容を教えて下さい

吉野さん:
メイン事業は、家の玄関・勝手口・窓など「開口部」となる箇所の販売(大工、工務店など)や工事を手掛けています。
低価格で高品質、窓ガラス交換早急に対応、地元業者ならではの柔軟な対応力、という強みを活かしてサービスを提供しています。

──地元ならではの強みとは具体的にどういったものですか？

吉野さん:
現在は広範囲でサービスを販売するお店も多くあります。
商圏は広がりますが、その反面アフターサポートがやりづらく、すぐに動くことが難しくなります。
岡本アルミガラスは商圏を津幡・かほくに絞ってサービスを提供しています。
ガラスが割れた場合や戸締まり周りの工事・修理は急ぎで必要とされることが多いので、すぐに動けるような体制を維持しています。

昔から繋がりのある会社さんや地域住民、チラシやネットで知ったお客様や口コミで知った方々などからご依頼をいただいております。

──創業から50年以上経っていますが、当初から地元を中心に？

吉野さん:
創業当初は大工さんがお客様で、サッシを販売していました。
大工さん、工務店などの卸しをもともとメイン事業でやっており、それが徐々に一般消費者である個人のお客様と直接つながるようになってきました。
現在では、個人と企業5:5の売上金額になっています。
件数で言えば、個人の方が多いです。

──現在はどれくらいのご依頼があるのでしょうか？

吉野さん:
ガラスの交換や鍵の交換など、足が速く単価が安いものも含めると年間顧客は元請け下請け含めて700件ほどありますが、弊社は従業員2名と現場2名、事務員のメンバーで対応しています。

──年間700件以上の件数をなぜ少人数で対応可能なのでしょうか？

吉野さん:
地元のお客様がほとんどのため移動時間が短く、1日に数件対応することができます。
作業時間も短いもので数時間、長いものでも1日で終わります。

地元を中心に展開することで、少人数の体制でも年間700件の依頼を受けることができます。
商圏を広げることを考えることもあるのですが、現在のサービスとアフターサポートの品質維持が難しくなります。
また、大手や中小のライバル店が多くなり、値段ばかり見られてしまいます。
営業範囲も拡大する必要があり広告費もかかるので、商圏拡大にあまりメリットが感じられません。

小さな依頼でも丁寧に対応する。大手にはできない

──現場の基本的な業務の流れを教えて下さい

吉野さん:
例えば玄関窓の取替えだと、
①お客様からご依頼を受注し見積もりを提出します
②見積り金額をご検討いただき、ご注文を受けます
③現場を確認し、対象物のサイズを測ります
④メーカーへの商材の手配が必要であれば発注します
⑤入荷日確認後、お客様のご都合を確認し、工事日を決定します
⑥工事完了後、お客様へ請求書を提出します
⑦入金確認
といった流れです。
基本的に1日で工事が終わることがほとんどになります。

他の大手では営業ノルマがあり、基本的に大きな数を売りたいと思っています。
そのため、窓1箇所の対応などは引き受けて貰えないこともあります。
ですが、お客様にとっては1箇所も数箇所もあまり関係ありません。
私たちはむしろ、まずは1箇所試してほしいと思っています。
そして、さらなる注文や、何かあったときにまたご依頼していただければ良いと思っています。

様々な家があり、家によって作りが違うため対応が難しいものもありますが、年間700件以上の対応をやってきて、家によって最適な対応が感覚でわかるようになってきました。
1箇所の対応でもご依頼いただければと思っています。

──業務の中で課題はありますか？

吉野さん:
見積もりや経理などの事務処理が大変です。
人件費がかからないように全て1人で対応しています。

──ITを活用されていますか？

吉野さん:
メーカーのシステムで、請求書や領収書を書式で出すものを利用しています。
YKK APのシステムで、YKK APが展開するMADOショップ事業の一環です。
これまではPCで請求書などの書類を作成していましたが、顧客管理はできていませんでした。
システムを入れてからはどのようなものが売れているか、粗利や各項目の割合、仕入れに関する情報など、細かく管理できるようになりました。
年間顧客件数など見れるので、顧客解析も可能です。

また、MADOショップの運営サイトに津幡中須加店としてホームページを公開しています。
ホームページ、書類、顧客管理などすべてYKK APのシステムを利用して作業することができます。
MADOショップとしての費用も少しかかりますが、DMの発行もできますし、大きなメリットを感じています。

──御社にお伺いしたときMADOショップのことが気になっていました

吉野さん:
一般消費者向けに販売するための窓口がMADOショップです。
MADOショップは「ニッポンの窓をよくしたい」という理念のもと、YKK APとパートナーシップを結び、全国で活動する窓リフォームのお店です。
YKK APから「MADOショップのお店をしませんか？」と声をかけていただいて参画しています。

最適な宣伝方法を検討しているが、答えは出ていない

──業務の中でITを活用されているものはありますか？

吉野さん:
業務連絡やお客様とのやりとりなどコミュニケーションは電話がメインですが、人によってはLINEを利用する方もいます。

──IT活用に興味や関心はございますか？

吉野さん:
ITは重要視していかないといけないと思っています。
現在は年配のお客様が多いので、年に4回くらいほど折込チラシを出しています。
ただ、新聞を取らない人も増えてきていますので、今後チラシの効果が減っていくでしょう。
広告宣伝費の使い方や方向性を改めて検討する必要性があると思っています。

ただ、一般消費者に向けての最適な宣伝方法は現時点ではわかっていません。
MADOショップのページでも工事・修理事例に費用を記載していないお店がありますが、消費者の方の参考にしてもらえるように、弊社は金額を載せています。

──お客様の年代や性別などターゲット層はどのような種類ですか？

吉野さん:
家を立てて20年以上経つ一般の方がメインターゲットです。
おおよそ20年経過頃から玄関や窓に不都合が出始めます。
仮に30代で家建てたとしたら、50〜60代の方々です。
ただ、中古住宅を購入した方もいらっしゃるので、その限りではありません。

また、外壁は10年くらいで寿命がくるものがあるので、そういった周期の方々に目に留まるよう広告を打つようにしています。

──同業者とのつながりはありますか？

吉野さん:
津幡町商工会を中心に、地元の大工さん、瓦屋さん、水道管屋さんなどとのつながりがあります。
例えば住宅のお仕事では、1つの業者様が請負し、得意分野のお仕事をそれぞれ担当するよう紹介したりします。

サッシの同業者でいうと、ガラス組合というものがあり、MADOショップというくくりでも県内でも9社ほどつながりがあります。
親子で経営していたり家族でやっている会社が多く、繁忙期などは近隣のサッシ屋さんに応援依頼することもあります。
横の連携は取れていると感じています。

昔から連携はありますが、最近は若手世代が横のつながりを大事にしています。
逆に、親世代の方が周りをライバル視しているイメージです。

また、残念ながら廃業も増えています。
跡継ぎがおらず、親世代でやめる人たちも多いです。
現在では、津幡やかほく市周辺だと3～4社になると思います。

──コロナや戦争の影響はありますか？

吉野さん:
コロナ渦で、お客さんの購買意欲が下がりました。
また、家に直接お伺いすることができなくなってしまったので、工事キャンセルが相次ぎました。
そのため、売上が1000万円ほど落ちることもありました。

昨年は換気需要で網戸などの受注が増えていたのですが、戦争の影響によりまた購買意欲が下がってしまいました。
現状、チラシを出してもこれまでより反響が薄いです。
以前よりお客様の財布の紐が硬いと感じます。

──建築の建材などの材料費が高騰していると聞きます

吉野さん:
原価がすごく上がりました。ガラスは燃料高騰で戦争以前より2〜4割値段が上がっています。
具体的には、6000円の原価ガラスが9000円になりました。

──費用も変わっている？

吉野さん:
やはり見積り作成時点で、これまでより2割～4割価格が上がっています。
原価の高騰により、定価表記も上がっています。
そのため、お客さんの負担が増えていくのが心苦しいですが、仕方がない部分もあります。

──最後に、読者の方へのメッセージをお願いします

吉野さん:
弊社の職人はプロフェッショナルです。
直ぐに、丁寧に、迅速にご対応することを心がけています。

お客様の満足を第1に考えております。
良い職人さんがきれいに仕上げることで、お客様に喜んでもらえることがやりがいです。
事務、経理、現場の職人含め全員で努力しております。

玄関・窓でお困りの際はぜひお声がけください。

──以上になります。ありがとうございました。

吉野さん:
ありがとうございました。

有限会社岡本アルミガラス様　連絡先

〒929-0332 石川県河北郡津幡町中須加ろ27-2
有限会社岡本アルミガラス
代表　吉野　茂樹
http://okamotoarumi.com/

日本標準産業分類

大分類：建設業
中分類：職別工事業
小分類：ガラス工事業、金属製建具工事業

おわりに

今回は、津幡町にある岡本アルミガラス様に取材させていただきました。
実は、弊社メンバーの1人が岡本アルミガラス様に2重窓の取り付けを依頼したことがきっかけで取材に至りました。

窓の取り付けを数社に見積りしたところ、岡本アルミガラス様の価格が1番納得できたそうです。
また、取り付け場所の確認において、作業や説明が丁寧だったことが依頼の決め手に。
実際の取り付けもきれいで手際良くすぐに終わったようで、大変満足しているとのことです。
取材を通して、地元のお客様を第1に考えていることをとても実感することができました。

吉野さん、この度はお忙しいところインタビューを快くお引き受け下さり、本当にありがとうございました！

本内容が少しでも皆様のご参考になりましたら幸いです。
今後も他業種インタビューを更新していければと思いますので、次回をお楽しみに！

【IT×他業種インタビュー】第1回：一般貨物自動車運送業 野々市運輸機工株式会社 代表取締役 吉田章様

こんにちは。Beta Computing株式会社の吉村です。

ITの活用がどの業界でも叫ばれるようになってから数年が経ちました。
しかし、現場レベルではまだまだ浸透しているとは言えず、活用しきれていないと感じることが多くあります。
その度に弊社は皆様にとってどのような存在でいればよいのか、兼ねてより、より具体的に価値を見出そうと考えておりました。

どのような価値を提供できるのか──。

どのような存在になれるのか──。

皆様が、どのような業務をこなし、どういった課題に直面し、どんな対策や取り組みを行っているのか、まずは知らなければならない。
であれば直接話を伺う方が正確で早いと、インタビューする企画を思いつきました。

IT×運輸業インタビュー

第1回目として取材させていただきましたのは、運送事業をメインに手掛ける 野々市運輸機工株式会社 の代表取締役である吉田章さんです。
よろしくお願いします！

大手がやりたがらないものをやる。そこにニーズがある。

──事業内容を教えて下さい。

吉田さん:
お客様にあった物流を提案させていただき、お客様にあった運送を行っています。 主に、北陸3県を範囲とした運送と北陸-大都市圏の運送がメインです。 様々な運び方がありますが、主力の1つに重たくて長いモノに特化した運送サービス"メタル便"があります。
全国に構成された運送ネットワークを使い、北は北海道から南は九州までリレーのバトンを渡すように目的地まで荷物をお届けしております。
メタル便は全国を網羅できるよう中小企業7社で作っています。

──7社はどうやって？

吉田さん:
メタル便の歴史は古く、2000年から開始されているサービスになります。
メタル便は長尺物や重量物を運送するサービスですが、この長尺物や重量物というのは大手運送会社が嫌がる荷物で、業界では「ゲテモノ」呼ばわりされていました。
大手が運送の対象物としなかったことで、それらを運ぶ需要が生まれました。
関東では多くの重量物が運ばれ、大阪では長尺物ばかり集まっていたようです。 「総合トラック」という会社が中心となり、関東と大阪をサービス圏にメタル便が開始され、それが2000年になります。
弊社は2016年度に北陸地域の運送会社として加入し、現在では7社となっています。

──メタル便をはじめてみて反響はありましたか？

吉田さん:
メタル便が利用できるからこそ商売を続けられる会社さんもいらっしゃいます。
メタル便として北陸地域に向けてDMをうった次の日の朝一番から「こんなサービスがあるのか！」とDMを握りしめたお客様が訪ねてきました。
「メタル便がなければ商売をやめていた」と言われたこともあり、お客様から求められていることを強く実感できました。

現在、働き方改革や2024年問題によりドライバーが不足しており、今後も需要が高まると予想されます。
さらにはガソリン高騰によって大手企業の費用も高くなっているので、メタル便に注目が集まっています。

──御社の強みをお聞かせください。

吉田さん:
北陸エリアでの混載・共同配送を得意としております。
また、メタル便では大手が引き受けない長尺物・重量物の全国運送を行っています。
その他では、大都市圏の大手企業が北陸まで荷物を運ぶのは手配の手間やコストがかかるということで、北陸に拠点(ヤード・倉庫)を作りたいという企業が増えてきました。
これまでは、高速道路の整備やトラックの普及が進み、地方の在庫が無くなっていき、東京や大阪に集約される動きでした。
ところが、長距離ドライバーの労働時間規制の動きが大きくなり、大手企業はコンプライアンス違反を気にするようになったため、地方に在庫を確保し工期に合わせて運送するような形に変わっていきました。それにより、保管業務の依頼が増えてきています。
弊社は機械等を運ぶだけでなく、お客様の工場内へ搬入し据え付けまで行います。
大型機械等の移動も専門に行っており、お客様の工場内にある機械のレイアウト変更などすることも可能です。

──お客様の業種は？

吉田さん:
製造業、建築業など、大きくて重たいものを運ぶ必要がある業種です。
機械装置や、鋼材・鉄・ステンレスの素材、木材など建築資材を運送します。

──現場の業務の流れを教えて下さい。

吉田さん:
現在40人ほどのドライバーさんがいます。ドライバーは長距離ドライバーと地場ドライバーにわかれます。
長距離ドライバーは北陸3県から大都市圏にモノを持って行く、大都市圏から北陸にモノを持って帰ってきます。
地場ドライバーは北陸3県内にモノを持って行きます。毎日日帰りになります。
長距離ドライバーは泊まりになることが多いです。1日かけて運送します。

──長距離ドライバーは県を跨ぐことになります。コロナの影響はありましたか？

吉田さん:
県を跨ぐことによる影響ですが、ドライバーは1人の時間が長いので、感染者もなく、県外には行くが他の人と触れ合う機会は少ないので感染者が出た等は特にありませんでした。
ただ、お客様の出荷が止まってしまったため、売上に大きく影響がありました。

──業務の中で課題はありますか？

吉田さん:
課題はたくさんあります。
外部環境としてコロナが落ち着きそうで落ち着かないことと、さらにはウクライナでの戦争も始まってしまいました。
原油高が非常に辛く、同じ距離(少ないくらいなのに)で昨年度より1千万円のコスト差が出ております。
どうしても外部環境の影響を受けてしまいますね。

社内では、直接のコミュニケーションを取りづらくなってしまいました。
飲み会や食事でのコミュニケーションが減り、細かな情報共有や社員の調子などわかりづらくなっています。
チームワークが重要であるのに、それを強める機会が減っています。

IT導入はスモールスタートが良い。受け入れてもらうことが大事。

──情報共有について、ITツールを使用していますか？

吉田さん:
ITや情報に興味があり、10年ほど前から会社の基幹システムを入れ替えました。
また、社員とのコミュニケーションでいうと、2018年に社内でスマートフォンを支給しました。
スマートフォンの普及が進み、父親60代でも使えているのを身近で感じたこともあって、全社員に渡しました。
一番の目的はチャットツールを利用するためです。

支給前の業務連絡は電話でを行っており、例えば、どこにモノを降ろしました、卸し終わりました、どこに向かっていますなど、社員みんなが電話を掛けるため、つながらないことがしばしばありました。
以前から電話での情報共有に不満があったので、業務連絡は基本電話禁止し、全てグループチャットでやることにしました。
つながらない、折返し、などの作業の無駄が無くなり、また、エビデンスとして残るようになったため、言った言わない問題も無くなりました。
注意事項の情報共有など、すぐに周知できるのも良いところです。

──ちなみに支給したスマホはiPhone？Android？

吉田さん:
通信会社から良い提案があったので、Android端末を支給しました。
格安スマホなどもまだ無かった中、ショップでは無理でしたが、通信会社と直接交渉したところ、安く提案いただけました。

──スマホを支給したことによる社員の反響はありましたか？

吉田さん:
60代社員でも使えており、業務中の電話がすごく減りました。
1人だけ64歳の人が3日たっても電源の入れ方がわからないと戸惑っていましたが、すぐに解決しました。
1週間で電話からチャットワークの体制に変更できたのは良かったです。

また、情報のやりとりがグループチャットになので、誰がどこで何をしているのかの会話が見えるようになりました。 当事者同士の会話が見えなかった以前は、あいつばっかり楽をしているではないか等の不満が募っていたのが、グループチャットだと他の人の苦労が見え、他人への不満が減りました。

──チャットワークを選んだ理由を教えて下さい。

吉田さん:
みんなが使いやすいシンプルなのはチャットワークかなと思い選びました。
使用に対する社員からの声は特にありません。ただ、何もないことは良いことだと思っています。

チャットワークにはAPIの提供があるので、それを利用していけばいろいろな情報を自動的に社員に発信できるようになります。 自分で調べながら工夫して進めています。
例えば、ありがとうカードをチャットワーク上で行えるようにしました。
ありがとうカードとは、他人への感謝を伝える取り組みになります。
ドライバーは孤独な作業が大半であり、会社で褒められることが多くありませんので、社員同士で感謝の言葉を紙に書いて社内に設置したポストに入れるようにしていました。 今では会社のカルチャーとなっています。
ただ、これまでに何千枚と紙が使われていた上、外出中のドライバーでも利用しやすいように、ありがとうカードをチャットワークに移行しました。
Googleフォームとスプレッドシートとチャットワークを連携し、自動で配信・集計するようにしています。
加えて、くじびき機能もつけて100分の1で当たりが出るという、少し遊び要素も入れています。

──社内・社員のITに対するイメージは変わりましたか？

吉田さん:
根本は変わっているわけではないですが、慣れていっていると感じます。
ITを勉強しているわけでは無いので、プログラミングできる人が増えましたとか、どんどんITツールを提案してくる人が増えたということではありませんが、ITツールを使いましょうということにたいしては受けいれてくれます。
コミュニケーションインフラとしてチャットワークもみんな利用してくれています。

現在、これまで紙で管理していたものがどんどん電子化していってます。
FAXをpdfで保存し、サーバーからGoogleドライブに自動保存し、自動でチャットワークに配信するようにしました。
FAXもできるだけ出力しないようにしています。
ただ、お客様側がFAXなので、現状は完全に無くすのは難しいです。

──業界ではITやIoTの活用は進んでいない？

吉田さん:
同業者はまだIT化が進んでいないと思います。
IT導入は、スモールスタートで費用をかけずに進めていって、ここから先は自分たちでは無理だと感じたときに本業のソフトウェア会社に依頼できるような流れが良いと思います。
自分たちで少しでもITを理解、挑戦していくことが必要だと思っています。
弊社としても同業者にITを普及させていきたいと考えています。

今後も積極的にITを活用していく。AI分野にも興味がある。

──新しいIT活用に興味・関心はありますか？

吉田さん:
興味がありすぎて・・・

Withコロナは今後も続いていくと思っています。
人が集まれる機会や時間が少なくなって、本来はもっと集まって社員教育やコミュニケーションを取れればと思っています。
現状は、社員教育をスマートフォンで見る動画のサービスを利用しています。
年に3回くらいの集合型もあったりしますが、まだまだ少ないと感じます。
最近ではそれが難しい時代と考えて進めていった方が良いと捉えるようになりました。
さらにITツールを活用し、社員教育を改善できればと思います。

また、現在は運送業とIT業のコンソーシアムに参加しています。
1日に百枚～千枚という数のFAXが届くので、紙から電子化をAIを使って自動化できないか実験を行っています。
FAXから自動で情報を取得というのは、AIが進化したからといって自由記述が多いとやはり難しいとわかってきました。
ですので、現時点ではソーター(仕分け作業)だけでも自動化できないかと考えています。

──今後、連携したい他業種はありますか？

吉田さん:
やはりIT企業ですね。
IT化進み、ITが現実空間を飲み込んでいると感じています。

様々なIT企業が物流業界に参入してきてますが、まだまだ攻略できてないのが現状だと思います。
どこもイニシアチブをとれたと言えるところまでは行っていません。

物流の全部は難しくても、セグメントでわけることで運送でシステム化をめざしていくといいのではと思っています。
メタル便はそれの一つになりうるかもしれません。

──以上になります。ありがとうございました。

吉田さん:
ありがとうございました。

野々市運輸機工株式会社様　連絡先

〒920-0211 石川県金沢市湊1丁目55番地23
野々市運輸機工株式会社
代表取締役　吉田　章
https://nonoichiunyu.com/

日本標準産業分類

大分類：運輸業
中分類：道路貨物運送業
小分類：一般貨物自動車運送業

おわりに

普段聞けない大変貴重なお話をお聞きすることができました。
業界の動向や、ITの取り組み方、ITに対する捉え方など、勉強になることが大変多くありました。
60代の社員がいらっしゃる中で、社内のスマートフォン導入がスムーズに進んだことは驚きでした。

吉田さん、お忙しいところインタビューを快くお引き受け下さり、本当にありがとうございました！

本内容が少しでも皆様のご参考になりましたら幸いです。
今後も他業種インタビューを更新していければと思いますので、次回をお楽しみに！

Jetpack Composeに入門してみた

弊社Android・クロスプラットフォーム担当のd-ariakeです。
先日 Jetpack Compose の正式版がリリースされたので、さっそくうちでも試してみることにしました。

作ったもの

以前の記事 でご紹介したQiitaの簡易クライアントアプリと同じものを今度はJetpack Composeで実装してみました。
リポジトリはこちらです。
→ https://github.com/BetaComputing/SimpleQiitaClientAndroid/tree/compose

良いと思った点

Jetpack Composeを使ってみて、4点ほど良いと思った点があったのでご紹介いたします。

角丸などの細かなUIデザインが簡単

このアプリでは ユーザアイコン画像 と 記事タグ に角丸を設定しています。
従来のViewでは、角丸を設定するのにbackground用のdrawableを作らないといけませんでした。
(参考: AndroidでViewを角丸にする - Qiita)

しかし、Jetpack ComposeではModifierで

RoundedCornerShape(corner = CornerSize(4.dp))

をセットすることで、簡単に角丸を実現することができます。
(該当コード: アイコン画像, 記事タグ)

また、ripple effect を付けたい場合も、

indication = rememberRipple()

をセットすることで、簡単に実現することができます。
(該当コード: 記事項目, 記事タグ)

このように、細かなUIの作り込みはJetpack Composeの方がラクに実現できるかと思います。

リストUIが簡単

従来のViewでは RecyclerView を使ってリスト系のUIを実装していたと思います。
RecyclerViewではAdapter/ViewHolderの実装や、リストの変更通知の仕組みが大掛かりになりがちで大変だったと思います。

Jetpack Composeでは、描画の仕組みが従来から大きく変更されているので、RecyclerViewのようなViewを使いまわしたり、細かな変更通知を行う仕組みが不要になりました。

LazyColumn を使って、

LazyColumn(
    modifier = modifier.scrollable(state = rememberScrollState(), orientation = Orientation.Vertical),
) {
    items(items = articles ?: emptyList(), key = { article -> article.id }) { article ->
        ArticleView(
            article,
            onArticleClicked = viewModel::onArticleClicked,
            onTagClicked = viewModel::onTagClicked,
        )
    }
}

このようにスッキリ書けるようになりました。
(該当コード)

ただし、まだスクロールバーまわりの機能が弱いみたいなので、今後の進化に期待です。🚀

MVVMパターンの考え方がJetpack Composeでも通用

このアプリでは、UI以外の部分 (ViewModelから上位のレイヤ) に対してほとんど手を加えずにJetpack Compose化することができました。
既存のコードがMVVMパターンで設計されている場合、ViewModelから決まってくる状態の、UIへの紐付けの記述の仕方が少し変わるくらいで、従来とほとんど変わらない設計になると思います。
既存の知識があれば、ほとんど学習コストを掛けずにに対応できると思われます。

参考: 状態と Jetpack Compose | Android Developers

既存のアプリにも部分的に組み込み可能

Jetpack Composeには ComposeView という従来のViewにJetpack ComposeによるUIを組み込むための仕組みが用意されています。

このアプリでも ↓ のコミットで、RecyclerViewのみを部分的にJetpack Compose化し、検索用UIの部分などは従来のViewのままで実現するといったことをしてみました。

記事リスト部分をJetpack Composeを使って実装 · @9e4c88d

xml中での RecyclerView 使用箇所を ComposeView に置き換えて、

<!-- リスト部分 -->
<androidx.compose.ui.platform.ComposeView
    android:id="@+id/articleList"
    android:layout_width="0dp"
    android:layout_height="0dp"
    android:visibility="@{viewModel.isProgressBarVisible ? View.GONE: View.VISIBLE}"
    app:layout_constraintBottom_toBottomOf="parent"
    app:layout_constraintLeft_toLeftOf="parent"
    app:layout_constraintRight_toRightOf="parent"
    app:layout_constraintTop_toTopOf="parent" />

ComposeView#setContent{} でJetpack Composeで作ったUIをセットしてあげるだけでした。

//  一時的に記事リスト部分のみJetpack Composeで実装する。
this.binding.articleList.setContent {
    ArticleList(viewModel = this.viewModel, onArticleClicked = this, onTagClicked = this)
}

(該当コード: main_activity.xml, MainActivity.kt)

このようなことができるので、新規で開発する部分やJetpack Composeの恩恵を受けながらリファクタリングしたい部分だけでも、かんたんに導入することができます。

参考: 相互運用 API | Jetpack Compose | Android Developers

おわりに

私たちBeta Computing株式会社は、石川県にあるスマホアプリ開発会社です。
Kotlin・Swiftによるスマホアプリ開発も、FlutterやXamarin.Forms、Unityによるクロスプラットフォームのスマホアプリ開発も、どちらも得意としているスマホアプリ開発のプロフェッショナルです。

Jetpack Composeに限らず、FlutterやSwiftUIに関しても幅広い知識を持っていますし、従来の開発手法に関しても確かな経験と実績があると自負しています。
スマホアプリ開発をご検討されているのでしたら、是非私たちBeta Computing株式会社におまかせください！ 業種・ジャンル問わず対応可能ですので、ぜひご相談下さい。

Flutterでパズルを作ってみた話

弊社Android・クロスプラットフォーム担当のd-ariakeです。

弊社でもクロスプラットフォーム開発においてFlutterを採用しています。
今回はFlutter for Webでシンプルなパズルを作ってみたので、紹介させていただこうと思います。

作ったもの

このようなパズルを作ってみました。

GitHub Pagesに置いてあります。
ぜひ遊んでみてください。
→ https://betacomputing.github.io/flutter_puzzle/

ソースコードはこちらに置いてあります。
→ https://github.com/BetaComputing/flutter_puzzle

Flutter for Webについて

3/4に Flutter 2.0 がリリースされましたが、その際にFlutterのWebサポートがstable化しました。
私もなにかFlutterでWebアプリを作ってみたいと思ったので、さっそくこのパズルを作ってみました。

特に手動で有効化設定を行わずともWebサポートが有効化されているので、

flutter create --org jp.co.betacomputing --platforms web ./flutter_puzzle

といったコマンドでWeb用のFlutterプロジェクトが作成することができます。

Webアプリ用ビルドは

flutter build web --web-renderer html

というコマンドで行うことができます。

上記ビルドコマンドにもオプションとして指定していますが、Flutter for Webには html と canvaskit の2通りのレンダリング方式があります。
それぞれダウンロードサイズの削減・他プラットフォームとの互換性とパフォーマンス性というメリットがあるようです。

ですが、現状はCanvasKitによるレンダリングにおいて正しく文字列が描画されないというバグがあるようなので、 --web-renderer html を指定したほうが良さそうです。

参考:

• Web renderers - Flutter
• Flutter webでHTMLかCanvasでの書き出し

スライドアニメーションについて

このパズルを遊んでもらうとわかると思いますが、ピースを選択するとスライドアニメーションが再生されるようになっています。
これは AnimatedPadding を利用して実現させています。

パズルのピースを配置するコード は以下のとおりです。
各ピースの左と上のパディングを設定することによって任意の位置に配置するという実装アプローチを取っています。

//  パズルの複数のピースを生成する。
Widget _buildPieces(double pieceWidth, double pieceHeight) {
  return Stack(
    children: puzzle.pieces.map(
      (piece) {
        final offsetX = pieceWidth * piece.currentPos.hIndex;
        final offsetY = pieceHeight * piece.currentPos.vIndex;

        return AnimatedPadding(
          padding: EdgeInsets.only(left: offsetX, top: offsetY),
          duration: animDuration,
          child: SizedBox(
            width: pieceWidth,
            height: pieceHeight,
            child: _buildPiece(piece),
          ),
        );
      },
    ).toList(),
  );
}

あるピースがクリックされ、1つ右のマスに移動する状況を考えます。
右に移動するため、水平方向のインデックス piece.currentPos.hIndex の値が + 1 されます。
すると、 EdgeInsets.only() の left には、更新前の値 offsetX よりも pieceWidth 分だけ大きな値が指定されます。
ここで AnimatedPadding を利用しているので、更新前と更新後の左パディングの値を線形補間しながら、なめらかに表示されるように描画してくれます。

更新後の値を渡すだけで、アニメーションの途中経過の面倒な座標計算を一切せずとも、Flutterが自動的にいい感じにしてくれました。 🙌

参考:

GitHub Pagesについて

最後にビルドとデプロイに関して軽く説明します。

見ての通り、このパズルはGitHub Pagesに配置しています。
タグをプッシュすると自動的にビルドが走り、ビルド内容が gh-pages ブランチにコミットされるように設定しました。

Release.yml:

  - name: Build (Web)
    run: flutter build web --web-renderer html

  - name: Deploy
    uses: peaceiris/actions-gh-pages@v3
    with:
      github_token: ${{ secrets.GITHUB_TOKEN }}
      publish_dir: ./build/web

gh-pages ブランチへの配置には peaceiris/actions-gh-pages@v3 というactionを利用しています。 GitHubのトークンとビルド先のディレクトリと指定するだけで、自動的にいい感じにしてくれます。 🙌

FlutterとGitHub Pagesを使えば、こんなに簡単にWebアプリが作れちゃいました。
今後も簡単なWebアプリであればFlutterで作ってみようと思います。 😤

おわりに

Beta Computing株式会社は石川県のスマートフォンアプリ開発に特化したソフトウェア会社です。 Kotlin・Swiftによるスマホアプリ開発も、FlutterやXamarin.Forms、Unityによるクロスプラットフォームのスマホアプリ開発も、得意としているスマホアプリ開発のプロフェッショナルです。

スマホアプリ開発をご検討されているのでしたら、是非私たちBeta Computing株式会社におまかせください！ 業種・ジャンル問わず対応可能ですので、ぜひご相談下さい。

Xamarinの共有プロジェクトでも単体テストが書きたい!

弊社Android担当のd-ariakeです。

現在、Xamarinの改修案件をさせてもらっています。
そのプロジェクトで単体テストを書こうと思ったのですが、少しハマってしまいましたので、それを共有したいと思います。

このプロジェクトはXamarinネイティブの 共有プロジェクト でした。
共有プロジェクトは単なるソースコードの置き場で、AndroidとiOSのそれぞれのプロジェクトでそのソースファイルを参照するといった仕組みです。

この案件には既存のコードがあり、そのソースではがっつりそのままXamarin固有のコードが多用されていました。
ですので、そのまま .NET Core の xUnit プロジェクトで共有プロジェクトの参照を追加してしまうと、Xamarin固有のコードを含むソースファイルでエラーになってしまいます。

↓ こんな感じに、Xamarin.AndroidプロジェクトとXamarin.iOSプロジェクトから見たときはビルドが通りますが、単体テストプロジェクトから見たときにエラーになります。

単体テストでテストしたい部分というのはXamarinに依存しない計算ロジックや判定ロジックだったりします。
そのため、 共有プロジェクトをまるごと参照に追加するのではなく、ソースファイル単位での追加をすること で解決することができました。

↓ これです。

既存のファイルの追加で、Xamarinに依存していないソースコードのみを単体テストプロジェクトに追加します。
もし、テストをしたい箇所でXamarin固有の機能 (Preferencesなど) を使用している場合、適切にリファクタリングをしてあげましょう。

固有の機能を必要とする箇所を IHogeHogeProvider や IHugaHugaRepository などといったインタフェースで切り、テストをしたいビジネスロジックがインタフェースのみに依存するように変更します。

先ほどの画像でも Xamarin.Essentials.Preferences を使っている箇所がありましたが、 IHogePrefereces というインタフェースと HogePreferences (Impl) という具象型をつくり、単体テストプロジェクトには IHogePrefereces のみを追加しました。
これでちゃんと単体テストプロジェクトでもビルドが通るはずです。

そして、もう一箇所ハマったので、そちらも共有します。
私はテストに Moq というモックライブラリを使っているのですが、何も設定せずに使うと以下のようなエラーが発生しました。

System.ArgumentException : Cannot set up 〇〇 because it is not accessible to the proxy generator used by Moq: Can not create proxy for method 〇〇 because it or its declaring type is not accessible. Make it public, or internal and mark your assembly with [assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")] attribute, because assembly 〇〇 is not strong-named.

怒られている内容に従い、 AssemblyInfo.cs に以下のような属性を追加します。

using System.Runtime.CompilerServices;

[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2")]

しかし、最初は Hoge.Shared と Hoge.Shared.Tests というプロジェクトがあったとき、Hoge.Shared の方に書いてしまい、エラーが消えてくれませんでした。
共有プロジェクトは単なるソースコード置き場で、それを取り込む側の単体テストプロジェクトでアセンブリが吐かれるので Hoge.Shared.Tests の方に書かないといけません。 (ここで少しハマってしまいました。)
単体テストプロジェクトの方に書き直すと、正常にMoqによるモックが動作してくれました。 🎉

共有プロジェクトの保守をする際には是非参考にしてみてください!

先日のFlutterでのサンプルアプリをAndroidネイティブアプリでも作ってみた件

Android担当のd-ariakeです。
先日 弊社もFlutter採用致します! - Beta Computingブログ という記事の中で このような サンプルアプリを作り、紹介したかと思います。

今回はこのサンプルアプリと同じようなアプリをAndroidネイティブでも作ってみたので、設計の比較やポイントをご紹介したいと思います。

作ったアプリ

仕様は先日のものとほとんど変わっていません。

https://github.com/BetaComputing/SimpleQiitaClientAndroid

この同じような仕様のアプリをネイティブで作った際のポイントを軽く解説していきます。

ポイント

以下が今回説明するポイントとなります。

• UIの設計
• ネット上の画像のロード
• FlexboxLayoutの導入

UIの設計

Flutter版では BLoC パターンで設計していましたが、Androidネイティブ版では MVVM パターンで設計を行いました。

UIはxmlで記述し、ViewModelにUIを制御するための変更通知機構を持ったプロパティ (LiveData) をもたせ、データバインディングによってViewModelのプロパティの状態をUIに反映させています。

internal class MainViewModel(/* 省略 */) : ViewModel() {

    //  取得中かどうか
    private val isFetching: MutableLiveData<Boolean> = MutableLiveData(false)

    //  記事リスト
    private val _articleList = MutableLiveData<List<Article>>()
    val articleList: LiveData<List<Article>> = this._articleList

    //  検索キーワード
    val keyword: MutableLiveData<String> = MutableLiveData("")

    //  検索ボタンが有効かどうか
    val isSearchButtonEnabled: LiveData<Boolean> = MediatorLiveData<Boolean>().also {
        val onChanged = { it.value = this.isFetching.value == false && !this.keyword.value.isNullOrEmpty() }
        it.addSource(this.isFetching) { onChanged() }
        it.addSource(this.keyword) { onChanged() }
    }

    //  プログレスバーを表示するかどうか
    val isProgressBarVisible: LiveData<Boolean> = this.isFetching

    //  検索ボタンがクリックされたとき。
    fun onSearchButtonClicked() { /* 省略 */ }

    //  検索を行う。
    private suspend fun search(keyword: String) { /* 省略 */ }
}

<layout <!-- 省略 --> >

    <data> <!-- 省略 --> </data>

    <LinearLayout <!-- 省略 --> >

        <com.google.android.material.appbar.AppBarLayout />

        <LinearLayout <!-- 省略 --> >

            <androidx.constraintlayout.widget.ConstraintLayout <!-- 省略 -->>

                <com.google.android.material.textfield.TextInputEditText
                    android:id="@+id/keywordEditText"
                    <!-- 省略 -->
                    android:text="@={viewModel.keyword}" />

                <com.google.android.material.button.MaterialButton
                    android:id="@+id/searchButton"
                    <!-- 省略 -->
                    android:enabled="@{viewModel.isSearchButtonEnabled}"
                    android:onClick="@{() -> viewModel.onSearchButtonClicked()}" />

            </androidx.constraintlayout.widget.ConstraintLayout>

            <ProgressBar
                style="@style/Widget.AppCompat.ProgressBar.Horizontal"
                <!-- 省略 -->
                android:visibility="@{viewModel.isProgressBarVisible ? View.VISIBLE : View.INVISIBLE}" />

            <androidx.recyclerview.widget.RecyclerView <!-- 省略 --> />

        </LinearLayout>

    </LinearLayout>

</layout>

例えば、検索ボタンの活性の制御の場合です。
以下のコードで、取得処理中かどうかを表すLiveDataと検索キーワードを表すLiveDataから、検索ボタンの活性に変換しています。

val isSearchButtonEnabled: LiveData<Boolean> = MediatorLiveData<Boolean>().also {
    val onChanged = { it.value = this.isFetching.value == false && !this.keyword.value.isNullOrEmpty() }
    it.addSource(this.isFetching) { onChanged() }
    it.addSource(this.keyword) { onChanged() }
}

そして、xmlのデータバインディング構文を使ってボタンの android:enabled プロパティに反映させています。

<com.google.android.material.button.MaterialButton
    android:id="@+id/searchButton"
    android:enabled="@{viewModel.isSearchButtonEnabled}" />

Flutter版では RxDart の combineLatest2() で変換した Stream/Sink と StreamBuilder で実装していましたが、本質的には同じことをやっています。
このように主流の設計パターンが両者とも似ているので、Androidアプリ開発者がFlutterを学習するのはとても敷居が低いと感じました。

ネット上の画像のロード

Flutterではネット上の画像を表示させたいときは、単に

Image.network('URL')

というように書けばOKでした。
Androidネイティブには標準でそのような機能が用意されていので、Glide を使用しました。

Glide.with(context).load("画像のURL").into(imageView)

Glideを使うとこのように書くだけで、通信を行い、画像を反映させ、自動でキャッシュまで行ってくれます。
今回はデータバインディングを使った設計をしていたので、

@BindingAdapter("imageUrl")
fun ImageView.setImageUrl(url: String?) {
    Glide.with(this.context).load(url).into(this)
}

このような BindingAdapter を書いて、

<androidx.appcompat.widget.AppCompatImageView
    app:imageUrl="@{article.authorIconUrl}" />

xml上で画像の指定をできるようにしてみました。

このような処理はよく書くので、Flutterが公式で用意してくれているのはとてもありがたいですね。

FlexboxLayoutの導入

記事のタグを表示している部分は、動的に要素数を変えたり、横幅からはみ出た際に折り返しをしなくてはなりません。

Flutterだと Wrap を使うことで自動的に折り返しを設定してくれます。
Androidネイティブだとそのような機能が標準ではありません。

そこで FlexboxLayout というライブラリを使うことにしました。
使い方はとってもかんたんで <FlexboxLayout /> の下に <RecyclerView /> を入れてやり、FlexboxLayoutManager をセットしてやるだけです。

RecyclerView recyclerView = (RecyclerView) context.findViewById(R.id.recyclerview);
FlexboxLayoutManager layoutManager = new FlexboxLayoutManager(context);
layoutManager.setFlexDirection(FlexDirection.COLUMN);
layoutManager.setJustifyContent(JustifyContent.FLEX_END);
recyclerView.setLayoutManager(layoutManager);

引用元: https://github.com/google/flexbox-layout#flexboxlayoutmanager-within-recyclerview

しかし、Androidネイティブのリスト (RecyclerView) を扱おうと思うと、Adapterに関する部分のコードを書く必要があり、多少めんどくさいです。
そこで、コードの見通しを良くするために、カスタムViewを作ることにしました。

internal class TagList(/* 省略 */) : FlexboxLayout(/* 省略 */), TagClickedListener {
    internal var listener: TagClickedListener? = null
    private val adapter = Adapter(this)

    init {
        LayoutInflater.from(this.context).inflate(R.layout.tag_list, this, true)

        val layoutManager = FlexboxLayoutManager(this.context, FlexDirection.ROW)
        this.recyclerView.layoutManager = layoutManager
        this.recyclerView.adapter = this.adapter
    }

    internal fun setTags(tags: List<String>) { /* 省略 */ }
    override fun onTagClicked(tag: String) { /* 省略 */ }

    private inner class Adapter(private val parent: TagList = this) : RecyclerView.Adapter<BindingHolder>() {
        private val inflater: LayoutInflater by lazy { LayoutInflater.from(context) }
        var tags: List<String> = emptyList()

        override fun getItemCount(): Int = this.tags.size
        override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): BindingHolder =
            BindingHolder(TagBinding.inflate(this.inflater, parent, false))
        override fun onBindViewHolder(holder: BindingHolder, position: Int) {
            holder.binding.tag = this.tags[position]
            holder.binding.listener = this.parent
            holder.binding.executePendingBindings()
        }
    }

    private class BindingHolder(val binding: TagBinding) : RecyclerView.ViewHolder(binding.root)
}

@BindingAdapter("tags")
internal fun TagList.setTags(tags: List<String>?) {
    if (tags != null) this.setTags(tags)
}

@BindingAdapter("onTagClicked")
internal fun TagList.setListener(listener: TagClickedListener?) {
    this.listener = listener
}

TagList というカスタムViewとそのBindingAdapterを生やし、

<TagList
    <!-- 省略 -->
    app:onTagClicked="@{tagClickedListener}"
    app:tags="@{article.tags}" />

このようにxml中で使えるようにしてみました。

Flutterだと数行で実現できたことですが、Androidネイティブでやろうとすると、ものすごく大変でした。

感想

UIに関して、シンプルなUIを組むことに限って言えば、Flutterだとものすごく簡単に感じました。
Androidネイティブの場合、ActivityとFragmentの概念や、ライフサイクルの理解と画面の再生成の対応など、知っておかなくてはならないことがたくさんあります。
Flutterだとそれらを意識せずに作れてしまうので、アプリ開発初学者に対する敷居もかなり低くなっていると思います。

当然、Android固有の機能であったり、一部のUIに関してはAndroidネイティブが必要ですし、ネイティブがすぐに不要になるとは思いませんが、今後はFlutterの選択肢も増えていくと思います。