きのこる庭

スタートアップ界隈でよく聞くのが「アイデアそれ自体よりも、いかに早いスピードでPDCAを回すかがサービスとしての勝敗を決める」という言葉。

一般にサービスをつくる人間であれば「ユーザのニーズをできるだけ汲み取りたい」「サービスを大きくしていきたい」と思うのが常だけど、そういうユーザのニーズって 言ってしまえば無数に存在すると言っても過言ではない。

ただ、経営的に考えると「PDCAサイクルは早いほうが良い」んだけど、ここに大きな落とし穴があると個人的には思っている。
すなわち、サイクルを早めんがために人的リソースのキャパシティをフルに圧迫したりするような事が起きるのは良くないと個人的に思っている。

人的リソースのキャパシティをフルに圧迫した状態とは

勿論これは業務時間中に力を抜け、サボれという話ではない。
しっかり業務にコミットして義務を果たすのが道理だし前提だと思う。
ただ、ここで良くないと思うのは「スピードを推し進めるあまり、”義務”が必要以上に膨らんでしまっていないか」ということ。

どういうことか？
全うな社会人であれば、「まずは義務を果たさないと権利は主張できない」と考える。
さらに「義務」を業務時間中にこなせなければ、業務時間を超えて義務を全うしようとする という光景は世の中ではよくあることだと思う。
ここでPDCAのスピードを重視するあまり、義務を膨らませ続けると何が起こるか？

義務が業務時間中に終わらない状態が当たり前になり、場合によっては 毎日朝9時に仕事を始めて0時まで働かないと終わらないような仕事量にまで膨れ上がってしまってにっちもさっちもいかなくなるような事態になるかもしれない。

それでも真面目な人ほど「義務をこなせないのは自分の力不足が原因だ、だからここで頑張って義務を果たしてから権利を主張しよう」と考えるため、
義務が常に膨張する状況下では「義務を果たしてから」の無限ループに入ってしまう。

【例】 開発リソースにおける問題

ここまで一般的な「人的リソース」についてのみ言及していたが、技術者のはしくれとして、上記の問題が開発の現場で起きた際にどのような問題が発生しうるかを考えてみたい。

1. 技術者が 業務以外の時間で技術文献を読んだり、勉強会に参加したり、技術的なアウトプットをする時間・体力が無くなる。

スタートアップの場合で劇的な技術的成長を遂げるスーパーエンジニアで「やらなければいけない状況で、なんとかして実現しているうちに結果として力が付いた」という話をよく聞く。いわゆる 物理インフラも組めて、ネットワークも組めて、CIも導入できて、適切に負荷分散やスケールアウトもできて、プログラミングもできるような、わからないことがないんじゃないかというレベルの人。

そういう人を見ていると、やっぱりスタートアップを通した業務から得られる成長って圧倒的で計り知れないんだろうなーと思う。
ただ、それは義務を膨張させて技術者を縛るための正当な理由にはならない。
何より「自由な時間」の中での試行錯誤を通した成長や楽しみは決して無視できない。

また、時間・体力が無くなるという事について、甘えや他責じゃないかと思うかもしれないけれど、この部分にこそ主観が入りかねないので気をつけた方が良いかもしれない。

月80時間残業してる人からすれば月40時間の人はまだ余裕があるように思えるだろう.
月120時間残業してる人からすれば月80時間の人はまだ余裕があるように思えるだろう.
月160時間残業してる人からすれば月120時間の人はまだ余裕があるように思えるだろう.
(以下無限ループ)

2. 技術者が 技術的なトレンドを追いづらくなる。

勉強会やコミュニティはただ技術を学ぶだけの場所ではなくて、その分野に非常に精通している人達や同志と繋がるきっかけになったりするし、その空気を吸うことで 技術的なトレンドを「共通言語」として身に着けるための場所にもなる。

勉強会やコミュニティに参加すれば、 こういうツール群は ある種の共通言語として 普遍的に飛び交うので、勉強会を通してこうした共通言語を空気のように吸収し続けることで、一つ一つの記事を追うより効率的に 感覚値として技術的なトレンドをつかめる。

移り変わりが激しく膨大な技術的トレンドの中で、何が重要か、何が重要になり始めているか、反対に何が落ち始めて何が代わりに浮き始めているかを追い続けるのは、より良いチームの技術体制を敷いたり、より良いプロダクトを作り続けていく上で大切なこと。

因みに以下の図にここ最近の世の中のトレンドをまとめてみた。上に行けば行くほど世の中寄り、下に行けば行くほど技術寄り。
※なお、これまでGitのようなバージョン管理とか主に開発ドメインのものだったけど、最近では人事の人でこうしたシステムやその必要性を理解している人が多くなってきているので( コマンド叩ける人もいるくらい )、そういうものは世の中一般のトレンドと技術の世界のトレンドの境目の部分、つまり真ん中の部分くらいに置いてます。

・・・という具合に、技術者が学ぶことは結構多いし、常に技術は移り変わるので、迂闊に技術者の自由な時間を奪うのはチームの長期的な成長・発展にとっても良くない場合がある。

【技術者の例:拡張】　「自由な時間」がチームに与えるメリットだけを見てきたけど…「仮に技術者が 直近でチームの役に立ちそうにもない全く異なる技術の勉強をしていたら？」

義務(ただし必要以上に膨張していない)を果たした上でやっているなら、以下の理由で良いのではないかと思う。

その人の「趣味」としてみれば良い

「趣味」を通じた遊びや試行錯誤から価値を生む着想を得る場合が少なからず世の中ではある(その技術者の想像力に貢献する)し、何より日常のストレスを発散してその人が長く健康に働くための大事な要素にもなる。

休日にジム行ったりサッカーしたりお酒飲んだりするのと一緒。楽しいから趣味で技術触る。
趣味っていう観点で見れば「それをやる必要あるの？」とはならないだろうし、何よりその人の精神衛生上のメリットが大きい。

更に言うと、一見関係していない技術でも、ふとした瞬間 それが実務に結びつく場合もある。
例えば 日頃オブジェクト指向ベースのフレームワーク上で業務してる場合、業務上で関数型プログラミングというパラダイムに出会う機会はそうそうない。でも関数型プログラミングを知っていれば、実務でよくあるような複数属性の情報をちゃちゃっとフィルタリングしたり、フィルタリングした上でちゃちゃっと共通の処理を適用したりするような事がすごくスマートにできるようになる(※ただし 銀の弾丸 ではない)。

まとめ

・PDCAサイクルを早める際は 人的リソースのキャパシティを考慮した方が良いかもしれない。
・特にサイクルを早めるあまり「義務」を必要以上に課して、チームメンバーが勉強する時間・機会を失っていないか注意した方が良いかもしれない。
・(技術者の場合) 自由な時間でのインプット/アウトプット、勉強会・コミュニティ参加は結構大切。