感嘆符（!?）を全角に

onestop-techbook · Dec 18, 2024 · acecfce · acecfce
1 parent 1e89824
commit acecfce
Showing 1 changed file with 5 additions and 5 deletions.
diff --git a/src/chap-forte2.re b/src/chap-forte2.re
@@ -15,12 +15,12 @@ ITエンジニアに必要なスキルとして設計とプログラミングは
 === 実務で通用するとは
 
 ==== 通用するかどうかの判断方法
-自分のスキルが実務で通用するかどうか分からないと思うのであれば、視座を一段あげて考えてみることをお勧めします。もしあなたがマネージャーやリーダーのような指示をする側だったとして、あなたにその作業(設計やプログラミング)を任せられると思えるでしょうか?
+自分のスキルが実務で通用するかどうか分からないと思うのであれば、視座を一段あげて考えてみることをお勧めします。もしあなたがマネージャーやリーダーのような指示をする側だったとして、あなたにその作業(設計やプログラミング)を任せられると思えるでしょうか？
 
 安心して任せられると想像できるならあなたのスキルは実務で通用すると言えるでしょう。逆に不安だな、心配だな、難しいなと思うなら実務で通用するレベルに至っていないかもしれません。しかし安心してください。業務では100%安心して任せられるから作業を指示するということの方が稀です。多くの場合、やったことないけどできそうだからやらせてみる(やってもらう)というケースの方が圧倒的に多いです。
 
 ==== スキルアップの考え方
-そのため逆に言えば、不安や心配な点をカバーできれば実務で通用すると言えます。具体的には「設計書の書き方が不安なので一通り書けたらご確認いただけますか?」とか「実装はできますが、もっと良い書き方があるかもしれないので一通り書けたらご確認いただけますか?(またはペア・モブプログラミングしていただけますか?)」のように自分が不安に思う点を補足するようにすれば十分実務で通用すると言えるでしょう。
+そのため逆に言えば、不安や心配な点をカバーできれば実務で通用すると言えます。具体的には「設計書の書き方が不安なので一通り書けたらご確認いただけますか？」とか「実装はできますが、もっと良い書き方があるかもしれないので一通り書けたらご確認いただけますか？(またはペア・モブプログラミングしていただけますか？)」のように自分が不安に思う点を補足するようにすれば十分実務で通用すると言えるでしょう。
 
 もしそんな不安や心配な点を素直に伝えて大丈夫かなと思われたら安心してください。往々にして現場のリーダーやマネージャーというのはメンバーの教育、スキルアップも業務に入ってます。そのため、メンバーから教育してほしい点を伝えてもらえるのはむしろありがたいことなのです。稀にコイツは使えないヤツだな…のように判断するリーダーやマネージャーがいますが、その場合はこちらから見限るチャンスです。メンバーのスキルアップに貢献できるリーダーやマネージャーの元に移動しましょう。
 
@@ -42,13 +42,13 @@ ITエンジニアに必要なスキルとして設計とプログラミングは
 次にプログラミングにおける実務で通用するスキルについて考えてみます。これは単純です、実装できるかどうか、その環境で求められる品質やルールに適したものにできるかどうかです。
 
 ==== 実装できるか
-まず実装できるかどうかは単純ですね、そのプログラミング言語で要求されたプログラムを書けるかどうかです。これも何も調べずに書ける必要はありません。細かい文法などは調べながら書いてもいいですが、書こうと思った際に何からしたらいいんだろう?と固まってしまうようであれば実務で通用するとは言えないでしょう。もちろん詳しい人に助けてもらいながら進めて良いのですが、事前に助けてもらうことを明言してから進めるのと、できますと言ってから助けてもらうのでは印象が異なります。もし不安や心配事があるのであれば、できるかどうか確認する(検討する)のでちょっとお時間をくださいのように予防線をひいておくのもいいでしょう。
+まず実装できるかどうかは単純ですね、そのプログラミング言語で要求されたプログラムを書けるかどうかです。これも何も調べずに書ける必要はありません。細かい文法などは調べながら書いてもいいですが、書こうと思った際に何からしたらいいんだろう？と固まってしまうようであれば実務で通用するとは言えないでしょう。もちろん詳しい人に助けてもらいながら進めて良いのですが、事前に助けてもらうことを明言してから進めるのと、できますと言ってから助けてもらうのでは印象が異なります。もし不安や心配事があるのであれば、できるかどうか確認する(検討する)のでちょっとお時間をくださいのように予防線をひいておくのもいいでしょう。
 
 ==== 求められる品質やルールを満たせるか
 次に品質や開発ルールに則っているかが求められます。必要なエラー処理が抜けていたり、エラーや例外が発生した際に適切に処理ができいない、DRY原則やYAGNI原則に反しているなど書けているし動きもするが、リリースできる状態にないコードでは実務に通用するとは言えないでしょう。ここで現場でありがちな例が、品質の悪いプロジェクト内のソースを参考にしてしまい指摘されてしまうケースです。これはスタートアップでとにかく早くリリースすることを目的としていた場合や有識者が少ない(いない)場合、デスマーチでとにかく納期に間に合わせた場合などに起こりがちなのですが、DRY原則に反していても、多少のエラー処理がなくても動くのならリリースしてしまったことにより技術的負債として残ったソースであり、それを知らない人がこのプロジェクトはこのレベルでいいんだなと真似して実装するとレビューで指摘されてしまうというものです。
 
 ==== 事前に求められているレベル(期待値)を確認する
