「経験の浅いソフトウェア開発者が気になっていること」という募集への反応のまとめ

数日前にブログや記事、書籍執筆ネタ集めのためにこういうtweetをしました。

その結果、返信および引用RTで数十個のネタが寄せられたので、まとめてみました。その場で回答したものについては回答一緒に書いています。それに加えて、私がわからないと言ったことについて別のかたから回答をしていただいたものについても書きました。さらに、既に経験豊富なかたがたから「経験の浅いソフトウェア開発者が気になっていそうなこと」や「知っておいてほしいこと」のようなネタもいただいたので、こちらもまとめました。

文面は基本的には改変せずにそのまま掲載しています。明らかな誤字脱字は修正しています。

ネタ提供者が誰かについての情報は省いていますが、知りたいかたは上記tweetからたどってください。回答についてはわたしのものか、あるいは別の人によるものかだけ書いています。

経験の浅いかたからいただいたネタ

家庭や子供の影響

ご結婚なさったり, お子様ができて, コンピュータに対する感覚に変化はあったかが知りたいです. 大事なものが増えたり優先順位のバランス調節は人生の節々で考えたり意見が変わるものでしょうか...

以下筆者の回答。

結婚では何も変わらなかったですが子供ができてからは「この子が独立するまでは死ねないな」と思うようになりました。人生の優先度も子供が一番になりました。しかし気持ちは枯れずにいまもコンピュータは大好きです あとは強制的にパソコンから離れられるようになった結果、精神的な休息の重要性がわかるとともに、無理やり休めるようにもなりました。ほかにも子育ては分業が大事なのでひとり頼るのはうまくなったかも うちの妻は私に好き勝手させてくれるので、それに依るところが大きいです。たとえば転職したいけど家族からの生活の安定を理由とした反対で不可能、というのはよく聞きますね。うちは転職どころか辞めただけだったけどとくに反対は無かったです

過去やっておけばよかったこと、やるべきじゃなかったこと

開発者新人のころにやっとけばよかったということと新人のころにやるべきじゃなかったなということを聞きたいです

以下筆者の回答。

やっとけばよかったことは - 楽しみながら仕事をする - わからないことは人にどんどん頼る、聞く、一人でかかえこまない - PC使わない趣味を見つける かな。技術的なことは障壁になることはあったけれども苦ではなかったかな

やっとけばよかったことに追加で、「自分を知ること」ですね。 - 何が得意で何が不得意か - 上記それぞれ何をすれば伸ばせるか、克服できそうか - 何が心身の疲れのサインか - どういうやりかたなら頑張れるか - やりたいこと、やりたくないことはなにか

やるべきじゃなかったことは - 「〜すべき」思考による無理な学習 - キャパを超えて新しいことをしようとする - 人と自分を比べる。とくに経験値が全く異なるベテランのすごい人たち - 新しいことを体系的に本を読んでじっくり学ぶ。このやりかたは全く向いてなかった

上記を受けての再質問

ありがとうございます、「わからないことは人にどんどん頼る、聞く、一人でかかえこまない」とかすでにめっちゃ大切さを実感してます 逆に「PC使わない趣味を見つける」って何があったんですか？

「〜すべき」思考による無理な学習ってめっちゃ思い当たる節があるんですがその後どうしましたか

筆者の回答。

「できない上にストレスが貯まるだけだから意味ないんじゃね？」と気づいて、興味がないのに勉強しようとしていた本を全部捨てて気持ちを切り替えました。めちゃくちゃスカッとしましたね。で、これんやるまでに数年かかりました。これも誰かに相談しとけばよかったのかもね

上記メッセージへの返信。

それ強いっすねー、ストレスなのめっちゃ分かるので、その手のやつはやっぱりマジで必ずやらなくちゃいけないやつ一つとかに絞っていきたいです...

修羅場経験について

(一番の修羅場体験……)

DMで一部回答。

組み込み開発について

組み込みのテストを自動化するように言われたのですが、取っ掛かりがあればご教授いただきたいです。 組み込みに特化したような書籍もなく、テスト自動化で使用するツールの保証をどうするのかを考えると中々手を出せずにいます。(デバッガー2年目)

ほかのかたが回答。

