エンジニアのアウトプットを考える2022

そもそもエンジニアがアウトプットをする方法がいくつあるか、という話です。
（読後？所感）

一度書き上げて一日寝かせて再度自己レビューしているんですが、思った以上に過激というか

「それってあなたの感想ですよね？」

とか

「なんかそういうデータあるんですか？」

と、指摘されても仕方ないなー、と冷静に思いました。
（CoeFontさんありがとうございます！）

謝辞

この投稿は私の感想であり、そういうデータは俺ソースです。
類似した別の方の意見とも比較し、ご自身にあったアウトプットをご検討ください。
比較の基準の一つとしてご活用ください。

筆者来歴

私の感想の記事ですが、俺データに説得力を持たせたいので、ちゃんと来歴を残します。

• 平成初期のおぢさん
• 小学生から学生生活すべてパソコン系の部活動で沼る
  • 高校時代はパソコン甲子園の常連
• 貧乏大学生だったので、取れる単位は全部取っていく方針に
  • この中に教育課程があった（結論として、現在まで教職にはついていないが、活かされている）

職歴、は書けないものがあるので、入社理由とか状況とか

• 話すの苦手だしずっとやってきたパソコンを仕事にしよう！
  • 「高いコミュニケーション能力が必要」の意味が分からず、社会人１年目でボコボコにされる
  • 肩書はプログラマーなのに飛び込み・ポスティング・名刺配りが主業務。システム構築は上長のサポートで呼ばれた時にする（当然、研修はナシ）
• 開発がしたくて入社したのに！と一念発起して新卒カードを捨てて中途採用で沼る
  • 経験社数（転職・並行プロジェクトも含む）がアッサリ２桁社を超える
  • 数がすごいのと、飛び込みで磨いた営業トークで経歴を面白おかしく語っていたら「出来る奴」だと思われてなんの冗談かCTOに据えていただく
  • しかし、実績がないので人を採用する立場になっても自分が一番の新人で若手だと思って何でも屋として動き回る
• ちゃんとした開発をするため上京。（当時）口がうまければ良い待遇になった地元と違って実力主義社会に震えて眠る。実力がなさすぎてそのうち社泊。
  • 気がついたらチーム内（社内）の特定の分野でナンバーワンになり続けた。
  • 勉強会（社外）で通用するスキル感を求めて登壇したりハッカソンに、コミュニティも主宰する
  • 業務のモチベーションが「自分のスキルを高める＜メンバーへの貢献」に
• 過去にやってきた「開発」以外の仕事をもう一度見つめ直す
  • 実はコンサル業とかQAは経験済みだったが、（今思うと）まともな開発スキルもなかったので、改めて再経験
  • 開発職のステップアップとして、マネジメント層を目指す
  • 開発スキルを生かした異業種を考えたところ、IT講師・新卒研修のご縁をいただく
• 当初想定していた以上に講師業の評価をいただき、模範講義指導やエンジニア講師の育成にも関わらせていただく

なるべく圧縮しようかと思ったんですが、俺データがなんか信頼性ありそうだぞ？と思えるぐらいに仕上げるのに苦労しました…。
ネットなので、こういった書き込み自体がウソだと言われると証明が出来ないものもあったりしますが、まぁここでウソついても良いことないので、信じてね？というぐらいしか出来ないです。
自慢は目的ではありません。むしろこういう生き方は専門性を伸ばしにくいし、転職しすぎているので会社勤めが合っている方にとっては人生ハードモードすぎてオススメできません。
逆に言うと、転職をする事になってもそれなりの高い意識と行動力（今の御時世、エンジニア文化も育ってきたので実績も）があれば逆転可能です。30代まではまだ行けると思いますが、40代からは転職する前に今の会社でスキルを活かしたポジションを意識した方がトータルで良いことが多いかも知れません。

（追記・ここまで）

対象読者

• 業界志望で未経験者
• 業界人だがエンジニア未経験者
• 人事・スカウト

for Japanese
特に海外では通用しないお話がメインです。

エンジニアのアウトプットとは？

エンジニアのアウトプットを考える前に、会社としてエンジニアに求めるアウトプット（結果）が何か見ていきます。
探せば多岐に渡りますし、プロジェクトやポジション毎に異なりますが、概ね以下が多いです。

