現実的なオブジェクト指向でツラいところ

cassetteの延澤です。
最近、Elixirにハマっている。モダンな言語らしく痒いところに手が届く良い言語だなと感じる。個人としては今まで色々な言語で書いてきて得意な言語はあるけど、好きな言語というのはなかったので良かった。関数型だがモナドを用いないやり方で副作用に対してアプローチしていくというのはすごく面白かった。で、興奮冷めないうちにオブジェクト指向と関数型について比較した内容を書く。Elixirについては書かないw

オブジェクト指向で書くということ

オブジェクト指向で書くことの問題の一つとして状態を持つことが挙げられる。例えば、Aというオブジェクトのaメソッドの中でB, Cのオブジェクトのメソッドが呼ばれていた。A, B, Cというオブジェクトはそれぞれ３つの状態があったとする。すると、aメソッドをUnitテストする場合、3 × 3 × 3の状態の組み合わせになり27パターンのテストをしなければいけなくなる。実際には27パターンの中でもあり得ない組み合わせなどがありもっと少ないが、その見極めをしなければいけない。いや、mockやstubを使えばもっと効率的に出来るという指摘もあるがそれを使うかどうかはまた別の話だ。

状態を上手く管理したいのであれば疎結合に作りカプセル化することである。その上でテストしやすくすることが求められるだろう。その実現としてDIコンテナ・デザインパターンも使用して高いレベルのクラス設計することが重要になっている。事実、オブジェクト指向を前提とした設計を扱う書籍はかなり多い。

オブジェクト指向で書く現実問題

私が考える問題は以下である。

1. 状態の準備
2. クラス設計の高いレベル
3. Web業界の事情

状態の準備

Unitテストを実行する前に多大な準備が必要なケースが多い。上記で書いたようにオブジェクトの状態が特定の状態でないと正しく動かないケース。小さいアプリケーションではそこまで問題ではないが複雑で規模の大きいアプリケーションになると大きな負担となってくる。また、膨大に準備することはテスト実行時間にも影響が出て来る。

クラス設計の高いレベル

状態の準備が大きく必要だが疎結合で作られていないことが多い。そのため、適切な設計をすることが重要になってくる。私も過去に概念分析・UML作成・クラス設計をしてきちんとやった経験もある。そこで感じたのはやっぱり辛いなということだ。そもそも概念分析の必要性やクラス設計の意図を伝えることが大変だった。前提知識が違うため何でそういう意図の設計なのかを伝えるのに時間がかかる。メンバーからすればそこまで複雑な設計にしないといけないのという疑問もあった。また関連する資料も作成したりするのでコストも高かった。正直、設計についてはそこまで辛くないが人に正しく伝えるというところが何だかんだ一番大変。

Web業界の事情

Webのサービスのシステムに本当に高いレベルの設計が必要かどうかが分からない。 それによってどういう影響があるかというと、Webでは設計期間をあまり取らずプログラミング主体なことが多い。設計が弱いため時間が立つと技術負債に陥りやすい。何が言いたいかと言うとオブジェクト指向で複雑な要件をシステムに落とし込むには高度な設計が必要なのに現実は出来ていない。
そのため、3〜4年経ったスタートアップでは技術負債により開発スピードが途端に落ちるケースが多い(この技術負債をどう返したかという記事はよく見かける)。現実問題としてはシステムを一からリライトは難しいのでマイクロサービス化に取り組むことが多い。。

関数型のメリット

上記のことを全て解決してくれる銀の弾丸ではないが関数型を用いることによって参照透過性は得ることが出来る。まあ検索すれば沢山オブジェクト指向と比較した記事があるのでわざわざ言及はしない。主張したいことは設計のテクニックで複雑性を解決するのではなく、言語の機能で解決する方がスマートではないのかということ。

で？関数型言語は普及するの？

