【悲報】職務経歴書が書けない

愚痴。

職務経歴書が苦手です。
ブログはもう何百本、Qiitaも何十本書いてる私ですが、職務経歴書を書こうとすると手が止まります。これ私だけでしょうか。
フォーマットが苦手とかいうのもあるんですが、過去の仕事に対して実績をPRするところが苦手です。

職務経歴書でよく見かける参考例は営業とか管理職が多い気がします。
「20人のチームをまとめました」とか「10億円売り上げました」とか「賞を取りました」とか、確かに分かりやすいんですよね。
翻ってエンジニアはどうかと言えば、「こういうシステムを作りました」を並べていくとまあ分かりやすいと思います。

でも私の強みはどちらかというとエンジニアリングそのものより、どれだけプロジェクト・プロダクトを成功させるためにどう動くか、みたいなところです。
しかしそうやって考えると、過去はむしろ失敗続きです。成功してたら既に会社立ててCEOになってメガヒットサービスをバンバン出しています。そんな奴世の中にほとんどいません。

だから失敗続きの諸々を、反省的に振り返って哲学的に向き合わなければなりません。
振り返るならまだしも、それをPRとして書かなければならない。

うーーん？
「◯◯したけど、△△したのでよかった（小並感）」しか書けないじゃないですか。

これ、面談ではもっと上手く言えるんです。
ストーリー建てられるので、非常に難しい課題、かつ自分に全権限があるわけではない状態で、どのように振る舞ったかっていうのは話せます。
でもそれを3行くらいに落とし込むのは非常に厳しい。

・・・いや、何か言い訳かもしれないですねこれ。文章力がないだけか。そもそも成功してないのが悪いんですよ（ちゃぶ台返し）

（日記）会社訪問は楽しい

最近、3社から直接お声がけ頂いて、会社訪問をしています（1社は明日）

サービスをある程度ワークさせている方とお話するのは純粋に楽しいです。日頃のストレスが落ちるくらいリラックスできます。

ただ結構私に求められがちなのが企画層を含めた開発周辺っぽいので、もう少しアプリ＋サービス周辺について理路整然と語れるようになっておきたいです。

と言ってもそんな簡単なもんじゃないですが。
「難しいと思う」という旨を語った結果お仕事発生しないのは痛し痒しですね。

「アプリを作るいいタイミングが来たら声を掛ける」と言うフェーズのベンチャー企業がもうこれで6社くらい・・・

なぜバグが多いのか、なぜバグが増えるのか

今度Qiitaに書きたいんですが、メモとして

論理構造はこのような感じです。

キーワードは状態数ですかね
あと仕様のコントロール

（日記）習得するべきスキルが多すぎて無理

最近週65時間労働です。

眠いです。

まあそれはいいんですが、これからどのようにスキルを伸ばしていくか悩んでいます。悩んでいますっていうか、悩んでいないときがないです。

皆苦しんでると思うんですが、「一領域に非常に詳しい人」を維持するには、月80時間は関わってないと退化していく気がしています。月160時間1年やってようやく少しレベルが上がるくらいでしょうか。

「詳しい人」ではなくともあらゆるジャンルで「最低限できる人」になりたいわけですが、これが達成できるまで大体500時間くらいです。前も同じこと書きましたこれ。
「詳しい人」を維持しつつ他の領域を攻めるには、多分フルコミットを新しいスキルで、副業を詳しいスキルでやればいいと思うんですが、フルコミットをできるようになるまで500時間かかるはずなのでこれは理想論です。
ただ余裕のある企業の社員になるとここらへんできるんですよね。2年ごとに様々なスキルを身につけるような人はメガベンチャーでよく見かけます。

詳しいスキルをフルコミットしつつ、新しいスキルを500時間でつけるなら、月に捻出できるのは100時間程度でしょうから、半年かかります。
きつい。

私の場合は50時間も捻出できないので1年はかかるでしょう。
きつい。

さらに言えば、その程度のライトなスキルを身に着けても、年商には大して響かなさそうなんですよね。
どうにもきつい。

もっとサックリ技術習得できないですかね。
　

追記：

直近で習得したいスキル

Laravel＋WebAPI（年内頑張る）
Go＋React（ケンチクカタチでやる予定）
PWA（やりたいが無理か？）
英語（ほとんど諦めている）

