🎉

プログラマに必要になっているプログラミング以外の技術の一例

2021/04/04に公開

仕事

プログラミング

技術

tech

はじめに

よくソフトウェア技術者にはプログラミング以外にもたくさんの技術が必要といわれます。では具体的に何が必要なのか…というと、実のところ個々人が置かれた状況によって全然異なるので何とも言えません。ただこれだけだと実務経験が無い人には全然ピンと来ないと思うので、現役職業プログラマである私が今の仕事で必要になっている能力について書きます。

私が現在なにを作っているか

私がやっていることはオンプレのインフラ基盤であるKubernetesクラスタの開発、およびその上で動くストレージ基盤であるRook/Cephクラスタの開発です。簡単に言ってしまえばこれらを作るのが現在所属しているプロジェクトのミッションです。

その中でもわたしのわかりやすい仕事はRookの開発です。上記インフラ基盤に必要な機能の開発、バグ修正が中心です。Rookはメンテナとして開発に参加しているので、それ以外にもコードレビューやユーザサポートなどをすることもあります。

わたしの仕事はほかにもいっぱいある(たとえばRook/Cephクラスタを実際に構築するとか)のですが、全部書くと焦点がぼやけるので、本記事ではRook開発に必要な技術についてのみ書きます。

どういう技術が必要か

では本題です。個々の技術について詳細に解説しているときりがないので、さくっとキーワードだけを書きます。プログラミングに関するものについて書いた後に、それ以外のものについて書きます。

プログラミングに関するもの

まずはプログラミングに直接かかわっていそうなものです。何がプログラミングに関係する能力なのかの定義は個々人の心の中にしかないのですが、私が考えるものはこれ、というものを列挙しました。

プログラミング言語の構文: Go, bashスクリプト、まれにPython
データ構造とアルゴリズム: 基本的なデータ構造(配列、リスト、hashあたり)と線形サーチ、バイナリサーチ、あたりだけ知っていればだいたいOK。独自に複雑なアルゴリズムを実装したりはしない
Goライブラリの使い方
- 基本的な処理: YAMLやJSONの処理
- テスト: testify
- k8s関連: client-go, controller-runtime
RookやCephのコードの読解: 読めないソースの変更は困難
デバッグ: デバッガの使い方、問題の絞り込み方、など
ログ、メトリクスの出し方: 監視やデバッグに有益な必要十分なものを出す。出せばいいというものではない
テスト: どこをユニットテスト、どこをCIにするか、どこの部分をテストするか、など
必要十分なエラー処理: 後片付けをする、必要十分なエラーログを出す、など
git,github,github actionsの基本的な使いかた

実務がないとログ、メトリクス、テスト、エラー処理あたりはピンと来ないのではないかと推測しますが、いかがでしょうか。

一点補足をしておくと、それぞれのプログラミング技術について全てを理解したり特定ソフトウェアのソースを丸暗記したりしているわけではないです。都度ライブラリのマニュアルを見たり、ソースを読んだり、POCしたりして次第に身に着けていきます。

プログラミング以外のもの

それ以外には次のような技術が必要です。

KubernetesやRook、Cephの使い方(何物かわかってないソフトウェアのソース読み書きは困難)
イベント登壇用スライドの作成やブログ書きについてのもの
- 想定読者、および何を伝えたいの定義
- 完結明解な文書の作成
メールやgithubの通知などから必要な情報を抜き出してトラッキング
- リリースに関するもの
- 自分に関係しそうなバグや使っている機能、欲しい機能についての状況
英語: 国際イベントでの発表、ドキュメントの読み書き、github上での話し合いに使う
- 中高生レベルの文法理解
- IT技術に関する単語や述語
upstream OSS開発についてのもの
- バグ報告: どういう環境でどういう条件で何が起きるのか、などを簡潔に説明
- バグ修正や開発方針についての議論、調整(場合によっては複数のプロジェクトをまたぐことも)
- 何のためのどういう変更なのかを説明するコミットログを書く
優先順位付け: 依存関係を考慮して着手する順番を決めたり。必要に応じて後回しにしたり、やらないことにしたりも
仕事におけるキーマンの理解
自分の担当分については指示が飛んでこなくても自律的に決断して先に進める

とりあえずすぐに思いついたのはこんなところですが、一瞬で思い出せるものを書き連ねただけなので、時間をかけて考えれば他にもいくらでもあると思います。

おわりに

わたしは世間の中ではかなりプログラミングをしている比率が高い技術者だと思います。それでも本節に書いた技術がなければ仕事を進めるのは困難です。見かけ上プログラミングに関係ないほうの技術を使ってやっている仕事の時間はそれほど多くないにせよ、これら技術が不足しているとプログラミングに費やす時間は大きく減りますし、プログラミングそのものも必要な知識が不足しているために困難になるでしょう(たとえばソフトウェアの使い方を知らないとソースの読み書きなんてできない、など)。

最後になりますが、これまでに書いてきたことが読者のみなさまのモヤモヤ解消に役立てば幸いです。

おまけ

個人の趣味を仕事に持ち込まないというのもわりと重要かもしれません。たとえば自分が単に〇〇言語が好きだから「〇〇言語で開発しましょう！」とか、新しい△△という技術をやってみたいから「次の製品は〇〇で作りましょう！」とか。

わたしの場合は個人としてはOSS大好き人間なのですが、仕事としてのOSS開発は趣味とは完全に切り離していて、必要だからやっているだけです。プログラミングそのものにもこだわりません。すでに使えるものが世の中に存在するのならばプログラミングはしないに越したことはありません。

さらに脱線なんですが、職場で無駄に人のモチベーションを下げたり不和を招かないためのコツを一つ。「趣味を仕事に持ち込まない」ということを言いましたが、逆もまた然りで、「仕事を趣味に持ち込まない」ということもいえます。「趣味を仕事に…」から飛躍して人の好み(エディタが好きとか言語とか)についてどうでもいいとかケチ付けたり「手段を目的化するな」と怒り出したりする人がいますが、そういう人はほっときましょう。