しないと思う。明らかに現金よりキャッシュレスでのお会計の方がメリットあるのに中々普及しないのと同じ理由である。ライブラリが少ないなどの問題もあるかもしれないが、人々の意識の方がより根深い問題だと思う。それに、関数型を使える経済的メリットが少ない。関数型言語を使えることで大幅に年収がアップするなら勉強する人も多くなるがそういうわけでもないし全ての問題を解決してくれるわけでもない。

それでも普及させるには

社会全体に普及させるのは困難である。しかし、技術選定として関数型言語オンリーにするアプローチがある。よくサービスによってオブジェクト指向の言語と関数型言語のアプリケーションが混在していることがある。しかしこれだとリソースの効率性から人員をオブジェクト指向と関数型で分業してしまうことがある。大企業であれば別だがスタートアップでは分業はデメリットが大きい。しかも、採用面でも募集がやりにくい。
だから、システム要件に合わせるのではなく本当にやりたいのであれば関数型言語に統一した方が良い。私はサービスが成功するかどうかは技術アーキテクチャと関係ないと感じる。成功するサービスはPHPだろうがJavaだろうが成功する。つまり、Scalaを使おうがElixirを使おうが成功するサービスは成功する。 RubyやPHPなどは扱える人が多く募集しやすいが、反面転職されやすい言語とも言える。そう考えると関数型にオンリーとするのはそこまで悪い選択肢ではない。

2017年度の振り返りと2018年度に向けて

総括

前職を退社して今月でちょうど１年になるので今年度の振り返りと来年度の目標を書く。 結果で言えば技術は大きく飛躍した。しかし、本来自分がやろうと考えていたことに関しては色々と見直さなければならない。来年度も今年度の延長線上で進めていくのは何とも面白くないので見直すところは沢山ある。

技術が大きく飛躍した

まず、技術について。前職ではとにかく技術負債との戦いがメインだった。今あるシステムを安全に運用して新しいものに作り変えていくことが主。そのためマネジメントや設計について深く勉強することが多かった。簡単に言えば技術で物事を解決していくのではなく、人やプロセスで解決することが多かった。
しかし、今年度は言語で言えばRuby、Python、JavaScriptを主に使用することが多かった(前年はPHPオンリーでしかも5.2を使っていた…)。特にJavaScriptは後半になってからよく書く機会が増えいった。そのおかげでクライアントサイド全般についてかなり詳しくなれたのは大きな収穫だった。また、JavaScriptは関数型言語に分類されないが、関数型っぽく書くことが出来るため関数型の書き方について何年か越しでついて大きく理解することが出来た。
インフラ面においてもDockerを使用する環境が多かったので便利さを大いに実感した。今後環境構築においてはDockerを利用して構築することにする。なんだか前職をディスってしまう書き方だがマネジメントの経験をして本当に良かったと実感はしている(スタートアップでは中々経験出来ないので個人的にマネジメントは自分の強みとなっている)

ビジネスにはいまいちだった

これは本当に反省。やっぱり思い通りにならなかった。
別に諦めてしまった訳ではないがテスト管理ツールの作成があと一歩のところでずっと足踏みしている。反省としては以下。

• 1カ月で作れる規模にすれば良かった
• SPAを多用したこと
• 外部要因として利用するシーンと接しなくなったこと

まず1カ月で作れる規模にすればよかったのは本当に同意でモチベーションの管理が難しくなった。一応機能を削ったMVPを設定して作ったのだがもっとバッファを持たせれば良かった。またSPAを多用したことによって単純に作業量が倍になった。
特にサーバサイドは初挑戦のPython・Djangoの組み合わせでフロントはVue.jsを使った。思いのほかDjangoの学習量もキツかった上にゼロからモダンなJavaScriptの環境で作業したので大きく時間がかかった。(ただ、このおかげでフロント技術について一気に詳しくなったので経験には繋がったが…)
トドメはスタートアップで仕事しているとテスト管理ツールを使うイメージがあまり湧かなかった。。前回記事を書いたようにしっかりテストをするというよりも、テストコードを書いて重要なフローを検査すれば大きな問題にはならなかった。
反対に成功した面としては企画や仕様の検討、マークアップは事前にやっておくことで開発に集中することを実感したのでこれは上手くいったと感じている。

