AWS DeepRacerリーグ初参戦の報告

AWS Summit Tokyo 2019で開催されている、AWS DeepRacerリーグ Summit Circuitに参加してきました。

 

せっかくなので自分の作ったモデルで挑戦したいと思い、１週間前くらいからモデル作りに挑戦。

 

 

まずは完走することを目標に、なんとか走れそうなモデルを作ってみました。

 

そしてやってきましたAWS Summit１日目。

 

恥ずかしながら、ものすごい勘違いをしていました。

DeepRacerリーグとDeepRacerワークショップは全然別物でした。

DeepRacerリーグは本会場のど真ん中にあるけど、DeepRacerワークショップはちょっと離れた国際会議場のM会場。ここにはサーキットや実車があるわけではなく、DeepRacerのモデル作成のハンズオンでした。

とはいえ、今までちゃんと理解していなかった、DeepRacerの裏で動いているSageMaker、RoboMaker、Kinesis Video StreamsなどのAWSの各サービスや、強化学習の仕組みを学べて良かったです。1秒間に15回、状態（画像）を取得して行動し報酬を得る、というのを繰り返してモデルを成長させていく、など。

このワークショップで得た内容を元に、モデルをもう一度作り直しました。

 

そして、２日目。朝イチでDeepRacerリーグに参加申し込み。ですが、10:00開場と同時に人の列が…コースは2つありますが、両方とも一瞬で20人以上が並んでいました。この時点で2時間待ちを覚悟。 

 

並びながら他の人が操作している様子を見ていると、結構コースアウトしている人も多く、安心しました（笑）。良い走りをすると歓声があがり、拍手が沸き起こる。お祭りのような楽しい雰囲気です。

 

そして、11:50頃にようやく自分の番が回ってきました。

まずは準備。USBメモリに入れてきた自作のモデルを実機に挿入。操作用のタブレットから実機にアクセスし、モデルを選択します。

スタッフさんからタブレットによる実機の操作方法を習います。といっても、操作できるのはスロットルの出力を何％にするかだけ。ハンドル操作やアクセル・ブレーキは訓練したモデル任せです。

次に、エントリー情報の入力。メールアドレス、名前、電話番号などを入力。

ここまできたら、いよいよ実際のレースです。

 

f:id:takusamar:20190614103438j:plain

 

コースアウトしたら元に戻すため、スタッフが後ろを付いていきます。DeepRacerは前方にカメラが付いているので、映り込まないようになるべく後ろに立つようにしています。レーサーができることは立ち位置に気をつけることと、スロットルの出力を調整することだけ。

 

持ち時間は4分間。何周走っても良くて、その中でもっとも良いラップタイムが成績となります。最初は安全運転で、出力40%くらいで様子を見ました。意外とコースアウトせず、ちゃんと走ってくれます。

レース後半はちょっとスピードをあげてみようと思って出力を60%くらいにしたら、あっさりコースアウト。欲をかいたらいけませんね。50%くらいでなんとか走りきりました。

結果はこんな感じ。14周して、きちんと回れたのが12回。ベストタイムは13秒10でした。思ったより好タイムが出てビックリ。

f:id:takusamar:20190614103340j:plain

 

最後に記念撮影をして、DeepRacer初参戦は終了。

 

ちなみに、1週間ほど遊んだ結果がこれです。$153・・・大人の遊びとはいえ、いいお値段。NAT Gatewayがけっこうかかるみたいです。

 

f:id:takusamar:20190614105122p:plain


 

ファン・ダン・ラーン（Fun/Done/Learn）で１年間をふりかえった

ファン・ダン・ラーン（Fun/Done/Learn）を世界で初めて体験した（実験台となった）チームBのtakusamarです。

年度末に1年間のふりかえりをする機会があったので、ファン・ダン・ラーン（FDL）を使ってみました。 

yattom.hatenablog.com

 

FDLは既に様々なところで実践されていて今さら説明不要とは思いますが、自分の現場（某システムの運用保守チーム）では以下のように実施してみました。

