Zenn
🔰

いちから伝えるwebシステム開発② ソフトスキル編

2023/02/17に公開
初心者
教育
研修
ソフトスキル
idea

前回記事の続きです。
いちから伝えるwebシステム開発マニュアル① 計画・概要編

ソフトスキル

🤔 ソフトスキルとは

システムエンジニアに限らず、他の業種にも通じる社会人としての心構えに近いですね。
今回はその中でもエンジニアに向けた内容について書いていきたいと思います。

☕️ 余談: ハードスキル

エンジニアにとっては、プログラミングそのものや、設計・テストに関わること、それらの作業に必要なツールを使うためのスキルということになります。

自己解決と周囲へのヘルプ

  • どんなささいなことでも質問できる人はえらい🎉
  • 分からないことを分からないと言える人はえらい🎉
  • 15分調べて・考えて解決できなければ、周りの人に相談してみましょう(オープンスペースで独り言程度にコメントするだけでも⭕️)
  • 誰が何でつまづいているかをチーム全体で共有することが大事(課題の見える化)
  • 他の人に質問するのを躊躇って自己解決にこだわるより、有識者に聞いた方が結果的早く解決できます💡

情報検索時の気をつけること

  • 1次情報[1]以外の検索結果の内容を鵜呑みにしない
  • 情報の出典元を意識すること(検索で出てきた個人ブログの情報が正確とは限りません・情報が古いこともあります)
  • 情報の新しさ・古さを確認した上で参考にするかどうか判断する、自分で判断できなければ周囲に相談してみましょう💡
  • 何も考えずにサンプルコードのコピペで解決しないようにしましょう(サンプルがそのまま自分のコードにそのまま使えるとは限らないため)
  • 理解できないものをよくわからないまま使い回さないようにしましょう(公式リファレンスなどで情報の裏をとる習慣を身につけると⭕️)

記録とバージョン管理について

  • 打ち合わせや内部ミーティングでは「いつ」「誰が」「どの場面で」「何を」発言した / 行ったかの記録を残す習慣をつけましょう
    →設計・実装・テスト時も同様に、客観的な証跡が重要です。そのためソースコードやドキュメントの適切なバージョン管理が極めて重要になります(人間の記憶は揮発する)

業務ドメイン[2]・業務知識を理解すること

  • 今自分が書いているコードはどのような「業務・サービス」を具体化しようとしているのか？をよく考えてみましょう。一人で考えても分からないときは周りのメンバーに協力を仰ぎましょう。
  • どのような「業務・サービス」をシステムに落とし込むべきか、最初エンジニアは何も分かりません。そういった情報は、お客さんや営業さんの方が詳しいので、ドメインに関する疑問はステークホルダー[3]の立場の人に質問するのが良いでしょう💡

課題解決と設計実装作業の関係性を考える

なぜその機能が必要なのか・その機能は業務ドメインの中でどのような振る舞いを求められるかを考える

自身の作った設計・実装がなぜこの形になったのかを考える

☕️ 余談 開発環境(物理)・習慣について

タッチタイピング(ブラインドタッチ)

  • 出来ると案外生産性が高まります⤴︎
  • また、手元と画面の視線の行き来の回数が減るので、目や首の負荷軽減につながります(画面に視点を集中できるため)
  • 練習に7〜10日はかかりますが、一度身につけばドキュメント作成・コーディングの速度は上がる(まとまった連休などを利用して練習に当てるのが良いでしょう⭕️)

キーボード・マウス

  • キーボードは特に重要、家電量販店などで自分に合ったものを探して使ってみるのがよいでしょう
  • タッチタイピングに慣れているのであれば、分割キーボードを導入すれと、体勢的に胸部が開くので身体にかかる負荷を抑えられるでしょう(猫背・巻肩対策)
  • マウスも自分の手にあった形・大きさで選ぶのがよいですが、遅延なく操作できるものであればなんでもいいと思います
  • お小遣いに余裕があるのであれば多ボタン対応のマウスを使うことで作業が捗ります(コピーペーストなどよく使う操作をボタンに割り当てることができます)
  • 作業机が手狭な場合はトラックボールがおすすめです

https://www.logicool.co.jp/ja-jp/products/mice/m575s-ergo-wireless-trackball.910-005877.html

机・椅子(在宅勤務時)

健　康　は　大　事　！

  • エンジニア・デスクワーカーの大敵、肩こり・腰痛・腱鞘炎から身を守るアイテム
  • 可能な限り椅子と机の高さは自分の身体にあったものを選ぶことをおすすめします
  • 身体に負荷のかからない環境づくりは地味ですが重要です(どんな仕事も身体が資本)

https://amzn.asia/d/6t1g5sS

電動式昇降デスクはちょっとお高いのですが、クランクを回して手動で高さ調整できるものもあります(お値段も安め)

モニター

健　康　は　大　事　！ (2回目)

  • 眼精疲労に注意
  • ノートPCのモニターの高さが低いと目も肩も疲れやすくなるので、PCスタンドなどを用意して負荷の少ない姿勢で作業できた方が良いでしょう

