https://jp.quora.com/%E4%BB%8A%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9E%E3%83%BC%E3%81%AB%E6%B1%82%E3%82%81%E3%82%89%E3%82%8C%E3%82%8B%E6%8A%80%E8%A1%93%E3%81%AF%E4%BD%95%E3%81%A0%E3%81%A8%E6%80%9D%E3%81%84%E3%81%BE%E3%81%99
プログラマとしてコードを書く人の観点ですと
技術というよりも能力って感じのイメージでしょうか。
- 概念やコンテキストを理解する力
- アーキテクチャの設計や考え方に興味関心があり議論に参加ができる
- スコープを切り分ける時に無駄のない仕組みの技術の考え方ができる
- チームやプロジェクトで同じ景色で概念を見通すことができる
- コードを論理的に書く能力
- 無駄のない処理フローチャートをコードで表現ができる
- その場しのぎのコードを書かない
- チームとしてコードを書く時に全体感を見通して論理的につなぐことができるコードを意識できている
- コミュニケーション能力
- 必要な要件を満たしているか、満たすためのクリティカルパスは何かを意識ができる
- 問題点を見つけた場合にすぐにレポートやトラブルシューティングができる。
- 問題のレポートをすぐに伝達できる
- 被害を最小限に抑えるための改修や行動ができる
- チームや多人数プロジェクトの場合、ネガティブな言葉を使わずに生産性の高いアウトプットができる
- 見積もり能力
- 工数の見積もりが適切か見積もることができる
- Aさんの見積もりだと１週間、Bさんの見積もりだと3日、実際は3日しかかからなかった。実際は１週間かかってしまった。プロジェクトへのインパクトを予算内かつ無駄なく貢献ができる
- スケジュールへの工数落とし込みができる
- WBSを引くために参考となるスケジュールや工数が見積もることができプロジェクトマネージャーへ連携ができる
- 言語の理解と仕組みの理解
- プロジェクトで利用する言語の得意/不得意部分と不得意部分の対応策やベストプラクティスの理解理解
- その言語のキレイにかけているライブラリや参考にする書き方などを熟知しておく
- ライブラリや既存コードでよりベターな選択肢を選定をする能力
- 一般的なアルゴリズムや仕組みを知っておく（ソートの仕組みなど）
- バブルソート、クイックソートなどメモリ、処理ステップ数など意識ができるかどうか
- 会員登録をする場合に、最低限必要の情報や抜け漏れがないかいろんなコンテンツを熟知しておくなど
- 課金系コンテンツを作る場合に一般的な遷移や処理フローが意識できコーディングに落とし込める
- OSとプロセスの動き方への熟知
- LinuxベースやWindowsベースで動作が異なる場合があるので熟知しておく
- パフォーマンス観点でCPU/メモリの使用量を意識してコードが書ける
- 大きなファイルやデータを扱う場合Disk I/Oのパフォーマンスも意識できる
- I/O waitがボトルネックとなった場合に原因はなにか？など突き止めることができるなど
- パフォーマンス向上施策に対する知見を持っておく
- 一般的なキャッシュの仕組みや概念などは同じアーキテクチャでクリアできるので一般的な使い方をよく理解しておく
- データベースや共有資源に対してオーバーヘッドを意識することができる
- メモリサイズを意識してオンメモリで処理できる限界やバランス感覚を意識することができる
- ネットワークへの知見
- 最近はネットワーク経由でのデータやりとりやプログラミングが多いので理解する。必須は以下
- TCP/IP・UDP
- HTTP(s)
- DNSの仕組み
- 一般的な配信データjson,xmlなどの形式をparseできる
- ネットワーク越しのデータのやりとりは回数が増えるほどオーバーヘッドやリクエストの処理回数が増えるのでまとめて処理をするなどパフォーマンスを意識したデータ送受信フローを考える
- セキュリティルールやアクセス権について対応ができる
- 外部セグメントからのアクセスを制限できる知見がある
- 必要なアクセス権限を持たせ必要以上にフルアクセスさせない
- セキュリティーへの知見（コードを書く上で）
- 一般的に使われるクロスドメインの仕組み
- CSRFなどの仕組みやクロススクリプト対策
- SQLなどにインジェクションされない仕組みを使ったコーディング
- IP/Portなどで制限をかけ必要最低限のルールで運用
- 必要なログデータなどを判断して残すことができる
- 課金決済/ポイント系は決済ログなど追えるような仕組み
- アクセスログや問題のあるログをあとからチェックやフィルタをかけられるように残せる
- マーケティング分析に必要なログデータを必要な時にすぐに準備や理解ができる
- ビジネススキルとマーケティング知識
- WEB系だとマーケティングの広告などの仕組みを知っておく
- アフィリエイトや広告での成果、機械学習系での最適化がかかる項目をしっておく
- 広告のCPA/CPCから売り上げ粗利のROASなどの議論ができる
- 広告費の無駄を減らすためのアドバイスと技術的アプローチができる
- WEB系以外の場合（例えばtoB向けの経理/会計システムの場合）
- 業界の最低限の知識を競合サービスなどを利用して確認できる
- 一般的な会計や計算方法などを理解ができコーディングできる
- 日時・月次・年次処理など締め処理や一般的に必要な集計処理を期待した上でデータの整理ができる
書き始めると無限に書ける気がしますね。
下に行くほど必要なさそうに見えますが
プログラマとして理解しておくと話が早く
一緒に仕事をしてほしいと求められることが多いと思います。
所謂Web屋やサバクラやって(た|る)人間として、かつ、直後の段落とも関係しますが「技術」というか「技能」としての回答になります。
職業、趣味問わない範疇ならば「不易流行」を理解し、それを見抜く能力を持つ事でしょうか。
時代が移ろうとも変わらない物事が「不易」、その時々において斬新とされたものが「流行」となります。
2000年代のソフトウェアハウスの経営者の間で流行っていた言葉です。
当時は「老害がなんか言ってるｗｗｗｗ」とか莫迦にされていましたが、今この場でも使える通り、まさに「不易」な言葉ですね。
そもそも松尾芭蕉が説いてから331年もの時を超えるほどの筋金入りの「不易」なんですけどね。
職業プログラマに必要とされる技術だったらば、今昔問わず「業務を高速に理解するために必要な技術」となります。
- 資料を読み解く能力。
- 読み解いた能力を概念として再構築出来る能力。
- 業務上使う用語・単語を様々なコミュニケーションの中から蓄積する能力。
などなど・・・
まぁこれは最近流行りのドメイン駆動設計におけるドメイン知識の確立やユビキタス言語に自身をなじませる事と同義ですが。
今後、流行りの潮目が変わり、ドメイン駆動設計が旧いものとなってもそのまま使えます。
さて、業務も転職なり時代が変化するりすれば移ろいゆくものです。
業務に依存しないプログラミング能力としての技術は次のものとなります。
- 推測するな計測せよ
- 1に計測、2に計測。計測が出来ていない場合、危機的状況にあると考えてください。
- パフォーマンスや今後の推移をみる場合は「そういわれているからこうしました」や「なんとなく」ではなく、計測し、数値を出して話をしましょう。
- 一度読んだ知識を永続的に信用するな
- 言語やミドルウェアのバージョンで前提がひっくり返ることはままあります。
- 定期的に調べなおした方が良いでしょう。
- 今使っている環境の得手、不得手、癖を知る事
- 昔の話となりますが、PHP5系くらいまではPHPではユーザ定義関数の呼び出しがパフォーマンスに影響するレベルでコストが掛かっていました。
- フレームワークの速度差がユーザ定義関数のコール数で明確に差が出るほど。
- XHProfを用いた計測ではCodeIgniterが4,000コール弱、FuelPHPで13,500コール近辺、Symphony2が36,000コール近辺。最大でレスポンスに数百ミリ秒の差が出るほどでした。
- 自作のフレームワークでもユーザ定義関数のコール数を15,000から6,000まで減らしたところ、レスポンスが100ミリ秒速くなりました。
- なお、上記の話はPHP自体の高速化により、今では実質考慮不要のものとなっています。
- 定期的に調べなおすの大事ですね。
- 「知的握力」の維持
- 「概念を考案」「あり得る可能性の考慮」をしたりする際に、「そんなに考えてもしょうがない」「難しく考えすぎ」などと言って思考を手放さないこと。
- 大抵の事はまともに考え計測していれば「やる前から判る」事です。
- これは意識的に考える習慣を持ち続けないと直ぐに衰えます。
- "目的"指向で意思決定する
- 「何のためにそれをやるのかを考えて」検討・実装できること。
- 何らかの選定時にどの「技術を用いるか」"だけ"で迷っている場合は、大概目的が明確になっていません。
- コードツリーを全体構造として俯瞰する能力
- マイクロな所だと「本当にそこでDBにアクセスする必要ある？もっと手前でアクセスすればINを使えるからクエリの発行を1本に出来るよ？」など。
- 「その単発のDBアクセス持ってる関数、ループの中で呼ばれている上にそのループを持つ関数もループから呼ばれているんだけど・・・」などもあります。
- 「単発のアクセスだからいっかー」として書かれたちょっと重たいクエリが100回コールされるメソッドから100回コールされて都合10,000回実行されるなど・・・
- 自律
- 「死ね」「バカ」などの威力と悪意のある事は言わない、言わせない。
- 耳に入った全員のパフォーマンスが25%程度低下するとの研究もあります。
- 同様に頻繁な「ため息」もよくありません。
- あなたのお気持ちの発露は本当にチーム全員のパフォーマンスを25%低下させるだけの価値がありますか？
- 人の良かった「行動」を具体的に褒める。
- 手始めは両隣、次はチーム、うまく行けばフロア全体の感じが良くなり、様々な物事が少しだけスムーズに進むようになります。
最後に。
プログラミング関連に限らず、様々なものごとを知るようにしましょう。
「書を捨てよ、街に出よう」と言ったところでしょうか。
例えば・・・
かつては自動車業界の生産技法を知るとシステム開発技法について世間に先んじる事が出来ました。
20年近く前から日本で流行っているアジャイルやリーンソフトウェア開発に繋がる話です。
この技法の源流はトヨタ生産方式にあります。
また、軍事を知ると改善や意思決定手法について先んじる事が出来ました。
最近話題になり始めているOODAループですが、これは朝鮮戦争における戦闘機パイロットの戦訓から得られたものです。
なんと70年前の技法なんですよね。
あらかじめ軍事における意思決定手法に興味があれば70年分世間を先んじれましたね。
他にも「ちょっと良い値段のする個人レストランで料理人が何を考えて意思決定をしているのか」や「この絵画はなぜこの順で色を塗る必要があったのか」など一見、プログラミングと無関係に見える事柄からも学びやインスピレーションを得る事が出来ます。
「プログラミング技術」や「直接的な趣味以外の物事」にも興味・関心を持ち、触れてみる事で、流行に流される事の無い、不易な価値を自分にもたらすことが出来ます。
そしてそれはどんな時代の「今」でも求められる技術として求められるでしょう。
技術では有りませんが、能力ではパターン認識力を最重視しています。要件定義、ロジック構築、関数・モジュール分けで違いが出ます。
パターン認識の弱い人はロジックの再利用に関しても意識が低い傾向に有ります。呑込みの良い人はパターン認識力が高いと思います。
その辺りを意識して指導すると、グイグイと吸収してくれます。ベタベタにコードを書いている人は、プログラム内の関数分けもブサイクです。
コードは下に行く歩度ネストが上がり、最後にカッコ閉じで元のインデントにはね戻る傾向に有ります。こういったコードは作るときは良いのですが、修正を加える時に手を取られます。メンテナンス効率を考えると、汎用的な二度と手を加えなくても良い機能を独立させてモジュール化しておくことが重要です。
よくネットでは効率（速度としての）を論じられていますが、自分はむしろメンテナンス効率重視すべきだと思っています。 } (改行) else { としているのも処理ブロックごと移動しやすくするためです。
余談ぽい気もするのですが、 OA系の開発では構造体配列の処理が多く出ます。この時構造体は配列と同じくアドレスでハンドリングされていることを意識しないととんでもないことになります。今も仕事中にBluetoothキーボードでスマフォに打ち込んでいますが、目の前の画面ではJavascriptの汎用配列モジュールの試験画面がgvim 4分割画面で開発試験中です。これはどれだけ関数に受け渡しても元の値を書き換えない事を目的としています。
なにかダッチロールした感は有りますが、プログラミングに関わらずあらゆる業務でパターン認識力は重要と考えます。
いい質問ですね。
世の中には様々な技術があります。例えばScrum。「柔軟かつ全人的なプロダクト開発ストラテジーであり、共通のゴールに到達するため、開発チームが一体となって働くこと」を目標とした開発手法です。
スクラムガイド by Ken Schwaber & Jeff Sutherland
そして、2019年の開発言語のトレンドは1位 Go (37.20%)、2位 Kotlin (26.45%)、3位 Python (26.14%)です。
さらに、JavaScript Frameworkでは、React JSフレームワークのアングル構造とAngularが持つサーバーレンダリングに軽量の双方向データバインディングアプリケーションを開発する理想の選択肢であるVue.jsなどがあります。
不具合と向き合う
ただし、どんなに素晴らしい技術を持ってしても、無意味どころか被害を生み出してしまう。それは不具合です。
「不具合」関連の最新 ニュース・レビュー・解説 記事 まとめ
これだけ新しい技術が生まれても、未だに不具合は増える一方です。なので、不具合を先に見つける事に着目した、テスト駆動開発という技術があります。
設計と向き合う
しかし、不具合なく作ったとしても、そもそも設計が間違っていたら無駄になります。文章で書かれた設計に対して事前条件、事後条件、不変表明を明確にする「契約による設計」という技術があります。
Building bug-free O-O software: An Introduction to Design by Contract™
納期と向き合う
これで、あなたは正しい設計で不具合のないプログラムを開発できるようになりました。ところが納期までに人も時間も足りません。こんな時は早く開発することが求められます。そのために過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し、名前をつけ、再利用しやすいように特定の規約に従ってカタログ化した「デザインパターン」という技術があります。
なお「デザインパターン」はオブジェクト指向をベースとしています。よって事前にオブジェクト指向を理解する必要があります。ここでは一般的なJavaかC#で学んでみるのが良いかもしれません。
余談ですが、構造化プログラミングを考案したエドガー・ダイクストラの抽象データ構造と階層的プログラム構造を基礎にオブジェクト指向は生まれました。構造化プログラミングはソフトウェアに必要な機能と，それぞれの機能で使用するデータの流れを分析／設計する手法（構造化手法）です。このように，機能（処理）に着目して開発する手法をプロセス中心アプローチ（POA：Process Oriented Approach）又はプロセス中心設計といいます。構造化設計には，処理効率の向上，保守の容易化，モジュール の部品化（再利用）などのメリットがあります。
シンプルになる
おそらくは、この一連の技術は今も昔も、そしてこれからも求められるものだと思います。そして、これらの技術をより深く理解したプログラマーは、複雑で難解なロジックをシンプルなコードで解決します。
普段は目立たないものですが、プロジェクトによっては何十人もの人が何ヶ月も掛けて作ったものを、一人だけで僅か数週間で作ったりします。その磨かれた技術は芸術的な才能といった方が、近いかもしれません。
｢文章にしろ、和音にしろ、リズムにしろ、美しく、優雅なもの、優れたものはすべて、シンプルである｡」
プラトン
「プログラマー」とひとくくりにするのが難しいご時世なのかな、と思います。
知人に非常に優秀な「プログラマー」が多数いますが、彼女ら彼らの活躍するドメインは多様であり、プログラミングの性質も大きく異なります。少し例をあげますと
- エンドユーザに最適な体験を届けるためのモバイルUIを作っている
- 効率的にモバイル端末が動作するようにシステム側で無駄なく要求を処理するようにロジックを組んでいる
- モバイル端末が効率よくネットワーク通信を行えるように上層のアプリケーションと仮想の無線ハードウェアモジュールとの媒介をするソフトウェアモジュールを組んでいる
- エンドユーザがよりお買い物をするようにWeb UI上でA/Bテストを実施するためのWebフロントエンドを作っている
- A/Bテストを出来るようにフロントエンドに関連した情報を送る機構を作っている
- HTTPが高速になるようにCDNを効率よく使えるようロジックを書いている
- そのCDNを作っている
- 長いなぁ
- Railsバックエンド、Djangoバックエンド
- リアルタイム動画処理、GPUを効率良く使う
- ハイパフォーマンスコンピューティングでLU分解を高速に解くアルゴリズムを特定のハードウェアに特化して実装する
- ハードウェアを高級言語で記述する
- その高級言語を作る
- あーもう
- 各業界、例えば物理・化学・金融・建築、それぞれに必要なソフトウェアを作る
- ٩(′д‵)۶やーめた
このすべてが、いわばざっくり「プログラマー」の仕事であります。
「論理的に考える」といったことも当然重要です。ただそれは「プログラマー」に固有の話ではなく、「教養も大事」などと同じ、社会人が一般的に持つべきスキルや素養の話である気もします。質問が「プログラマーに求められる技術は何か」なわけですから、社会人一般ではなく「プログラマー」に特徴的に求められる要素を、ここでは集中して考えてみたいです。
とすると、……何が必要な「技術」なんでしょうね。
「プログラマー」の扱う領域は、既に述べました通り広大です。それは「プログラム」「ソフトウェア」と称されるものがあまりに強力かつ汎用すぎることの裏返しだと思います。多くの人が「プログラム」という言葉ひとつにあまりに多くの期待を込めすぎてしまうのも、そのためでしょう。
であるとすれば、それぞれの「プログラマー」にまず必要なのは、「自分が何を期待されていて、何に貢献できるのか」を効果的かつ効率よく見抜く技術かもしれません。
「俺は○○を得意とするプログラマーで、✗✗は知らない」そういうことを判断出来ないと、気づくと自分が力を発揮できないことを手伝わされていて、己の満足度も相手の評価も低くなってしまう、なんていうことがあり得ます。
起こらないようでいて、起こるのです、これ。
例えば、コンピュータ・サイエンス（CS）を大学で学び、自信たっぷりのソフトウェア開発者が、スマホのアプリを作ることになったとします。
確かに、CSの知識が生きる場面もあるのです。ただし、モバイルアプリの世界ではモバイルプラットフォームが変化する中で作用するソフトウェアの「力学」と、エンドユーザが満足するデザインについての理解が、CSのような基礎以上に頻繁に求められることは、どうしても多くなります。
「力学」とここで言っているのは、例えば「このプラットフォームでは以前こういう作り方が鉄板だったのだが、最新バージョンでXXという機能が追加されたことで、この作り方がアンチパターンになってしまった」といった変化が良く起こることを言っています。「これを使えば、複数のプラットフォームを一つのコードでサポート出来るよ！」みたいな「技術」の登場も「良く」起こります。
また、CSの教育過程でUI・UXの実践に重きを置くケースはまだあまり多くないと思います。モバイルプラットフォームを作る側がCSの知見を元に良いバランスの独自のプラットフォームを出し、コミュニティが不足を補う第三者ライブラリをうまく使えば、あまり「計算量」のようなことを意識する機会は多くないかもしれません。
すると、その「プログラマー」に求められる「技術」はCSに則った「計算量」「ハードウェアアーキテクチャ」のような「基礎」では必ずしもないかもしれず、エンドユーザを満足させるデザイン手法、考え方（例えば「ダブルダイヤモンド」とかかな？）に寄っていく可能性が高いです。
Webフロントエンドエンジニアでも状況は類似しており、こちらはデザインに加えて、クラウドやSaaSの良い扱いを出来るための「技術」になるでしょう。もちろん、その界隈でよく使われるプロジェクト管理の考え方を「技術」と考えるならば、それも含めましょう。
クラウドの後ろで高効率・高収益なSaaSを構築するための「プログラマー」は、今度はUIデザインはそこそこに、外部の「プログラマー」に使ってもらいやすい、良いAPIデザインを行うための「技術」を習得するという全く違う要求が発生します。今ですとGraphQLとかOpenAPIとかは候補になるでしょうか？IaaSを作る側は、今度はオンプレミスの諸処の制約を理解し、「ヘネパタ」のような書籍に書かれる「技術」を必要とします。ちなみに最近の「ヘネパタ」はウェアハウスコンピューティングの類もきっちりカバーしています。
非常に良く勘違いしがちなのは、自分の周囲だけが「プログラミング」の主領域だと思ってしまうことです。ある種「フィルターバブル」のようなものによって、特定の業界の特定の技術こそがプログラマーが知るべき重要な技術である、と思ってしまうのです。これは、誤った一般化でありまして、危ないです。
もし本質問のように異様に広い領域をカバーするような質問に対して、共通して適用できる「技術」があるとするなら、「プログラマーとして必要な技術領域の広がりを理解する技術」と「その中で自分が必要とし、深く探求すべきものを取捨選択する技術」が大事なのかな、と感じられます。
もしかすると、いくらかの方は、最初に並べたいろいろな「プログラミング領域」について「そんな分野に私はいないし興味もないヽ(=´▽`=)ﾉ」と思った、かも、しれないです。そのご意見は全くもってごもっともでして、実施、全部の領域を全部深く学び仕事に活かすなんてことなんて、一人では無理に決まっています。
とはいうものの、自分が活躍したい業界において先端を突っ走る、あるいは少なくとも遅れを取らないようにするためには、当初は「他の分野」だと思っていたところから浸透してくるソフトウェア技術の潮流をライバルよりもいち早く捕捉したり、お隣さんが興奮している「技術」を自分の情報探索の網にひっかけられなければなりません。取捨は、まず「取れて」はじめて「捨て」られます。
そのように広く情報網を広げつつも、流行りだからといって新しい潮流のようなものに飛びついて、1年後には全く使わないしそのノウハウを全く横展開できないとすれば、これは「プログラマー」の時間の使い方としてはあまり良くありません。外国語学習について「エスペラントを学べば世界のどこに行っても大丈夫だ！」と思うのと類似の誤りに感じられます。
ソフトウェア技術において「浅く広く潮流を把握し」「本当に必要なものを選別する」ということ、これを推したいと思います
（……あれ、これもこれで別に「プログラマー」に特有の話じゃないような……）
これは答えねばならない気がした。
なんやかんやでその道20年です。
プログラマーにとっての「技術」とは、コンピュータを自由自在に操るための膨大な知識（プログラミング言語、フロントエンド技術、サーバーサイド技術etc）です。ソフトウェア開発を組織的に円滑に行うためのプロジェクトマネジメントスキルなども含まれます。
これらの技術は日進月歩でどんどん新しくなっていくし、今なにが求められるかというのは確かに気になるところ。
でも技術も大事なんだけど「何を作るか」がもっと大事だと思います。
その「何」ってのはとても難しいんだけど、自分からは出てこないかもしれない。
だから、いろんな人と交流を持つことで化学反応が生まれ、よいアイディアが出てくると思っています。
なので今求められるのは、「いかにいい人になれるか」じゃないかな。どっちかというとメンタル的なやつ。マインドの使い方の技術です。
いい人には人が寄ってくるんですよ。悪い人も寄ってきますので、そこは見極めが大事ですが。いい人と出会うと結果的にお金も入ってきます。いい循環ができてきます。その流れに乗るだけです。
プログラマーとしてある程度の技術を身につけたら目指すはそこかなと思います。僕らの仕事は人の役に立つこと。それでしかないと思いますので。
皆さんがそれぞれ良い回答をしてるので、そこに無いものを付け加えると、下記になります
私が物事を考える時によく使うのが二つの視点です
一つはそれにおける基礎体力ベースとなるものは何かが一つともう一つは他の人は気づいていない近道は何か？アンフェアアドバンテージとか言います
まず、基礎体力ですがプログラマーとして私が重要だと思うのは、メンタルやストレスのコントロールスキルです
例えば弊社のプログラマーだとタイトな締め切りに集中している時は私からの呼びかけや電話にも対応せず複数のタスクが重なっている時は一旦PCを再起動してデスクトップをきれいにして一つのタスクを始めるそうですそのおかげか他のプログラマーと比べてタイトのプロジェクトでも安定したパフォーマンスを出してくれます
次に近道アンフェアアドバンテージですが、日本だと特に英語を覚えて外資系の日本進出企業に転職すると給料やその他が他の日本のIT企業より恵まれてると感じます
すぐできるのは、Link、edInにプロフィールをしっかり書いて登録すると日本では知らないけど、海外では大きい企業からもオファーが来ます
また、日本のプログラマーは英語ができないがゆえに、車輪の再発明をしたがる傾向がありますが、英語でしっかりGoogle技術があれば海外のAPIサービスやオープンソースのフレームワークを使って、できるだけコストをかけずに価値が高い製品が開発できると思います
基礎体力で思い出したんですが、その業界を詳しくなって顧客に、開発側から最適な提案をできるというのは今後の付加価値となっていくでしょう
プログラミングできるだけだと特に日本では顧客の要求自体がそもそも価値が低いものになってる場合があるので、それを検証してあげて、価値の高いものにして製品化してあげることで、他のプログラマーと差別化できるかもしれません
直裁的な話しで行けば、現場で人が少なく常に求人を求められているプログラム技術者は ①WEB系のプログラマ ②クラウド基盤インフラのプログラマ(仮想システムの自動化) ③ スマホやウェアラブル端末の組み込み系のプログラマ になるのではないかと思います。
個別のアルゴリズム技術の発達や開発インフラのトレンドは置いておいて、一番必要とされる人材は「いかにプログラマーに利用者側の観点に立たせるかを伝えるエンジニア」かもしれません。
往々にしてありがちなのが①や②は不必要なスペックや最新式の技術を売り込もう、または勉強したいと思って提案してくるエンジニアです。多くのSIerは単月ベースの人材売りがメインでいかに利幅の大きい自社開発を売り込みたいと思ったりしますが、大概失敗することが多い。またエンジニアもエバンジェリストとか社内エキスパートとして働きたく、全てではありませが後輩の教育や数字を作る努力をしない人が多い。
技術に磨きをかけてそれだけで歩みたい、というのであればなるほどそれで良いと思いますが、顧客や最終消費者の意向を汲んで最適な改善、改修を提案できるプログラマは皆無です。そのために間に立つリーダー的なエンジニアやマネージャーがいるのですが、アドバンス領域まで極めたプログラマ経験のある人は少ない。
一番手取り早いのが自分がプログラマ兼インターフェース的なエンジニアになることでしょう。しかしそれだけの人材であればすぐに起業してしまうと思うので、相変わらず市場にはどちらか一方のエンジニアしかいないことになります。
ここからはジョークになりますが、仮にそのような複線的なスキルがあれば、今度は社内で煙たがる勢力が現れるかもしれません。営業は数字を作る過程までは感謝しますが、エンジニアが対顧客に営業のような顔で振舞うのは面白くないからです。これはもはや社内政治的な話なのでそれも含めて起業力を身につける、がベストになるのかもしれません。
こんな感じの質問ってプログラミングを始めたばかりの人がしそうな感じですよね。きっと「効率よく学びたい」「何を学べばいいのかわからない」「教科書のような目次・指針が欲しい」という意図があるのかなと思います。なのでこんな記事を書いてみました↓
プログラマーという言葉は人によってその含む範囲にだいぶ違いがあります。
・デスクトップアプリのプログラマー
・ハードウェア制御のプログラマー
・モバイルのプログラマー
・WEBフロントのプログラマー
・WEBアプリ（サーバーサイド）のプログラマー
またプログラマが知っておいたほうが良いプログラミング以外の技術として
・ソースコード管理（GitHubとか）
・ネットワークの知識（TCP/IP、HTTP、クッキーなど）
・セキュリティ関係（XSS、CSRF、CORS、OAuth認証など）
・自動テスト（UIテスト、ユニットテスト）
・クラウドの技術
・DevOps
などがあります。もうちょっと広げてみると
・要件定義（顧客のニーズを明確にする）
・開発管理手法（スクラムとか）
・プロジェクト管理（人の精神面のケア、予算と納期の管理とか）
・UX設計
・SEO関係
などもあるかもですね。仕事としてやるならば顧客のニーズを踏まえたプログラムを作る必要がありますし、WEBメディアのシステムであればSEOを踏まえた作りにする必要がありそうですし、複数人で開発するなら管理を適切にやる必要が出てきそうです。
まあとにかくプログラマーって言葉は結構幅が広いんですよね。個人的には
「今プログラマーに求められる技術は何だと思いますか？」
っていう質問は
「今料理人として求められる技術は何ですか？」
というのに近いと思ってます。WEBとモバイルでは半分くらいは全く別物の知識です。当然求められるものも全く違います。料理ってフランス料理店なの？中華なの？ってところを明らかにしてもらわないと回答できないよねってのと似てます。包丁さばきとかは共通で使えそうですけどね。
最も大事な技術は常に謙虚でいることです。プログラマ―といっても自分のドメイン外では素人でしかないのでどんなに詳しくなっても謙虚さを忘れずに勉強できること、そういう気持ちを持てる精神面の技術が最も大事だと思います。それがあればいつまでも成長し続けられるでしょう。そうすればいつかは1流のプログラマーになれると思います。
一例として「開発効率」を挙げます。
例: ある機能を実装するために8時間与えられました。下調べをしてみると、現在のプラットフォームで使えそうなライブラリが見つかりました。ライセンス(MITとかLGPLとか)はクリアしていそう。自分で書くコード量は少な目。また一方で標準ライブラリで実現する方法についても調べられました。コード量はやや多め。そんなときに前者を選ぶ勇気を持つことが必要な技術だと思っています。
実装時間はおそらくどちらも2時間程度で、レビュー通して、検査して、一日を目一杯使って双方どれだけの信頼性が持てそうかというところです。
後者のほうが、性能は出るかもしれません。バグに関しても不要な処理を加えていないだけに、ライブラリ特有のバグに悩まされることもないでしょう。
ただし…その程度で実装したものは、将来どうなるかはわからないのです。バグらずにその後2度とメンテナンスされないかもしれませんし、未使用のままお蔵入りするかもしれません。細かい修正が何度も入るかもしれません。勘違いしてはいけないのは、修正がなかった時でさえYAGNIもKISSも矛盾していないのです。
「与えられた時間を大切にする」技術なんだと思います。1日は1日として使う。稼げた時間はOSSに貢献したり、ライブラリの研鑽に充てる、なるべくなら新しそうなもの(メンテナンスされてそうなもの)を選びたいと思うのは、自らの仕事の垢を落としていくこと。自分の書いた数行(ひょっとしたらコピペしただけかもしれない)が、残り続けたことで、後を託された誰か(3ヶ月後の自分かも知れません。)が、その「レガシーコード」を技術的負債としてしまうのを防ぎたい。そういう心が大切なんだと思います。
こういう事を書いていても「車輪の再発明」は新しい技術を習得するためには有意義なんだよ!的なことを言ったりします。全くもって矛盾したもんです。
ご存じかとは思いますが、日本のプログラマーはIT産業ピラミッドの最下層に位置しています。
そのため、初心者歓迎！みたいな文句で人を集めるブラック・・・まではいかなくてもグレーだったり、ホワイトだけど未来がなかったり。プログラマーの多くは闇の深い業界だなと思っているのではないでしょうか。だいたい入ってくる人の数だけ辞めていく人がいる職業だと思います。
そんなプログラマーに求められる事は意外と多くありません。とても単純な事です。
「早く正確に作る技術」
どんな要求、どんなアーキテクチャ、どんな業界であっても求められる事は同一です。
・プログラマーにとって速さは正義です。余裕ができた時間でプログラムの完成度を増したり、機能改善や便利モジュールの作成、勉強してさらに能力を高める。など、色んな事が出来ます
・１つのミスもしないプログラマーはいません。ただ、ミスが少なければテスト工程やその後のスケジュールも安定します
・新しいアーキテクチャや他の言語でも早い仕事ができれば技術的な縛りが減ります
上記を達成するために優秀なプログラマー達は日々改善に勤しんでいることだと思います。
ちなみに、ドキュメント能力やコミュニケーション能力などもあれば非常に役に立つ能力ですが、それはプログラマーとしてではなく、SE、設計などもっと上位の役割を担ってほしいからだと思います。
他のジョブに行くことが収入を高める近道ではありますが、プログラマーにこだわるのであれば、ひたすら基礎技術を磨いてどんな環境や言語でも誰にも負けない速さと正確さを出せるのが日本の環境ではよいかと思います。
「日本で」と限定すれば、「今」求められているのは「プログラミングの外の世界」を理解する事ではないかと思います。
日本では長きにわたり、プログラマーの仕事というのは「言われた通りに動くものを作る」ことに限定されてきました。プログラミングのわからない人間が「これこれこういう感じのものを作ってくれ」と発注し、外側をわからないプログラマーが「こんな感じに作ればいいんだな」とえいやっと作る。
こういう仕組みでやっているから、紙の書式をそのまま画面上に再現して、ペンのかわりにキーボードで入力するだけの、なんちゃって電子化業務があちこちで生み出されます。
プログラマーは、ただ言われたとおりに作るだけの人ではなく、その上流をきちんと理解し、ソフトウェアを利用する人間までを含めた「システム」を考えられるようにならなければなりません。会社はそういう人間に強い権限を持たせ、業務を支えるソフトウェアとそれを使う人間全体を一貫してデザインさせるようにしないと、海外企業に勝てる見込みはありません。
今求められる技術という話なので、ロジカルシンキングやコードの理解力とかいう話は割愛しますね。
個人的に日本のプログラマと呼ばれる人々に圧倒的に足りないと思っている技術はデザイン力。
私も含めてね、本当にないんです。
そういう奴らの作る画面ＵＩは「灰色の団地」です。ディストピアです。
デザイン力がある人は色彩を巧みに操って視線誘導させたりするのですが、俺らにできる発想は精々、赤色の警告色か、青色の強調が限界。
こういうプログラマ達は結局「他人の考えたアイデアやソリューション提供案件」を
コード化するだけの機械でしかなく、どんなにコーディング能力が上がろうと火消しの傭兵プログラマにしかなれません。
欧米のプログラマ達はもっとクリエイティブなんです！
なので、デザインを勉強しましょう！マジで！
「AはBである。BはCである。よってAはCである」という発想を行う技術です。
難しくはないのですが、twitterを見るとわかるように「AはCでありBはXでない事は否定できないしEはZかもしれない。よってAはK！ハイ論破！ブロック！！」って論理展開の人いるんですよね……
東京、秋葉原に雨後の筍のごとく小さな会社が生まれたソフトウェア産業創世記から今現在まで、業界で仕事をして世の中を見てきたプログラマーとしての意見は、極めてシンプルです。
プログラミングに詳しくない、業界に詳しくない方々、例えば、営業、企画、マーケティング、発注者者（お客さん）と、普通の噛み合った会話ができるという事です。プログラムとは、ニーズがあってこそ書けるものです。
彼らは何を求めているのかを、きちんと聴き、今までの知識や経験を総動員して、実現のための最適な方法、最も近い、近道を考え、幾つかの方法を提示し、それぞれのメリッド、デメリットをきちんと説明できる事です。その際、業界通的な専門用語やカタカナ言葉を連発して、煙に巻くのはダメです。こういう言葉を言うのは好きではありませんが、それ、二流、三流、低レベルプログラマーです。
彼らには、できるだけ専門用語を避け、解りやすい言葉で説明することが大事です。それができないのでは、一人前のプログラマーとは言えません。
全ての技術について全方位的になんでも知っているというのは、今の時代では無理です。不足している知識については、知っている人に聞けばよいだけです。依頼者には、そういうアプローチを示せば、安心するでしょう。なんでもかんでも知ったかぶりをすつよりは、信頼されます。
彼らが求めている事、関心がある事は、どうい方法なら実現できるかであり、カタカナ言葉を連発するような技術的な、こまごまとした詳細は、はっきりいってどうでも良いという事です。
始めることは、まず、身近な、小さな事から、例えば、モニタ、タイマ、センタ、ドライバ、プログラマ、等のようは一般の人は使わない違和感のある言葉を文書に書く癖を改めるなどです。
私個人の見解ですが、この先プロフェッショナルと呼ばれるような人たちは、その中でもトップ層にいる人達を除き淘汰されていくと考えています。
こんな話を聞いた事があります。中国のとあるIT企業に務めるDBプロフェッショナルのインフラストラクチャエンジニアは、数十人規模のチームを率いるリーダーでしたが、AWSやGCP、Alibabaといった多くのクラウドプロバイダが提供するSaaSとしてのDBサービスが出た事で、リーダーである彼自身と、自身のチームにいる大半のDBエンジニアを解雇または異動しなければならなくなったのです。会社のために尽くしてきた彼は、会社のために職を失ったのです。
これはDBエンジニア以外にも言える事です。そこからわかる事は、今プログラマーと呼ばれる職種に就く人に求められる技術はIT以外の分野の専門知識を身につける力です。
医療に金融、アパレルに不動産、交通、行政、と、IT以外の分野といっても枚挙に暇がありません。
どれでも良いでしょう。IT x 医療やIT x 行政など、様々な領域とITを結びつける架け橋になれる人材が今後更に求められるようになっていくと思います。
もっと専門的な、開発手法や言語や設計思想などは他の方が回答している通り私も同じ考えですので省きます。私の回答は、他の方の回答に追加でこういう力も必要だと言いたい事をご理解ください。
技術に関しては、どんどん新しいものが出てきます。個人的に衝撃だったのはiPhoneのアプリです。コンパイル言語からスクリプト言語が優位に立ってきてた時代で、Rubyでいかにスマートに書けるのか？みたいなことを自慢げに話してた人たちがけっこういたわけです。個人的にはJavaの静的型付けが好きなので同じことしかできないなら、どうでもいいかな・・と思ってました。そこで華々しく登場したiPhoneはイケてるのはいいけど、objective-cを触り始めて、昔ながらのメモリ管理でどこか間違うとすぐ落ちてしまうし、isEqualToStringとかって無駄に長い名前でほんとにみんなこんなの使ってるのだろか？と不思議に思いました。後でいろいろな人に聞いたら、やっぱりWeb系の人はネイティブアプリからは逃げてた人が多かったみたいです。
また深層学習が出てきて統計なんかのどちらかというと宣言型で処理の中身は書かない感じのプログラミングと、IoTでマイコンの原始的なプログラングが同時に流行ったりするのですよね。
ほんとに何が起こるかわからないのと同時に、別にひとつふたつに乗り遅れても過去の知識は無駄になり蓄積もするわけでもなく次の波は来るのでそこにしっかり合わせればいいのですよね。
幽体離脱して寝てる時すらコーディングする溢れんばかりのエネルギーでしょうね。
https://off.tokyo/blog/programmer-kagami/生涯プログラマーを続けたい、という解釈で回答します。
プログラムが書けるだけの単なるプログラマーでいる限りは、あまたいるプログラマーの一人でしかないので、技術をいくら身に着けても労働単価の価格競争に巻き込まれて安い単価の人と入れ替えられたり、賃金が上がらないといった悩みから解放されることは難しいのではないかと思います。
ただでさえ日本人の人件費は高いので、海外に発注した方が安いとか、派遣社員を雇って書かせた方が安いとか、そういったような世界です。日本人開発者の給料に見合うお金を支払えるとすれば、よほどの付加価値を付ける必要があります。
ではその付加価値は何なのかとなると、専門的な業務知識を必要とする分野や、セキュリティ、金融などの信用が重要な分野などです。自分のような知識と技術を持つ人がいなければこのプロジェクトは成功しない、といったレベルになってしまえば、雇用にかかるコストは二の次になるので、交換可能な単なる労働力、という立場ではなくなり、長期にわたって安定して仕事を続けられるのではないかと思います。
「今」ということが大事だとして、最新のフロントエンド等の技術を追いかけるのも楽しいかとは思いますが、それが付加価値として顧客にどのような利益を生み出すのか、顧客にどのような競争力を与えるのかという視点を抜きにしては、技術はあってもうまく活かせないのではないかと思います。
良いプログラマーになるために必要なのは、「ワーニングを無視したりしないこと」と「汚いままのコードを動くからといって横着して放置しないこと」と「常に未来にそのコードを読む人の為を想って気を遣って書くこと」です。
プログラマーが一番やってはいけないことは、ワーニングを無視することと、汚いけど動くコードを放置することw
という記事を書いたのでシェアします。めちゃくちゃ雑に書いたので、色々許してください
プログラマーが一番やってはいけないことは、汚いけど動くコードをそのまま放置すること。
特に、個人開発でレビューする人がいない現場とか、スキルの高いエンジニアがいない現場とか、自分独断で開発が進められる現場とかは要注意です。
数ヶ月後、数年後にプロジェクトの改修を始めると、そのツケがドカーーーンッと降ってくる、まるで雷みたいに。
まあ、この辛さは、実際に体験しないと分からないのでw 皆んな最初は、スピード重視で兎に角動くコード書きまくって、
その後に地獄を見て、それから志を入れ替えて人が変わっていくんだよ。
そして、「将来の自分や、他の人が読みやすいコードとは何か、将来的にもパフォーマンスが落ちないコードとは何か」ということを賢人みたいに考えるようになって、
いいレビュワーになっていく、いいエンジニアになっていく。
現場でPRがマージされることだけを考えるのではなく、本当のソフトウェアにとっていいコードとは何か、本当に他の人にとって良いコードとは何か。
そういうユーザー視点に頭が回るようになり、現場で「使える」と評価されるエンジニアになっていくわけですな。
母国語。対人関係能力。英語の読解力（母国語が英語でない場合）。想像力。
- 母国語
- けっきょく、何を作りたいのか、どうしたいのかを言葉で書けないとプログラムもかけないです。
- 対人関係能力
- 雇われてプログラマになる、お金をもらうプログラマになるのであればお客様がいるはずです。そのお客様との交渉（値段・期日・要求・実現の可否など）力がないといつまでたっても終わらないプログラム作業を行う羽目になり、お金ももらえないです。
- 英語の読解力（母国語が英語でない場合）
- 残念なことにコンピューターのプログラミングのドキュメントはほぼ英語です。何にしても英語の言語仕様書を読む羽目になります。母国語に訳されているのを待つとそれだけで英語圏の人から遅れることになります。
- 想像力
- プログラミングでこう書くとこうなる…という想像力がないとプログラミング自体が非常にきついです。
『Rust』でしょう。
同ガイダンスには「可能であれば、メモリー保護機能が言語自体にほとんど、またはまったく内在していないCやC＋＋といった言語から、メモリー安全性の高い言語への移行に向けた戦略的遂行手段を検討することを組織や企業に推奨する。メモリー安全性の高い言語として、C＃やGo、Java、Ruby、Swiftなどが挙げられる」※と記されている。
※原文： The language institutes automatic protections using a combination of compile time and runtime checks. These inherent language features protect the programmer from introducing memory management mistakes unintentionally. Examples of memory safe language include Python®, Java®, C#, Go, Delphi/Object Pascal, Swift®, Ruby™, Rust®, and Ada.
NSAはGoogleやMicrosoftにおける最近の調査結果を引用している。それらによると、「Google Chrome」や「Windows」内で発見されたセキュリティ問題の70％はメモリー関連に起因するものであり、その多くはCやC＋＋といった、メモリー関連の脆弱性を作り込んでしまいやすい言語で記述されたために生まれたものだという。
米国家安全保障局、CやC＋＋からメモリー安全性の高いJavaなどへの移行を推奨 ZDNET Japan 2022-11-14
実行速度とオブジェクトサイズのバランスはC++よりRustの方が優れています。
0 件のコメント:
コメントを投稿