投稿者: 技術広報チーム

はじめに

こんにちは。株式会社プロトソリューション・ソリューション開発部沖縄の當山(とうやま)です。

これまで私は新規案件の開発業務を行うことが多く、日々目の前の開発に集中して業務を行っていましたが、最近「Web3.0」という新しいインターネットの概念が話題に上がっている事から興味を持ち、日々勉強中です。

そのため、今回は開発の話というよりも、Web3.0とビジネス展開の話をしたいなと思っています。

Web3.0とは？

まずWeb3.0の大きな特徴としては、これまで特定のプラットフォームや企業に情報が集まっている中央集権型とは異なり、プライバシー情報は個人で管理し、特定の管理者は存在せず、ノード同士が繋がる(P2P)、分散の時代のシステムが作られようとしています。

例えばアプリを開発する時、大きくシェアを占めているAppleとGoogleのストアからリリースをする場合、AppleとGoogleの自社決済システムを使うことが義務付けられています。また、ストアの方針でアプリが公開停止にされても開発者は従うしか選択肢がない状況です。

しかしWeb3.0では巨大企業抜きでも、インターネット上での活動が行える仕組みとなっています。Web3.0のベースになっている技術の一つが「ブロックチェーン」になります。

スマートコントラクトの魅力

ブロックチェーンの詳細は割愛しますが、特に魅力に感じたのは「スマートコントラクト(自動的に実行される契約)」です。

事前に決められたルールに従い、ブロックチェーン上で自動的に動作が執行されるプログラムがスマートコントラクトです。改ざんがされにくく透明性も高いため、現在不動産業界等においても、売買取引が迅速化・簡素化されることが期待されており、実現にあたって幾つかの企業が、実際に実証実験を開始しています。

ビジネス展開アイデア

例えば弊社の場合、中古車販売サービスがありますが、不動産売買と同じように 売買時に発生する契約書類手続きや決済などの業務が自動化されれば、時間や人手のコスト削減が大いに期待できます。

また、中古車を購入する際に気になる年式、走行距離、修復歴などの情報が一緒に記録され、かつ、改ざんもされにくいため、買い手側にもメリットがうまれます。