実施手順

  1. 準備
    用意するもの：ホワイトボード、付箋紙、ペン、シール
    ホワイトボードにFun/Done/Learnの図を描く。
  2. アウトプット
    この１年間の出来事、やったことを付箋に書き出す。（３つ以上、何枚でもOK）
    自分がやったこと、他のメンバがやったこと、どんなことでも良い。
    どんな小さなことでも、心に残ったことがあれば。

  3. マッピング
    書いた付箋の内容を１つずつ発表し、Fun/Done/Learnボードに貼る。
    その内容がFun・Done・Learnのどの領域に属するか、みんなで軽く話しながら。
  4. フリートーク
    全部の付箋が貼られたら、全体を通して話し合う。
    話し合っている中で付箋を移動しても良い。

  5. 次のアクション決め
    今後取り組みたいものや改善したいものにシールを貼る。（１人３票）
    票が集まったものについて、改善案を話し合いアクションを決める。

結果

所要時間は40分くらい。こんな感じになりました。

f:id:takusamar:20190404093544j:plain

Fun、Done、Learnの定義についてはメンバで話し合い

  • Fun：やってて楽しいと感じたもの
  • Done：何かの成果が出たもの（新機能リリース、業務効率化、作業手順の確立、など）
  • Learn：メンバのスキルアップに繋がったもの

という感じで分類してみました。

書き出したアイテムについて投票を行ない、以下のような結果になりました。

　1位（6票）ペアプロの実施
　2位（3票）業務効率化に向けた工夫
　3位（3票）カンバン・ふりかえりの実施

次年度の取組事項や優先順位についてメンバ全員の認識を合わせることができ、非常に有意義なふりかえりができたと思います。

所感

いつもの癖で問題点や反省点を書き出してしまう人がいたので、「ProblemよりもKeepに注目しよう」という話をしました。

自分たちがやったこと（事実・実績）を書き出すことで記憶を共有でき、ポジティブな気持ちになれるのがFDLの良いところですね。

FDLのふりかえり結果を元にして今年度の結果報告と来年度の目標設定ができるので、会社向けのめんどくさい資料作成もぐっと楽になります。（チームリーダー的にはこれが一番嬉しい）

余談

FDL実施後に気づいたのですが、ホワイトボードがかなり汚れてました。（以前に書かれた文字がちゃんと消えてなくて、写真をそのままアップするのが憚られるレベル）

乾ききって何ヶ月も経過してて、普通の白板消しではなかなかキレイに消せない。困ったな〜と思いましたが、たまたま手元にあった赤ちゃんのおしりふきで拭いてみたところ、とてもキレイに消せました。

f:id:takusamar:20190404101510j:plain

右が拭く前、左が拭いた後です。モザイク処理をかけていますが、だいぶ違うのが分かるとお思います。

ちなみに私が愛用しているのはGOONの肌にやさしいおしりふきです。

f:id:takusamar:20190404101619j:plain

純水99%でホワイトボードの表面を傷めません。ふんわり厚手タイプでしっかり拭けます。1枚あたり1〜2円程度とコスパも良いので、ホワイトボードの消えない汚れにお悩みの方、ぜひお試しください。

那覇でLTしNight!!に参加＆カンバンの経過報告

前回のブログ記事（スクラムをやめてカンバンに切り替えた話）の内容を「那覇でLTしNight!!」で話してきました。

その時のスライドを貼っておきます。

 

www.slideshare.net

 

カンバンを始めてからそろそろ２ヶ月。チームもだいぶ慣れてきました。

付箋紙に担当者を示すシールを貼るなど、メンバからの改善案を取り入れて少しずつ進化しています。

 

f:id:takusamar:20190210180917p:plain

 

メトリクスの計測はまだ上手くできていないけど、とりあえず１週間毎に完了したタスク数を数えています。本当はタスク毎の相対見積もりもやりたいけど、一気に詰め込むとメンバの理解度を超えてしまいそうなので、小出しにしていこうと思います。

スクラムをやめてカンバンに切り替えた話

運用保守チームで2018年5月からスクラムをやっていたが、12月でスクラムを終わりにしてカンバンに切り替えた話。

スクラム実施状況

以前の記事

運用保守チームでスクラムをやってみた話 - takusamarのブログ

このような感じでやっていたが、どうも上手く回せなかった。

