Inspiring the OutSystems Community globally

こんにちは、OutSystemsのTaijiです!
今回は、OutSystems Championについて説明しようと思います。

はじめに

日本では、残念ながらまだまだできていないところが多いのですが、OutSystemsのユーザーコミュニティでは、お互いの交流を深め、ナレッジを共有したり、お互いにサポートすることで、地域のエコシステムを成長させてきています。我々OutSystemsでは、コミュニティの仲間である他者の成長を支援することに情熱を持てる、そんなコミュニティに貢献する意欲のあるユーザー(= Champion)を常に探しています。

OutSystems Champions Programとは

Champions Programでは、コミュニティをリードできるユーザーをリーダーとして認定し、ベネフィットをお届けすることです。 OutSystemsは、OutSystems User GroupやOutSystems Education Programなどのエンゲージメントプログラムを通じて、ローカルコミュニティの活性化に積極的に参加し、メンタリングやオンラインコミュニティなどでのコラボレーションなど、コミュニティへの貢献者が表舞台に露出するべきと考えています。

このプログラムは、コミュニティメンバーとOutSystemsチームがコラボレーションして、エコシステムとプラットフォームへの「強い想い」を世界規模で成長させるためのフレームワークを提供します。

公式Websiteはこちらです。

OutSystems Championになるための要件

OutSystems Championになるには、OutSystemsプラットフォームの本当のファンになる必要があります。 判断基準は、みなさんがフォーカスを当てて貢献する分野によって異なります。 活動が多ければ良いわけではありません。量より質が考慮されます。

コミットする必須の指標はないのですが、逆に影響力のある活動をしているコミュニティメンバーは絶対にChampionになってほしいと思っています。


ごあいさつ

みなさんこんにちはTaijiです!
今月からOutSystemsでLead Community Managerとして働くことになりました。所属はGlobalチームで担当はJapan/APACになります。
どうぞよろしくお願いいたします。

さて、日本ではOutSystemsのユーザーコミュニティの担当がこれまで不在だったこともあり、なかなか活動できずにいました。
今回、私が正式にコミュニティ担当となりましたので、みなさまにコミュニティへお誘いしたいと強く思っております!

OutSystemsとは

GartnerとForresterがリーダーとして認めたOutSystemsのローコード開発プラットフォームは、全世界で1400社以上に導入されています。

Webおよびモバイルのアプリケーションをビジュアルで設計し開発することが可能なローコードプラットフォームでは、一行のソースコードも書く必要がなく、開発者全員が同じレベルのスキルセットで開発することが出来ます。サーバー側の言語、Objective-C、Swift、Javaなどの知識は不要です。また、「ローコード」であるため、コーディングによるカスタマイズも簡単に行うことが出来ます。必要に応じて、従来のコーディングを行うこともできるのがローコードの特徴とも言えます。

OutSystemsのローコード開発プラットフォームでは、ビジュアルで開発することによって、従来の開発手法と比較して、5~6倍の生産性の向上が可能です。ぜひGartner Peer Insights、Capterra、TrustRadius、G2 Crowd、GetAppなどのレビューサイトで、満足度で高評価を頂いているユーザーの方々のレビューをご確認ください。


バイクブログ2回目はマフラー交換を解説します。

はじめに

私が乗っているHarley DavidsonのXL1200Lは2007年式です。Sportsterは、2004年式〜2013年式はマフラー交換においては作業に違いがないとのことなので、この範囲の年式のSportsterオーナーの方の参考になればと思います。

今回はXL1200Lに装着されている日本向け純正マフラーから、Screamin Eagle Ⅱへ交換します。このマフラーはスリップオンタイプですので、エキパイを外す必要はありません。

写真下側のScreamin Eagle Ⅱの刻印がある方が後方のサイレンサーになります。

お約束ですが、この作業内容は私の実施工程をまとめているだけのものですので、参考に作業なさる場合は自己責任にてお願いいたします。

必要な工具・ケミカルなど

作業に当たり、以下を揃えておくと良いと思います。ケミカル類は私が使用したものを掲載していますが、同様の効果を得られるものであれば代替品で問題ないと思います。

  • ソケットレンチ:ヘックスの1/2インチ、5/16インチ
    ※ディープソケットの方が作業しやすいかも
  • 潤滑剤:WAKO’S ラスペネを使用
  • パーツクリーナー:Lubrica パーツクリーナーを使用
  • インターコネクトガスケット:前後のマフラーをつなぐ連結管用です

交換するマフラーにインターコネクトガスケットが付属していない場合は、別途購入が必要です。Amazonや楽天などでも購入可能です。

