Rubyが好きなプログラマーの日記。日々の生活、開発に関するメモとか考えとか。
今日、今年度の新卒とランチに行ってきた。 配属されたばかりのOJTでは大変そうで、残業をしちゃってるようだ。
自分の新卒のころを振り返って、今思うことは、もっと手を抜く努力をすれば良かった、ということだ。 新卒のとき僕はほとんど終電で帰ってた。主に残業だけど、会社で勉強もしてた。 それはそれで良いところもあったとは思うんだけど、頑張ることを勘違いもしてた。 もんもんと1人で考えて、あーでもないこーでもないと苦悩しながら、睡眠時間やプライベートな時間を減らし、身を削るような思いをすることが頑張ることだと勘違いしてたと思う。
この考えは、仕事を与える方、もらう方の双方にとって悪影響だと思う。 確かに頑張ってるように見える。実際に周りもそう見えていたのだと思う。 仕事を与えた方も、あんな辛そうにやってると評価してあげなければ報われないよな、なんて思ってしまうかもしれない。 なんとなく自分だったらそう思ってしまう。思わず「よくやった!」って言っちゃうかもしれない。 そんなことを許容しはじめたら、そのうち職場はガマン大会会場になるだろう。
でね、仕事で一番大事なのはアウトプットですよね。アウトプットが一緒なら、楽な方法が良い。 楽な方法なら、他の人より早く帰れる。早く帰れれば好きなことができる。 周りから見たら楽をしている、すなわち怠けているように見られるかもしれないし、そう思うと、楽しちゃいけないような気もしてしまう。 「先輩だってまだ残ってるんだから、自分がこんなところで帰るわけには…」なんて思ってしまうかも。自分はそんな感じだった。 けれど、本当はそんなこと考えなくて良いのだと。怠けている、と思われたくなければ、楽になる方法を教えてあげればいい。 仕事は幸いにも、学生の時のテストと違って、答えは周りに教えて良い。むしろ、どんどん教えた方が良い。
そして、もしエンジニアになりたいというのであれば、楽になるためのコードを書いた方が良い。 エンジニアの仕事は、誤解を恐れなければ、仕事を楽にすることだからだ。 どうしたら楽になるか、本当に人間が頭を使わなければならないところで頭を使える訓練が必要だと思う。 「えぇっと、323 と1987443を足して、税率をかけると云々」なんてのは頭をつかうところではない。コンピュータの仕事だ。計算機だもの。 人間の仕事の目的を果たすために、計算機がどんなことをすればいいのかを考える訓練とも言える。
まとまりのない文章ですが、
半年くらい通勤の時間に、あーでもないこーでもないと考えながら読んで、今日やっと読み終えた。 ソフトウェア開発は、目に見えないものを複数人でつくるので、それぞれの頭のなかで描いているソフトウェアのイメージがずれてしまうので、色んな不安が出てくる。 そもそも作ろうとしてるものに価値があるのか、作る順番はこれでいいのか、作り方はこれでいいのか、そのやり方は可能なのかどうか、とかとか。 ユーザーストーリーマッピングは、そういった不安を解消するためのプラクティスなんだろうな、と思った。
ユーザーストーリーマッピングというか、粒度の大きいバックログアイテムをどう分解するのか、新しいバックログアイテムをどう見つけるのかといった活動が大切なのだと思う。その活動の実装としてのユーザーストーリーマッピングということを意識しておかないと、目的と手段を履き違えてしまって、付箋ばかり並んだけど、何もわからない、決まらないってことには陥りそう。これは本にも書いてあったので、十分に起こりえることなんだろう。
みんな、どういう風にやっているのか気になるので、読書会とかあったら行ってみたいな。
ユーザーストーリーマッピング [ ジェフ・パットン ] |
昨年から新規事業の開発の部署にいるので、「技術をどうやって事業に繋げるか」ということに興味があった。例えばブロックチェーンや人工知能みたいに、流行りのものを盛り込めば、それが事業として容易に成り立つわけではない。かといって、そういったものを疎かにする訳にもいかず、積極的に取り入れなければ、いざという時に価値に繋げられないだろう。それとは別で、知り合いが技術経営(MOT)の勉強をしていたので、何かの役に立つのではないかと思い、この本を買ってみた。技術経営の本は探すと、教科書のような本が沢山出て来るのだけれど、この本は新書なので手に取りやすかった。
この本は、著者が実際に経験した大企業の中から新規事業の立ち上げをケーススタディとして、シーズを生み出す研究フェーズから量産体制に入る産業フェーズまでの間にある越えなければいけない「魔の川」、「死の谷」そして「ダーウィンの海」のそれぞれを越えるための知見が書かれている。 著者は製造業の人なので、今自分がいるインターネットの産業とはモノや技術はかけ離れているところはある。けれど、魔の川を越える時などで、経営者や管理職が気にしなければいけないことは、共通するものがあるようだ。例えば、研究段階では人が多くいてはいけなかったり、関連する外部の開発企業に対しては相手側の立場になって関係構築を重視しなければいけなかったり、など。
研究で生まれたシーズをものとしてなんとか成り立つ製品を開発し、そこから実際にお客に価値があるものとして認められる商品にする事業に発展させていく段階的な流れは、リーン開発と何か近しいものがあるんじゃないかと思った。まだリーンスタートアップは読んだことは無いのだけれど。
途中のケーススタディは、新素材開発の話なのでわからないところは多々あるのだけれど、それらは流し読みして*1、失敗談やそれらから出てきた知見やアドバイスは、インターネットのビジネスの人たちにも役に立つのではないかと思う。
あと、後半に書いてある、大企業で新規事業をするメリットと大企業病の話は、「本当にこの会社(大企業)で(新規事業を)やる意味があるかどうか」を判断するのに役に立ちそう。メリットが感じられなくなったら辞めるという判断になりそうだ。
*1 わかる人はちゃんと読んだ方が良いと思う。