問題点

  • 運用保守という業務の特性上、どうしても緊急の割り込みが発生する。だいたい当日中か翌日までに対応しなければならない。

    • スプリントの途中で割り込みが入るのが当たり前になってしまい、スプリント計画を作る意味がない。

    • 急ぎの作業はPOを通していたら間に合わず、顧客から開発チームに直接依頼がくる。

  • 10年以上前の設計思想で作られた既存システムから新システムへの過渡期のため、使用している技術要素が多すぎる。

    • POが全ての作業内容を把握しきれず、開発チームへ丸投げになってしまう。

    • 特定の担当者や特定の端末でしか実施できない作業があり、チーム全員で一気に作業することは難しい。

  • 開発案件は他部署・他ベンダーと連携するため、各関係者と調整しながら進める形になる。

    • 調整待ちのまま何週間も待たされることが多い。

    • 1週間スプリント毎にリリース可能な成果物を作るのが難しい。

    • 担当者2〜3名で（他の案件と掛け持ちしながら）数ヶ月かけて仕上げる、という開発形態になってしまう。

  • プロジェクト管理ツール（JIRA）を使いこなせない。

    • JIRAを見ながらミーティングしているとメンバが自分のPCばかりを見てしまう。同じ部屋にいるのに会話が少ない。

    • タスクが可視化できるので管理している気になるが、見た目だけきれいになっている感。

    • 顧客がJIRAを見れないので報告用にRedmineも使っていて、二重管理が面倒くさい。

考察

スクラムが悪いわけではなく、現場の業務内容と合っていなかったのだと思う。 「スクラムをやってみたい」というノリで始めて失敗する典型例。

いったん「スクラム」を離れて、自分たちが何をしたいのか、どういう仕事の仕方をするのが一番良いのか、を改めて検討。 その結果、

  • 各タスクがどういう状況かチーム・顧客と情報共有したい。

  • プロジェクト管理に工数をかけたくない。

  • チームメンバ同士の会話を増やしたい。

という点を満たしたい。それならカンバンが良さそうだよね、という結論に至った。

僕たちのカンバン

f:id:takusamar:20190103151714p:plain

  • 作業場所（顧客とチームメンバが入室可能）の壁に模造紙*1を貼る。

  • 模造紙にステータス毎の欄を作る。

    • （空白）：顧客の要望や将来案など、ネタは出ているがまだ作業可能になってない。（Not Ready）

    • 未着手：顧客から作業依頼が来たもの。これからやるべき作業。

    • 着手中：担当者が作業中のもの。

    • 確認中：顧客や他部署・他ベンダの確認中・問合せ中。

    • 受入待ち：作業完了。顧客への月次報告待ち。

    • 完了：作業完了。顧客への月次報告が済んだもの。

  • タスクを付箋紙に書く。

    • タスクは誰でも追加できる。POだけでなく開発チームや顧客も書いて良い。

    • 業務毎に付箋紙の色を変える。

    • タスクの概要、納期（明確な場合）を書く。

    • 作業状況に合わせて付箋紙を動かしていく。

ルールはこれだけ。なるべくシンプルに、アナログ重視でやってみた。

カンバンの効果

カンバンをやり始めて半月だが、仕事が進めやすくなったように感じている。

  • カンバンを前にしたデイリーミーティングで、今まで少なかったメンバ同士の会話が増えてきた。

  • 壁に貼ってあるので、顧客にも状況が見えやすくなった。

  • タスクのステータス更新し忘れが減った（ような気がする）

ただ、カンバンではリアルタイムな状況を見ることはできるが、記録が残らない。 そのため、カンバンのタスクをRedmineのチケットとしても記入することにしている。 ここだけは二重管理をなってしまうが、致し方ない。 カンバンのステータス分類をRedmineと合わせたので、まだ転記しやすくなっているはず。

今後の課題

  • 属人化の対策

    担当者同士で少しずつ仕事を教え合ってもらいたい。会話が増えてくればそういう動きにも繋がると思う。

  • 相対見積もり

    スクラムで相対見積もりをやっていたので、カンバンでも相対見積もりは続けたい。 どのように書くか、どのように集計・計測するかは悩み中。

  • 請負契約の取り扱い

    準委任契約の作業は顧客と情報共有した方が仕事が上手くいくが、請負契約の場合はどこまで見せるかが難しい。