今年度の目標

去年はフリーランスの常駐の仕事がメインだったので常駐以外の分野に進出したい。今の現場は本当に恵まれていて楽しいが将来への投資も必要だと感じている。特に今まではWebメインの開発が主だったので幅を広げたいと考えている。
戦略としてはニッチなスキルに投資をするのではなく、大きく需要のあるスキルの掛け合わせで価値を高めていきたい。

ブロックチェーン分野に携わる

今年はブロックチェーンについての仕事が出来たらと考えている。今年やりたいことの優先順位の中では一番高い。何故やるのかは詳細にここでは書かないが要するに風上に乗る戦略。今後、どういうサービスが流行るのかは残念ながら自分はあんまり分からない。しかし、ブロックチェーンの基礎を知っていれば自分の方向性が見えた時に舵を切りやすい。

クライアントの分野に引き続きやる

今年はフロントでReact, Vue.jsに携わることが出来たので来年度も仕事で携わりスキルとして固めたいと考えている。本当はiOSやAndroidのどちらかやりたいのだがブロックチェーン分野を優先してやりたいのでリソースとしてキツい。。(誰か仕様を考えてくれればやってもいいのだが…)
ただ、アプリは現状需要が大きいが同時に経験年数による参入障壁も高い。上手くいけば安定した仕事には繋がりやすいので投資はしたい。

ウォーターフォール・アジャイル以外の第三の道

cassetteの延澤です。 今回は「ウォーターフォール・アジャイル以外の第三の道」について書いていきたいと考えてます。ウォーターフォールとアジャイルのメリデメを簡単に紹介して、最後に私の考えを載せております。
ここでアジャイルについて言及してますが、本来のアジャイルとは違う私の経験ベースの内容に一部なっております。なので、アジャイル自身について知りたい方は別の記事を参考にした方が良いです。

スタートアップにアジャイルが都合が良かったわけ

私が大手企業からスタートアップに行って驚いたのは、あまりドキュメントを残さないことでした。開発における仕様書は、デザインとこうやりたい企画書レベルのドキュメントのみ。最悪、企画書さえもなく口頭で伝えられることも多いです。そのため、開発者は以下の能力を求められることが多かったです。

1. 自分で仕様を考え、それを納得させる力
2. 素早くコードを書ける力
3. テストコードが書ける

自分で仕様を考え、それを納得させる力

開発のスピードで一番重要なのは手戻りを少なくすることです。ウォーターフォール・アジャイル問わずそこは同じです。しかし、アプローチが違います。ウォーターフォールでは要件定義に重きを置きます。つまり、開発着手前に決めるべきことは決めることが一番の肝になります。反対にアジャイルでは開発着手前に細部まで詰めません。細部に関しては開発者がよしなに開発をします。えっそれでいいの？と思われるかもしれませんが開発者自身が仕様をコントロール出来る権限があるためそれが実現できます。もし、仮に権限がなかったとしてもそれを認めさせるように行動するべきです。こう考えると最終的な権限がない受託開発の場合アジャイルでやることが根本的に難しくなります。逆に事業会社であるスタートアップではこのやり方がコミュニケーションコストも含めてコストを下げるベストな形になります。
ここではやるべきことを精確にやるのが得意な人よりも、自分で提案してどんどん進めるのが得意な人の方が相性良いです。

素早くコードを書ける力

