技術以外のことを語るエンジニアのブログ(仮)

エンジニアのブログですが、技術ブログではありません。でも時々技術のことも書きます。

全力でやる 〜新人時代にやっておいて良かったこと〜

4月も終わりに近付き、新社会人の方々も入社してそろそろ1ヶ月、という時期ですね。
そこで今回は、僕が新人の頃やっていて良かった、一番大事だったと思うことを体験談交えて書こうと思います。
(と、言っても新卒じゃなくても大事にした方がいい内容ですが)


やりたい仕事はなかなかできない

みんな仕事を始める時、「こういうことやりたい」とか「こういう世界なんだろうなー」とか色々想像しながら入ってくると思います。
ただ、初めから自分の想像通りにやりたいことをやれることは滅多にないです。
例えば

  • プランニングをやりたいと思って入ったけど最初はデバッグをやる
  • UnityやりたかったのにCocosのプロジェクトに入った
  • 単純作業とか雑務ばかり振られる
  • 希望通りに配属されたんだけど思っていた感じと違った

など様々です。

ではその状況から自分でやりたい仕事をやれるようになるにはなにをすべきか?
それは今任されている仕事に全力で真剣に取り組むことです。


全力でやると得られること

信頼される

どんな仕事でも全力でやっている人は、それだけでも信頼に値します。
それはその人が仕事に対して真剣に取り組んでくれる人、適当なことはしないという証明になるからです。

特に新人の時は何も実績がないので、そこで手を抜いてしまうと「この人は真剣に仕事しない人なんだ」という評価しか残りません。

なんだかんだ学びがある

新人の頃は何もかもが初めての経験になるので、やっていれば必ず学びがあります。
仮に自分が将来やりたい仕事とかけ離れていても、知っておくことでいつか何かの役に立つこともあります。

ただ、それもその仕事に対して全力で臨んでいればこそ。
全力でやるからこそよく考えるし、その仕事の本質を理解できます。
手を抜いてしまうと惰性でなんとなくこなしてしまい、終わった後自分の中に何も残すことが出来ません。

成果が出やすい

全力でやっていれば絶対成功するわけではないですが、嫌々でやっているよりもずっと成果につながる可能性が高いです。
(言うまでもないことかもしれませんが)
前述したように信用されて学びがあることに加えて、さらに成果が上がれば言うことなしですね。

体験談

僕がエンジニアになって最初にやった仕事は金融系システムのデータ移行作業のプロジェクトでした。
実際どんな作業をやっていたかと言うと、Excelに書いてあるコマンドをひたすらターミナルにコピペして実行するという仕事です。
プログラムを書くということは一切ありませんし、正直面白い仕事ではありませんでした。

しかし、それでもとにかく全力で真剣に取り組んで、誰よりも早く、正確にその作業が作業が出来るようになったら、徐々に他の仕事も振られるようになってきました。
それだけしかやっていないのに、2年目には別の案件でリーダーを任されたりもしました。

全力でやって成果を出したことで、スキルとかではなく、周りから人としての信頼を得られたからかなと思っています。

そうやってしっかり成果を上げれば、「じゃあこういう仕事も任せてみようか」と任せられる仕事の幅も広がっていきます。
(この人単純作業メッチャ得意だからこれだけいっぱい任せよー!とかにはならないので大丈夫です)

もちろん、自分のやりたいことをしっかりと周りに伝えておくことも必要ですが。

ちなみに学びもしっかりとあって、この仕事のお陰でExcelの使い方に結構詳しくなりました笑
知っていると意外と便利な使い方がいっぱいあって、今でもエンジニアとして作業する時に役立っています。


まとめ

人は仕事に対する姿勢とか、取り組み方とかを結構見ているものです。
そしてそれは成果やその人の雰囲気にハッキリ現れてきます。

それに最初から仕事に手を抜いてしまうと、せっかくの学ぶ機会や成果を挙げられるチャンスを逃してしまってもったいないです。

働いていれば面白くないことや、やりたくないことをやらなければならないことは幾度となくありますが、無駄なことなどないと思って何事にも全力で真剣に取り組むことが大切だと思います。