*1: 使ったのはこれ。ポストイット 付箋 イーゼルパッド 卓上タイプ 584×508mm 白 20枚 EASEL 563

エネテラスvol.4 参加報告

エネテラス vol.4「動き方をアップデートする」に参加してきました。

f:id:takusamar:20181201065439j:plain

エネテラスとは？

某社会インフラ企業の若手社員が中心となって開催するトークイベント。

非オフィシャル（会社業務ではない）だが、今のところ一般には非公開（グループ企業内でも一部メンバーにだけお誘いがある）

 

私は今回が初参加でしたが、主催者の１人に「このイベントのことを外で話していいか？」と確認してOKをもらい、こうしてブログに書きました。

これを読んで興味を持った方がいたらぜひご連絡ください。

 

内容

入社10年目〜くらいの中堅社員の経験談。

修羅場の乗り越え方

求められるのはスピードとわかりやすさ。資料の体裁は仕事の本質ではない。

あえて「怒られる」ことでコミュニケーションを取る。

 

「修羅場」とは。どんな無理難題な状況でもやり切らなければならない場

 

時間がない中でいかにやりたいことをやるか（スキマ時間の使い方）

手帳に、やりたいことをやった時間を記録する。（1H=1.0、6分=0.1）

過去３年間の記録を公開。週平均でも7〜10時間程度はやりたいことができている。
ちょっとした空き時間でも積み重ねると結構大きい。

出張はボーナスタイム。移動中に2時間くらいまとまった時間が取れる。

 

人事異動後、新しい環境での動き方

最初は自分のやりたいことをやらせてもらえない。
まずは雑用であっても嫌がらずにやり、日々の仕事からジャブを打つ。

部署の中で面倒くさい仕事・誰もやりたがらない仕事があったら手を挙げる。
特に上司・役員・他部署と調整するような案件は自分を売り込む絶好の機会。

 

スネ夫のような「したたかさ」「ずる賢さ」を持つこと。

 

質疑応答

  • 他社への出向で感じた、自社との違いは？
    →自分の仕事を自分で考えて進められる（無駄な調整が少ない）
    →スピード感がある（決裁までのハンコの数が少ない）
    →社員個人個人の能力にはそれほど差はない。
  • クリエイティブな仕事をしたいが、どうすればよいか？
    →自分がテンションあがるものを見つける。
    →結局は自己満足。それが世のためになればOK。
  • 自分から率先して動くためには何が必要？
    →根拠のない自信と妄想力。
    →「俺だったらできる」という勘違いは大事。
    →○年後にこうなっていたい・こうしたい、という妄想に向かって進む。

所感

  • 修羅場の話は過去の記憶が蘇ってきて、胃が痛くなった。
    修羅場になると本当に重要なことにしか力を注げなくなるので、結果的にアジャイルにならざるを得ない。１日１スプリントみたいな感じ。
  • あえて「怒られる」のは自分を下げて相手を優位に立たせてあげることでコミュニケーションを取りやすくなるけど、やりすぎると自分が壊れるので要注意。
  • スキマ時間の使い方はとても参考になった。生まれつき頭が良い・悪いではなく、時間の作り方・勉強の仕方が上手いかどうかで差がつく。
  • 人事異動後の動き方は、転職先で最初にやることと同じ。
  • 楽しい仕事は偶然出会うもの・与えられるものではなく、自分で獲りにいくもの。
  • 優秀な人材が多数いるのに、使いこなせていない感。組織的な問題か？

と、いろんなことを考えさせられたイベントだった。

個人的には、グループ全体の中には（良い意味で）変人や熱い人がじつは結構いるんだということがわかり、そういう人たちと会社・部署の壁を超えて繋がることができたのが良かった。

本音を言うと、グループの中だけで閉じないでもっとオープンにやって欲しい。社内事情をどこまで話せるか、という点が難しくなるけど。

 

運用保守チームでスクラムをやってみた話

前置き