とにかく素早く仮説検証し実装していくためスタートアップでは素早く機能を作れることが重要です。何故、Ruby on Railsというフレームワークがスタートアップと相性が良いのかはそれが理由です。素早く生産性が高いため採用されているのです。(情報が多いなどの理由もあります。ただ、個人的にRailsはあまり好きなフレームワークではないです。。)
そもそも開発者が仕様を考えるぐらいですから、ある意味適当に作れるぐらいが丁度良いのです。仕様通りじゃなくて本当にいいのかという疑問も勿論あります。ただ、事業の目的は仕様通りに作ることではありません。ユーザーに価値を届けることが目的だからです。仕様通りにバグがない精確なシステムだったとしても、使いにくければ誰も使いません。

テストコードが書ける

時間も人がいないスタートアップでもテストコードはしっかり書いてあるケースは多いです。何故、時間も人もいないのに書くのか？
それはテストコードがドキュメントの代わりだからです。スタートアップだとしても仕様は複雑だったりします。また、仕様に詳しい人も多くなく、その人自身も忙しいです。そのため、新しく来る人は手探りの状態で開発を行います。ここでテストコードが威力を発揮します。追加したコードによってテストが落ちることで以前の仕様と整合性を保ちながら開発が出来るのです。

ウォーターフォール・アジャイルの限界

ウォーターフォールの限界の一つとして即ち事前に全てドキュメントに落とすこと、ドキュメントを常に最新状態に保つことが難しいです。そこで、色々とルールを決めたりダブルチェック・レビュー会などの人海戦術で乗り切ろうとしますが非効率であることは否めません。
ではアジャイルにも全く問題がないかと言えばそうではありません。現実的に全ての仕様をテストコードに落とし込むのは容易ではありません。例えば、E2Eテストを全てに適応しようとすると今度はテストコードの保守コストが高くつきます。また、今後のFintechやIOTなどのミッションクリティカルなサービスやバージョンアップが難しいサービスに対して今まで通りのスタートアップのアジャイルのやり方が正しいのかは疑問が残るところです。

解決策

ここからは私自身の考えです。ウォーターフォール・アジャイルというようにどのように開発を効率良くするかというよりも、そもそも発想を変えて開発する範囲を狭めていけば良いのではないかと考えてます。例えば、画像配信のCloudinaryや認証のAWS Cognitoなどの外部サービスを活用するのです。本当に必要なビジネスロジックの開発は行い、セキュリティリスクが高く保守コストが高いものは外部化するのです。メリットは以下です。

• 少ない人数で高速に開発できるようになる
• テスト範囲を切り分けできる
• セキュリティを専門化に委託することができる

エンジニアの人数が多ければ必然的に管理することが難しくなります。また、現在のエンジニア不足の問題もある程度解決できます。次にテスト範囲でもテストコードで担保が難しいシステムテストの範囲を狭めることが出来ます。セキュリティに関しても、今後は専門のサービスに任せる方がセキュリティエンジニアを沢山雇うよりもコストが低く、結果的にセキュリティも高まると考えてます。
ウォーターフォール・アジャイルをどちらを選択するのかは、ビジネスモデルにも影響されるため結論は出ません。ただ、ビジネスのコアとは関係ないシステムは外部に放出してコアとなる箇所に力を注ぐべきだと考えてます。
そうすればウォーターフォールとアジャイルのいいとこ取りも実現できるのではないかと考えてます。

補足

何故、スタートアップは急激な成長を求めるのかという疑問はありませんか？
そもそも、しっかりシステムを作ればいいじゃないのかと指摘もあります。でも、働いて思ったのですがこれ難しいんです。
まずスタートアップで働く人は定年まで働こうなんて誰も考えていないんですよ。じゃあ、何を求めているのかというと事業やその人自身のスキルも含めての急激な成長です。その中で成長に伴わない技術選択や施策を実行する決断が難しいし、それで人は中々ついてこれないのです。
ただ、モラルを著しく欠いたシステム開発は大手・スタートアップ問わず止めるべきなのは事実です。

テスト合宿に参加した

cassetteの延澤です！ 本日はテスト関連のイベントに泊まり込みで参加した感想とそこから得た考えを書きます。

どんなイベント

