『あ～、このルーチンワーク、自動化できないかなぁ』
そんなことを考えたことはありませんか？
どんな作業においても言えることですが、ルーチンワークは積極的に自動化していきましょう。そして自動化とは人を使うのではなく、まず先にプログラム、コンピュータでできないかを考えることです。
その理由はいたって簡単、プログラム、ツールは年中無休で働いてくれるし、ランニングコストがほぼゼロだからです。これが人だとしょっちゅう休むしランニングコストがかけた時間の分だけかかります。
ツールの開発というのはランサーズやクラウドワークスを利用することが多いでしょう。フリーランスのシステムエンジニア・プログラマなんかも仕事が豊富なので集まっています。
しかし、エンジニアに対して、
- こんなことがしたい！
- こういうの作って！
と伝えるとたいてい変なものが出来上がるし、変なものができても『仕様です。修正するには追加料金が必要となります。』と言われたりします。
今回は、ランサーズやクラウドワークスでツールの開発依頼をするときに大切なことをまとめてみます。
ツール開発でやるべきこと
1.入力と出力を明確にする
これは以前の記事にも書いたことなのですが、ツールの開発を依頼するのであれば、入力と出力を明確にしましょう。
- 入力が明確になっている。
- 出力が明確になっている。
- エンジニアは基本的に『入力 × 変換 = 出力』で考えている。
- ゆえに、入力と出力が明確であれば、変換(やるべきこと)が見えてくる。
当ブログで公開しているAsinStockerで例えるならば、
- 入力がASIN
- 出力がresultファイル
といった具合です。つまり、要求を明確にするということです。
2.速度といった目に見えない仕様を明確にする
入力と出力がわかってやるべきことがわかった。さあツール開発の始まりだ！…と思うのは少しだけ早いです。
期待する結果が得られたとしても、その過程も大切です。過程とはたとえば、
- 処理速度
- CPU・メモリ使用量といったPCへの負荷
などなど。たとえば、期待する結果は出てくるけど1ASINに1分とかかかってたら使い物にならないですよね。あまりにもツールが重たすぎて他の作業が一切できませんってなったら逆に効率ダウンですよね。
こういった目に見えない仕様も明確にしていきましょう。
3.インタフェースを明確にする
インタフェース、聞き慣れない言葉だと思います。
インタフェースって何？
開発者としては、
- どんな画面にするのか？
- 画面上からどんな操作ができるのか？
ということも知りたいです。たとえば、当ブログで公開しているAsinStockerでは、アプリ上にAmazonのwebページから商品画像をポイポイと投げ込むことでASINがストックできる作りになっています。
これがいわゆる『インタフェース』であり、『インタフェース設計』なんです。
4.こういうときはどうする？という例外も明確にする
細かい話をしていくと、ツールを開発した時、ツール自身が扱うファイルというものがあります。
それを手動で開いた状態でツール起動したら
- どういうエラー画面を出しますか？
- どういう振る舞いをさせますか？
ということを決めます。単純にポップアップを出すだけで処理続行か、処理中断か、などなど。
あまりにも細かくて数が多くなるので、大まかに下記の２つがあることをイメージしておくと良いです。
- 安全動作(フェールセーフ)
- 縮退運転(フォールバック)
要は、間違ったら困るんでシステム止めてね、なのか、システム止まるのだけは困るんで機能制限してもいいから動いていて欲しい、なのか、どっちかということです。
5.どこまでやって、どこまではやらなくていいのか、作業範囲を明確にする
下記の記事でも書いたことなのですが、作業範囲を明確にするということは大切です。
わたし自身、今まで開発業務をやってきて一番モメてきたのが作業範囲についてです。
- どこまでやって？
- どこまではやらないのか？
最悪なのが、お互い『そっちがやることだと思っていた』といって作業が漏れるパターンですね。野球で言うならお見合いってやつです。
6.『自分がやること』は何？外注=作業なしと思うなよ！？
ツールを外注に依頼するってなると、なんとなく作業を丸投げしたというか全部やってくれるようなイメージになってしまいます。
よく外注で完全自動化とか言われていますが、そんなことはないと思います。必ず外注の管理もあるし、細かい作業の説明、仕様決めが存在します。
自分がやることは何か？というより、作業を発注する側にも必ず仕事があるんだよ、という意識を持っていてね、ということです。
7.納期と成果物を明確にする
開発に限らず、どんなお仕事でも納期があります。
- いつまでに。
- 誰が。
- 何を作るのか。
ということを明確にしましょう。
8.ソースコードは回収せよ！著作権のありかを明確にする
さて、ここからがわたし的に超重要なお話です。
ツールの実体は英数記号の羅列であるソースコードです。
このソースコードさえあれば、同じものをいくつでも複製できるし、さらにワンランク上のツールに改造することもできます。
最初に特に取り決めがなければ、著作権は製作者に帰属します。あなたのアイデアで、あなたが作業を発注したとしても、開発者が著作権を所有します。
これの何がまずいのかというと、たとえばこういうことができてしまうんです。
- 2台目以降のPCにインストールする場合は追加ライセンス料50,000円になります。
- 追加機能は1機能で100,000円になります。
つまり、ソースコードや著作権を相手に握られているということは、そのツールの命を握られているのと同じってことです。信頼できる企業であれば別に気にしなくていいのですが、ランサーズやクラウドワークスのように個人とのやり取りは信頼性が少し低いので、できればソースコードは回収しておきたいです。
ソースコード・著作権さえこちらあれば、ライセンス料なんて取られずにいくつでも同じものが作れてしまうんですよ。別の人にまかせることもできます。
対策としては下記があります。
- 外注に発注するのではなく、自社の一時的なスタッフとして雇って開発してもらう。
- 納品物にソースコードを含める。
- ソースコードはプロジェクト完了後、こちらで管理・メンテすると伝える。
上記の場合、著作権はあなたに帰属します。本当にかしこい人は外注に発注するのではなく、期間限定で外注を雇っているはずです。でもこれを知っている人は少ないでしょうねぇ～…。
ただし、上記のような条件ではやってくれないエンジニアもいるはずです。要は、ツールを自分のものにして荒稼ぎしたいからです。
なぜなら、わたしだったら絶対にそうするからです！！
足元見てくるようなエンジニアに依存しないような体制にしましょうってことです。足元見てくるかどうかは、一度開発が完了したあとにわかることです。最初の時点では見抜けません。
9.簡単でもいい。『モジュール関連図』をもらう
ソースコードの回収の有無に関わらず、『モジュール関連図』を作成するように伝えておき、もらうようにしましょう。
モジュール関連図って何？
なぜこれが必要かというと…わたしもついやってしまいがちですが、会社みたいにガッチガチにしばられていないと設計図を書かずに頭の中の構想だけでプログラミングを始めてしまうことがあります。
これをやると、あとでメンテナンスしようとしたときに、どこになんの処理があるかわからなくなってしまうんです。そうすると作業工数は増えるし、コストも増えてしまいます。
可能であればしっかり設計書を作ってもらうべきですが、規模が小さいようなものでも最低限、モジュール関連図だけは作ってもらいましょう。
たとえば、当ブログのAsinStockerだとこんな感じになっています。(簡易なので許して！)
参考までに、AsinStockerは、画面、Amazonからのデータ取得、結果出力、の3層構造になっています。各モジュールは専用のデータ受け渡しのお皿(先入れ先出しのキュー)を用意し、モジュールの結合度を弱くしています。結合度が低いほど、1箇所変更したらあっちもこっちも直さなきゃ、という自体が少なくなる。
まとめ
- 細かいことまでしっかり明確に。
- 外注化=作業なしになるわけじゃない。
- ソースコードと著作権は回収しておきたい。
海外のシステムエンジニアは非常に年収が高いのですが、その理由は『自分にしかできない開発作業』にしてしまうから、というのが理由の1つです。
海外のソースコードを見ると、とても読めたものじゃありません。とにかく汚い。たとえるなら国語の教科書の中にギャルの会話が入っているようなイメージ。
こうやって他人がメンテナンスできないような仕組みにすることで、
というように脅迫できちゃうんです。
こういったことが、あなたが発注したツールで起こり得るかもしれないってことです。