現在進行形の話なので書けないこともたくさんあるけど、自分があの時こんなことをやっていたと後日ふり返るために書き残しておく。

状況説明

チームメンバ

６名（うち１名は管理職、5名が実務担当）

  • 管理職：スクラムマスター
  • 自分：プロダクトオーナー（実際はスクラムマスター的な動きもしている）
  • 他４名：開発チーム（スキル、経験はかなりバラつきあり）

業務内容

  • とある業務システム（オンプレミス）の運用管理
    • サーバー（物理・仮想）やネットワーク装置のログ管理・リソース監視
    • セキュリティパッチの確認・適用
    • 業務用のマスターデータの更新
  • 他システムとの連携機能の保守開発
  • その他、さまざまな依頼対応

技術要素

使っている技術は以下の通り。物理インフラからDB、webアプリケーションまで幅広く取り扱っている。

こうやって書き出してみると本当にいっぱいある。もうちょっと整理して減らしたい。。。

スクラム導入の目的

【建前】

  • 属人化の問題

    今までは各担当者が守備範囲を決めて個別に作業していたため、業務知識や技術スキルが属人化してしまっていた。 担当者以外は何がどうなっているのか分からない。休みが取りづらい、人事異動が難しい。

    →チームで作業する習慣が浸透すれば、属人化が解消できるのでは。

  • 業務の増加

    セキュリティ強化や既存システムの機能追加・新規システムの開発など、顧客の要望が質・量ともに年々増加している。 技術者不足や予算の制限もあり増員することが難しい。

    →もっと効率的に業務を遂行できる体制・仕組みをつくりたい。

【本音】

  • 単に自分がスクラムをやってみたかった。

  • 会社としても今年度の取り組み事項として目玉になるネタが欲しかった。

    →両者の利害が一致！

やったこと（時系列）

情報収集

POStudy勉強会 vol.1 に参加（2017年5月）

https://postudy.doorkeeper.jp/events/60455

新規事業創出のための事業企画、仮説検討、プロダクトバックログの作成を学ぶワークショップ。内容が濃すぎて理解が追い付かなかった。。。

運用保守の世界とは全く違うけれど、顧客のニーズを汲み取って改善提案をしていく流れという点では非常に参考になった。

社内アジャイル研修の開催（2017年11月）

外部からプロのアジャイルコーチを招き、社員（事業部内の管理職・技術職・営業職）を対象にアジャイル・スクラムの研修を開催した。

また、その前に予習として勉強会を数回開催し、アジャイル・スクラムの用語、原理原則、考え方を知識として理解してもらう活動を行なった。

※新しいことを始めるにあたって、前もって上層部に理解を得ておくのは大事。地道に根気よくプッシュし続けた。

POStudy勉強会 vol.2 に参加（2018年2月）

https://postudy.doorkeeper.jp/events/69880

2017年5月のものとほぼ同じ内容。

前回は消化不良だったので再度受講したけど、やっぱり分かるようで理解しきれなかった。

頭で分かったつもりでも実際に手を動かすとあれれ・・・となる。やっぱり実践あるのみか。

開始手続き

稟議書の起案～決裁（2018年2月～4月）

アジャイル（スクラム）の実施を承認してもらうため、稟議書を起案。

  • 年間計画
    • インセプションデッキの作成　○月～○月
    • スプリントの実施　○月～○月
    • 結果報告　○月
    • 成果指標、目標値

  • アジャイル導入により増える工数・費用の見積もり

    • インセプションデッキの作成　○○人日
    • プロダクトバックログの更新　○○人日
    • スプリント実施（計画MTG、レビュー、ふりかえり）　○○人日
    • 社内報告書作成　　○○人日
    • 管理作業　　○○人日
    • 社外研修の受講費用、および工数　　○○円、○○人日　

  • 実施体制図

    • 責任者
    • 管理者
    • スクラムマスター、プロダクトオーナー、開発チーム
    • 顧客との関係、業務フロー

こんな感じの資料を作成して、直属の上司～社長に至るまで片手に余る数のハンコを押してもらい、決裁をいただいた。

