エンジニアとしての仕事のやり方の基本を語る。
エンジニアとしての仕事のやり方の基本を語る。
最近、仕事では設計業務を行ってる。Flutterでプッシュ通信を行うシステムを作る予定なんだけど、それに関して工数見積を行っている。Flutterに関しては仕組みとかはまぁまぁ理解は出来てきたね。androidとiOSを両方開発できるマルチプラットフォーム開発環境なんだけど、Dartという言語を使って開発を行ってる。Flutterに関してはGoogleが猛プッシュしているので、これからアプリ開発の分野では結構伸びていくんじゃないかと期待している。
休憩時間にネットをフラフラしていたら見つけたこのQiitaの記事は興味深く読んだ。
見出しだけでも引用してみるか。
1.納期に間に合わない時、自分から報告してこない
2.タスク分解しないで、仕事し始める
3.進捗の見える化をしない
4.Noと言えない
5.仕様でわからないところを適度に質問できない
6.工数に休日や残業を含めている人
7.客観的に自分の位置付けができない
8.仕組み化して効率化を図らない
9.反論=ケンカだと思っている人
今回引用した記事はアンチパターンとして書かれているけど、できるエンジニアなら作業する前に考えている仕事術としても読めるね。まぁエンジニアあるあるというか、仕事をやる上での基本的な心がけだよ
僕もさんざん無茶振りされて心を壊すまで働いちゃったから、こういう仕事のやり方については骨身に叩き込まれている。何か業務を割り振られたとしたら、作業を始める前にまず具体的なタスクをリストにして書き出す。そしてその作業については優先度と工数を割り出してスケジュールを決める。実際にコーディングなどの作業を行う前に、具体的な作業リストを作るのと工数見積を出すのはエンジニアの基本である。
僕も今、新しく割り振られた業務に関してタスクの分解を行ってる段階だけど、大きなプロジェクトだと工数見積でも数日使うこともありうる。まず、コードリーディングなどを行って、実際に変更を行う箇所とどういう実装が必要なのか想像できるぐらいまではっきりと確認しないと作業開始できないっすね。
趣味でプログラミングをやるなら兎も角、僕らは金をもらって仕事をしているのである。そのシステムを作るのにどういう作業を行って、どれぐらいの品質で、どれぐらいの時間が掛かるのか顧客に報告して承認をもらわないと、怖くて仕事なんてできない。期間内にできませんでしたで会社の信用を損なったとしたら、個人で責任を取れる問題でもないのである。
僕は今ん所、単なる下っ端のプログラマではあるけど、なぜか知らんが会社のiOSのアプリ開発責任者みたいな立ち位置になっちゃってる。これから新アプリを開発するということで、企画段階から設計、コーディングまで自分で上司に報告しつつやっていかないとならんのである。なんか、障がい者雇用で安月給なのに貰ってる給料に対して責任が重すぎな気がするんだけど、まぁ今のプロジェクトを完遂したとしたら上司の覚えや人事考課も良くなるでしょ。バリバリ働くざんす。おまんまのためだ。
なんでまぁ、安月給の下っ端なのに重い責任背負わされるのは嫌なので、やるべき具体的なタスクに関しては随時上司に報告するようにしている。こういうので怒られるケースというのは仕事のミスというよりは、報告不十分で上司が把握できてない所で工数漏れがあって納期遅れが発生するケースである。
僕は内向的なんでコミュニケーションって苦手なんだけど、与えられた仕様に関しては完璧に理解して納得できるまで何度でも聞き返すようにしているよ。これもエンジニアにとっては基本的なことで、完璧に理解できてない仕様でシステムを作ってバグが発生しても本人の責任なのである。そこんところの仕様の説明を省くような顧客なら仕事は断った方が良い。
後は、僕がプロジェクトマネージャーとかやってた時に嫌というほど分かったんだけど、一人で作業を全部抱え込むといつまで経っても忙しいのが終わらない。チームメンバーの現状抱えている作業とかは雑談でもしながら情報共有しておいて、手すきなやつに抱えているタスクを渡したほうがよいのである。
エンジニアにはありがちなんだけど、タスクを頼む面倒くささよりも自分でやったほうが良いと思いこんでる節があるけど、一人で作業を全部抱え込んでボトルネックになると一人だけではなくチーム全体が損失を被るのである。こういうのは最後まで抱えていると爆発する爆弾みたいなもんなので、人に渡せる仕事はさっさと渡して責任は分散したほうが良い。
こういうの、仕事のやり方としては基本的なことなんだけど、新卒とかは理解できてなくて苦しんでる事が多い。僕も苦しんで覚えてきた一人なので、苦しんでる新人とかいたら教えてやりたいっすね。
あわせてよみたい
