読者です 読者をやめる 読者になる 読者になる

ガルトラで遊ぼう

ガルトラ、プログラミングについてのブログです。月に4投稿ぐらいのペースでやっていきたいと思います。

MDAツールについて

あなたはMDAツールを使ったことがあるだろうか?そもそもモデル駆動形開発という言葉を聞いたことがあるだろうか?
筆者は前職にてMDAツールを用いたシステム開発を行った経験がある。今回は、その知見について記載したい。

MDAツールとはなにか?

MDAツールとはモデル駆動形開発を推進するためのツールである。以上。
具体的には、MDAツールとはモデル駆動型開発を後押しするツールのことだ。モデル駆動型開発は、ある時期流行ったソフトウェア設計手法の一つで、ざっくりいうとシステムの要求、アーキテクチャをモデルで表現しようというものだ。そして、重要なことは正確なモデルが出来上がれば、そこから実装を分離して生成できるようになるという点である。代替のツールのMDAツールは図を書くもの、そこからコードを生成するものだと思ってもらえればよい。

「図からコードを生成する」

正直なかなか聞こえはいいツールだと思う。特にコーディングという作業に対して問題意識がある人にはそうだろう。ウォータフォールモデル等を経験したことがある人なら聞いたことはあると思うが、コードは誰が書いても同じとはよく聞く言葉である。また、コーディングに対する欠陥数の指標を「欠陥数/ライン数」なんて計算式で出したりする企業もある。そんな企業にしてみればMDAツールを導入すれば正しいモデルさえ作ればコーディングの欠陥数をまるまる失くすことができるかもしれないMDAツールは非常に魅力的だろう。

MDAツールのメリット

以下にMDAツールのメリットを上げてみる。

  • 図で表現できる

これが、一番のメリットであろう。図は直感的で見やすいというのが一般的な認識である。図で表現することにより、コードが持つ特有のメソッドについて処理内容を知らなくても大丈夫になる。

  • コードを自動生成できる

これもよく聞くメリットだ。モデルからコードを自動生成できるので、開発者は設計に集中することができる。正確なモデル(設計)のみを追求すればよいのである。

MDAツールのデメリット

反対にMDAツールのデメリットを上げてみる。

  • ツールが高い

一般的にMDAツールはベンダーが提供しているパターンが多い。OSSフリーソフトというのはあまり聞かない。そして、そのツールは大抵高価である。開発ツールだけで数百万というのはよく聞く話である。

  • 専門性が高い

ツールはベンダーが提供しているので、そこで、使われる図もそのツールに特化したものになっていることが多い。大抵はUMLベースではあるが、微妙に表記が違うということがある。もちろんその図を使用して設計するのもそれ相応の知識が必要になる。

  • 画面内の情報量が少ない

図とコードを比べると画面に表示できる情報量がかなり違う。コードのほうが全然情報量が多い。

  • 重い

私が使っていたツールだけかもしれないが大抵のモデリングツールは重い。起動するだけで数分、画面移動で数分、ビルドで数分といった具合であった。もっとひどいのはgrepがとてつもなく重い上に検索結果を開くのもいちいち重いといった始末であった。

生成されるソースコードは人間に読めるものではなかった

個人的なMDAツールの今後について

私の上司はMDAツールは未来のツールだとよくいっていたが、個人的にはそのような未来が訪れる気はしない。もともとコーディング悪し!というところでMDAツールが導入されたらしいが、今はそもそものコーディング環境が向上したように感じる。設計やドキュメントに頼らずともTDD、アジャイル開発により品質の高いソフトウェアを作る技法がたくさん出てきている。そういう意味でも現在、MDAツールがあまり主流になれなかったのはよくわかる。

しかし、この後、より簡単に作図できるツール等が誕生したらMDAツールの逆転もありえるのかもしれないとか思いながら今回の記事を終わる

タイガーチームについて

タイガーチームという言葉を聞いたことがあるだろうか?ロバート・C・マーティンの著書「」に記載されている。私も一時期あるプロジェクトにてタイガーチームに所属していた。そのプロジェクトは今まで企業向け社内コミュニーケーションツールとして大企業、中小企業それぞれ別パッケージとして展開していたものを一つに統合するプロジェクトであった。