たとえばルネサスのCS+のようにPythonで操作できるIDEならPythonで実機でのテストを書けばいいのですが、独自スクリプトで操作できるIDEでもいいですが、そうでなければIDEのGUIを外からスクリプトで操作することを考える。いずれにせよスクリプト言語でテストが自動実行できるように準備する。 リアルタイム性が損なわれるけど、RAM化けを作ったりするのもスクリプト言語でブレークポイントを設定しRAMを書き換えて実行→停止で値を読むとかもできる。 電源変動試験ならシリアルやUSBで制御可能なものを使って、IDE操作と電源をスクリプトで操作する。

波形取得ならUSB制御可能なオシロ(DSO)をスクリプト言語から制御できるように準備し、IDEをスクリプトで操作しながらDSOを操作し波形を取る。 忘れてはならないのは、あんまり頑張りすぎないこと。どうしてもデバッガが介入するので動作が変わるし、スクリプト言語で操作できることも多くはないから。 スクリプト言語で頑張れないところは普通のプログラミング言語で組んでもいいと思います。

設計について

大規模なWebサービスバックエンドの構築に携わることがあって、そのときに設計（実装前の作業）について考えていました。しかし、実装もしないといけない中で、設計についてちゃんとは理解できなかったです。 そこで、設計はどれぐらいの粒度でどのようにすべきか？について聞きたいです。 補足というべきか分からないですが、関連するツイートです。 引用ツイート

筆者による再質問

「既存の型のどれにするのかではなく、まずはそういう制約なしで考えるほうがいいのでは？」というやつですかね

これに対する答え。

そうですね。既存の型は参考にはできると思ってますが、そのままの形で即採用というとうーん？という気持ちがあります。

書籍を書いたきっかけ

本や記事を執筆するようになった切っ掛けとか知りたいです

筆者による回答

作文が好きだったこと、とくに難しいことを噛み砕いて書くタイプのものが好きだったこと、なんとなく自分で本を書いてみたかったこと、必要以上に難解で高度なものを思われているOSカーネルを広く知ってもらいたいという思いがあったこと で、その思いを何年も持ちつつも多忙やらで機会は無かったんですが、会社辞めた後に時間ができたので知り合いの編集者のかたに相談した上で技評に持ち込みました

大規模OSSについて

Linuxのような大規模なOSSの品質に対するsatさんのお考えを教えていただけないでしょうか？ 特に、高い信頼性が求められるシステム(例えば、証券取引等)にOSSを導入した場合、OSS部分に対してはどのようなテストを実施するのか？等をご存知でしたら、教えていただきたいです。

以下わたしからの回答。

直接OS公式のもの(upstream版)を使うことはかなり少なくて、典型的には 1. ディストリビュータがある公式安定版をfork 2. distro版のテストや公式版で新たに見つかったバグの修正により枯らす 3. SI業者が顧客システムを想定したテストにより発見したバグを報告、修正して更に枯らすとなります

別のかたからの補足

大手の SIer だと必要な機能/修正を独自に開発、upstreamおよびディストリビュータに取り込ませるというのもありますね。

製品にはじめて自分のコードが入るまで

今まさに経験の浅いソフトウェア開発者をやっているのですが、自分のコードに全く自信を持てません。売り出されるプロダクトに自分のコードが組み込まれるまでどれくらいかかりましたか？またその際に仕事以外の時間でどれくらい勉強されてましたか？とても知りたいです。よければよろしくお願いします

筆者が回答。

プロダクトにコードが入ったのは、しょぼいのだと三か月くらい、ちゃんとしたものだと二年くらいですかね。 勉強は平日は一日1,2時間、休みの日は3,4時間ってとこですかね。でもまちまちですよ。寝たいときは寝る、休みたいときは休む。量ではなく質です。当時無理したので公開してるくらいです

それに対する回答。

ありがとうございます。satさんでも2年かかるのですね… 無理されてたのですね…平日全く勉強に時間を当てられてないので勉強しようと思いました。ありがとうございます。

テストについて

ソフトウェアのテストって、どんなテストをどのくらいやってどんな結果や数値が出せれば、ある程度安心してリリースできるでしょうか？テストシナリオやテストケースの作成、リリースの判断基準に悩みます。まだリリースや本稼働の経験が乏しく経験的にこの程度で良さそう、というラインがわからない。

筆者が回答。