以下のイベントに参加しました！
WACATE2017 冬 ～すべてがTになる～ 開催概要 - WACATE （ソフトウェアテストワークショップ）

Web、パッケージ、エンタープライズ、組み込みのQAエンジニアが主に参加していました。しかし、私のような開発側も2〜3割参加しているので開発が参加しにくいという雰囲気ではなかったです。

何で参加したの？

今、テスト管理ツールを作っていてそのヒントになればと考えたのがきっかけです。また、QAエンジニア方とは普段接しないのでお話を聞いてみてどのように普段仕事をして、どのように考えているのかを知りたかったです。

ここから感想

QAエンジニアの人の熱気がすごかったです。勿論、泊まり込みなので元々やる気がある人が集まりやすいという特徴はあるのですが、夜中まで真剣に議論をしていて単純に圧倒されました。

テスト自動化について

私自身の考えだと自動化に興味があるのかと考えてましたが、どちらかというと開発側の人間の方が現時点では興味がある傾向が高いと感じました。勿論、社内の自動化チームの立ち上げメンバーになっていたりと関心自体はあるのですが活発に取り組んでいるという印象は受けませんでした。 また、テスト自動化という言葉自体もビッグワードになっていると考えていて、ユニットテストやE2EテストやCIなど多くのことが一つにまとめられてしまっているので実はこの部分は出来ているということ個別であるのかもしれません。

さらにリリース頻度が高頻度ではない場合、自動化するメリットをそこまで感じていない(テスト期間をがっつり取る)のも理由の一つです。Webやスマートフォンアプリなどは高頻度にアップデートするため自動化に自然と関心を持ちますが、パッケージシステムなどそこまでアップデート頻度が高くないのであればいかにテスト計画をしてしっかり製品を磨くのかということに関心を持ちがちになってます。

今後のQAエンジニアに求められること

フロントエンドエンジニアとサーバサイドエンジニアの関係性でも感じたのですが、QAエンジニアと開発の両方知見のある人が少ないです。特に、企業全体のテスト戦略から構築できる人と考えるとそこら辺のCTOよりももっと数は少ないです。スタートアップ時期はテストについてそこまで神経を尖らせる必要はありませんが、上場目前のシステムやミッションクリティカルなシステム(フィンテックなど)になるとテストだけで大幅な時間が取られてます。何故なら、今までの機能と整合性を保ちながら機能追加するのは新規にシステムを作るよりも難しい場合がよくあるからです。機能追加すればするほど今までの機能が壊れてないという保証をしなければならないからです。
そういった時に自社では自動テストではどこまで保証して、手動テストではどこまで保証するか、もしくはプロジェクトのどの段階からシステムの正当性を保証していくかなどは企業ごとそれぞれの事情を考慮しなければなりません。そうなると、やはりテストと開発両方知っておく必要があるし、また会社のビジネスモデルも意識しなければいけません。

まとめ

個人的な考えですがテストと開発というのを別々に切り出す必要はないと考えてます。よくテストコードを書く時間がないと言われてますが、テストコードを書かないから時間がなくなるのです。

サーバサイドの人間が最新のフロントエンドに入門した

cassetteの延澤です！

今回は「サーバサイドの人間が最新のフロントエンドに入門する」について書いていきます。 私自身普段はサーバサイドのプログラミングがメインです。しかし、最近事情がありフロントエンドの開発もしております。
元々、マークアップエンジニアの仕事もしていたのでHTML・CSS・jQuery程度は書けました。しかし、進化の激しいフロントエンドにどっぷり浸かるよりも他の分野を優先してきました。ただ、やっと重い腰を上げて(ざっくり言うと仕方なく)フロントエンドやるかーぐらい気持ちで挑みました。
そうして、改めて勉強してみてフロントエンドの現状のベース情報が少ないなと感じましたので、今回ブログにまとめました。

対象ユーザー

