kwsktr's study log

kwsktr のおべんきょログ

ブログにコメントをいただいたのでお答えします :: 6年後のボク

kwsktr.hatenablog.com

マスさん、コメントありがとうございます。


気付けば6年間過ぎていました。


現在の職は PG 兼 SE みたいな、ハイブリッドな仕事してます。
ちょっと大きめのサイトを、一人で内部の追加開発したり、フロントいじったり、DB触ったりと、SEOしたり、デザインしたり、いろいろやる楽しいお仕事をしています。
フルスタックエンジニア とかいう感じでしょうか。技術はいまいちですが、とにかくなんでもやってます。


職場もいろいろ変わりまして、当時の中小 SE 会社ではないのですが、6年前の苦しかった経験から、今、楽しくやってるボクなりのアドバイスを送りたいと思います。

自分の解る部分を解る

よく聞く言葉とは思いますが「解らないことが解らない」状態を無くすことが、最初の一歩です。


どこなら自分は解っていて、どこが、どのように解らないのか。
そもそも、なぜPGだったのに、SEやってるのか。というようなことも、聞くことをおすすめします。
プロジェクトの目的は何か、そのために何が必要か、納期はいつからいつまでか、予算はどれくらいか、協力会社は何社か、何人体制で作っていくのか、などなど、なんでもいいから解ることを増やしていくことで、また見えてくるものがあるかと。


そして、大きな部分から、徐々に細かくしていく作業を繰り返し、解らない部分を減らしていくのはどうでしょうか。


右も左も解らない状態から一歩踏み出すために、今の自分がどこにいるのか、を自分自身が解ってあげて欲しいです。
周りに気付いて貰う、その前に自分で気づくことで自信が生まれると思います。

脳みそから物理的な何かに落としこむ

解らないことを頭の中だけで留めておくと、もうまるで解らないループに落ち込んでしまうかと。


Excelでもマインドマップでもなんでもいいのですが、とにかく脳から紙、ファイル、などの物理的な何かに移すことができるか、が大事だと思います。


ボクの場合は、とにかく文書化でした。
手書きで図を書きまくって、ユースケースなどを理解していきました。


文書化できない = 理解してない、解っていない。
そのような心づもりでいたので、それなりの量のお絵かきをして、それを要件定義の書類にまとめたりしていました。

誰かに聞いたほうが早い

どうしても解らないことは恐れずに聞くことです。
解る人なら1分で解ります。解らない人は3時間たっても解りません。


だからといって、解らないまま進めることのほうが、怖いことで、あとあとの問題になってきます。
ウォーターフォール型の開発でなくとも、初期の要件定義はそれなりに影響してきますし。


解らないことを尋ねるときも、どこまでなら解って、どこが解らないのか、を伝えることができるので、コミュニケーションしやすくなります。
とは言え、何でも聞く、というのもアホだと思われて厭かも知れませんが、その時の聞き方次第でしょうね。


マスさんに、メンターの人がいればいいのですが、どうなのでしょうか。
聞くに聞けない、そんな関係にしない、というのも大事だと思います。SEなら。

仕事だからこそ人間関係を大事に

当時のボクは人間関係が上手く構築できませんでした。
そこが原因として、ボクの精神はズタボロになっていきました。


向き不向きあるので、なんとも言えないのですが、仕事の向き不向きより、人間の向き不向きのほうが辛かったですね。


人間関係が上手くいっていれば、仕事はなんとかなります。
自分のために仕事をしようとすると、きつくなりますが、同僚のため、チームのため、組織のため、クライアントのため、と考えると、味方が大勢いることに気が付き、プラス思考が生まれて仕事がしやすくなると思います。


でも、それは人間関係が破綻してない場合ですよね。


ボクは転職するときに、当時の社長についていけずに辞めました。
小さい会社だったので、距離も近くてきつかったですね。


彼から教わったことに金言もあるのですが、それ以外の部分に悩まされて仕事ができなくなってしまい、誰も得しないから辞めよう、と決めました。
ボクにとっては、とても良い選択肢でした。

本を読む

後は勉強ですね。これはエンジニア職なら当たり前のことですが。


  


要件定義関連で、読んで良かった本を貼っておきます。
初歩すぎるかもしれませんが、ご参考までに。


そして、最後に大事なのはコレ。


enjoy!!


今を楽しんで。