エンジニアが自然と意識していることについて(･ｘ･ ) ｡oO

最近、*エンジニア的な仕事を経験した人との仕事の方が物事が進みやすく、いい成果が出ると感じております。

また、社会的な流れとして小学校でプログラミング教育が必修になりました。プログラミングのスキルを身につけることもさることながら、それを学ぶ上で身に付く思考法を重要視しているとも言われています。

最近の所感と社会的な流れを踏まえて、プログラミング/エンジニアリングのスキルというよりも、それらを身につける中で自然と意識できるようになっている&汎用性の高いことについて書きました。

0. 目標を達成するために計画を立て試行錯誤を繰り返す
1. 事実を整理して相手に伝える
2. 準備をしてから手を動かす
3. 影響範囲を考えて行動する
4. 本当に必要かを考える
5. ベストプラクティスがないから、守破離にしたがってその時点での最適解を考える

この6つのことは仕事をする上でも参考になると思います。

*「エンジニア的な仕事」とは、一般的にイメージされるコードをゴリゴリ書くだけではなく、SaaS系のサービスを触ってシステム構築したり、CMSでサイトを立ち上げてみたり、など情報化社会のツールを駆使した経験も含んでいます。

プログラミング教育では目標を達成するために計画を立て試行錯誤を繰り返す力を身につける

まず、簡単に社会流れの押さえておきます。

プログラミングの教育が小学生で必修の科目となりました。情報社会において、情報技術を理解することは必須であり、将来の可能性を広めるためにも重要だと考えられています。それだけでなく、プログラミングを学ぶ過程で「プログラミング的思考」を育むことも目的とされています。

「プログラミング的思考」は抽象度が高い言葉ではありますが、文部科学省では下記のように定義されています。

プログラミング的思考を端的に言い換えると「目標を達成するために計画を立て試行錯誤を繰り返す力」です。

今までの教育では「試行錯誤を繰り返す力」を身につけることは実現できていたと感じます。ただ、今までの学校教育は、先生がカリキュラムを考え宿題を出し、生徒がそれらをこなすことがで主だったので、「計画を立てる」ところに関してはできていませんでした。

自分自身プログラミングをやっていて「計画を立てる」ことが知らないうちに身についていたので、その力を身につけるためにはプログラミング教育は非常に有効な手段だと思います。

このように、幼い頃から技術に触れ、プログラミング的思考法を身につけた人が多く出てくる社会になっていきます。

自分の周りの方達でエンジニアリング的なことをやってる人はこの「プログラミング的思考法」が身に付いていると感じます。逆にエンジニアリング的なことをやってない人は、「プログラミング的思考法」が欠如してると感じます。後者はこれからの社会にとってはかなり不利になります。

プログラミング的思考法は「目標を達成するために計画を立て試行錯誤を繰り返す力」と説明しましたが、それ以外にもエンジニアリング/プログラミングを学ぶ中で身に付く

1. 事実を整理して相手に伝える

プログラミングでエラーに遭遇してなかなか解決できない時にはstack overflowという質問サイトでよく質問をします。日本語だとTeratailが類似サービスとして有名です。
ただ、これらのサイトには無数の質問が投稿されるため、単に質問をするのではなく、他の方が回答しやすいように質問の仕方を工夫する必要があります。

質問をする際のTipsについてTeratailの「質問するときのヒント」に詳しく記載されています。

このように、ただ「エラーが起こりました。教えてください。」とだけ伝えるのではなく、現状を整理して質問することが推奨されてます。
私も質問する時はこれらのフォーマットを意識して質問するようにしていました。また、このフォーマットで質問をまとめる過程で情報が整理され、自分で解決できてしまうということも多々起こりました。

相手に理解されることで初めてコミュニケーションは成立します。
プログラミングをやったことがある人は、エラーを解決のために上記の質問を繰り返し行うことで、「事実を整理して相手に伝える」力が自然と身についているのか感じます。

2. 準備をしてから手を動かす

行き当たりばったりで物事を始めて、後から「こうしておけばよかった！」と反省することは多くの人が経験しているのではないでしょうか。
と同時に、方針を改めれば何とか巻き返せる場合も多くあると思います。