以下に書いてある内容はプログラミング初心者には結構難しい内容です。
プログラミング経験2年目以降ぐらいで、そろそろJavascriptを勉強しようかと考えている人に向けて書いてあります。また、JavaScriptはエコシステムは進化が激しいので、2017年12月当時の内容になります。

HTML・CSSをまずきっちりやる。そしてタスクランナー

まず、HTMLとCSSを使ってしっかりマークアップが出来るようにしておきましょう。ここを飛ばすと流行りのReact・Vueのライブラリのベースとなっているコンポーネントについての設計が出来ません。また、最終的なアウトプットが出来ません。
ここではセマンティックなマークアップなどは現状意識しなくて大丈夫です。但し、CSSはSASS・SCSSなどで記述するようにしましょう。Gulpなどを使ってSASS・SCSSをコンパイルしてCSSを吐き出す訓練を今のうちにしてます。ここで意識するのはGulpが何を解決するツールなのか同時に理解しておくことです。

フロントサイドJavaScriptとサーバサイドJavaScriptについて

たぶん、フロントエンドのエンジニアの人は当たり前すぎて特に意識していないのかもしれませんが、ブラウザで使用するJavaScriptとサーバサイドのJavaScirpt(Node.js)が違うことの言及があまりされていないです。どういうこと？と思われるかもしれませんが、例えばDOMなどを操作するAPIはサーバサイドだと不要だし、MySQLを操作するAPIはフロントエンドでは不要です。そして、何が分かりづらいかと言うとサーバサイド(Node.js)でのプログラムの記述とフロントエンドのプログラムの記述が微妙に違っているということです。分かりやすいのが、モジュール管理で使用するrequireでフロントエンドでは使用出来ません。しかし、パッケージ管理のnpmなどは共通で使用しています。互いに重なり合っている箇所もあるが、重なっていない箇所もあるということです。全体的にJavaScriptの各ツールは「互いに重なり合っている箇所もあるが、重なっていない箇所もある」ことが多く混乱します。

もうJavaScriptはコンパイル言語だった

はい、最新のJavaScriptはもう真面目にやろうとすると簡単な動的言語ではもはやありません。まず先程のWebpackの役割はファイルの依存関係を解決して1ファイルにまとめることが主な役割です。ここでややこしいのがどうせ依存関係を解決してJSを1ファイルにまとめるなら、一緒にトランスコンパイルもしちゃおうぜというBabelの存在です。サーバサイド側で分かりやすくいうと、Python3系で記述したのをPython2系の記述に変換(トランスコンパイル)してあげることです。つまり、JSの複数あるファイルを1ファイルにまとめつつ、同時にトランスコンパイルもします。
また、どうせ最後にWebpackで1ファイルにまとめる処理をするなら、素のJavaScriptを書くよりも、型付けがあるTypeScriptで記述した方が良いいじゃねという発想もあります。
そのため、現状の開発はWebpackでファイルの更新をwatchしながら差分コンパイルするような開発スタイルになります。

サーバサイドのMVCとフロントサイドのMVCは違うことの理解

この内容を真面目に書こうとすると、これだけで膨大な文字量になってしまいます。ここで言いたいのは一旦サーバサイドのMVCは忘れましょう。
MVVMやBackborn.jsが必要になった理由を勉強すると分かってきます。

最新のEcmaScriptを学ぶ

JavaScriptの情報自体は膨大な量があり、何を勉強すればいいのか分かりにくいです。特に入門記事などは大体古い構文の記述になっています。また、Javascriptのクセの強いところは糖衣構文が多すぎます。さらにTypeScriptなどのスーパーセットもあるため、ますます王道が分かりにくくなっております。
なので、最新のJavaScriptの構文(ES6)からまず勉強しましょう。古い構文を見つけたら最新のやり方ではどうやって記述すればいいのかを意識して書けば自然と文法は理解できていきます。 JavaScriptの文法は以下の本でだいたい理解できます。

初めてのJavaScript 第3版 ―ES2015以降の最新ウェブ開発

まとめというか雑記