-これはまず期待値を調整すると回避できることが多いです。具体的には参考にできる既存ソースはこれでよいですか?や参考にするにあたって注意点はありますか?など参考にする際にお互いの期待値を調整すること、またはこれから実装するソースは品質優先か速度優先かどちらなのか、もし実装上で守るべき開発ルールや原則があれば教えて欲しいなどのように期待値調整するのも有効です。これにより環境に合わせて適切な品質のコードを提出することができるようになります。これなら実務に通用すると言えるのではないでしょうか。
+これはまず期待値を調整すると回避できることが多いです。具体的には参考にできる既存ソースはこれでよいですか？や参考にするにあたって注意点はありますか？など参考にする際にお互いの期待値を調整すること、またはこれから実装するソースは品質優先か速度優先かどちらなのか、もし実装上で守るべき開発ルールや原則があれば教えて欲しいなどのように期待値調整するのも有効です。これにより環境に合わせて適切な品質のコードを提出することができるようになります。これなら実務に通用すると言えるのではないでしょうか。
 
 == 実務で通用するスキルの学び方
 
@@ -59,7 +59,7 @@ ITエンジニアに必要なスキルとして設計とプログラミングは
 定義で確認したとおり、設計においてどのようなスキルが必要なのかはその環境などによって変わってしまいます。そのため、学び方としては一般的な開発知識として設計論を学ぶ方法と、いまいる環境に合わせて学ぶ方法の大きく2通りが考えられると思います。一般的な開発知識としての設計論は「システム開発 設計論」などで検索すれば技術書がヒットすると思いますので、それらから学ぶことができるでしょう。書籍以外にもUdemyなどにも設計に関する講座があるので購読してみても良いかもしれません。
 
 ==== 現場に合わせて学ぶ方法
-次にいまいる環境に合わせて学ぶ方法は、そのプロジェクトですでに作成されている設計書やドキュメントを参考に自分が担当している機能の設計書を書いてみたり、そのプロダクトに機能を新たに実装するとしたらどんな設計書やドキュメントを書く必要があるか考えて実際に書いてみるなどが良いでしょう。可能であればそれらをチーム内の誰かにレビューしてもらうとより学びが深まります。実際に作業することも大事ですが、フィードバックをもらうことも大事です。人はどうしても視野が狭くなりがちです。自分では問題ないと思っていても客観的にはそうではない、またはもっと良くするための新たな視点が必ず存在するものです。そう言った意味でフィードバックは重要と言えます。もし、チーム内でフィードバックをもらうのが難しいのであれば、外部でもらうことも検討しましょう。その際は機密情報漏洩にならないようにシステムや用語を一般的なものに置き換えたものに対してフィードバックをもらうようにします。例えばYoutubeにコメントが流れる機能を付けるとしたらどうすればよいか?などを考え、必要な設計書を書いて誰かにレビューしてもらうなどのイメージです。工夫すればできることは必ずあるはずです。
+次にいまいる環境に合わせて学ぶ方法は、そのプロジェクトですでに作成されている設計書やドキュメントを参考に自分が担当している機能の設計書を書いてみたり、そのプロダクトに機能を新たに実装するとしたらどんな設計書やドキュメントを書く必要があるか考えて実際に書いてみるなどが良いでしょう。可能であればそれらをチーム内の誰かにレビューしてもらうとより学びが深まります。実際に作業することも大事ですが、フィードバックをもらうことも大事です。人はどうしても視野が狭くなりがちです。自分では問題ないと思っていても客観的にはそうではない、またはもっと良くするための新たな視点が必ず存在するものです。そう言った意味でフィードバックは重要と言えます。もし、チーム内でフィードバックをもらうのが難しいのであれば、外部でもらうことも検討しましょう。その際は機密情報漏洩にならないようにシステムや用語を一般的なものに置き換えたものに対してフィードバックをもらうようにします。例えばYoutubeにコメントが流れる機能を付けるとしたらどうすればよいか？などを考え、必要な設計書を書いて誰かにレビューしてもらうなどのイメージです。工夫すればできることは必ずあるはずです。
 
 === プログラミングスキル