2018-03-13

会社に夢を語れる人が消えた日

「なぜ今これを開発しているのか」というモヤモヤが出てきてしまったので雑に書いてみる。うまくはまとめられないので察してほしい。

※想定しているのは割と小規模でメンバーも20人もいないくらいの「ガンガン行くゼェ！」みたいなときプロダクトオーナーなどがいれば解決しそうではある。

複数のサービスを運営して収益を得ている会社は多いと思う。運営しているということは、絶対サービスを企画し立ち上げた人がいるわけだ。最初のサービスの企画者はFounderパターンは多いと思う。それ以降のサービスは、中途入社の熱量がある社員だったりする。

熱量のある企画者は何かor誰かしらの「課題」を解決しようとしてサービスを企画し立ち上げる。*1

サービスを立ち上げ初期はチームメンバーも少なく、企画者の「課題」が共有されおり、みんなその「課題」どのような方法を取れば、一番解決できるのかを話し合い、ユーザーにヒアリングし機能に落とし込んで実装する。みんなが大なり小なりサービスを考えて、自分の仕事の質をあげようとしている。この繰り返しを行うことで、初期の想定ユーザー課題を解決しつつ、様々な知見が溜まりサービスのさらなる可能性を広げていく。

サービスがフェーズを順調に登って行くと、それに関わる人（社員）ももちろん増加傾向になる。人が増えて行くことはとても良いことでリソースが増えるので課題解決のサイクルの「質」x「量(回数)」のどちらも向上する。しかし人が増えると企画者の熱量や思いをうまく伝播させ、同じベクトルを向いて仕事できる人が少なくなってしまう*2。まだこの時点だと取り戻せる。やりようはいくらでもある。本当に

最悪のパターンの企画者が退職している場合、最初の熱量・課題を言葉や行動にすらできない。そうすると自分の仕事が何につながっているのかがわからなくなってしまう。「ユーザーの課題を解決しようとした小規模のサービス」と「仕事をする人」がそこに残る。何か行き詰まったときに「微成功しているサービスのコンテンツ」や「先人たちの思い」みたいなのがあってピボットもうまく決まらない。そうするともうサービスとして停滞となる。うまくいかすことも殺すこともできない。変にマネタイズしようとして広告をいれたり、KGIがないKPIの数字改善を行い始める。

何をしようとしてたんだっけ?の無限ループ。終焉。サービスをいい意味で破壊してくれる人が来るのを待つだけである。

おやすみ

*1:利益が1番で「儲かる」ところにサービスを打つ場合も多々あると思っている

*2:振られた仕事を全うしていれば良いの考えの人は別世界の人

2017-12-25

エンジニアのドキュメント作成について理解はしているが手が動かない現象

Document作成について自分が現在思うことを書いてみる。

Documentといっても種類がたくさんある。

手順書
設計書
メモ(?)バッチとか一覧が書いてあるやつ仕様書に近い

documentを書くべき理由は自然と理解している人は多くいると思う。なくてもやっていけるが、あれば物事がスムーズに進む場合がある。

例えば

環境構築手順
インフラ構成図
よく使う便利コマンド一覧とかとか

ドキュメントの有無で作業のキャッチアップまでがとても早くなり次の行動への生産性が上がる。入れ替わりの激しい所であれば再度同じ質問などを繰り返し聴かれなくても済んだりもする。
理解はしているがマジで書きたくない。でも書かなきゃな〜と思っている人に向けて感想を書いている。

自分が重要と思ったところは「書くべきところを決める」「書き始め方」「どう継続させるか/周りを巻き込むか」だと思う。

書くべきところを決める

さすがに全てのドキュメントを書くことはできない。そんなことをしたら鬱になる。

ドキュメント書け書け星人がいても、ドキュメント文化がない所だと書いたところで誰も見ないし誰も保守をしない事が目に見えている。文化があればこんな文章見ていない。

まず書くべきドキュメントを決める。

[使用頻度] / [めんどくささ] / [お金を生む量]

様々な解釈はあれば上記などで優先度をつけて書いていけばいいと思う。

コードのテストも似たような優先度でかけると思っている

お金を産んでないシステムはお金を産むことに注力して、お金を生み始めたらクリティカルな部分はテストで書いていくべきだろう。

リファクタなども同上

書き始め方

書き始める前に

どの粒度でまとめればいいのだろう
どのようなファイル・文章構成にすればいいんだろう
読む人のことを考えると・・・あれも　これも・・・図も・・・