タイガーチームの結成

なぜ、タイガーチームを結成することになったのか?私の会社は元々、中小企業向けにそのソフトを展開していたが、今回の新製品の要求仕様は大規模向け開発を行っていたチームが取りまとめていた。その第一版は既に展開されていたが、その内容はほとんど、大規模向けに特化しており、中小企業向けの内容がほとんど盛り込まれていなかった。このまま新製品が世に出ると中小企業向けの製品展開が難しくなり中小企業向けにソフトの開発を行っていたチームは解散を余儀なくされる状態であった。

我々タイガーチームの目的はずばり、その要求仕様書に中小企業向けの要求機能を盛り込むことであった。まずは、大規模向けと中小企業向けの差分を一覧にまとめた。そして、いくつかの基本方針を作った。

  • 大規模向けになく、中小向けにある機能はそのまま盛り込む
  • 大規模向けにあり、中小向けにある機能はそのままにする
  • 大規模向けにあり、中小向けにもある機能はシステムで切り分けられるようにする
  • 既存機能で要求機能に記載が足りない部分は記載を付け足す

私はこの基本方針に乗っ取り既存の要求機能仕様書を修正しまくった。要求機能仕様書は見違えるようによくなっていった。幸いなことにソフトの販売元である顧客からも感謝された。彼らも既存の要求機能仕様書はわかりづらくひどいものだと感じていたようだった。作業は分量が多く、2ヶ月ほどかかった。その間、我々タイガーチームと顧客とで秘密裏に作業を進めた。タイガーチームのことは、他のプロジェクトメンバーには内緒で進められた。

顧客とのギャップを埋めたい

f:id:scrap_girl:20170408151946j:plain

上の絵は、要求分析の難しさを表した有名な絵である。ご覧の通り、顧客が最初に説明した要件と最終的に得られたサポートが大きくずれている。それどころか顧客が本当に必要だったものは最初に顧客が説明した要件とも違うのである。これが日常茶飯事ならまったくもってやってられない。

プロジェクトが始まる時、顧客はどのようにサービスを考えるのか?

何らかの新製品、新サービスを開始する時、顧客はどのようにサービスを考えるのだろうか?想像だが、トップダウン的なアプローチをとるんじゃないだろうか?つまりマーケティングの情報や流行のキーワードからサービスを想像するんじゃないだろうか?当然聞きかじりの情報が多くなり、キーワード的な説明になりがちになると思われる。例えばクラウド対応とか、AIの技術を取り入れたいとか。

ここで厄介だと思うのは、顧客がサービスの説明をする時に手段まで考えて説明してくることじゃないだろうか?例えば、上記の絵では最初の説明でブランコを説明している。顧客は「木にくくりつけて揺らして遊ぶ」ことを実現したいと考えておりその実現のためにブランコという手段を考えて説明しているんじゃないだろうか?

技術者はどのようにサービスを考えるのか?

反面、技術者はどのようにサービスを考えるのだろうか?はっきりいってサービス自体に興味を示さない人も多いと思う。というのも、技術者は技術的興味からサービスに関わることもできるからだ。例えば、サービスを実現するために汎用的なIFを開発するとか、新しい機械学習の手法を試してみるとか、新しいフレームワークを試してみるとか。サービスを実現するための手段自体が技術者にとってサービス開発に関わる目的になり得ると思う。

そういう視点でみると上記の絵の「プログラマのコード」はプロジェクトについては致命的だが、プログラマの目的は果たしているかもしれない。ここでは、サービス云々より、木にブランコがくくりつけられているだけだが、その事自体に技術的価値があるかもしれないからだ。ただし、プロジェクトとしては限りなく失敗へ向かう気がする。

すり合わせについて

もし、顧客がサービスの説明をした時に機能や手段から入ってきたら危険だ。顧客はおそらく親切のつもりだろうが、逆に本当に必要なものが何なのかを隠してしまっている。その機能や手段がプログラマの技術的興味を揺さぶるものだとなお危険だ。特に、議論がされないままプロジェクトにGOサインがでることになる。そのようなプロジェクトは失敗の確率が上がると思う。やはり必要なのは、最初の段階で本当に必要なものがなにかを見極めることだと思う。.