JavaScriptのことを書こうとするとあれもこれも沢山書くことが多くなります。つまり、それだけ勉強することが多いです…
例えば他にも、コンポーネント・非同期処理・イベント駆動・関数型・リアクティブプログラミングなど重量級のテーマが盛りだくさんです…
ただ、それだけサーバサイドと違って新しい概念が次々に起こっているのも事実です。もし、常にプログラミングの最前線にいたいならJavaScriptを学ぶのが良い選択です。それはいくつかの言語に関わってきた、私の感想です。何でそういう感想になるのかというと、サーバサイドで例えばScalaなどの非同期でプログラミングするのが大規模システムや広告システムではない限りそこまでビジネスメリットを感じないからです(個人的には書きたいです)。反対に、JavaScriptの方が開発の小回りが効きやすいので一部導入はサーバサイドに比べて比較的簡単な印象を受けました。 最近、プログラミングで刺激を受けることが少なくなってきましたが、改めて面白いなと認識できる良い経験になりました。入門したてて間違っている箇所や印象論あると思いますが、察して下さい。今回、書ききれない内容もありましたのでまた後日書ければと考えてます。

WEB開発したいならUbuntuを使う！

cassetteの延澤です。

今日は環境構築についてお話をしたいと思います。 とくにこれからプログラミングしたいと考えている方向きの内容になります！

以前、書いた通り環境構築を習ってしまえば初期のの学習コストは恐ろしく減ります。
そこで私が効果的だったコツを紹介します。

PC・サーバーの目的とは

まずPCとサーバーの目的の違いを知ることから始めましょう。
PCは基本的に自分一人で使う目的のコンピュータです。例えば、家のPCを家族で共有することはあっても、みんなで同時に使用したりはしません。 ここで重要なのは同時にという単語です。
反対にサーバーとはみんなで同時に使うコンピュータです。ここが非常に大きな違いです。そして、この違いを覚えておいて下さい。

WindowsやMacでプログラミングをするということ

プログラミングをしようと思ったなら、手元にあるWindowsやMacのPCでプログラミングしようと思うのが普通です。
ここで重要なのは何を作るかです。例えば、iPhoneアプリやAndroidアプリを作るのであればそこまで問題はありません。何故ならそのアプリは基本的に一人で遊ぶものだからです。一つのLineアプリを家族で共有して使う人はほとんどいないでしょう。 反対にWebサービスはみんなが使う想定のです。例えば、Amazonや楽天でも今この瞬間に自分しかアクセスしていないということはありえません。

結論を言ってしまうと、OSには得意・不得意があってWindowsやMacからWebアプリを作るのはさほど向いてません(MacはWindowsに比べればマシですが…)
それは上記で書いた通り目的が違うからです。OSの目的が違うため、OSの上で動くアプリにも得意・不得意があるのです。 Ruby on RailsやLaravelといったフレームワークも多くの人からアクセスを想定しているため、下記のUbuntuで環境構築をするほうが楽です。因みに、最近の流行であるDockerもLinux環境で構築した方がメリットが大きいです！

Ubuntuを使う

UbuntuとはLinuxをベースとした最も人気のあるOSです。Linuxとはサーバー向けの無償のOSです。 そして、Ubuntuの良さはデスクトップ環境が安定していることです。要するにWindowsみたいにマウスでも動かすのも可能です。 さらに、Google ChromeやGoogle 日本語入力も使えるのでかなり使い勝手もいいです。

例えば、Laravelの環境構築をしたいならば、PHP、Apache、MySQLなどのミドルウエアをインストールすればパッケージ管理のapt-getでインストールしていけば構築できると思います。ここで重要なのは最悪ミスればOSの初期化をすれば良いということです。WindowsやMacなどを初期化するのは気が引けますが、Ubuntuなどは積極的に初期化して構築しても大丈夫です。ただ、余っているPCにインストールすることをおすすめします。普段、自分で一番使っているPCにインストールすると他の作業が捗らなくなるからです。