• 開発書類（要件定義書、システム・テスト設計書、テストシートなど）
• システムそのもの（ソースコード、ビルドしたアプリケーション、アプリケーションが動く環境など）
• 保守（ドキュメント：運用・保守・作業手順書）、トラブルシューティング

今回は上記に限定します。
（注：やり出せば本当にキリがないので、新人研修の総合演習でよくやるチーム開発を想定しました）

アウトプットパターン：A

ここで取り上げたいのが、以下のパターンについて

	できる	できない
やる	やる	※
やらない	やらない	やらない

ポイントは「できないのにやる」必要がある場合の判断だけですね。

• 別の実現可能な方法を模索する
• システムでは難しいので、運用対処をする
• 何とかして「やらない」にする

過去に受講生にディスカッションテーマとして投げた際にブレストした結果、多かった意見です。
特に３つ目の意見はなかなか出てこない意見だったので、これを出してきた受講生はすごいな、と思いました。
（※彼らの表現を私なりに集約している部分が大きいので、実際には異なる可能性があります）

アウトプットパターン: B

ここに、以下の条件を入れてみます。

	できる	できない	曖昧
やる	やる	※	？
やらない	やらない	やらない	？
曖昧	？	？	？

実務（アジャイル）ではよくあるケースですね。
たとえば「仕様はまだ確定してないけど（現状の方針では）必要になる可能性が高いので先にやっておこう」なんてケースです。
（なお、新人研修では、この曖昧さを無くすために基本的にはウォーターフォールでガッツリ仕様確認して各工程に講師レビューを入れる事が多いです）

実務では、曖昧な部分の対応を判断するのはマネージャーだったり、クライアントと折衝して方針を決定するのですが、意見や方法を検討するのはマネージャー以外も必要です。
この場合、以下の「マネージャーがエンジニアに求める・求めないもの」を検討する必要があります。
といっても、想像する（説明する）のが難しいので、少しユースケースが異なりますが特に判断が難しい「リリース後のシステムで障害が発生し、対応完了したその後のケース」と置き換えて想定します。

マネージャーがエンジニアに求めて良いこと

• 原因追求
• 問題解決
• 再発防止策の提案

主に、一緒に問題や障害を乗り越えるための行動です。
部活動のキラキラした部分です。

マネージャーがエンジニアに求めてはいけないこと

• 犯人探し
• 責任の追求
• 稼働管理

主に、リアル人狼行為です。
特に稼働管理は大問題です。
時給・日給月給制はオンライン業務とは相性が悪いと言われがちですが、実はオフィスに出社しての業務も内情はこれと何ら変わりません。
見られているから頑張っている風を装おって半日で仕上げ

（企業風土なども関係するため、）拡大解釈になるのであまり自信を持ってお勧めし難いのですが、業務の評価を成果主義にすると、オンラインだろうがオンサイトだろうが同じ結果になるはずです。

for 新人研修

特にチームリーダー役になる受講生には上記を指導するようにしておきます。
受講生全員が仲が良い環境ならある程度失敗も許されますが、特定間の受講生の仲が悪いとチーム全体が微妙な空気になります。
特にリーダー役が出来る方で、メンバーにあまり開発に慣れていない方を入れる場合などは起こりがちです。
（特に犯人探し。探さずとも決めつけてしまって＝その決めつけは正しかったとして、良いことは何一つありません）

多くの研修事業社はカリキュラム（システム開発概論や開発手法など）が存在しますが、マネジメント論（人間関係など）については扱っていないため、個々の講師のマネジメント経験に依存している事が大半です。
その中で、カリキュラムやテキストがないため、こういった問題に触れられる事がなくチーム開発演習が終了しても、「」「受講生視点」でチーム全体として良かったという感想にならない事も考えられます。

チーム開発演習の目的は「チームとして課題を解決すること」ではありますが、講師として見た場合は「成功にしろ失敗にしろ、受講生が自ら課題を見つけ、解決する（または解決する方法に気づく）こと」です。
チーム開発が終わったら業務・契約終了になる事が多いですが、報告書には上記を書き含めておくと喜ばれます。

for 現場（サーバントリーダーシップ）