「ノー」と言えるか?

私が好きな本にCleanCoderという本がある。この本はソフトウェアのプロ意識について書かれている。とてもわかりやすく面白い。

Clean Coder プロフェッショナルプログラマへの道

Clean Coder プロフェッショナルプログラマへの道

どの章も面白いが特に第2章の「「ノー」と言う」が好きだ。この章ではプロとしてノーということの重要さが語られている。この章はCleanCoderの中でも特に面白いと思う。上司と部下のやり取りがミニエピソードで紹介されていてそれがまた面白い。この章に共感を得た私は早速社内でも実践してみた。そして失敗した。

「ノー」と言う

奴隷は「ノー」と言うことを許されていない。労働者は「ノー」と言うことをためらうだろう。だが、プロは「ノー」と言うことを期待されている。実際、優れたマネージャは「ノー」といってもらいたがっている。それ以外に何かを成し遂げる方法はない。

上記は、CleanCoder第二章からの抜粋である。私が特に好きな文章だ。私はここに書かれているようなプロになりたいと思う。そして、ここに書かれているような人たちと仕事がしたいと思う。しかし・・・

「ノー」と言えるか

私は前職で「ノー」と言うことを実践したことがある。結果は失敗だった。上司との中はみるみる悪くなった。プロジェクトは前に進まなくなった。何がいけなかったのか?考えられるのは次の2つだった。

信頼関係
まず一つ考えられるのは、私と上司との間で信頼関係の構築がそこまでできていなかったと思う。私はプロとして振る舞おうとした。しかし、上司は私をプロとしては見ていなかったのだ。私の対立意見は単なる私のわがままと捉えられていたと思う。正直、無理もない話だと思う。プログラマの仕事の成果物は動くソフトウェアになることが多いと思う。これはできる、できないの話になりやすい。十分な信頼関係がない状態で対立意見を出したらどうなるか?それは、技術力不足、人格否定につなげやすい。相手が協力会社なら?納期を引き伸ばし、利益を稼ごうとしているとみられる。相手が新人なら?新人のくせに仕事を選んでるとか思われるのが関の山。技術的に認められ、ある程度の発言力を持たなければ、対立意見を出しても関係が悪化するだけだろう。

スケジューリング
次にスケジューリングのまずさもあった。CleanCoderでは急な顧客でもに対応するためモックアップのログインページを渡すというやり取りがある。ログインページの完成ではなく、ログインすることだけを見せればいいという上司の目的を汲み取り、Eメール送信、パスワード再発行機能の対応を後回しにして、モックアップを提供するというやり取りだ。ここまではよい。似たようなやり取りを私も経験した。問題はそのあとの後回しにした機能である。私はこの機能を実装するスケジューリングが上手くできないことが多かった。ある意味、このやり取りの対応はその場しのぎの絆創膏対応に近い。しかし、このような急場をしのいだら上司はすぐに次の対応をもってくることが多かった。ログインの次はサインアップ、ダッシュボード、マイページetc。私はこのような対応を続けることで未完成の仕掛品を大量に生み出すことが多かった。ここでは、後回しにした機能を実装するスケジューリングを立てる必要がある。

注意

ここで書いていることはあくまで私の経験から基づく考えである。また、CleanCoderの第二章は単に「ノー」と言うことを推奨しているだけの話ではないので悪しからず・・・。

初めてのOSS活動

私がよく使用するOSSにBeegoというものがある。これはGo言語製のWeb Frameworkで非常にシンプルにWEBアプリの作成ができると感じている。語弊があるかもしれないが雰囲気的にはRailsに近いと思う。Beegoについては別の機会に詳しく触れたい。今回はBeegoのCLIツールBeeに対しての話題だ。このツールで初めてOSSプロジェクトのコントリビューターになれた。この記事はその回想録である。

beeについて

beeとはbeegoによるアプリケーション開発を簡単に行えるようにするためのCLIツールである。railsコマンドのようなものと思ってもらえればよい。beeにはLiveReload機能等が備わっておりbeegoでアプリ開発を使って損はないツールだ。

バグを踏む