HARLEY-DAVIDSON(ハーレーダビッドソン) 純正インターコネクトガスケット HD65927–00


私は今でこそDeveloper Relationsという仕事をしていますが、元々はエンタープライズシステム系のエンジニアでした。そのなかで、ある種特徴的なFlashエンジニアという経歴があるので、Flashのサポートが完全終了するこのタイミングで、ちょっと振り返りを書いてみます。

異業種からIT業界へ転職し、最初はVBのエンジニア〜Javaのエンジニアとしてそのキャリアをスタートさせた私ですが、FlashはMX時代のAS1.0から2.0の時に結構開発で使いました。当時リッチクライアントにFlashを使うというのが少し流行って、私もそのために仕事で覚えていった感じです。これが2003年頃。

Flash MX 後継のMX2004まで使う(AS1.0〜2.0まで)

このとき働いていたのは小さなソフトウェアハウスでした。

その後、フリーランスSEとして仕事をしていましたが、元々Java開発をやっていたこともあり、FlashフロントエンドとJavaサーバーサイドを1人で作れるということで、とある会社に引き抜かれました。それが今は無きGluonsというパッケージベンダーで元日本オラクル執行役員だった佐藤聡俊氏が立ち上げたベンチャーでした。

ここで私が担当していたパッケージ製品は、いわゆるEAI(Enterprise Application Integration)で、システム間連携を、異なるシステム基盤や異なるRDB間でもシームレスにリアルタイムに行うという、当時としては結構画期的なツールだったかと。(同系統のツールってData Spiderくらいじゃなかったかな?)これが2004年頃だったかな?


※本記事に登場するすべての企業、団体、個人に関する記述はすべて筆者の私見であり、決して何かしらの公式見解ではありません。

私は前職のMKI時代に同社のモバイルソリューションを推進するテクニカルエバンジェリストとして2年、そしてIBMへJoinしてIBM Cloudを推進するデベロッパーアドボケイトとして4年、合計で6年間この手の仕事へ関わってきました。

今回は一つの節目として、改めてテクニカルエバンジェリストやデベロッパーアドボケイトの仕事を振り返ってみたいと思います。

MKI時代

Node-RED UG Meetup

MKIは正式名称をMitsui Knowledge Industry/三井情報といいます。世間一般ではシステムインテグレーターと分類される会社ですが、その仕事は多岐にわたりました。私が抜けてから4年経つので、今は変わっているかもしれませんが、当時はシステムインテグレーションにとどまらず、ネットワークインテグレーション、データセンター事業、バイオインフォマティクス、新規事業開発、自社プロダクト・サービス販売、R&D、など。

特に、商社系SIerの力を発揮し、海外のプロダクトやサービスをいち早く輸入し国内展開することも多かったです。私は11年間この会社へ居ましたが、後半5年〜6年くらいはこのあたりの仕事をしていました。

その中に、モバイルを中心としたサービスがいくつかあり、当時MKI内では数少なかったモバイルアプリ開発エンジニアの私に、テクニカルエバンジェリストという役割として動け(厳密にはエバンジェリストという言葉では言われてません)、という流れになったわけです。

ここで、私が意識して活動したのは以下になります。

・会社のブランディング
- モバイルやWeb界隈で会社の知名度を上げる
- 私の活動をトリガーに案件の引き合いを作る
・私自身のセルフブランディング
- 社内外で「何かあればまずはこの人に声をかけよう」という状態を作る
- ネットワーキングを通じてOpportunityを生み出す
・会社へのフィードバック
- 外に見えている会社のイメージや、パートナー、顧客からの声を会社へ伝える

その結果として、ある程度の成果は見られたように思います。一方で、会社としてそういった活動に対する評価が難しかったのではないかと感じました。(あくまで私の主観です)
これらの活動は、多くの企業ではマーケティングまたは営業活動の一環として位置付けするしかなく、仕事としてのKPIを定めづらかったのかもしれません。

IBM時代


DevRelといえばテクニカルエバンジェリストやデベロッパーアドボケイトといったRoleが思い出されますが、この人たちはどんな仕事をするのでしょうか?

例えば、私が働いているIBMでは、デベロッパーアドボケイトは以下のような活動を仕事として行っています。

  • セミナーやカンファレンスでの登壇
  • ワークショップなどでの講師
  • ハッカソンなど技術イベントでのテクニカルサポート
  • オンライン、オフラインでの情報提供(ブログ、SNS、各種メディア、書籍など)
  • オープンソースプロジェクトへのコントリビュート
  • パートナー企業やクライアント企業へのテクニカルアドバイザリー