メンター使って高速でやれないかなーと考えたらうめのん氏のブログが見つかりました。前も見ましたコレ、実際難しいですよね（お金的に！）

プログラミングでハマったら有料相談できるCodementorを使ってみた – うめのんブログ

「詳しい人」に気軽に聞けたとしても、500時間がせいぜい350時間に減るくらいでしょうか？

別解として「人を使う」とか「チームを組む」があって、こちらの方がまともだと思うんですが、そうすると「目的」が必要になって、今度はプロダクト側・マーケティング側の知識が必要になって、更に大きいチームが必要になって・・・と際限が無くなるんですよね。
すると最終的には「会社立てるしかない」となるんですが「ネタがない」「仕事を探さなければならない」「ファイアリングしなければならない」でまた別の苦しみがどうのこうの。

仕事で挨拶が重要なロジカルな理由

anond.hatelabo.jp

わかる〜〜〜

以前居た会社で同じ感じでした。特に出社時間がバラけると挨拶が消えがちです。

良くないなーと思うからあいさつ位しようよ！と言いたいんだけど、あいさつをした方が良いロジカルな説明が出来ない

所詮気持ちの問題なのだろうか

マナーやモラルの話なのか

理系のエンジニアさんも納得してくれるような説明ないでしょうか？

当時考えた説明を書きます。

前提：挨拶はマナー、モラルという発想をやめる

IT業界は必要なもの、必要じゃないものをゼロベースで考えられる数少ない業界だと思います。そういうところは好きです。
だから他の業界では常識なことも「それは必要ない」と言ってやっていない会社もたくさんあります。
それでも挨拶は大事だと思います。
なので一旦、マナーやモラルと言う観点はやめましょう。

挨拶以外で一言も会話しないケースが多い

IT業界、たとえばプログラマーなんかはコードと一日向き合ってもお金がもらえるお仕事です。なので、その人と一言も話さず終わるということが結構あります。
そしてどんなに喋る人でも、自分から関係性の距離が遠くなるほど話さなくなります。

一言も話さない人には、話しかけづらい

一言も話さないと、当たり前ですけどどんどん話しかけづらくなるものです。
でも私達の仕事は大抵の場合話さなきゃならないシーンは存在するものです。
そのときに話しかけるハードルが高いと「まあ、別に話さなくてもいいや」となってしまいます。
すると認識の不一致による様々な事故が起きたりします。
あのとき軽い確認をしていたら、というようなことが起きます。

もちろん「全ての情報をチケットで管理するべき」みたいな人も居ますが、話が難しくなるほどどうしても会話が必要になってくるので、単純な作業しかできなくなってしまいます。

というわけで結論：話しかけにくくならないようにするために挨拶する

例外はあるか

必要なときにはきちんと話す仲であれば、別になくてもいいんじゃないでしょうか。
特に挨拶が重要なのは知らない人、仲良くない人、話しかけづらい人です。

または、その人が完全に自分の仕事に関係ないなら、別にしなくても困らないかもしれません。

知らない人に一番話しかけやすい内容：挨拶

いきなりその人に、趣味や天気の話をするより、挨拶するほうが簡単ですよね。挨拶は誰にでもしていい一番最低限のコミュニケーションツールです。

無視のデメリット

無視すると、余計に話しかけづらい人認定されてしまいます。
これは積み重ねです。10回に1回無視するのはさほど問題ではありませんが、3回連続無視したら4回目はないかもしれません。

無視されても挨拶する

正直イヤだと思いますが、無視されても挨拶しなければなりません。
挨拶以外でもいいんですが、上に書いたとおり挨拶が最低限のコミュニケーションツールなので、挨拶以外の選択肢がさほど見つかりません。

困ること：時間がバラバラ

出勤、退勤時間がバラバラだとか、そもそもシフト制で会えないとか、いろんな理由で最小限のコミュニケーションを封じられるケースがあります。その場合は代わりの何かを探さなければなりません。

挨拶の欠点は時間縛りがある点ですね。
コミュニケーションにうるさい芸能関係などでは常に「おはようございます」ですが、そういう理由もあるのかもしれません。

代替案：Slackで挨拶、メールで挨拶

