インデックス | その1：ライブ, 読書, 資格 | その2<この記事> | その3：発信, 規定作成, データ収集

開発

個人でのアプリ開発については、最近は本当にちょっとずつしか進められていない。ただ、モチベは高い。というのも、自分が使いたいアプリ（上記のライブ参加の予算管理）の構想があるし、仕事の節でちょっと詳しく書こうと思ってるけど、本業以外で1円でも稼ぐ手段を持つことがとっても大事なんじゃないかと最近思ってて、アプリやサービスを提供することは、それにつながっていくと考えている。そもそもそんなこと関係なしに、自分がやりたいとずっと思えていることの一つなんだよね。

まぁちょっと最近ライブ行き過ぎっていうのもあるんだけれど、平日夜にだらけてしまうってなんだかんだ時間がない、という事態になってしまっているので、業務時間外も時間管理をして1時間でも30分でも毎日開発が進められるよう習慣化していくことが必要と思っている。1年目で開発が進んでいた時は、やっぱり平日も開発ができていたので。そのために「データ収集」節で触れるように時間管理を強化していきたいと考えている。あと、ライブに行かない週は休日にがっつり開発したいね。

今開発を進めているのは主に2つ。

［1］ライブ予算管理アプリ（仮称）

上の「地下アイドルのライブ」節でも触れたけど、持続的に楽しむために予算管理をするアプリを作っている。単に予算管理するだけじゃなくて、参加したライブの記録にもなる。ただ、ライブごとに細かい記録をするのはなかなか面倒なのが問題といえば問題。細かい記録が苦にならない人にはいいけど、普通は面倒だよね。もしかしたらライブ情報を収集して提供するAPIサーバを立てる必要があるかもしれない。まぁまずはアプリ作ってからそういうのを考えるのもありかもね。これは自分が必要なアプリなので、早く使いたい。

アプリ内データのER図。自分用の集計ExcelシートのERを参考に検討している。

検討中の画面例。

アプリはiOS向けに作ろうとしている。iOSアプリはCoreMLを試すためにサンプルを適当に作った程度の経験で、iOSとは顔見知りレベルなのでこれから仲良くなっていきたいと思っている。あとで書くようにAndroidについてはわりと業務でアプリを作っていてだいぶ仲良くなったので、iOSとも仲良くなって両方いけるようになりたいね。

せっかくなら全く使ったことない宣言型UIを使ってみたいと思ってSwiftUIを使ってるけど、リスト表示をするとかある程度シンプルなものは簡単に作れて良いね。ただ、今回のようなアプリでもSwiftUIで表現できないようなUIもわりと出てきそうなので、これだけでっていうわけにはやっぱりいかなそうではあるけど。なるべくSwiftUIだけで済むようにしたらだいぶ楽そう。Androidでもこういう宣言型UIはあるようだけど使ったことないので、今度業務で組むアプリでは使ってみたいなと思っている。

［2］究極大富豪 / umefugo

めちゃくちゃたくさんあるローカルルールを全部詰め込んだ究極の大富豪ゲーム。一度ベータ版を出したものの、コードがぐちゃぐちゃやし、カード候補の絞り込みとか本来クライアント側でやるべき処理もすべてサーバにやらせた結果、レスポンスが終わってるダメダメな仕上がりになってしまって一から作り直している。あと、特にジョーカーありの縛りの判定とか難しい処理が意外とあって、ちゃんとテストケースを書いて正確な判定処理であることを確認しなければならない。これは上のアプリ開発もあってだいぶ先になりそうではあるけれど、できたら楽しそうだな～と思うのでいつかは作り切りたいと思っている。

まだ大富豪しか作ってないが、ベータ版提供時の「例のゲーム」のほか、将来的にはマイナーなものも含めてトランプゲームをいろいろ実装してみたいな～と妄想している。

最初のバージョンではサーバ・クライアント共通でUnity＋C#（.NET）で作っていたが、サーバとして必要なのは大富豪のロジック処理のみで、オブジェクトの位置同期とかは要らないわけなのでサーバに関しては純粋なWebサーバとしてC#（.NET）で書いている。クライアントは今回もUnity＋C#（.NET）で作るが、サーバとの通信はHTTP（REST API）およびWebSocketで行う。クライアントは別にUnityで作らなければならないわけでもなくなるので、だいぶ柔軟性がある。

サーバに関して、最初のバージョンと同じようにAgonesでk8sクラスタの管理をしようとしている。加えて、将来的には対戦プレイヤーのマッチングもできるようにしたいが、これはOpen Matchを使ってみたい。本業は不特定多数の人向けにサービスを提供するという感じではなく、こういうのを提供しない限りk8sとか使う機会ないので楽しいし勉強になるよね。

仕事

