生きてます。
最近、知り合いからエンジニアとしての深みがー、ビジネスマンとしての深みがー、というアドバイスをよくもらうのですが、
ぶっちゃけどうでもいいんだよね。そういう自己啓発系の考えとは昔からどうも僕は相性が悪いらしい。
個人でやっているGithubのプログラムについても技術選定がーとかGithubでの勉強の仕方について色々言われたけど、正直Githubは興味本位で作ったものを載せる、程度にしか使ってないし、興味があるもの勉強すればよくね？と考えてしまう。ある程度考えるのは大事かもしれないが、個人のプライベートの時間までそんなこと考えると疲弊してしまう。正直世の中自分の考えを押し付けるエンジニアが多すぎて辟易する。
仕事に関しては稼働時間とか成果物のアウトプットは真摯にやっているが、エンジニアとしての深みとか全く考えないし、仕事をこなせていれさえすればそれでいいと思ってしまう。「エンジニア＝プロジェクトを遂行させるためのパーツ」と割り切ってしまっているからそもそも僕はそこまで考えないのかもしれない。自分のキャリアを考える上ではある程度上記言われたことも考慮する必要はあるのかもしれないが。。
前置きは置いておいて、仕事で役に立ったなあと思う考え方を柄にもなく上げてみる。
- システムの理解はユーザ視点で考える
- あるべきシステムの形を考える
- バグの報告はあるべき姿から説明する
システムの理解はユーザ視点で考える
昔から仕様の理解はすごく苦手だったが、これはすごく大事。エンジニアだから変にシステム側から考えようとすると全くわけがわからなくなる。このstep1というタイミングでXというフラグが渡ってきてー、とか考えるとわけがわからなくなる。
が、そもそもであるが、システムは何のためにあるのかを考えたときユーザの業務を改善するためにあるわけだ(業務系システムの場合)。その場合、ユーザの業務を知って、実現したい業務の内容・範囲、システムで実現したい機能を知る必要がある。(これが要件定義なんだけど)そうすれば、このstep1というのはどういうタイミング(何をするタイミング)、Xというフラグが何か、何のためにあるのか、というのを知って理解の手助けになる。
腐っても人間なんでね、機械側で考えるより業務側で考えた方がわかりやすい。
割とこの考えをしてから仕様の理解がするすると入るようになってきた気がする。。
あるべきシステムの形を考える
仕様の理解を手助けとなる&システムの構築をどうするかの手助けとなる(かもしれない)上で、あるべきシステムの形を考えるというのはかなり有効だと思った。要件を聞いたときに自分なりにシステムの形を妄想してみるのが大事かも。
この要件を実現するにはこういう機能が必要で、こういう機能を実現するにはバッチが定時実行で動く必要があってー、そのバッチの実行状況を画面から見れる必要があってー、そうするにはバッチの実行中にこういうことをする必要があってー、みたいな感じで連想ゲーム式に妄想する。すでにあるシステム構成と間違ってもいい、妄想することが大事。下流だけやってるエンジニアだと気づきにくいかもしれない。(俺はそれまで言われたもの、設計がすでにある状況で仕事していたのでそう思う) が、これをするとシステムを作るうえで一歩先を考えられるようになった(気がする)。必要なアプリの機能だけでなくインフラ構成とかも考えるとなおいい。
バグの報告はあるべき姿から説明する
相手に説明するのは難しい。「この機能はこう動くべきですね。でも、今はこういう状況なんですよ。」っていう順番の問題。基本的に報告系は結論から先に言うのと、あるべき姿から報告するのが無難。
こんなところだろうか。技術的な研鑽も大事だが、結局仕事なんでね。。
プラスで問題の切り分け能力、技術にしろ仕事にしろ、問題の切り分けの癖は付けておくと幸せになれる気がする。
他には、当事者意識、これは自分しか出来ないような状況に追い込まれると芽生える。この意識のあるなしだと仕事へのコミットしようとする力が全然違う。でも、これを新卒とかBP案件で流れ作業しかやってきませんでしたー、って人は身に着けるのは時間がかかるかなあ。。
何を当たり前のこと書いてるんだと思うかもしれないが、人並みのエンジニアになるためには大事な考えかなと思った。
なんか他にもある気がするけど、思い出したらおいおい。
