『週刊』エンジニア奮闘記①「初週の学び6選！！」【第21号】
こんにちは！
テクノシップブログです！！
コツコツと記事の執筆を積み重ねて、やっと20記事を超えるところまで来ること
ができました！！この調子で少しずつステップアップしていきたいと思います🔥
さて、私は6/1よりエンジニアとしてのキャリアがスタートした訳ですが、
さすがにいきなり現場には行けないものの、先輩方に様々な話をお聞きし、
「実際に働く」場合のことに関して驚いたり、なるほど！と思わされることが
数多くあることに気づきました！！
今まで単なる「学習者」としてエンジニアをやってきた私には、
いい意味で「働くエンジニア」とのギャップを理解することができて
良かったと思ってます！
最初の1週間で学習したことをアウトプットし、これからエンジニアとして働き
たいと思っている方の参考となりますように✨✨✨✨✨✨
1. 初週で「驚いたこと」「なるほどと思ったこと」6選
①セキュリティへの意識の高さ
まず驚いたのが、実際に働くエンジニアの方の「セキュリティへの意識の高さ」
です。
お客様から大切な情報をお預かりしてプログラムを開発することが多いことを
踏まえ、並々ならぬセキュリティ意識が備わっていることが分かりました。
●PCには勿論ウイルスバスターを導入し、週一のペースでチェックする
●外出時、PCはロックするか、ロッカーに入れて施錠する
●帰宅時は基本的にPCの持ち出しは禁止
●PCに余計なソフトのダウンロードは行わない、必要だと感じても
自分の判断では決して行わない
●メモをするのが面倒くさいからと、スマホで撮ることは断じてしない
私が先輩方から聞いただけでも、これだけのことを徹底していました。
特に「ハッと」させられたのが、「メモをするのが面倒くさいからと、
スマホで撮ることは断じてしない」です。これに関しては、言われなければいつか
思わずやってしまっていたと思います。チョッとしたメモ書きでも大切な情報で
あり、記録に残して自分用に持ち出すことはNG。
非常に勉強になりました。
【ToDo】
上記のことを徹底するとともに、仕事で使うあらゆる情報や物に
対して、「もし無くしたら」どれだけ大変なことをしたことになる
のかということを常に肝に銘じて仕事をする！
②開発業務でのチーム編成の新たな流れ
これに関しては、「なるほどな」と思った要素ですが、普通プロジェクトを
開始するのあたってのチーム編成において、「PM(ProjectManager)」、
「PL(ProjectLeader)」、「メンバ(プログラマー)」といったように編成しますが、
近年、PMとPLの業務を補佐する立場として、
PMO(ProjectManagementOffice)
というものが重要視されているそうです。
PMはお客様との折衝や、組織管理などの業務が大変で、PLもチーム管理が大変
です。そのため、それぞれを繋ぐ事務的な役割を中心に果たしてくれる事務方の
チームが求められているとのことです。それが「PMO」です。
「進捗管理」などを任されることが多いようですが、優秀なPMOは「徹底力」
がすごいそうです。各要素の進捗状況について、期日までに決められた
要件を満たせるように「徹底した管理」ができることが求められます。
今後、実際にプロジェクトに入ったら目にするチームになるかもしれないので、
頭に入れておきたいと思います！
【ToDo】
実際のプロジェクトに入ったら、PMOの業務についても気にしてみる
③成長するエンジニアの特徴は「〇〇する姿勢」
色々な先輩に「成長するエンジニアの要素」についてざっくりと聞きました。
皆さん口を揃えて仰っていたのが、
周りを気にする姿勢
です。
例えば、自分が携わったプロジェクトで、自分自身の担当業務が「プログラム
テスト」だったとして、その業務だけに気を配るのではなく、「上流工程」、
「インフラなどの担当」、「他のチームの状況」など、あらゆる要素を気にする
姿勢があるかどうかで、「メンバ」から「PL」や「PM」に昇進できるかどうかが
決まってくるそうです。
【ToDo】
自分の担当とは別の業務をしている人やチームに「質問」を投げかけてみる
④開発工程に関する注意点について
私が入社した会社では、主に「業務システム開発」を手掛けています。
そのため、「ウォーターフォール型」の開発形態を取ることが多いそうです。
ウォーターフォール型の開発では、「V字モデル」という開発モデルが提唱
されており、開発の進め方の指針となるものの内の一つですが、このV字モデルに
ついて、「なるほど」と思わされた部分がありました。
V字モデルでは、一連の流れで開発まで辿り着いた後、それぞれの工程用の
テストを順番に行っていき、納品まで繋げていくモデルです。
ここで、大事なのが、「テスト」はあくまで「各工程の設計書に対するテスト」
であり、「コードそのものに対するテスト」ではないということです。
コードに対してテストをしたとしても、そのコードそのものが設計書に書かれて
いる要件を満たしていなければ意味がありません。だからこそ、「設計書」や
「要件定義書」の内容を満たしているのかという視点でテストを行っていくことが
重要だということです。
【ToDo】
テスト業務に入ったら、このことをしっかりと意識して業務に臨む
⑤あらゆる「資料」に関する注意点について
エンジニアとして仕事をしていく中で、今後様々な「資料」を作成する機会に
恵まれると思います。そんな時、注意するべきポイントについても教えていただき
ました！
●統一感を出す（インデント、用語、品質）
●セルフチェックを頻繁に行う（資料のレビューは「機能に関するレビュー」
の場であり、「資料そのものの誤字脱字などを指摘する場」ではない）
●必ず修正履歴を残す
特に、学びになったのが、「品質の統一」です。
これは、「忙しいかそうではないかに関わらず、常に同じ品質を保った資料を
作成する」ということです。
「今回は忙しいからこの要素は盛り込まなくていいや」でもダメですし、
「今回は余裕があるからあの要素も付け加えてみよう」というのもダメです。
常に同じレベルの品質で作成していくことが求められるということですね。
【ToDo】
資料を作成する立場になったら、上記のポイントに照らし合わせて作成する！
⑥レビューをすることの意義について
プログラム開発において、コーディングのレビューがあります。
これは、早期に欠陥を減らし、効率的かつ安全な開発を遂行していくためには
欠かせない工程になります。
しかし、上記の目的以外にも大切な意味合いがあるそうです。
それは、「連帯責任感の醸成」です。
プログラム開発を行っていくにあたり、「担当者一人の責任で終わらせる」の
ではなく、一人一人が全ての工程に責任を持つこと。
それによって本当にいいチームが成立し、より良い開発へとつながるという
ことです。
これは、③でも書いた、「周りを気にする姿勢」にも繋がると思います。
【ToDo】
レビューは丁寧に、慎重に行う！！
2. 研修内容について
入社日から早速研修をしているわけですが、課題は、
Flutterを用いた、電卓アプリの作成
です。
そもそも、Flutterとは、Google社が提供する、クロスプラットフォーム技術を
モバイルアプリ用フレームワークと言ってはいますが、AndroidやiOSはもちろん
のこと、WebやWindows OS、Mac OSにも対応している優れものです。
以下のサイトに詳しく特徴や、メリット、デメリットなどがまとまっています。
もし、学習してみたいという方がいれば、以下のサイトや動画が参考になり
ますよ！！良かったらチェックしてみてくださいね！！
【Flutter公式】
【YouTube --Flutter大学】
【Udemy】
いきなり新しい言語での取り組みとなりますが、何とかこの課題を乗り越えて
早くプロジェクトに配属されるように頑張ります！！
3. テクノシップ第21号プチ編集後記
〜新居でゴミ捨て場が分からず、あたふたした1週間でした、、、
意外なところで時間食ったり、つまずくのが人生なのかあ〜