どんな製品かによってかなり変わってきますので一概には言えないですね。とりあえずネタ帳に入れました。なにかかけるか考えてみます。

再回答

ありがとうございます。そうですね。一概には言えないですよね。 自分はもともと組み込み系で、厳しいけど割と形式化されたテストがあったのですが、IoTがらみでクラウドやWebも見るようになり、機能や関連コンポーネントが多いし自分が作ってないもの多すぎてどうしよう、ってなってるところです。

成長の実感について

どんな時に「自走できるエンジニアになったなぁ」と思えるのか知りたいです。 少しは成長している実感もありますがどんどん知らないことばかりが出てきます。 IT系2年モバイルアプリ開発半年です。

筆者が回答。

かんたんに書いておくと、やることをリーダーに逐一支持されることがほとんどなく、自分なりの考えをもとに仕事を完了させられたときですかね

リフレッシュ方法

プログラミングやトラブルシューティングは頭をものすごく使うので疲れてしまいますが、リフレッシュ法はどうされてきますか\

筆者の回答

音楽を聴く、カメラを持って散歩しに行く、子供と遊ぶ、寝る、あるいはせめて目を瞑る、コーヒーを飲む、あたりですね。特に仕事場から離れたり電子機器から離れるのがおすすめ

メモリ破壊の方法

メモリ破壊の原因の調査方法が知りたいです

筆者が回答

C限定ですけど以下のようなものがあります - valgrind - MALLOC_CHECK_環境変数

開発者になってよかったこと

ソフトウェア開発者になって良かったと思えた実体験 ・チューニング ・デバッグの方法やログレベル ・端末を開いてwebブラウザを起動してググって結果が表示されるまでのデータやパケットのなるべく具体的な流れ スマホアプリも同じく ・自身が描いているキャリアを伝えてベテランからの道筋指南

ネタ帳行き。

今の分野を選んだ理由

ソフトウェア開発といってもかなり広い技術分野、ポジションがあるかと思うのですが、どのように取り組む分野、仕事を選んできたのかお聞きしたいです。

筆者が回答。

興味の赴くまま、です。高校生のころあたりまで好きだったゲームから「このソフトウェアは誰がどうやって動かしているのか」を繰り返してたどり着いたのがカーネルで、その下には大して興味を持てなくてカーネル屋さんになりました。そのあと段々上の層にも興味を持ち出して今はk8sまで来ました

OS自作について

OS自作はPC周りを学ぶのに最適だと思いますか？

筆者が回答。

PCまわりがPCのハードウェアを指すとすると、最適かどうかはわかりませんがいい方法の一つだと思います(少なくともlinuxとかのソースをいきなり見始めるよりは)。ちいさなところから一個づつ試せるので。ただし進捗が目に見えてこないのでけっこう長い戦いにはなります

わからないことを検索するときのコツについて

わからないことがあってググる時にどういう手順で情報を探してらっしゃるか気になります。 例えば作りたいプロダクトのAWSサービス構成はぼんやり頭に浮かんでいる時に、各サービス名でググってもあまりイメージ通りの構成の例が得られないとかです。体系的な勉強から始めるしかないですかね？

筆者が回答。

そういうときは、同じことを表す表現をたくさん思い浮かべた後に、なるべく欲しい情報だけにマッチしそうなワードを選択しますね。いいかたを変えると、ノイズにはマッチしないようにする 体系的な勉強は人によって得手不得手がありますね。私は大の苦手なのでやらないです

Linux開発について

Linux関連の開発者になる手順。そして、それを仕事にしていくために、どこから取りかかればいいのか気になります。

ネタ帳行き。

勉強方法

データベースの勉強方法が分かりません、WEBフレームワークつかって何となくできてしまうのでどういう課題があるのか分からないです…。

筆者が回答

フレームワークでやってるようなことをSQL叩いてやってみる

開発の分業について

チームで作業しているときに、テストやデバッグなどで偏っている作業負荷を分散させる方法が知りたいです。

筆者が回答。

毎日朝会やってプロマネを中心として負荷の高いところやしばらく進捗が止まってるところに人を割り当て直したりしてます。とても良いです

勉強する技術について

どのように勉強する技術を選定しているな

筆者が回答

いま直近で自分に必要なもの、なにかのきっかけになって面白そうと思ったもの、ですかね。これは私の「好きなこと、今困ってることしかやらない、やりたくないことをやってもパフォーマンスが上がらない」という気質によるものです