さらに中古車販売 ✕ 別サービスをかけあわせたCross Creativity  (クロスクリエイティビティ）を活用することで、新たなサービス展開も視野に入れることが出来る可能性もあります。

例として、沖縄ではコロナの影響でレンタカー台数が30%も減ったためレンタカー不足となりました。

その影響もあって最近では個人間でのカーシェアリングサービスの利用が増えています。

例えばペンションや民泊で宿を借りる＋中古車レンタルサービスのセット等は既にありますが、さらに車と宿の鍵がスマートキー対応し、その契約手続きや支払いは店舗に訪れることなく、自宅のPCやスマートフォン１つで、事前に自動契約して簡単決済のようなことも実現できそうです。

そのような事が出来るようになったら、より競合会社とのサービス差別化が出来そうだと考えます。

スマートコントラクトのデメリット

そんな魅力的なスマートコントラクトですが、実はデメリットもあるので要注意です。

・処理実行後に、契約の解除やキャンセルができない。

・取引規模が大きくなると処理速度が低下したり、手数料が高くなる場合がある。

おわりに

なお、今回はあくまで仮定の話で、実現にするあたっては税制など含めてまだまだ課題も多く、

日本でも実証実験を数社が始めている程度の新しい取り組みですが、今後を見据えて今から勉強していかないといけない分野だなと強く感じます。

本記事ではWeb3.0の魅力の内の一部分しかお伝え出来ませんでしたが、サービス展開は無限大で、今のうちに参入しようと取り組んでいる所が、今後ビジネスチャンスを掴んでいくんだろうな、と思います。

同様に考えている方がいれば、ぜひ繋がって色々と会話したいですね。

最後まで読んでいただきありがとうございました。

おまけ (Web3.0に関するキーワード)

・分散の時代(特定の管理者が存在しない)

・特定のプラットフォームや企業に情報が集まらない

・プライバシー情報は個人で管理

・非中央集権型

・トラストレス(信頼するな検証せよ)

・特定のサーバを介さずに繋がり、ユーザーは同一の取引データを参照

・Web3.0で注目されているサービスや仕組みは、NFT、DeFi、DAO等がある

・NFT：コピー可能なデジタルコンテンツの取引履歴を分散管理する技術

・DeFi：中央管理者がいない形で取引をする、分散型金融

・DAO：自律分散型組織と訳され、共同のビジョンを持つメンバーがプロジェクト成功のために力を合わせる

・上記含むWeb3.0を支えている技術の一つがブロックチェーン

はじめに

初めまして。プロトソリューションの川満と申します。

2012年に入社し、スマートフォンアプリの開発・運用保守に携わっております。

現在は主にFlutterを使用し、スマートフォンアプリの開発をしております。

この記事ではそんなFlutterのCI/CDツールである、Codemagicの導入からCI実行について解説したいと思います。

導入開始

まずはアカウント作りから、CodemagicではGitHubやGitLabと連携できる前提のため、対象のアカウントがあればそのままCodemagicのアカウントを作成できます。

今回はGitHubアカウントで作成します。

アカウントを作り終わったら、導入するアプリを設定します。[Add application]より追加できます。

追加するアプリのリポジトリ設定を行い、Project Typeを設定します。（今回はFlutter App）

ビルド設定準備

ビルドするプラットフォームを指定（今回はRun tests only）します。

自動でビルドが始まるタイミングもブランチ指定やタグ指定で設定できますが、今回はパスします。

テスト設定

ビルド前に実施するテスト内容および静的解析の有無を設定します。

静的解析ツールを新規で導入せずとも良いです。

ビルド設定

ビルドするFlutterおよびXcode、CocoaPodsのバージョンを指定

通知先設定、そしてビルド開始

デフォルトでメールアドレスが設定されてますが、Slackにも通知が送れますので通知を設定し、[Start New Build]よりビルド実行

ビルドが成功するとこのようにSlackに通知がきます。

成果物のリンクも送られてきます。

逆に失敗した場合は、このような通知がきます。

まとめ

今回はテスト実施・静的解析をゴールとしたのでここまでですが、証明書周りもしっかり設定すれば実際のストアへの配信も簡単に行えます。

無料枠では毎月500ビルドまでという制限を超えてしまうことも考えられますので、本活用する場合は有料プランをお勧めしたいところです。

• 参考資料
  • https://docs.codemagic.io/getting-started/signup/

はじめに

はじめまして、プロトソリューション沖縄本社でマーケティングを担当している星川です。

私が働いているプロトソリューションは宜野湾市にあるコンベンションセンターの近くにありまして、社員が自由に利用できるリフレッシュルームからは海が一望できる素晴らしいロケーションとなっております。まだビルも新しくキレイで明るく働きやすい職場環境となっています。

コロナでリモートワークとなってからはその恩恵を受けられていませんが・・・

今回は私が入社してからマーケティングに出会うまでと、社内でのマーケティング組織拡大を目指した活動などをご紹介できればと思っています。どうぞよろしくお願いいたします。

感動カンパニーへ入社

2010年の12月にプログラマーとして採用になりまして、面接の時に担当だった方から年末に忘年会をラグナガーデンホテルでやるけど来る？と聞かれて驚いたことをよく覚えています。

コロナ禍であることから、今では忘年会自体が開催しにくい状況となっていますが、当時は200名規模が集まる大忘年会が毎年開催されていました。各部署から集められた実行委員が仕事と変わらないくらい本気で準備して盛り上げているのを見て「この会社やばい（いい意味で）」と思ったりしました。最後は参加者みんな感動していてこの頃からずっと「感動カンパニー」だったんだなと改めて思いました。

PGからSEへ

入社後はプログラマーとして親会社のシステム開発を行っていましたが、1年くらいでチームを任されるようになり徐々に役割がプログラマーからSEとなっていきました。

3年ほどSEとして沖縄と東京を行ったり来たりしていたところ、上司の方から自社メディアであるグーホームのWebサイトを担当してみないかというお話をいただきました。事業部が社内にあり進め方もある程度裁量をもらえるとのことでしたのでありがたくお受けしました。

グーホームは沖縄県内の方ならご存知いただけていると思いますが、不動産ポータルサイトとして物件を紹介したい沖縄県内の不動産会社と住む場所を探しているユーザーをマッチングさせるサイトです。

担当となってからはサイトのデザインリニューアルや機能の追加、SEO施策などサイトへの流入数を増やすための施策を多く実行してきました。

ただそれらの施策を実行するためには事業部の承認が必要になりますので、エビデンス集めとして営業の方に同行させてもらって不動産会社の方に要望をお伺いに行ったり、競合サイトや不動産関連のニュースを見て市場にどういうニーズがあるのかを調べたり、オンライン調査会社に依頼して県内でのシェアやサービスの満足度調査など行ったりしていました。

（当時は事業部の方から承認をもらうことを目的に行っていたことで、マーケティングとして意識的に動いていた感じではありませんでした。）

マーケティングとの出会い

転機となったのは、Web集客をもっと増やせないかと考えているときに「ウェブ解析士」の資格を見つけ受験してみようと思った時でした。

最初はGoogleアナリティクスを使った分析などの資格かなと思っていたのですが、マーケティングに必要な基礎を体系的に学べる資格となっていて、今でも公式参考書を見返したりしているくらい役立っています。

たまたま会社が資格取得を奨励し始めたタイミングで、「お金がもらえるなら～」と下心からの受験でしたが結果マーケティングを理解できる機会になって、本当に受験してよかったなと思っています。（更に資格取得してお金までもらえるので資格制度には感謝しかありません！）

上級ウェブ解析士を取ったのが2018年で、そこから社内でもマーケターとしていろいろ動き始めました。

マーケティング担当になってから

私と一緒に資格を取得した同僚がいたので、まずはチームを作りどういうビジョンでどういう目標で動くのかを言語化するところから始めました。

チームビジョンは「Information[マーケットの理解]、Initiation[戦略の立案・推進]、Inspection[プロセスの最適化]により、事業を成功に導く」としました。

目標は、マーケティングに必要なスキルを洗い出して習得し、担当している業務内容を最適化させていくところから行っていきました。また今後のチーム拡大に備え、社内での認知活動も行っていきました。

認知活動の内容についてはこちらの記事に記載しておりますのでよろしければ読んでみてください。

ビジョンと目標をもとに1年ほど活動して「よしこれからもっと活動してチームを拡大させていくぞ！」と意気込み、いろいろと計画を立てていました。

・定期的な社内マーケティング研修
・新卒向けの社員研修にマーケティング研修を追加
・県内コミュニティ構築を狙ったイベントの開催

ただ残念ながら新型コロナウイルスによって在宅勤務となり計画は頓挫することになりました・・・

パンデミック下でもできることはたくさん

もともとサーチコンソールやGoogleアナリティクスからサイト分析をして施策を考えて提案、実施後の効果検証がメイン業務でしたので、在宅勤務でもパフォーマンスを下げることなく業務は行えました。

ただやはりチーム拡大のための活動は難しかったです。逆に嬉しかったこともありまして、地方住みの方にはご賛同いただけると思いますがセミナーに参加しやすくなったことです。

Web担当者Forumミーティングに参加するために東京でしかできない仕事を捻り出し、出張費の承認を勝ち取る必要がなくなったのは本当にありがたかったです。（東京の仕事もちゃんとしました）

また、この頃から受付システム「ラクネコ」のマーケティングに携われるようになり、BtoC向けSaaSのマーケティングの楽しさと、一人でやれる範囲の狭さと己の無力さを実感するようになりました。

チームメンバーを募集しています！

今の業務はリードジェネレーションとしての活動がメインとなっていますが、事業を成長させるためにはリードナーチャリングやCSについてももっと関わっていきたいと考えています。

そのためにはルーティーンとなっている業務の整理・分業を進め活動を組織化していく必要があります。

マーケティングには正解はありませんので、私と一緒に新しいことを試し、検証し、ともに事業を成長させていく仲間を募集しています。

より詳しい業務内容などをお話ししているオンライン説明会なども実施しておりますので、ご興味があればぜひ参加していただければと思います。

最後までお読みいただきありがとうございました！

1.自己紹介

はじめまして。プロトソリューションの木村と申します。

私は、2016年に入社して、初めはAndroidアプリ開発から業務に携わらせて頂き、PHP＋Oracle＋オンプレミスサーバーを用いたWEBシステムの運用保守業務、今年からPython＋AWSを使用するWEBシステムの運用保守業務を行っております。

Python、AWSを業務として扱うのは今回が初めてで、色々と苦労しながらも何とか進める事が出来ております。

今回の記事は、AWS LambdaのPythonランタイム3.6が廃止されるため、急ぎ対応を行った件について備忘録として記載しようと思います。

2.はじめに

・AWS LambdaのPythonランタイムについて

名前	識別子	オペレーティングシステム	非推奨化フェーズ 1	非推奨化フェーズ 2
Python 3.6	Python 3.6	Amazon Linux	2022 年 7 月 18 日	2022 年 8 月 17 日

※ 公式サイトから抜粋

・非推奨化フェーズ1について

対象のランタイムで新規作成が出来なくなります。

既に構築済みの関数に関しては、引き続き関数実行・関数更新が可能となります。

・非推奨化フェーズ2について

対象のランタイムで新規作成、関数更新が出来なくなります。

既に構築済みの関数は実行する事は出来ますが、更新する事が出来なくなります。

運用保守しているAPIがPython3.6ランタイムを使用しておりました。

非推奨化フェーズ2の関数更新が出来なくなるのは問題になるため、AWS Lambdaで利用出来る最新バージョンのPython3.9ランタイムまでバージョンアップを行いました。

今回の記事では、私が実施したアップデート手順と詰まった内容について記載します。

3.要約

• CodeBuildにPython3.9用のイメージが無かった。OSをAmazonLinux2、ランライム設定をPython3.9に設定する必要がある。
• Python3.8以降のAWS Lambdaの実行環境では一部の共有ライブラリが不足していた

4.実際に行ったライブラリアップデートの検証手順

1.EC2サーバー上でライブラリアップデートを検証

2.手動でAWS Lambda API-GateWayを構築してAPI検証

3.開発用のCodePipelineにソースプッシュして実開発環境で検証

4.本番環境のCodePipelineにソースプッシュして本番環境にリリース

開発といえど利用しているのが私以外にもおりましたので、なるべく既存環境に影響を与えないために上記の手順で検証を行いました。

5.AWS LambdaのPython3.9ランタイムについて

・AWS Lambdaの実行環境について

名前	識別子	AWS SDK for Python	オペレーティングシステム	アーキテクチャ
Python 3.6	Python 3.6	boto3-1.20.32 botocore-1.23.32	Amazon Linux	x86_64
Python 3.9	Python 3.9	boto3-1.20.32 botocore-1.23.32	Amazon Linux 2	x86_64、arm64

※ 公式ページから抜粋

ランタイム変更に合わせてAWS Lambdaの実行環境がAmazonLinuxからAmazonLinux2に変更されました。

更新するAPIは外部ライブラリを利用しており、Pythonのバージョンに合わせてアップデートが必要でした。

私はライブラリアップデートの事前検証のために、AmazonLinux2で動作するEC2インスタンスを新規で立ち上げ、このEC2インスタンス上でライブラリアップデートを検証を行い、正常にインストール、ユニットテストが実行される事を確認しました。

※ AmazonLinux2のイメージがDockerHub等で公開されております。こちらを利用した方が料金がかからないため、費用を抑えたい方はこちらを利用した方が良いと思われます。

6.AWS LambdaのPythonランタイム変更について

弊社のQiitaに記載しておりますので、是非ご確認いただければと思います。

7.ライブラリアップデートについて

・構成図について

開発者がCodeCommitにソースプッシュすることで、CodePipelineが動作してAWS Lambdaにデプロイ出来るような構成になっております。

CodeBuildでPythonの各種ライブラリインストールを行っており、

デプロイパッケージが生成されたらCloudFormationの変更スタックを作成して実行します。

初回ならAWS Lambda構築とデプロイ、次回以降ならデプロイのみを行います。

8.詰まった箇所について

前提が長くなりましたが、ここからが本題となります。

① CodeBuildのイメージについて

以前までは公式が提供していた以下のイメージを使用しておりました。  

Python3.9用のイメージもあると思い、公式ページを調査しても上記イメージも含めて存在しませんでした。

そのため、公式ページを参照して別方法で対応を行いました。

対応内容

1．CodeBuildで使用するイメージにAmazonLinux2を選択する

2．buildspec.yamlのインストールフェーズでPython3.9ランタイムを設定する

上記の対応で想定していた環境を構築する事が出来ました。

② 不足する共有ライブラリについて

CodePipelineが正常終了してAWS Lambdaへのデプロイ完了後、テスト実行したら上記のエラーが発生しました。

libgomp.so.1

上記は共有ライブラリであり、実行環境に無いのは想定外のエラーとなりました。

調査するとAWS LambdaのAmazonLinux2実行環境には、様々な共有ライブラリが不足しているようです。

対応方法は調査すると様々な方法があるようですが、今回はAWS Lambdaレイヤーを使用しました。

今後バージョンアップ予定の他APIで同じライブラリを使用しているため、AWS Lambdaレイヤーで対応すると決めました。

※ AWS Lambdaレイヤーについて

AWS Lambdaレイヤーを利用するメリットは以下となります。

・よく利用するライブラリをまとめる事が出来る

・自作の共通処理をまとめる事が出来る

・一つ作成すれば他の関数にも設定する事が出来る

仮にですが機械学習などをよく利用される方は、Pandas,Numpy等をレイヤーとしてまとめて置く事で、それぞれのAWS Lambda関数に設定するソースに含める必要がなくなり、一つのレイヤーを設定する事で全関数に対応する事が出来るようになります。

公式ページ

対応内容

1．buildspec.yamlに共有ライブラリをまとめたzipファイルを生成してS3に格納する処理を追加

2．CloudFormationでリソース構築時にAWS Lambdaレイヤーも合わせて生成する設置を追加

① レイヤーソースをアップロードしたS3バケットを指定するパラメータ追加

② AWS Lambdaレイヤーを作成するフェーズを追加

③ AWS Lambdaにレイヤー設定を追加

上記を設定すると以下の画像のようにレイヤー設定が完了となります。

この状態で再度テスト実行すると以下のように正常終了となります。

※ 500エラーが返ってきておりますがパラメータを何も設定していないためとなります。

※ API Gateway経由でパラメータを付与して実際に実行すると正常終了します。

9.まとめ

Python3.6ランタイムからPython3.9ランタイムに変更すると、OSなどが変更されたため様々な所に影響が出ました。

既にPython3.6ランタイムの廃止日が過ぎておりますが、ご参考になれましたら幸いです。