こういう手続きは本当に非アジャイル的だけど、会社のルールはルール。 伝統的日本企業ではこの辺りでうんざりして諦める人も多いと思うけど、自分のやりたいことをやるには折れない気持ちで一歩ずつ前へ。

顧客説明（2018年3月）

アジャイル（スクラム）を実施することについて顧客に説明。

  • 顧客と運用保守チームとのやりとり（インタフェース）は変更なし
  • 今までよりも生産性が上がる＝同じ費用でより多くの仕事がこなせる

という説明をしたので、好意的に受け止めてもらえた。

スクラムの実践

チーム結成（2018年4月～）

それまでは客先常駐と自社内に分かれて作業していたのを、全員一ヵ所に集合させた。

インセプションデッキ作成（2018年4月～6月）

チームの全体像や進むべき方向を明確にしてメンバの意識を合わせるため、インセプションデッキを作成した。

1. 我われはなぜここにいるのか
2. エレベーターピッチを作る
3. パッケージデザインを作る
4. やらないことリストを作る
5. 「ご近所さん」を探せ
6. 解決案を描く
7. 夜も眠れなくなるような問題は何だろう
8. 期間を見極める
9. 何を諦めるのかをはっきりさせる
10. 何がどれだけ必要なのか

一気に全部作るのは無理だったので、毎週1時間ミーティングを行ない、１～2項目ずつ作成していった。 インセプションデッキを作り上げる過程でチームメンバが対話を積み重ねることにより、業務に対する認識が深まったこと、チームメンバ同士がお互いを理解し合えたことが非常に大きな収穫だった。

プロジェクト管理ツール（JIRA）構築（2018年5月）

無償のツールもいくつか試したけど、使い勝手が良さそうなのでJIRAを購入。 初心者こそ、多少お金をかけても良い道具を使うべき。

JIRAサーバー（オンプレミス版）買い切り価格　10ユーザー$10 https://ja.atlassian.com/software/jira/pricing?tab=self-hosted

Scrum.inc 研修受講（2018年6月）

https://scrum.esm.co.jp/

東京で開催されたスクラム研修に、運用保守チームから３名が参加。

  • スクラムマスター研修　1名
  • プロダクトオーナー研修　2名

Scrum Inc.認定スクラムプロダクトオーナー（LSPO）研修を受けてきた話 https://qiita.com/takusamar/items/97c8b734a065312bb310

プロダクトオーナー研修で学んだことを一言でいうと「Courage! 」

プロダクトオーナーは顧客とチームを結ぶ存在。50%を顧客と共に過ごし、残り50%はチームと共に過ごす。

　→スクラムを成功させるためにはコミュニケーションが非常に重要となる。

コミュニケーションを取ることを恐れない。スクラムを前進させる勇気が一番大事。

スプリントの実施（2018年5月～）

最初は２週間スプリントでやろうとしたが、

  • 週単位での作業、週単位での報告が多い。
  • 割り込みの依頼が頻繁にあり、2週間だと作業計画の変更がしづらい。

といった現場業務の特性を踏まえて、スプリント期間は1週間に決定。

また、週の始めと終わり（月、金）はいろいろと立て込むので、スプリントは「水曜～火曜」と決めた。

  • スプリント計画ミーティング（水曜AM）　1時間
  • デイリースクラム（毎朝）　5～10分
  • スプリントレビュー（火曜PM）　1時間
  • スプリントレトロスペクティブ（火曜PM）　1時間

だいたいこのような感じでミーティングを行なっている。

5月中旬から始めて、ここまで15回のスプリントを実施した感想。

  • 各作業をスプリント内（１週間以内）で終わるボリュームに分割して、計画を立てられるようになってきた。
  • 優先順位（重要度や納期）を意識して、順番の入れ替えや担当者の変更、作業負荷の平準化ができるようになってきた。
  • 相対見積もり（ストーリーポイント）の判断が難しい。 結局、時間換算（1ポイント＝1.0～1.5H 程度）になっている。
  • 運用保守という業務の特性上、どうしても緊急の割り込み作業は発生する。 割り込みの発生確率を予想して、キャパシティ最大まで詰め込まず余裕を持たせるようにした。