過去につまずいたことについて

エンジニアになってぶつかった壁で印象に残っているものがあれば教えていただきたいです。

筆者が回答

  • 凄い人と自分を比較した。比較する必要はなかった(以前ブログに書いた)
  • 何から手を付けていいかわからなかった。一気にやらずに目の前の気になるところ一個に絞って順番にやっつければよかった
  • 体系的な知識を得なければと思っていた。この方法がそもそも向いておらず、苦痛だった あたりです

技術的なところでいうと - ポインタ - 標準入出力の概念 - アセンブリ言語 - カーネルとユーザプロセスの違い - 排他制御 あたりですかね。たぶんもっとありますけど一瞬で思い出せたのがこれらです

開発環境について

勉強用に個人の開発環境を作っていますか？ もしあればどのくらいお金をかけていますか？

筆者が回答。

作ってます。Ubuntuを突っ込んだ安いデスクトップPC一台。10万円弱です。ただこれは勉強したいものによってかなり変わります。わたしはカーネルビルドしてVM上で動かせればいいだけなのであんまりお金かからないです。その一方で、たとえば機械学習する人だと数倍かかると思います

過去のトラブル解析について

どうやったらRyzenでせぐふぉ見つけられるんでしょうか？

自分が回答

カーネルサポートを長いことやって引き出しを増やして、発生している問題がソフトで起こせるかどうか、起こせないならどういう理由なら起きうるのか、ということがわかってくれば自然とできるようになります

プロからいただいたネタ

いろいろな職種の役割

一口にソフトウェア開発者といっても、SRE やら Web エンジニアやらいろいろあるので、どんな役割があるのかとか

未回答。ネタ帳行き

似たようなものに見える職種の違い

インフラエンジニアとKernel開発者の違いとか。部分的にやることは似ている時もあるけど、ベクトルが全然違うというか。KernelとHW双方に詳しい人もいますよね。

未回答。ネタ帳行き

プロファイラについて

各種プロファイラーとどういう時にどれが信頼できてどれが信頼できないのか、その評価の方法を…

ネタ帳行き

応用の効いた技術

今までで、最も「応用が利いた」技術は何でしたか? は知りたいなぁ。 ある知識をXで得たのだが、それをYやZで使えた…的な奴の内、YやZが最も「たくさん」あった技術は何だったか?と言うもの。

筆者が回答

サポートやって身についた思考プロセスですね。まず問題を定義して、どういう選択肢があるか仮説立ててそれぞれ検証しての繰り返し。本来は大学、大学院で身につけてきて然るべきものなんですがサボってたので就職後になりました

チューリングやデバッグ

なんかチューニング的な話。あとデバッグとか。

未回答。ネタ帳行i

サポートやって身についた思考プロセスですね。まず問題を定義して、どういう選択肢があるか仮説立ててそれぞれ検証しての繰り返し。本来は大学、大学院で身につけてきて然るべきものなんですがサボってたので就職後になりました

パフォーマンスカウンタについて

Intel CPU のパフォーマンスカウンタの読み方も欲しいですね。カウンタが多いのは素晴らしいけどどれがどれだかわかりづらい。できればインテルの中の人から各カウンタを設定した意図を解説して欲しい。

ネタ帳行き

自分が最終防衛ラインのときの心構えや対処手順

ここで言うソフトウェア開発者とは違うかもしれないけど、自分が最終防衛ラインにいる時に、再現性不明の未知の不具合がプロダクション環境で発生して、現在進行形でお客様に影響出てる時の心構えと対処手順とか、みんなどうしてるのかは知りたい

筆者が回答。

  • 心構え: どうせ自分以外にはわからんのだからと腹括る。ゲーミフィケーションなどで楽しさを見つける
  • 対処手順: 自分が調査に集中できるように報告する人や情報一元化する人を用意する。何のために何をしているのかをお客様のプロトコルで常に伝えて信用を得る ですかね

再度回答。

私の場合は、 とにかく周りに助けを求めまくって抱え込まない ごまかさない 事実と推測を分けて整理していく 今やっている事、これからやる事を共有する 調査/指揮/共有する係は最低限分ける ステ

ークホルダーが欲しい情報をきちんと共有する(専任で別の人にやってもらう)