まあ、大まかにこんな感じなのですが、今回はこの中からオープンソースへのコントリビュートというところへフォーカスしてみます。

何故、アドボケイトやエバンジェリストがオープンソースプロジェクトに貢献する必要があるのでしょうか?

これは人によっても捉え方が異なるかもしれませんが、私なりの意見としては、「デベロッパーアドボケイトは技術者たれ」というところではないかと思います。

先に列挙したIBMのデベロッパーアドボケイトの活動を見ても、全てにおいて技術が必要で、オーディエンスに対して有益な技術情報(トラブルシューティングやテクニカルサポートも含む)を提供する訳ですから技術力が必要なのは当然ながら、その人がどれだけ真摯に技術に向き合ってるか、というのが大事になってくると思ってます。

自分が好きな技術、自分が正に使う技術がオープンソースであれば、その技術の発展に貢献しない選択肢は無いのではないでしょうか。

とは言っても、いきなり開発を行えということではありません。オープンソースプロジェクトへの貢献の仕方はたくさんあります。

オープンソースプロジェクトはGitHubなどのパブリックリポジトリでインターネット上に公開されていることが多いです。機能改善や機能追加などの開発をして、直接プルリクエストを送るのも良いですが、いきなりはハードルが高いでしょう。

例えば海外のプロジェクトのドキュメント翻訳などからはじめるのも良いかもしれません。

また、直接何かをコミットしなくても、対象のプログラムを触って気づいた不具合やフィードバックをissueとして上げるだけでも十分貢献してると言えます。

私がユーザーコミュニティを運営している、Node-REDもまたオープンソースです。みんなが使えるように、独自のノード(Node-REDの機能パーツのようなものです)をライブラリに公開したり、ドキュメント翻訳でコントリビュートさせて頂いてます。

また、Digital Oceanが主催しているHacktoberfestというイベントが毎年開催されています。これは、オープンソースプロジェクトへコントリビュートした人にアワードを送るといったものです。

達成者にはTシャツとステッカーがプレゼントされたりします。こういう、イベントへの参加をモチベーションにするのも面白いかもしれませんね。


さて今回は、我々デベロッパーアドボケイトの仕事が、このCOVID-19配下でどのように様変わりしたのかについてお話したいと思います。

コロナ禍であろうがなかろうが、企業に属してアドボカシーを行う役割を担っている以上、結果を出す必要があります。しかし、このような状況下においては、普段の常識が使えません。新しい発想が必要になりました。

KPI

まずはKPIについて触れたいと思います。通常、エバンジェリストやアドボケイトのKPIは以下のようなものが多いのではないかと思います。

・サービス利用者数
・開催イベント数
・エキスパートプログラムの誘致数(例:MVPやIBM Championなど)
・パートナー、クライアントに対してのエンゲージメント数

これらを、少なくともコロナ禍以前より下げてしまってはいけないです。(実際に下がるかもしれませんが)

活動

上記で挙げたKPIを目指すために、我々デベロッパーアドボケイトはどのような活動をするのでしょうか?

基本的に、イベントをどんどん開催します。もしくは、自分が登壇者や講師として外部のイベントへ参加します。これにより、開発者へ影響を与えて自分が啓蒙すべきサービスのファンを増やしていく訳です。

しかし、コロナ禍ではこの状況が変わってきました。当然物理的な会場にたくさんの人を集める訳にはいきません。そうなると、イベントのデジタル化(オンライン化)は必然と言えるでしょう。

デジタルイベント

これは、どこの企業やコミュニティ団体でもそうだと思うのですが、イベントをデジタル化する、という正しい答えはまだ見つかっていないのではないかと思います。(答えは一つとも限りませんしね)

なので、この状況をトリガーにしていろいろなWebサービスも登場しました。今までのサービスに付加価値を付けたものも登場してきました。我々はそのようなツールを活用してデジタルイベントを計画し、実行する必要があります。

私はこの2月から12月までの10ヶ月間で以下のデジタルイベントに企画、運営で関わってきました。

・IBM Developer Dojo:毎週2回
・Water Cooler Conversation:隔週
・DevRel Meetup in Tokyo:毎月
・Node-RED UG Meetup:3ヶ月に1度
・Node-RED Con Tokyo 2020:Annual Coference
・DevRelCon Earth 2020:Annual Conference(DevRelCon Tokyo/SF/Londonの代わり)
・DevRel/Asia 2020:Annual Conference(DevRel/Japanの後継・拡張)
・筑波大学講義
・埼玉大学講義
・九州大学講義