ある日、beeツールにdockerizeコマンドが追加されたことに気がついた。このコマンドはDockerfileを作成してくれるものだ。これはDockerfileを億劫に感じていた私にとっては願ったりかなったりの機能だった。喜び勇みツールをアップデートした私は早速コマンドを実行した。しかし、問題が起きた。docker build時にエラーになってしまうのである。これには参った。原因を突き止める必要がでてきた。

解決はしたが・・

果たして原因はすぐに分かった。生成されるDockerfileにまずいところがあり、godep install実行時にエラーとなってしまうのである(細かい内容は避ける)。Dockerfileの問題の箇所を修正し再度buildしたら動きだした。ひとまずの問題は去った。しかしである。これはチャンスだった。かねてから私は何かOSS活動に携わりたいと考えていた。しかし、ソースコードを読む気概はなく、新機能の作成も夢のまた夢、リファクタリングも自信なし、ドキュメントを書こうにも文章力に課題があった。そこへ今回のバグである。ある意味願ったりかなったりであった。

コントリビュータに登録された

バグ自体は簡単な修正だった。Dockerfileのテンプレートを修正するだけで良い。1行で終わる。しかし、その後が大変だった。なにせ私はプルリクエスト自体が初めてであった。そもそもやり方がわからない。私は以下のリンク等を参考にし慎重にプルリクエストを書いた。
GithubでOSSのPull Requestを作成してマージしてもらう手順

コード修正は一瞬だったが、とにかくその後の作業に多くの時間を割いた。テストを行いデグレを起こしていないか確認した。コミット前後の差分を確認した。コミットログのわかりやすさや、英文法の誤りがないかは念入りに確認した(ほとんどGoogle翻訳に頼ったが・・・)。もうこれ以上はないほどの確認を行い、恐る恐るプルリクエストを出した。しかし、一瞬のうちにマージされた。少し拍子抜けしたがやはり嬉しく思わずTwitterにつぶやいたほどであった。

まとめ

終わってみればものすごいあっさりしていた。実際にOSSにプルリクエストを送る前はそれは、本当に実力のある一部の人たちにしかできないことだと感じていた。しかし、今回のような簡単なバグフィックスでもOSS活動に携われることを身をもって体験できた(そもそもOSSでバグを踏むこと自体初めての体験だった)。これからもBeegoを使う機会は多い。なので新規の機能等がリリースされたら積極的に使用し、バグフィックスという形からOSS活動を行いたい。

ガルトラルーチン

週間を身につけるということは有意義な人生を送るために必要なことである。それはソーシャルゲームでも同じことが言えるだろう。
例えば、毎日のログインするだけでボーナスポイントは10ポイントもらえるとする。それだけでは僅かな報酬だが、365日続ければ3650ポイントもらえることになる。これはゲームにもよるが約2万円分のポイントになることもある。

毎日のルーチンを決めよう

長くガルトラを楽しむためには、毎日やる習慣を作るのがいいだろう。あらかたのストーリーや、イベントミッション、武器・コスチュームの育成が終わってしまったら毎日やるべきことは以下の3つであろう。

  • ログインボーナス
  • デイリーチャレンジ
  • ログインボーナス

今から順に見ていく。

ログインボーナス
毎日10ジェム、7日目に30ジェムがもらえる報酬だ。忘れないようにかならずもらっておこう。日付けが変わるのは毎日AM0:00だ(現実世界では当たり前だが、ソーシャルゲームでの日付け変更が現実と違うのはたまにある)。

デイリーチャレンジ
出撃回数、アリーナでの戦闘などの7つの条件をこなすことで毎日もらえる報酬だ。重要なのは全てのデイリーチャレンジをこなすと貰える10ジェムだ。これも毎日欠かさず貰おう。また、アリーナで戦闘することで絆ポイントが50もらえる。これを利用すれば毎日絆ガチャの単発が1回引けることになる。懐事情が厳しく石の課金ができない場合は、この絆ガチャを利用してガチャをしたい欲求を満たそう。