しかし、プログラミングに関しては基本的に相互作用で積立式の成果です。つまり、Aが達成したら、Bに進むことができますが、AなしにBを進めることはできないことが多いです。完成目前で最初の設計がにミスがありゼロからやり直しと、途方にくれるケースも頻繁にあります。

こうしたことを防ぐため、実際にプログラミングを始める前には、どのような設計で、どのように進めるか事前に準備をします。

具体例を話すと、以前開発したTipJPYCはプロジェクトを開始してローンチまで3週間強でしたが、1週間半ほどは設計や要件定義などの実際に手を動かさない準備に時間をとっていました。

準備をぜずに進めると悲惨になることを知っているからこそ、事前に準備をして進める力が身についていると感じます。

3. 影響範囲を考えて行動する

チームでプログラミングをする際は、同じコードを共有しながら作業をします。とてもざっくりですがチーム開発は下記の流れで開発します。

• タスクを洗い出す、それぞれのタスクにアサインする

• 同じコードをローカルのパソコンにダウンロードする

• ローカルのパソコンでタスクに関係するコードを変更する

• 変更点を他のメンバーに共有する

• 他のメンバーに自分が変更したコードを反映してもらう

コードはGithubというサービスを使って共有しています。
この流れで一番注意すべきところは「３」です。「３」の時に自分の変更点と他の人の変更点が被ってしまうことを「conflict」と呼びます。
このconflictを解決するのはとても面倒な場合が多く、変更点が反映されないなど様々なバグの温床となる可能性があります。
チーム開発を始めたばかりは、自分のコードの影響範囲を考えることができずconflictを起こしチームメンバーに迷惑をかけたことがあります…..

そのためチームで開発する際は、「自分の作業が相手の作業にどのくらい影響するか」を常に考えながら作業します。

また、チームで開発する際は同じコードをみんなで扱うため、ドキュメントを整備したり、コードにコメントをつけたりして、前提知識を揃えるようにしています。

一般的にエンジニアはコニュニケーションが取れないと言われがちですが、実は周りへの影響を加味して行動するのは得意なのではないかと感じています。

4. 本当に必要かを考える

簡単な機能の追加に見えても、実装するとなるとかなり複雑で、「その機能本当に必要？」となることが多くあります。
なので、やることに対するコストとリターンを算出し、常に優先順位を立てて開発します。

5. ベストプラクティスがないから、守破離にしたがってその時点での最適解を考える

ソフトウェア界隈においては、OSS(Open Source Software)と言ってプログラムが公開されていたり、プログラミングの方法を記事に書いたり、と自身（自社）の知見を積極的に公開する文化が根付いています。
プログラミングに関する情報はインターネットに無数に転がっています。何か困ったことがあったら、それらの情報を参考に真似しながら解決することがよくあります。

このように世の中に情報が溢れているので、何か始める際にはまず先人の知恵を借りるべくとことん事例を集めます。

ですが、プログラミング言語は日々進化しています。記事の内容が古くなっていて再現できないことは頻繁にあります。なので、公式ドキュメントを隈なく読んだり、世の中に出回っている情報を自分なりに加工したりして、自分の中の知識をアップデートしていきます。

もちろん先ほど述べたように、アップデートされた知識もすぐに陳腐化していきます。陳腐化する状況でも、その時点での最適解を見つけて実装していきます。

守：事例をとことん調べる
破：情報を加工して知識をアップデートする
離：現状の最適解を見つけて実装する

この守破離の流れはプログラミングに限らず、物事を進めるにおいても使えると思います。

このように、「情報がオープンだがすぐにその情報が陳腐化してしまう」仕事をいているからこそ、守破離にしたがって最適解を求める力が身に付いているのかと感じます。

おわりに

適当に書き殴ってみました。何かのヒントになれば幸いです。

p.s. 
レバレッジじゃ！！ととりあえずレバレッジをかけて取引して$3000損しました。かそーつーかはムズカシイデスね٩( 'ω' )و