アウトプット=インプット

最近、突然ですがブログをはてなブログに変えてみました。
きっかけとしてはこれからの半期はちょっとブログの更新増やしてみようかな〜と思い、心機一転別のブログサービスに変えてみようと思ったからというだけです。
(ちなみに前のブログはこれ→ http://ameblo.jp/take-7010/entrylist.html )

で、なぜブログの更新を増やそうと思ったか?
それは自分の考えてることを他の人に伝えたいというのもありつつ、ブログでアウトプットすることが新たなインプットにつながると気付いたからです。

インプットとアウトプット

よく本を読んだりセミナーに行ったりして勉強することを「インプット」、それを実践して形にすること(エンジニアだったらコードを書いたり)をアウトプットと言います。

スキルアップにはこの2つをバランス良くやることが必ず必要なものだと思っているのですが、アウトプットは手間も時間もかかるし、「インプット」の方が新しい知識に触れれて楽しいと感じている部分がなんとなくありました。

ただ、そこで最近考えたのが冒頭にも書いた「アウトプットすることが新たなインプットにつながる」ということです。


整理する

まずインプットした知識は、とりあえず頭に入れただけなので割とふわっとしたイメージとしてしか残っていないことが多いです。
アウトプットとして形にする時には、自然とその内容を整理して思い出す必要が出てきます。

例えば本を読んでその内容、感想をまとめてブログに書こうとすると、いっぱいあった本の内容の筋を整理して、キモとなる部分をピックアップして、まとめた内容を書くということになります。

そうすると頭の中でふわっとしていたイメージが自分の中で具体的なイメージとして固まって、よりしっかりとした知識として頭に定着します。
(逆にしっかり固まらないと文章に起こすのが難しいですが)

これは「新たなインプット」というよりは、インプットしたものをより強固にするというイメージですね。

忘れた部分、知らない部分を調べる

整理しただけでは大体しっかりとしたアウトプットにならないです。
それはインプットした内容も全て覚えているわけではなく、忘れてしまったり、そもそもスルーしてた部分(流し読みしてたとか)もあるからです。

実際にアウトプットに起こす時にはそういう部分で「あれ、ここってどうなってたっけ?」「これってなんでこういう意味なんだっけ?」みたいになることがあります。

そうすると当然本を読み返したりして思い出したり、足りない部分を調べたりすることになるので、自然と新たな知識が入ってくることになります。
ここで「新たなインプット」が生まれます。

余談ですが僕は昔新しいプログラミング言語の勉強をする時に

  1. 入門書を一冊読む
  2. その言語を作って自分の欲しいツールを作る

という方法をよくやっていました。
サンプルコードとは違う、自分で仕様を考えたものをいざ作ろうとすると、前述の忘れていたり、流し読みしていた内容の部分でどうやって実装していいか分からない部分が山ほど出てきます。
そうして調べなおしたり、そもそも読んだ本に載ってないようなことは新たに調べたりしてやるので、しっかりと意味を理解して知識を定着させることができました。

ちなみに作っていたのは家計簿ツールだったり、仕事の書類を管理するツールだったり普段自分で使うものだったので、仕様のこだわりも強くなって分からないことはどんどん出てきたのでいい勉強になりました笑

人からフィードバックをもらえる

アウトプットをして人に共有すると、良いことも悪いこともフィードバックがもらえます。
これはアウトプットしないと絶対に得られない「新たなインプット」です。

僕も今まで10年くらいエンジニアをやってきて一番レベルアップしたのは、自分が書いたコードをデキる人にレビューしてもらって指摘を受けた時な気がしています。
自分の悪い癖を指摘されることもあるし、あるいは自分では全く思い付かない書き方を教えてもらうことも出来ました。

ブログに関しても、自分の考えをまとめて書くことで、他の人からコメントなどで感想を聞くことができます。
自分の書いていることが間違っていたりした時も、なにかおかしな考え方を書いてしまったとしても、人からの指摘で気付くことが出来ます。

そうしてもらったフィードバックは、自分の頭の中を人から見て出た意見のようなものなので、自分にとっての課題点なんかも見えて非常に貴重です。


最後に

ということで、今後はインプットしたことを出来るだけブログに書いていこうかなと考えています。
日頃仕事をしていて得たこともそうだし、本を読んだ時もいい内容の物は随時。

そして半年後くらいには、ブログを書き続けたことによって得たことをこのブログに書ければと思います笑

外側から考える

最近ちょっと興味があり、この本を読んでみました。

デザイン脳 ―桝田省治の発想とワザ― https://t.co/CpsKEhnMsS

読んだキッカケとしては「エンジニアは技術書で勉強するけど、プランニングとかのスキルってどうやって勉強するんだろう」と思い、そういう本を検索してみたら結構紹介されていたからです。



ゲームを作る時の考え方

この本自体、ゲームを考えてから作るまでの色々な考え方が載っていてとても面白かったのですが、その中でこの桝田省治さんがゲームを考える時の流れとして、次のようなことを挙げていました。

  1. まず、僕が面白いと思うこと、逆に言えばユーザーを面白がらせたいゲーム向きのネタをどこかで見つける
  2. 次にそのネタを再現するためのルールやゲーム目的を考える。ようするにシステム部分の構築だ
  3. そのルールや目的が存在してもおかしくない世界設定をでっちあげる
  4. 最後に、ルールや目的、世界設定が説明的にならず、感覚的に理解しやすいシナリオやキャラクターを追加する

これを読んで思ったのは、モノづくりに於いてどの職種も考える順序は一緒なんだなということです。
それがタイトルに書いた外側から考えるということです。
「全体から考える」とか「後ろから考える」とも言えるかもしれません。

上記の話で言うと、ゲームのネタ(やりたいこと)という一番外側の部分から考え、 それを表すシステム→世界設定→シナリオやキャラクター と内側へ進んで行っています。

※世界設定がシステムの内側というのは分かりづらいですが、この方は世界設定を「ゲームはシステムが重要で、世界設定やシナリオはより楽しく都合よく進めるためのもの」という風に置いてるので、この形になります。
(マリオに「ピーチ姫を助ける」という世界設定がなかったとしてもアクションの楽しさは変わらないよね、みたいな話です)




他の職種での考え方

では他の職種で考えてみます。 例えばエンジニアがコードを書こうとしたら

  1. 機能要件を決める
  2. 全体の設計を考える
  3. 各機能のインターフェース設計を考える
  4. ロジックを考えてコードを書く

と、これも
要件(作りたいもの)→全体→機能→各ロジック
と外側から内側へ向かっています。
会社によっては要件定義、基本設計、詳細設計・・・みたいな分かりやすい言葉もあります。

ライターさんが文章を書こうとしたら

  1. テーマ、世界観を決める
  2. 全体の話の流れを考える
  3. 構成に落とす(1章、2章とか)
  4. 各章の内容を書く

とかになるのかなと思います。 (ここは半分憶測なので実際はもっと色々あると思いますが)

このように言い方はバラバラですが、基本的にはまずは荒い粒度で「一番外側を考える」というフェーズから始まり、徐々に内容を細分化して肉付けしていく順序となっています。

なぜこうなるかと言えば、結局のところ一番外側の部分が「作りたいもの」を表していて、そこに向かってどうつなげて行くかでモノが出来上がって行くからだと思います。
(まあ実際は内側からいきなり作り始めてしまう人も多いですが・・・エンジニアで言うと設計せずいきなり一番内側のコード書き始めてしまうような)



まとめ

今回はエンジニアやライターさんのことを例に書きましたが、イラストレーター、UIデザイナー、あるいは建築士や自動車製造みたいな全然別の業種でもおそらく割と共通する考え方なのではないかと思います。
(もちろん職種によって多少の差異はあると思いますが)

ちなみにこのブログも本を読んで「外側から考えることの大事さを伝えたい・・・!」という全体像が思い浮かんだ後、

①本の紹介
②本の面白かった部分の話
③考察、例え話
④まとめ

みたいな構成に落としてから書きました笑
小さなモノでも、何か考えて形にする時は、こういう順序を意識して考えてみるとより良いモノが作れるかもしれません。