経験者ほどこんな事はやってないと思いますが、念の為。
属人的な環境だと犯人探し＝復旧をお願いする人を探すという工程になってしまっていると思います。
私も過去に勘違いしたサーバントリーダーシップを発揮しようとして、プロダクトのプラグイン（モジュール）が属人的になってしまい、稼働調整に非常に苦労した経験があります…。
（稼働調整とは、メンバーの方の都合でやむを得ず当初想定していたスケジュールを維持できず顧客との納期調整のお願いをした、などです）

執筆時点でも私の考えるサーバントリーダーシップについてベストプラクティスを語れる精度ではないのでお恥ずかしいのですが、プロジェクトで何か問題が起こった時だけメンバーに声かけをするような進め方をしていると、リーダーに呼ばれる＝良くない事があったとメンバーに意識づけしてしまうため、無意味な声かけ（進捗に関わらない内容、たとえば昼ごはんを何にするかとか、最近のブームとか）をするなどの働きかけをして、声かけ＝マイナスだという意識付けをしないよう努めましょう。
特にオンラインだとチャットあるいはボイスセッションぐらいしかアクションできないので、非常に重要です。

とはいえ、集中したいので煩わしいメッセージを送ってほしくないメンバーもいるはずです。
彼らに対するフォローとして「集中したい時はいっぱいあるだろうから、予めどの時間は手が離せなくなるか見積もり出しておいてほしい」と伝えてステータスの変更やカレンダーアプリでの対応をお願いをしてみましょう。
できれば、リーダー側は彼らの予定や時間を気にする事なくメッセージを送り、メンバー側は散発的にやってくるリーダーのメッセージを通知せず、落ち着いた頃にじっくり返信ができるようにしておく環境が望ましいです。
「メッセージには即レス」の文化は、リーダーに安心感をもたらす反面、メンバーには緊張感を与えます。サーバントリーダーシップを発揮したいならリーダーの要望とメンバーの（声にならない）希望の擦り合わせを事前にしておくべきです。

本題：エンジニアのアウトプット（Qiita）を考える

せっかくのアドカレの時期なので、アウトプットしましょう！
つまり、記事を書きましょう！

と、言いましたがどんな記事を書いたらいいの？という疑問も最もです。
最初は日記だと思って書いてもらっても良いかも知れません。
Qiitaに限った話ではないですが、はじめて何かを行う時は入念に調べて悩みすぎるぐらい悩んで踏み出すことでしょう。
しっかり利用規約も読んで、利用規約を違反していないか記事を見直す事も多くなると思います。
（追記：私もQiitaやQiita他で寄稿している私も、本稿は書いた後に一日寝かせてセルフレビューを実施して修正しています）

そこで、上記のアウトプットパターン: Bを記事で考えてみます。
以下、再掲です。

	できる	できない	曖昧
やる	やる	※	？
やらない	やらない	やらない	？
曖昧	？	？	？

記事を書くことは出来るし、やる人はやります。
問題は、書いた内容が正しいかどうかを、慣れないうちに誰が担保できるのか？を考える事が多いです。
が、Qiitaはわりかし記事の正確性を閲覧者が判断できる（これって実はすごいことで、個人サイトで記事を書いているとほぼありえないです）ので、開き直って先輩方にしごいていただくつもりで書くのがオススメです。
内容の誤りや、利用規約の勘違い（認識違い）への指摘などもある事を理解して、以下のように考えることが出来ます。

	できる	できない	曖昧
やる	やる	※	質問にする、 質問サイトで回答をもらって書く
やらない	やらない	やらない	※それっぽいサイトをブックマーク、備忘録、まとめ記事にする
曖昧	やる	質問にする、 質問サイトで回答をもらって書く	ネタ帳に入れる事も検討？

業務で曖昧なものはなるべくやらないか、やるかどうかの判断としましたが、記事となれば話は別です。
特に「曖昧なものはそのままにしない」というのがポイントです。
業務では能動的に曖昧を解決しようとするはずですが、個人であれば曖昧なものはあまり追求しない事が多いです。
これではチコちゃんに叱られます。

曖昧なものも、理解を間違えているものもこういった場できちんとした理解にできれば、指摘されて凹んだり萎えたりはしますが、トータルで見れば、直属や関連機関、あるいは将来的にあなたと共に仕事をする事になる方にとって大きな貢献となります。

まずはやってから考えろ

（アウトプットする場所の話もしたかったんですが、思った以上に長くなったので別の記事にします）

次の記事

• Github転職の最新事情2022(3日目)
• カレンダーページ