など、細かいものを入れると他にもたくさんありますが、だいたいこんな感じです。

メリットもあり、デメリットもありのデジタルイベントですが、ざっくり以下のようにまとめます。

メリット

会場の準備が不要
→ 会場を探す必要がない
→ 会場費がかからない
→ 参加者人数の増減にやきもきしなくて済む
飲食の準備が不要
→ 料理や飲料を手配する必要がない
→ 飲食費がかからない
→ 参加者人数の増減にやきもきしなくて済む
上記理由から、参加者へ参加費を負担頂く必要がなくなるので、参加しやすくなる。移動が不要
→ フライト不要なので海外からの参加者が増えた
→ 国内でも移動が不要なので、複数イベントに掛け持ち参加ができる

デメリット

一箇所(会場)に集まれない
→ オンラインが故に参加者同士のコミュニケーションが希薄になる
→ 技術サポートを必要とするイベントだとサポートが難しい
→ 自宅参加になる場合、家庭の都合で参加が難しい可能性が生じやすい

まとめ

こうしてみると、デメリットよりもメリットのほうが大きい気が今のところはしています。一方で、参加者同士のコミュニケーションが難しいことから、新規のコネクション、リレーションを構築することが難しいわけでして、なかなかDevRelとしては厳しい面もあります。
大事なのは、既存(オンサイト/オフライン)のイベントのあり方にとらわれず、オンラインならではの新しいスタイルを見つけていくことだと思っています。

前述の通り、ここに対する答えはまだ見つかっていません(少なくとも私は)。しかし、試行錯誤しながらimproveしているのもまた事実です。例えば、Node-RED ConなんかはTokyoで開催しながらGlobalカンファレンスの雰囲気を提供することに成功しました。これは、まさにデジタルで渡航が不要になったことにより、Node-RED開発者のNickや海外メンバーがリアルタイムで登壇してくれたことのおかげです。
同じように、DevRel/Asiaもかなり大規模のアジア圏間ファンレンスを各国の現地オーガナイザーと連携しながらリアルタイムで7トラック同時開催を成功させました。


はじめに

Node-REDからCloudantを使ってデータ処理をする方法というのは、とても簡単なのですが、簡単が故にあまり手順なども公開されていないように感じたのでここにまとめておきます。

環境

ここでは、以下の環境が作成済みであることを前提に進めます。

・IBM Cloud上にNode-REDが作成されている・CloudantのサービスがNode-REDへ接続されている

通常はIBM Cloud上でNode-REDを作成すると、必ずCloudantと接続されるので問題はないかと思います。

CloudantにDBを作成する

まず、Node-REDからデータを登録や検索するためのデータベースを作成します。IBM Cloudのダッシュボード上のリソースリストから、Cloudantサービスをクリックします。
Clo …


はじめに

今回は、IBM Cloudの代表的なサービスの一つであるCloud Foundryを使って、PaaSとしてのIBM Cloudの使い方を説明します。
昨今、コンテナでのアプリケーション実装が台頭してきており、Cloud Foundryでのアプリケーション実装が影に隠れがちではありますが、非常に便利なサービスですので、知っておいて損は無いと思います。コンテナ(Docker + Kubernetes/OpenShift)とCloud Foundry(広義ではコンテナと分類されます)は、シチュエーションに応じて使い分けると良いでしょう。

Cloud Foundry

Cloud Foundryとは、PaaSを実装するプラットフォームの代表的なものの一つで、Cloud Foundry Foundation配下のオープンソースプ …


はじめに

今回は、Raspberry PiのNode-REDを使用してセンサーデバイスから取得したデータを処理し、サーバー側のクラウドプラットフォームにデータを送信する方法を実装します。
センサーデバイスには、Grove の温度/湿度センサーとRaspberry Piを使用します。
クラウド・プラットフォームには、IBMCloudを使用します。IBM Cloudは、IoTでMQTTブローカーとして機能するサービスであるWatson IoTPlatformを提供してます。利用にはIBM Cloudアカウントが必要となるので、お持ちでない場合は、IBMCloudアカウントを作成してください。

Watson IoT Platform

Watsonという名前ですが、Watson IoT PlatformはAPIではなく、IoTソリューションで使用される …

Taiji

OutSystems Lead Community Manager | Ex-IBMer | DevRel 🥑 | Microsoft MVP Reconnect | 筑波大学非常勤講師 | ここでの発言・記事は個人の見解であり、所属する組織等の公式見解ではありません。

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store