お金で解決する

環境構築問わずお金で解決出来る問題はお金で解決した方が良いと思います。先程、余ったPCも用意することもそうですが、お金で解決出来ることは開発する上で少ないです。だからこそ、お金で解決出来ることはお金で解決しましょう。ネットにはお金をかけないでやる方法がいくつも載っていますがそれらを調べていると時間が足りなくなります。参考書も買ったとしても、全部読むのではなく目的に沿った必要な箇所を重点的に読む方がいいです。

最後に

伝えたいメッセージとして、もしWebアプリを作りたいのであれば、Linux環境に構築していくのがトータルコストとしては安いです。実際に公開して使うことになると、CentOSやUbuntuの環境で動かすからです。インストールが分からない場合は、WEBで検索していくよりも下記の本などを参考にインストールするのが簡単です。

今すぐ使えるUbuntu入門ガイド Linuxをはじめよう

Pythonが人気になっている理由

 cassetteの延澤です！

今回、pythonが何故注目されてきているのかについて書いていきます。

まず、以下の記事をご覧下さい。

www.publickey1.jp

pythonが人気言語の1位になっております。以前はランキングに対して私はそこまで興味を惹かれませんでした。しかし、pythonが首位になったことは大きな意味があると今回ばかりは感じてしまいました。

何故、今回注目したのか？

それは、データを扱うことがより当たり前になってきたからです(めちゃくちゃ今更です…)

ここで、「はいはい、ディープラーニング・ビックデータね。オレにはあんまり関係ない分野ね」という方はちょっと待って下さい。

事実、データサイエンティストでもない限りこれらのガチの機械学習に業務で関わる機会は確かに誰でもあるわけではありません。

ただ、PythonのPandasなどを使ったデータ分析についてはもう既に一般的なエンジニアにとって近い領域になっております。なぜ、データ分析の当たり前になってきたのかについて2点書いていきます。

理由1：企画結果を数値で検証できる

今まで私は沢山のサービスの企画をシステムとして構築してきました。

しかし、毎回どんな施策もヒットしていたというと…そんなこともありませんでした。

肌感覚で言うと２割ぐらい施策がまあ上手くいったかなという感じです。恐らく、多くの人が同じ感想を持つのではないでしょうか。

何を言いたいかというと、そもそも企画した内容ってそんなに当たらないことが多いです。しかし、良い企画もダメだった企画も数値として実施前と実施後にきちんと計測しておければ、次回の仮説検証を繰り返すデータとしてなるからです。

今までは一部の大手企業のみが大量のデータを保持し分析基盤を持っておりましたが、今ではクラウドを活用すれば比較的安価に分析作業をすることが可能になってきました。

データ分析メリット2：調査コスト削減

今、フリーランスになってサービスを企画する立場になって思ったのは調査に意外と時間がかかることに気づきました。。こういうデータが欲しいと思っても中々見つからなかったり、調べるのに時間がかかったり。しかも調べた結果、やっぱりダメだったよねとなった瞬間にはめちゃくちゃ疲れます(決して無駄ではないのですが…)

また、エンジニアに調査を頼むケースでもコミュニケーションコスト含めて高くついてしまいます(しかも、調査嫌がるし…)

つまり、調査しやすい環境があるということは企画者とエンジニア両方にメリットがあります。

データ分析の最終的なメリット

 一言で言うと意思決定が早くなり、効果の高い企画を実行出来るからです。データを積み上げていかないと、どこまでも企画にムラがあり余計な企画をしてしまうリスクがあります。余計な企画がブランディングの毀損やユーザーの混乱になるとむしろマイナスになってしまいます。

プロダクトを初期の頃はデータ分析よりも機能を作っていくことの方が望ましいですが、効果的な施策を実施するステージならば分析することが必要になってくるのではないでしょうか。そこで、分析に強いPythonを予め採用しておくことでスムーズに分析する環境への移行が出来ます。