今後の予定

  • インセプションデッキの定期更新 １回作ってみたけど、考えが抜けている点や周囲の状況が変わった点もあるので、再度作り直す。

    できれば、定期的に見直す機会を設けて、常に最新の状態を保つようにしたい。

  • 引き続き、スプリントの実施

    まだまだ上手く回っているとは言えない。 特に、現在開発中の新機能がそろそろ総合試験（ウォーターフォールで開発している他社システムとの連携試験）なので、そこをどう乗り越えるかが大きな山場。

  • スプリントレビューの改善

　気がつくと、レビューではなく進捗報告になってしまっている。 　顧客にも入ってもらって成果物のデモができるようなスプリントレビューにしたい。

APEX User Group - 第1回Meetup 参加報告

 APEX User Group - 第1回Meetup@東京に参加してきました。最初は5分程度のLTの予定でしたが、当日に急遽30分枠をいただき、たっぷり話してきました。

 

www.slideshare.net

 

参加の経緯

ハッカーズチャンプルー2016のLT「Oracle APEX実践報告」の資料をSlideShareにアップしてたのがオラクルの中の人に見つかってしまい、沖縄でAPEXを使って面白そうなことをやってる会社があるぞ、ということでAPEXのユーザー会に声をかけていただきました。

f:id:takusamar:20170427164033j:plain

 

感想

T字形ER手法×Oracle APEX＝超高速開発

当日の参加者がOracle APEXに期待しているのは「簡単な画面やシステムを楽に作りたい」ということで、T字形ER手法が必要なほどの複雑なシステムをOracle APEXで構築しようという人はあまりいなそうでした。ちょっと参加者のニーズを読み違えてた気がします。
 
T字形ER手法について自分自身の理解もまだ浅いためグダグダな説明になってしまいましたが「こんなビジネス解析・DB設計方法があるよ」という点は最低限伝えられたと思います。これまでに開発したシステムや、実際にT字形ER図を書いて実装したAPEXアプリのデモなどAPEX開発の事例紹介ができたのは良かったです。
 
T字形ER手法にしろ、Oracle APEXにしろ、世の中の主流ではないため情報が非常に少なくて大変です。ですが「人の行く裏に道あり花の山」というか、マニアックな所を攻めるのが面白いので、しばらくこのまま進んでみようと思います。
 

APEX5.1.1 ( Oracle Database Cloud Service ) アップグレードよもやま話

 APEX5.1.1いいなあ。自分が使ってるのは4.2.6だけど、既存アプリの修正なしで簡単にバージョンアップできそうなので試してみようと思います。
Oracle 12cでCDB・PDBを使っているときにハマった話など、実際に手を動かした結果の報告は聞いていてすごく勉強になりました。
 

大変便利なAPEX、ORDSの実業務での活用例を見て！（日本オラクルさんアピール不足ですよ！）

AngularJSで超かっこいいアプリを作ってて驚きました。これのサーバ側はAPEXだけ（REST API）だというのがすごいです。
 
APEXではシンプルな画面なら簡単に作れるけど、凝ったことをやろうとすると一気に難易度が上がります。そんなときは無理にAPEXで作り込もうとせず、REST APIを提供して別の言語（AngularJS）で作るのが現時点のベストプラクティスだと思いました。
 
ただ、REST APIのためだけにOracle APEXを使うのはもったいない話。
  • ユーザーの要求レベルが高い画面は、AngularJSなど別の言語で工数かけて作る。
  • ユーザーの要求レベルが低い画面は、Oracle APEXでさくっと生成する。

という使い分けをするのが良さそう。

 

APEXユーザー会について

海外では結構使われていて技術情報や事例が豊富だけど、英語ばかりで日本語の情報が少ない。それでAPEXを諦めた人も多いはず。
日本でユーザー会を立ち上げて、日本語の情報を増やしたら日本国内のAPEXユーザーも増えるはず。使う人が増えたらまた情報量も増えて、という好循環になって欲しいと思いました。
 
第1回のMeetupということで、進め方はまだ手探りな様子。他の勉強会に比べてややお固いかも、という印象（飲みが足りなかった？）
第2回以降、沖縄から毎回参加するのは難しいけれど、何らかの形でサポートしていきたいです。