この前3年目になり、はやいものだなと思った。ただ自分の部署には後輩が一人も入ってきていないため、特にそのような感覚がないんだけどね。

私はメーカーの社内SEというか、システムの何でも屋という感じで、業務システムの改修・新規開発・データメンテ・設計書作成・開発依頼、ETLワークフローの定義作成、工場設備信号収集プログラムの開発、データ可視化ツールなどのOSS導入、データ可視化画面定義、サーバ保守といろいろとやっている。製造系部署のシステム担当というくくりはあるが、じゃあその中でインフラ担当だのバックエンド担当だのいちいち分かれているわけではないんよね。（というかそんなに分けるほどの規模じゃない）

昨年度は、製造系の部署で利用するハンディ端末（中身はAndroidスマートフォン）のアプリ開発をした。まぁやることとしてはわりと単純で、製品を特定するQRコードを読み取って、それに紐づけて検査結果や手直し結果を入力するというもの。入力は基本的にボタンをタッチして詳細を順番に入力していくというもので、タッチ操作に慣れていない人でも使えるように配慮するため、細かい入力はすべて排除しボタンも大きめにしてタッチしやすいインターフェースにした。

ハンディのアプリケーションUIの一部モックアップ（※実際のアプリの画像ではありません）

特にこのタッチ操作に慣れていない人でも使いやすいインターフェースかどうかを検討するためには、実際にハンディ端末上でどれくらいの大きさが適切なのか、操作感のイメージをつかむ必要があるけど、この点はFigmaでモックアップを作成してハンディ端末上でプレビューして大雑把に画面を検討してから開発するというやり方がとても良かった。

アプリについてもフルスクラッチで一から作っており、Androidとだいぶ仲良くなれた気がする。ただ、今回はとりあえず作りきるのが重要なのでまずはシンプルにと思い、かつ一応部署のほかの人も読めるようにJavaで記述し、MVCなどのUIアーキテクチャパターンも適用していない。

Fragmentのライフサイクルメソッドで、ロジックを扱うクラスのシングルトンインスタンスから表示内容を取得して表示を更新し、UIからの操作を受け付けた際にはシングルトンインスタンスに対して操作を行うという非常にシンプルな作り方をしている。Javaさえ読めればなんとなくしていることは分かるように書け、求められる仕様を満たしたアプリの実現・機能拡張にも特に支障はきたしていないんだけど、UIアーキテクチャパターンを適用したほうがやはり良いのだろうか？実際にそれで作ってみてどうなのかを比較したいと思っているところ。今年度は別の業務について同様にハンディのアプリを開発する予定であるが、今度は宣言型UIを使ってみるとか、Kotlinで記述してみるとか、UIアーキテクチャパターンを適用してみるとか、試してみたいと考えている。

それにしてもこのアプリ開発で思ったのは、開発は非常に楽しい！レイアウトをどのようにしたら分かりやすく表示できるか、操作しやすくなるかを考えるのも楽しいし、それを基に実際にコードを書いて実装してみて、難しいことは調べて、想像通りの動きをした時の快感はたまらないね。趣味でもモバイルアプリ開発をしたいな～って思うようになったし、もっと開発能力を付けたいと思った。

ただ、これは弊社と同じような規模感の会社の社内SEとかなら誰しも思うことなんじゃないかと思うけど、そういったアプリ開発とか社内で実績がない、やった経験のある人がいないと、自分ができることが限界になってしまうという問題がある。自分が知らない・できない、もっと高度なことができるようにレベルアップしたいけれど、社内でそれを聞く「先生」がいないので、自分で試して経験を積んでいくか、社外で「先生」を見つけるほかない。これが難しいし、どうするのが正解なのか悩んでいるところである。同じような悩みは社内のほかの人からも聞いている。もちろん、開発以外の面において社内に経験を持った人がいることについては、勉強になることもたくさんあるけどね。

上記のように、純粋にアプリ開発が楽しいので趣味でもアプリ開発がしたい、開発能力を付けたいと考えているのだが、そのうえで会社に依らないで自分の能力を収益につなげるということが大事なんじゃないかと考えている。今の会社から生活するには何も問題ない十分な額の給料をいただいているが、収入源が一つというのはリスクがある。まずは金額によらず1円でも本業以外で収入を得るということを目指したい。

（※あくまで目標の話であり、現在本業以外で収入があるわけではありません。今後、万が一雑所得の範疇を超え、副業となるような場合には社内規定が定めるように然るべき対処をします。）

上みたいな感じで特に面白かった業務をまとめたり、困ったこととかをまとめると自分的にはすごくすっきりした気持ちになって非常に良いので、ちょくちょくまとめて業務経歴のレポートみたいなの作りたいね。色々役に立つ場面ありそうやし。

次の記事 > その3：発信, 規定作成, データ収集

公開コメント