などを考えるといつまでたっても完成しない。

最初の人は軽く「これでいいやろ」の精神で書くべきだと思っている。

工数が許す限り補正すればいい

どう継続させるか

Documentも更新（開発）が必要である。

なぜDocumentだけは更新されないのか・・・

自分が思う理想の開発の流れは

案件の調査 -> Documentを見てそのモジュール周りを理解 -> 実装しながらdocument更新 -> リリース

documentがなく「書くべき所」であれば「これでいいやろ」で書けばいい。

最初の人は「これでいいやろ」の精神で書いているので、読む人の経験/知識レベルなどは網羅する事は絶対にできてない。

さらに当時の環境から差分は生まれているはずなのでドキュメントとの違いは出てくるはずである。

その実装者がdocumentに足りないと思った部分を継ぎ足してくれるだけでいい。もちろんこの人も「これでいいやろ」の精神で書く。

知識の差がすごいと書いてある事が理解できないので、理解しようと頑張る。(実装にもつながる)

かつDocumentに残す事で「言語化」もできるし、理解もさらに深まる。

素晴らしい。

そしてなぜ「実装しながら」なのか、実装終わった後に書こうとしても、基本忘れているしめんどくさくなるだけである。リリース手前まで来てドキュメントを書きたくなるだろうか？自分ならリリースして次の案件に着手したくなる。

しかし「これでいいやろ」精神で実装しながらなら、エラーが出たらエラー文をコピペして解決策のURLを貼るだけでいい。

この作業に5分もいらないだろう。この作業だけで助かる人がいるかもしれない。労力に見合っていると思う。

モチベ,巻き込み

わからないｗ Documentはソースコードとは別サービスなどで管理されている事が多く(?)、更新しても誰も反応してくれない。反応があるだけで結構モチベって変わってくると思う。

もしドキュメント作成を布教しようとしている人は書く人のモチベを上がる方法を考えて見てはいかがでしょうか

使うと幸せになるかもしれないツール

http://asciiflow.com/
- アスキーアート的なのを手軽に書けるツール
https://www.draw.io/
- AWSの構成図とかフローチャートとかを手軽に書けるツール
markdown系の書きやすいツール（まだ僕も出会ってない）
- Bitbucketのpullreq画面が一番書きやすいと思っているｗ

2017-10-01

enyenvでphpのバージョンを管理する。

現状のPHPのバージョンとenyenvのinstall状況の確認

[workspace] php -v 
PHP 5.6.30 (cli) (built: Feb  7 2017 16:18:37)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies

[workspace] which enyenv
enyenv not found

enyenvのinstall

基本的にここのreadmeにそって行っていく。 github.com

install

git clone https://github.com/riywo/anyenv ~/.anyenv

zshrcにpath追記する

if [ -d $HOME/.anyenv ] ; then
    export PATH="$HOME/.anyenv/bin:$PATH"
    eval "$(anyenv init -)"
fi

追記後にshellを再読み込み

PHP ENVのinstallする

install出来る **env一覧

[workspace] anyenv install -l 
Available **envs:
  Renv
  crenv
  denv
  erlenv
  exenv
  goenv
  hsenv
  jenv
  luaenv
  ndenv
  nenv
  nodenv
  phpenv
  plenv
  pyenv
  rbenv
  sbtenv
  scalaenv
  swiftenv

install

[workspace] anyenv install phpenv

install完了後 shellを再読み込み

exec $SHELL -l

php envでinstallできるバージョン一覧

phpenv install -l

今回はphp 7.1.9をinstall

phpenv install 7.1.9

7.1.9をglobalのphpのバージョンに設定する。

phpenv global 7.1.9                                               
7.1.9

shellの再読み込みをしてバージョン確認をするとphpのバージョン確認をすると上がっている

[~] php -v                                                            18:59:13
PHP 7.1.9 (cli) (built: Oct  1 2017 18:41:45) ( NTS )

めでたし

2017-09-27

npm自体のバージョンをアップデートする。

npmのinstall

zsh: command not found: npm

npmコマンドが見つからない。

なので

brewでnpmをinstallする

brew install npm

install完了後

installされたnpmのversionの確認を行う。

[~] npm -v
5.3.0

updateを行う。

npm自身のupdate

npm install -g npm

version確認

[~] npm -v
5.4.2

完了！