https://amzn.asia/d/7bPUNQx

  • 部屋の明るさに合わせてモニターの輝度や寒暖色の設定をするだけで目にかかる負担がかなり抑えられる
  • 少し暗め・暖色に設定すると良い感じになります
  • 在宅勤務の場合は明るすぎず、蛍光灯の光よりも少し抑えた照度の環境で作業すると良いです(暗すぎるのは❌)

定期的に身体を伸ばす(年齢性別問わず)

健　康　は　大　事　！ (3回目)

  • 長時間のPC作業は巻肩(肩の姿勢が内側に固まること)・猫背・首の前傾姿勢に注意
  • 勤務中1回5分を数回で良いので肩や首、足腰の筋肉を伸ばす・ほぐす
  • 気持ちもリフレッシュされるので生産性も高まる

定期的に陽の光を浴びる・外の空気を吸う

こちらも気持ちがリフレッシュされるので生産性が高まる(1日5分で良い)

定期的に他のメンバーと会話・テキストチャットすることの効果

  • 特に午後〜夕方にかけては疲労や眠気で生産性が下がりがちになる☔️
  • そこで、あえてその時間帯に打ち合わせの時間を設けたり、1on1の時間を作る、出社しているなら休憩スペースでお茶でも飲みながら他メンバーと仕事の話をし合う(ほんの5〜10分でも頭が冴えるので生産性UPが見込める)
  • 在宅勤務時は作業しながら・休憩がてらオープンスペースでのテキストチャットや通話するのも⭕️

オープンスペースで雑談することの効果・密室で会話することのデメリット

  • ❌ DMのクローズドなやり取りが頻発するとメンバーの人となりが分からず仕事がしにくくなり、業務そのものに支障をきたし得る
  • ⭕️ そのため仕事の会話や雑談はオープンな場所で行うのが望ましい
  • 雑談とはいってもそこから知見共有の機会に繋がることもあるので、結果的として参加者にとって知識獲得・スキルアップの良いきっかけになります💡
    (プライベートな内容・プライバシーに関するやり取りに関しては個別DMや個別面談を活用するとよいでしょう)
  • テキストチャットであれば、忙しい人はあとで確認すればよいし・もくもくと作業することが向いているタイプの人には初めから参加を強要しなければよいでしょう
  • 他メンバーの仕事の混み具合なども全体で共有できるためリーダー・管理職側もタスク調整等がしやすくなる
  • メンバー間のやりとりを可視化・見える化することが大事。縦の繋がりも横の繋がりも円滑になる

参考図書について

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

https://bookplus.nikkei.com/atcl/catalog/16/P51550/

エンジニアの知的生産術――効率的に学び，整理し，アウトプットする

https://gihyo.jp/book/2018/978-4-7741-9876-7

問題解決大全 ビジネスや人生のハードルを乗り越える３７のツール

https://www.forestpub.co.jp/author/dokushozaru/book/B-1822

次回予告

次回は実際に手を動かしつつ、開発に必要な環境を作っていきます。
やることは山積みですが、一つずつ順次片付けていきましょう💪

  • VurtualBoxのインストール
  • Linux(debian)の導入・初期設定
  • Visual Studio Codeのインストール

いちから伝えるwebシステム開発③ 環境構築編(仮想環境とかSSHとか)

脚注

  1. 言語やフレームワーク・ライブラリの公式リファレンスサイト、開発者のGitHubのREADMEなどを指します ↩︎

  2. domain・・・「範囲」「領域」、ここでいう業務ドメインは、そのシステム化するお客さんの業務の領域・境界を指します https://xtech.nikkei.com/atcl/nxt/column/18/01195/011900031/ ↩︎

  3. 「利害関係者」という意味の言葉です。ここではシステムを利用して行う業務そのものに関する深い知識を持った人物を指し、システム開発ではステークホルダーとなる人物がシステム及び業務を俯瞰的に理解・判断することで、必要な機能の洗い出しや機能改善についてエンジニアと話し合い(ステークホルダー・ミーティング)その上でシステムの機能に落とし込むことになります https://www.itmedia.co.jp/im/articles/0710/15/news104.html ↩︎

  4. 「銀の弾丸」という言葉があります。『人月の神話』という本にも登場する、あらゆる問題・課題を一撃で解決できるような方法は存在しない、という意味で用いられています ↩︎

  5. 既存のソースコードの動作・振る舞いを変えることなくソースコードを修正し、より読みやすく・改修しやすく・壊れにくくする為の作業を指します。振る舞いを変えずに修正を行う必要がある為、リファクタリングの際はテストコードの導入によるデグレーション[6]を防ぐことが肝心です ↩︎

  6. デグレーション(デグレ)・・・「悪化」「退化」という和訳の通り、修正を加えたソースコードが元は正常に動作していたにもかかわらず、結果他の箇所で不具合が発生する状態を指します。こちらもテストコードの導入によってデグレーションを未然に検知・防止することで対処出来ます(このテストを「リグレッションテスト」と言います) ↩︎

Discussion