ダメなら他の方法で、最小限のコミュニケーションを試みるとよいかもしれません。
挨拶がダメなら他に何かしら考えなければなりません。

挨拶に類似するもの：「はじめまして」

例えばチームに新しいメンバーが入った場合、マネージャーは極力はじめましての機会を設けなければなりません。最初の最初の挨拶（自己紹介やはじめまして）を逃すと、最初のきっかけが失われてしまいます。

「別にしなくてもいいじゃん」に反論しづらい

話しかけやすさ（心理的安全性）というのは可視化されません。

そしてすぐに致命的な何かを生むわけではなく、じわじわと組織を蝕んていきます。

だから「別に挨拶しなくていいじゃん」には反論しづらいし、実際できないのですが、だからこそ自分だけは挨拶していかないといけないと思います。また挨拶しづらい組織は黄色信号なのだと思います。

これは「心理的安全性」でググったほうが早いかもしれませんね。

別解：コミュニケーション担当を置く

とは言え変なやつが多いこのIT業界では、それでも仕事をどうにかうまく動かさなければならないので、コミュニケーションハブになる人が存在することがあります。
でも明らかに組織設計としては重たくなりますよね。

TwitterAPIが高い件

メモです

新しいTwitter PremiumのFull-Archive API

https://developer.twitter.com/en/pricing/search-fullarchive

月に100リクエストで99ドルって書いてて、いくらなんでも高すぎない？と思ってましたが、実際高いらしいですこれ。

使った方の記事がありました。

Twitter Premium Search APIを使ってツイートを集めた話 - Qiita

え、1リクエスト100円ってことですか？
1リクエスト500ツイートが上限なので、1ツイート最低0.2円ってなりますねこれ。ひえー

例えばアニメのツイート数、1アニメあたり数万は軽くいくんですが。
10万ツイート　→　2万円なので、割りとキツイです。

おそらく、無料or安い、過去7日や過去30日までのツイートにアクセスできるAPIを使ってサーバーに貯めていくのが定石なんでしょうね。
でもそれは何年もずっとバッチ動かして無ければならないので、これからシステムを組むなら使えない手です。

うーむ。せめて1/10の値段ならいろいろできそうなんですが。

プログラマーが契約で確認する最低限のこと

忘れそうなのでメモ程度に。

請負か準委任か？

ググると類似の記事がたくさん出てきますが。これは請負か準委任か、みたいなボーダーラインを作ることが難しいです。
一番わかり易いところだと、準委任契約は完成義務を追わず瑕疵責任もない、みたいなのが一般的ですが、「準委任だよ」と言われて契約書を見たら完成義務と瑕疵責任が入っていることの方が多いです。
たぶん発注側企業としては「そんくらいやって当たり前」と思ってるんでしょうが、だとしたら単価の面でもうちょっと考えなきゃいけないですよね。

まあ考えても単価は上がらないんですけどね😭

ここらへん、境界線が曖昧なのでまとめて「業務委託」と言ってる会社も結構見ます。

契約書外も重要

過去の裁判を見ればわかりますが、契約書より「実際どうだったか」を重視されます。だからコミュニケーションが重要になります。

最低限、確認する点

• 時間を管理されているか（報告しているか）
• 瑕疵責任の有無（バグが後から見つかった場合誰の責任か）
• 完成義務（納品日までに終わらなかった場合、自身の責任で無報酬で完成させるか）

一番ありがちなのは「まだ完成してないから直せ、直したら払う」みたいなやつです。

これらに付随して

• 納期はどのように決定されるか
• 瑕疵責任がどのように決定されるか

ここらへんですね。
ここらへんは契約書に入ってこないので、PMやPLに確認する必要があります。法務部は頑ななので、プロジェクト内の人とそこでコンセンサスがどこまで取れるかが結構鍵なんじゃないでしょうか、現実問題（自分に圧倒的な実力があれば「そんな会社知らね」と言えるんですけど）

経験的に、「この契約書ちょっとあんまりでは？」と言ってもあまり通らないことが多い気がします。法務的な話になっちゃうので（1勝3敗2スルー）

まあでもそうなると単価や見積もりがガッ！と上振れますよね。個人的にそういうのアジャイル感とかけ離れるので嫌いなんですが、しょうがないです。

つらみ。