今年の7月から「REDEE」(https://redee.game/)という教育事業の責任者をやりながら、そこで顧客が使用するシステムの開発を始めました。

以前働いていた会社で基幹システムや簡単なVBAを使ったシステムを触っていたことはあったのですが、WEBアプリケーションは初めてです。

WEB技術のことを何もわかっていないし、JavaScriptについても「なんだこのカッコの多さは…」状態だったので、大量に本を買い、Udemyでハンズオンのレクチャー動画を買い、Google先生とYouTube先生に世話になりながら、なんとか頭に知識を入れていく毎日です。サムネは開発を始めてすぐに買った本。オライリー本の安心感は半端ない…。

私の事業責任者としての仕事は戦略を考えて、意思決定をして、社内のリソースを管理することです。ごりごり手を動かすよりも、抽象的なことを考えている時間のほうが多い。

本システム開発においても、当初は外部に委託する予定でした。要件定義書をつくり、見積もりも頂いたのですが、諸々の条件を考えると「うーん…」と二の足を踏んでしまい、結果として内製化することに決めました。

外部委託に必要な費用やリスクというのが大きな要因ではあるのですが、以下のようなことを考えて内製に踏み切った次第です。項目に分けて説明します。

どんなシステムを開発しているのか

「REDEE」は子どもたちにデジタルに関する技術を教えるサービスです。「カリキュラムの資料や動画を閲覧する」「カリキュラムの完了実績を登録する」「講義の日程を予約する」といった要件が必要になります。

子どもまたは親がメインのユーザー、PCとスマホが対象端末となるシステムになるので、WEBアプリケーションとして実装することを決めました。カリキュラムの中でJavaScriptを取り扱っているので、当該システムでもJavaScriptを採用しようと思い立ち、バックエンドはNode.js、フロントエンドはReactにしました。MERN(MongoDB, Express, React, Node.js)に染めようと思ったのですが、「NoSQLはちょっとわからん…」となったので、DBはMySQLになりました。

バックエンドのNode.js、Express、ORMでDB操作を行い、それをフロントのReactで取得してDOMをレンダリングしていく、というのがざっくりとした構成です。認証まわりにはFirebaseを使っています。

以上のような技術スタックを聞いて、「わたしもREDEEでWEBアプリケーションを開発したい！」という方がいらっしゃったらぜひ一緒に働きましょう。(ツイッターでDMをください)

高解像度でドメイン知識をシステム要件に変換する

システム開発を何度か経験しているので、顧客がやりたいことをシステム要件に変換することの難しさはある程度わかります。使用している言語が違うので、翻訳がうまく機能しないと、誰も欲しくないシステムが出来上がってしまいます。

ソフトウェア開発には「ドメイン駆動設計」という言葉がありますが、ざっくりと、ドメイン知識があらゆるレベルのコードに落とし込まれないと良いソフトウェアは生まれない、と私は理解しています。

ということは…ドメイン知識そのものを司っている意思決定者がコードを書けばよいのでは?

ドメイン知識といっても例えば、
A. 業界の標準的な商習慣
B. 業界で企業が創り出した商習慣
C. 企業の意思決定者が持っているアイデア
といった具合に、異なるレイヤーが存在します。(ドメイン駆動設計における定義ではないです、念のため)

意思決定者の立場の人間が作る要件はCには合致しても、AやBには合致しない可能性があります。よって、良くない要件が生まれるリスクは否定はできません。

とはいえ、ドメインを司る人間が脳内で考えていることをそのままコードに込められるというの効率的です。要件にまとめて、設計書を書き、エンジニアに説明するというプロセスを全てショートカットできます。要件を頭に浮かべながら直接コードを書けばいいのですから。

技術的な知識がドメイン領域の知識をアップデートすることもあります。技術的に可能なアイデアがそのまま経営アイデアとなるわけです。

人類がみなコードを書けるようになれば、営業 vs. エンジニア、経営者 vs. エンジニアみたいな対立軸はなくなるでしょう。自分で機能を考えて、自分でコードを書き、デプロイしてユーザーに使ってもらう、こんなに素晴らしいことはないのでは?

「自分でやってみる」文化をつくる

「REDEE」に来てくれた子どもには「(とりあえず)自分でやってみる」というマインドを学んでほしいと思っています。

「デジタル教育」という表題を掲げているのですが、デジタル技術の素晴らしいことは何でも安価で(なんなら無料で)使えることです。ゲームを制作するエンジン、動画の編集ソフト、DAW、3Dのモデリングソフトといったものは無料で手に入るものがたくさんあります。

「自分でやってみる」ことの経済的なハードルは年々低くなっています。インターネットにつながる標準スペックの端末があればだれにでも開発者・クリエイターになる道が開かれています。

環境はある、知識はWEBから無限に拾うことができる、となればコードを書く、ペンタブを握る、音を打ち込むかどうかはあなた次第…！な時代です。

そういうテーマを掲げた事業の旗振り役として「自分でやってみる」を自ら実践しないとダメなのでは?と思ったのです。誰にでも門戸は開かれているのであれば、まずは自分がくぐらなければ。

全ての人に「スーパーエンジニア・スーパークリエイターになってほしい！」という風には思っていないのです。「REDEE」で学んだ人の中からそういう才能が生まれてくれればうれしいですが、そういった結果のみならず、プロセス自体が大事なのです。

「自分でやってみる」こと、そして「学び続ける」という姿勢が現代のような不確実な時代に必要だと思います。

「REDEE」で学んでくれる人、そして「REDEE」に関わってくれる人には同じようなマインドを持ってほしいと願っています。

ミクロとマクロを行き来するのは難しい

開発をしながら事業の舵をとるという二足の草鞋を履いてみて分かったのですが、言わずもがな大変です。大変さの根源にはあるのは、業務の負荷というわけではなく、具体的なことと抽象的なことと、ミクロとマクロを行き来することだと思います。

なかなか取れないエラーに悩まされながら、四半期の事業の経営戦略を考える、というのは自分にとっては無理難題でした。なんというか脳の働き方が違う。

ミクロな問題については、頭をフル回転させて、24時間そのことを考えていないと、良いアイデアが浮かんできません。一方でマクロな問題については多様な情報を脳内のメモリにまき散らして、組み合わせたり、混ぜたりしながら、ふと良いものが出来上がってくる、というプロセスをたどります。

演繹的と帰納的の違いに近いかもしれません。どちらも必要な思考プロセスなのですが、両方を同時に扱うのは(少なくとも自分にとっては)難しいなと感じています。

「ソフトウェア開発におけるスクラムマスターはマネジメントに注力したほうが良い」と書いてある記事を読んだのですが、開発に携わったとしてもコードをごりごり書きながらだと他の仕事が手につかないなと実感しました。

このあたりは「自分でやってみる文化」の理想と限界なのか、自分の能力の問題なのかを見極めたいと思っています。

…こういう風なことを考えながら「REDEE」事業のシステム開発をごりごりとやっていた夏でした。

個人的に、ここ数年取り組んできたゲーム・eスポーツという分野の仕事から少し離れて、デジタル教育という軸に体を移し始めて2か月間くらい、コードを書くというのは自分の意識を変えるためにも、良い仕事になりました。

本ブログでは「デジタル教育」について色々な記事を書いていきます。良かったら、いいねとフォローボタンを押してもらえると嬉しいです。