親密度アップ
毎日、ショップ「アリーナ」でプレゼントが5個買える。これをキャラに渡すことによって、親密度を上げることができる。これを毎日行おう。親密度を上げることでキャラ毎のエピソードが解放される。全てボイス付きのエピソードだ。また、猫耳装備や鑑賞モードでのポーズなども解放される。ガルトラを楽しむためには必要だ。
5個全てのプレゼントを渡せばだいたい120ポイントほど親密度が上昇する。

私の一日について

私は朝起きたらまずガルトラを起動しログイン報酬をもらう。その後イベントミッション・アリーナでの戦闘をオートでこなしながら軽い運動と朝食を取る。朝食を終えたら絆ガチャを一回引く。最後に、武器とコスチュームを強化する。これでデイリーチャレンジはクリアだ。全部で30分もかからないだろう。私はこれを年始から続けている。ログインボーナスと合わせると代替1200個になる。これは、ジェムショップでの石の値段が1700個9800円ということを考えると代替6000円分になるだろう(もちろん、重要なのはその石でガチャを引きいい武器・コスチュームが引けるかだが・・・)。
ログイン報酬、デイリーチャレンジを無事獲得できたら次はショップでプレゼントを購入しキャラに渡す。渡すのは大抵コスチュームをもっておらずミッションでの親密度アップが困難なキャラだ。そうすることで一日のルーチンは終わりだ。1時間もかからない。

まとめ

ここに、上げたのはあくまで私の例である。例えば、複数のソーシャルゲームを掛け持ちしているのであれば、時間がとれないのであればログインボーナスだけにしても良いと思う。また、アリーナ上位を目指すために、アリーナでの戦闘回数をルーチンに追加してもいいだろう。しかし、あくまでルーチンは毎日の目標として定めるのであって、決してルーチンに縛られるようなことはないようにしよう。あまり頑なにルーチンを守りすぎると柔軟な行動がとれなくなる恐れがあるからだ。大事な約束をソーシャルゲームをしていたせいで破ったりしたら社会的信用は地に落ちてしまうだろう。

beegoにてローカル確認用のファイル配信サーバーを書いてみた

開発中にいつも気にしてしまうことがある。それは開発費である。AWSでEC2のインスタンスを立ち上げればその時から時間ごとに料金が発生するし、ETSを使えば分毎にエンコード料金が発生する。静的ファイルをS3、Cloudfrontにおいているならページアクセスごとに通信料が発生する。これはごく僅かなコストだが費用がかかることには間違いなく、もし動画に修正が入れば前回エンコードした動画は破棄しなければならなくなる。はっきり言って無駄でありできればなくしたいと考えた。

ちりも積もれば・・・

正直いって私はもともとお金に関して気にしすぎる性格である。特にランニングコストに関しては人並み以上に気にしてしまう自覚はある。
ある時、AWSの請求書を見たときのことである。そこではCloudfrontの使用料金が月7ドルとなっていた。正直いって絶望するほど高くはない。しかし、まだ開発中の段階で発生した料金である。仮に1年間毎月の開発費としたら年間8400円。10年続ければ8万4千円だ。これを高いとするか、安いとするかは個人的な感覚ではあるが(おそらく安い方だとおもわれる)私は仮に10年後に8万4千円もらえるのであれば今から対策を考えるのもありだと思う。

自分でローカル確認用のサーバーをたてようと考えた

通信費を軽減するためにローカルで確認するためのファイル配信サーバーを作ることにした。仕様はごく簡単で、S3やCloudfrontのようにURLのパラメータを用いてファイルを返却するだけである。ソースコードは以下のリンクより見ることができる。

Githubのリンク(scrpgil/localfront)

フレームワークにはbeegoを使用した。これは気にって使っているGo言語製のフルスタックなフレームワークであり、簡単なWEB APIをかくのに適している。また静的にファイルを返却するだけならnginxなどでも可能だと思うが、勉強も兼ねて、また今後なにか機能を追加したりすることも考えてbeegoを使用した。

結果的に・・・

思い立って作成してみたがあるとなかなか便利ではある。ファイルをアップロードする手間が省けたし、HLS形式の動画配信もローカルでできる。何より自分で作ったことで動作が把握できてるのがよい。何か追加の機能が欲しくなったときにも追加実装が簡単に行えそうである。正直いって実装にかけた時間はほんのわずかだが思い立って行動してよかったと思っている。