  |
はてなキーワード: 社内Wikiとは
入社しばらくしてからずっと、仕事への抵抗感がすごすぎて人の目のないところでは常時頭かきむしって手足バタバタさせながら無意味にAlt+Tabを連打して無駄に時間を浪費してる。
これどうすれば治るんだ？仕事って行為そのものが向いてない気がする。
自分なりに考えたんだけど、なんか考えても無駄な『無意味な仕事に対して湧いてくるイライラ』みたいなものへの抵抗力が極端に低いんじゃないかと思うんだよな。
でも無意味に感じる仕事とか、サラリーマンってそんなもんか。もう最近はなにもわからん。イライラしすぎて今日も無駄に有給使ってしまった。
ぼかしてるから全然意味不明だと思うけど、今の業務の不満点みたいなものを書きなぐってみた。
現状の職種としては対法人なんだけど、「現場の営業にあらゆる業務プロセスの不備の後始末が任される構造になってて、同担当の先輩見ても業務時間の2割も客とやり取りしてないのマジで意味が分からんなぁ」とか考えてると、目の前のこなすべき事務作業も全然捗らずにストレスだけが溜まってしまう。
なんというか自分の本業(対顧客)に力を注げるまでのオーバーヘッドがでかすぎて、一周回って自分が何やってるかわからなくなってくるんだ。
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
↓
みたいな感じなんだけど、言語化できるだけまだマシな部類なんだよな。こんなんが何十種類もあって、担当内の誰もわからなくてナレッジがあつまるような場所もないから毎回手探りで対応して、それぞれに毎回イライラしてる。
上の一個一個の作業は大した手間じゃないけどこれが1人当たり5,6社(部門)×各2～4案件くらい並走してるので、ワイの貧弱なワーキングメモリが悲鳴を上げてる。
というか客に関係あるの最初と最後だけで、極論、間に挟まってる作業は社内で自動化できるはずで、俺が手作業で丹精込めてやってる意味なんもない気がする。
でも間の作業で規定から外れるとまたその修正作業が増えて余計に手間が掛かるので、客とのやり取りを雑に済ませて社内用excelマクロを延々ポチポチしつつ、社内他部門へのメールを連打している。
これに加えて、例えば「各部署内で事務作業の効率化を図りましょう！」とかお達しがあってRPAのライセンスだけ渡されて、通常業務の片手間でシナリオ作って効果検証して提出みたいなことをやらされたりもする。(そもそもの業務が全然定型的に組まれていないのでシナリオ作りも大変苦痛)
もっと腰を落ち着けて業界の情報取集したり客の要望引き出したり提案練ったりそのための社内調整したりしたかった。
なんだかんだ業界トップのクソデカ企業だし、まがいなりにもITだDXだとか言ってるからもう少しマトモな仕組みがあるのかと思ってた。
何の意味もない作業に時間を取られて、何のスキルも身につかないまま無為に時間と精神を削られるのもだいぶつらい。
ただ、普通に考えて自分でどうにもできない部分は「仕事の効率が～」とか喚いてないで何も考えずにこなすしかないし、逆に「運と相性が悪かったから評価最低でもいいや」と割り切って異動のために勉強に時間割くとか、そんな感じで開き直れもせずにウジウジしてるのは単に自分が無能で仕事にも向いていないからとは思う。
わからんなにも。どうしたらいいんだろう。
絶賛リモートワーク中の弊社ですが、業務改善に関する打ち合わせで「どうせやるならちゃんと仕組み作りましょうよ」「後で調べられるように担当者は社内wikiに記録残すのはどうですか」って言っただけなのに、「君意識高いねー」って言われてしまった。
恐らく上司に悪意はなくて、これ以上負担が増えるようなことはしたくないってだけなんだろうけど、コレ言われたらたまったもんじゃない。入社以来ずっとリモートワークで会社の雰囲気も掴めない中、必死にアイデア出してるのに「意識高い」って適当に扱われると今後どうしたらわからなくなる。こちとらそんなメンタル強くないんじゃー
求人資料を見るだけじゃなくて、可能な限り、直接面接で聞いたり、中の人に聞いたほうがよい。
Developer Experienceてきなところっすね。
バックエンド系なので、フロントエンドのことはよくわからない。
（給料とかは当然見ると思うので省略）
Windowsが悪いという話ではなく、WIndows以外の選択肢（Mac、Linux）を選べるというのが大事。
Windows縛りのところはだいたいろくでもない。
リモートワークが好きってわけではないんだけど、台風の日とか出社しなくてもいいのはありがたい。
あと、リモートワーク可な職場は、非同期コミュニケーションが発達していて、エンジニアとしての仕事がしやすい可能性が高い。
例えば、Github Enterpriseじゃなくて、github.comが使える、とか。ASP/SaaSがどの程度使えるか、ってのは、セキュリティがめんどくさいかそうでないかの試金石として有用。
Oracle RACを使っているところは経験上、結構がちがちな開発スタイルの可能性が高い。
古いRubyとか、古いMySQLを使い続けている職場は、そもそもあまり技術に関心がない可能性が高い。
エンジニアブログが無いのは論外（いい会社かもだけど、外からはわからん）、あと更新頻度、更新者のプロフィールをちゃんと出してるか、など。
更新者のプロフィールをちゃんと出している会社は、中の人間の対外発表をそれなりに推奨（黙認）していると想像できる。
いわずもなタイトルは釣りです。たぶん、過去に色んな技術者やメディア等で議論されてきたのではないかと思う。自身が今の職場で久しぶりに清々しいくらいに経験しているので、備忘録として状況をできるだけ冷静に書き記すものである。参考になりえるとしたら”現職の状況がヤバイんだけど、どうやって現状打破を目論見ながら最悪のシナリオを想定した逃げ道も確保するか”といったところの考え方くらいかもしれない。それ以上もそれ以下も意味はない。
業界についてはあえてぼやかすが、歴史が長い業界だ。自身が参画したのははじめての業界だ。いろいろと勝手がわからないことはある。業界の歴史が長いからということではないと思うが、業務フローやプロセスが古臭い。逆に私達技術者の活躍の伸び代がまだまだある業界でもあると言える。自社事業（サービス）を持つベンチャーだ。
技術的なことを包括的に担当してほしいということだった。結果的に(他にマネージャがいるのに)ただの人月計算をするおじさんになっている。ベンチャーでそういった担当者がいないのでよくあることだ。
いくつか状況を記載しておく。
やり方はどうでもいいから
当初このように聞いていた。目的が達成されれば、もしくは課題が解決すれば、ということだと思っていた。しかし、そうではない。
この方法以外認めない
という含みがあり、フォーマリティが実はちゃんとある。しかし、そういった期待値のコンテキストが不足しているという状態。そしてすべての事柄について隠しフォーマットがあり、それに準拠しなければならない。なぜならこういった背景だから。というものがしっかりある。個人的にベンチャーやスタートアップでは抜けがちな”背景”がしっかりあるのは良いことがと思うが、後発で加入してきた人に対して明文化されていない状態もあり、自身の役割としてはそういった期待値の明文化をすることも含まれるのではないかと思った。（しかし、そこにそんなにコストかけんなバカってことにもなった）
Web系スタートアップ・ベンチャー界隈ではこういった課題に関しては社内Wiki的なSaaS型サービスで全員で知見を同期的に書き出して意見交換をすることでナレッジ化していくといった手法を取っているところが多い気がする。そしてその行為を”文化形成”などと表現しているところもある。しかし、業界的にはそういった文化にはないためすべてはファイルベースでの情報共有となっている。もちろん、そういった手法で十分なケースもあるのだが、一方的に送りつけておいて”これ読んでおいてください”などとして一切の背景を説明されていないのが現状な訳で、背景が不確実なまま自身の想像力と経験で行動してしまうと業界の常識等の地雷を踏んでしまうことが多々あるのでできるだけ不確実な要素をなくしていくといったことにコストをかけることになる。
前に言ったじゃないですか
となる地雷が沢山あるやつ。スタートアップ・ベンチャーに限定したあるあるみたいだと思われるのも問題なので、一応書いておくと大手でもある。しかし、大手は割としっかり明文化している。その代りそのフォーマットを厳守することを要求されるし、従業員はその制限の中でいかに最高のパフォーマンスを出せるか？というレースになっているという印象。
これは確実に消耗戦になるやつだ。殺しにかかっている。
別にWeb系スタートアップ・ベンチャー界隈のやり方にこだわるつもりはないが、課題管理表を管理する工数を取る文化は色んな業界にまだ根強くあると思う。具体的な管理手法としては昨今では一般的なIssueベースなのに結局Excelでやることになる。ただのExcelではなくてWBSという形式で欲しがっているケースが多いのではないかと思う。WBSを引くということはアジャイル的な変動的なスケジュールを持つといった管理方法ではなく、割とFixされたウォーターフォール型に近い考え方がある場合にこういったことが起こりやすいのかもしれない。とは言え、何らかのプロジェクトマネージメントツールを使いたい。そしてこれも確実に消耗戦になるやつだ。殺しにかかっている。
とにかく割り込みタスクが全員から投げられる。(WBSで欲しがるのに)具体的な優先度や期日もない。下手すれば”何をしてほしい”といったコンテキストもない。すべては投げられた人のMy Wayで処理されることになり、ナレッジマネージメントもおざなりになっているような状況ではスーパー属人化する。こういった状況は”投げられる人が投げる相手がいないからPlaying Manager化していること”が原因でも起こる。人事計画次第では解決できる可能性のある問題ではある。しかし、そういった見通しがない場合はしんどい。これも確実に消耗戦になるやつだ。殺しにかかっている。
自身としては”確実性”のある部分については"可能な限り確実に"しておきたい。それは具体的にいうと"今見えてる課題で緊急度が高いもの"の対応だ。これは"確実に飛び越えられるハードル"という意味ではなく、"確実に解決しなければならない課題"という意味だ。もちろん、そういった課題がなぜ緊急性が高いのか？というコンテキストの説明についてはコストをかけて説明しなくてはならない。地道ではあるが方法はそれしかない。しかし、そういったことを経験しておくと”自分の言葉でわかりやすく説明する”といったスキルがつく。そういったスキルが欲しい方にはおすすめする。また、確実に処理したことでかつて不確実だったものの具体性があがることもある。もっと理想を言えば不確実なものの具体性を上げるためにどう確実化していくか？というスケジュールの引き方をしても良いと思う。
問題はメンバーそれぞれのスペシャリティ、経歴、興味、個性がまだわからないことを前提にした説明が必要で”相手が何からわからないのか？”がわからない状態だ、色んな補足情報をゼロから入れながら説明すると物凄いコストになる。かといってあまり上から目線でモノを言ってしまうと後のチームビルディングにおける心理的安全性にも影響するため、嫌がらずできるだけニコニコしながら説明するしかない。これは一種の”信頼貯金”に将来つながってくるものだと思う。
しかし、何事も限度はある。それを自身で見極めないと確実に消耗戦は始まる。殺しにかかってくるのだ。
さて、正直困っている。というか疲れている。
忙殺されてしまったりするとどうしても以前のライフスタイルや状況と比較することすらできずにいることがある。気をつけたい。ある人は独身かもしれないし、ある人は配偶者も子どもいて育児や家事などのタスクを抱えているかもしれない。自身は家庭の事情もあり家庭運用タスクももっているライフスタイルなので、ワークがライフに侵入してくると大きな問題として認識する。実際に今、そういった状況が起こっている。（もちろん、それなりの待遇の場合は家庭内で調整して検討しても良いとは思うがあくまで運用可能な状態であることは前提である）
そういった判断ができにくい状況にあるということを一度立ち止まって認識するということが大事だ。さもなくば遠慮なく消耗戦に持ち込まれ、殺しにかかってくるのだ。
実際、定時外（邪魔の入らない時間）でのパフォーマンスに大きく依存する状況が続いている。死にたい。体調不良等でリモート勤務にしたときの捗り具合がヤバイ（笑）しかし、本来、定時内のパフォーマンスで自身の力量や限界を測るべきだ。そして無理なことは無理という勇気を持つことも大切だ（自戒）。
https://youtu.be/0sEM3UKuRw4?t=28
完全に気力・体力との勝負ではあるという前提ではあるが、少し粘ることで状況が外的要因等により改善したりすることもある。内的要因であることが理想的ではあるのだが…そこは自身の気力・体力と相談して”いつまでこの船に乗るか？”を決めていくべきだろう。自身でその状況を変えたい！と思うモチベーティブな人間はその限りではないが、その状態でいられる状況とそうではない状況もあるということは言っておきたい。
多くのベンチャーの場合、代表の哲学は経営方針や事業方針に深く影響しているというか、そのまんまそれが方針になっている。そして多くの求職者はその”綺麗な上澄みだけを抽出した部分"だけを読んで共感して入社することになる。しかし、入社してみると違うと感じることもある。感じるだけじゃなくて、実際に言っていることから違うこともあるだろう。しかし、それが会社だ。と最近思える程度に大人になった。
それって理念に反してませんか？
みたいなことを言えるなら良いと思うが、言えないならそれはすでに消耗戦の始まりであり、いつでも殺しにかかってこれるヤツだ。
正常な判断が困難な場合、こういった指標で評価することにはなる。自身は仕事が好きな方ではあるので割と参考にする。そして、楽しめていない。もちろん、苦しいときもあることは承知の上だが、この状況を具体的に変えていくモチベーションも沸かないのでそれに輪をかけている。これは確実に殺しにかかっている。
現実問題として不確実的で抽象度の高いタスクを集中砲火されてしまい、自分で優先順位を決めにくい状態が起こっている。自分の手に余る程度であれば良いが(多少の無理なら許容する)、確実にこのままでは消耗してしまうことは目に見えているので、年末年始や週末を利用して(週末は邪魔な割り込みが入らないから作業しやすいという悪循環にもなっている)自分なりの"働きやすさ"を作ろうと必死だ。しかし、それが自身の限界を超える前に構築できなかった場合、最悪倒れる。その前に転職も見据えた行動を取るべきだろう。ということで行動するしかないので行動している。
おかげさまで既に数社からリファラルで引き合いがある。しかし、こういった状態であることもご存知なため（笑）、あまり良い状況（良い印象を与えることができる状況）とは言えない。迎え入れる側も気力・体力が満たされた状態の人に来てほしいに決まっている。しかし、命辛辛逃げようとしている脱北者みたいな人たちにはそういった余裕がない。それとそういった状況において転職先を正常に判断できない可能性もある。また同じ状況になりやすい。気をつけたい。というか面談のときに”他に聞きたいことはありますか？”というところで聞く質問はそこだと思う。
全てはここに帰するのではないかと思う。
今年の夏頃に妊娠がわかって、その時は嬉しい反面今後に対する不安の方が大きかった。ただパートナーが大いに喜んでくれたのが良かった(一方で目一杯喜べない自分が少し嫌になったのもあった。)
ただ、原因不明の体調不良が何に起因しているかがわかってホッとしたのもあった。
不安いっぱいで両親には半分泣きながら電話で伝えた。こっちがこんなな調子なので親もちょっと困惑してた、でもめでたいことだから、と。
後々LINEで改めておめでとうと届いた。
父親はせめて丸々3〜4年は…と言ってた、ちょっと早いよ、と。
私もそう思う。
環境に慣れてきたものの全体はまだ見通せてない2年目、3年目になってこれから、というところで。
自分が風邪の諸症状だと思っていた、びみょーに高い微熱と身体のダルさはつわりだったのだ。
最初の3ヶ月ぐらいは貧血になりがちで通勤中にフラフラする事も多かった。
体も疲れやすく、仕事が終わった後はそのままソファに転がっていつのまにか寝てる…みたいな生活が続いた。
パートナーはそんな私をダラけていると感じている節があった。お皿を洗う気力も無いぐらいめちゃめちゃに眠たくて、寝転がる前に洗えばいいじゃんと言われるけど食後に10分も立ってられなくなってた。
これぐらいの時からブラの締め付けがキツく感じ、窮屈な服を着ると気分が悪くなった。
常に微熱状態みたいな頭のモヤモヤ感に、このまま働いていけるのか不安になった事もある。
吐き気もあったけど日中は我慢できる程度にマシだった。でも唾液が止まらなくて気持ち悪くてずっとガムやらハイチュウやらを食べて気を紛らわしていた。
晩御飯は梅干し茶漬けばっかり食べてた時期があった。お茶漬けを食べられればいい方で、だめな時は桃やプラム、梨を食べていた。
カルボナーラが好きで作ったのに、一口食べたらもう食べられない…ということもあった。飲み込めないし、なんか胃が拒否するのだ。
食べたあとどうしてもダメで全部リバースしてしまう事もあった。鍋物もうどんもダメなのか。
お寿司、生物だから食べない方がいいけど私はサーモンのお寿司が食べたくてたまらなかった。お寿司が食べたくてイライラした。
このあと1年はお寿司が食べられない。キレそうであった。
私の想像していたつわり、というかテレビやアニメ、漫画で知っていたつわり(妊娠)の知識って、
・登場人物がトイレで吐いてもしかして妊娠…となる(吐くのは1回だけ)
・酸っぱいものが無性に食べたくなる(食の好みが変わるだけで、食べられなくて辛いとかは無い)
だったので、
大きなギャップがあった。
親から出産が大変だったという話は何度か聞いたが、妊娠中が大変だった話は聞かなかった。
ほとんど同じ時期に妊娠した同級生は殆ど全くつわりが無いと言っていた。
気を遣って貰ったのか、仕事もスポットで入るような細かいものがほとんどで、量も少なかった。
なんなら仕事のない日も多かったので、これはこれで何か社内ニートみたいでちょっと嫌だった、ような気がする。
とにかく自分の体調がコントロールできず、ふだんの6割程度のパフォーマンスしか出ないことに苛立っていた。
秋ぐらいになって、一個案件を任せて貰えることになった。
つわりの諸症状は夏と比べると大分良くなってた。吐き気も無い。
でも、やっぱり日によって体調とメンタルが崩れてしまうことがあってぽつぽつと休む暇あった。
終わってから何週間か経ってだろうか、
朝、焼けるような腰？背中？の強い痛みで目が覚めて痛みで動けなかった。
その日はそのまま休んだ。おやすみの連絡を入れてからしばらく経って痛みは治まった。
そこからずるずる1週間休んだ。
夜中や早朝に身体がひどく痛む、のももちろんあったけど、出社してもどうせやる事無いしなあ、とか、苦手な人に会うの嫌だなあ、とか考えるうちに行かなくなってた。このまま産休に入ってしまいたいとも思ってた。
なんとか踏ん切りをつけて出社した。
最後だし、あと振り返りでもっとこう出来るといいね！と伝えられていたのもあったので、とにかく頑張ろうと思った。
引き継ぐものは引き継いだ。
最終出社日、お世話になった人にお菓子を配って、デスクを整理して、社内wikiを書いたりしながらのんびり過ごした。
ああこれで最後なんだなと思った。
何か気を緩めると涙が出てきそうなので、先日のセールで注文した液タブのことを考えた。コンビニで受け取って帰ろう。
家に着くとまたなんともさみしい気持ちがこみ上げてきた。
春夏ごろはむしろ会社に行きたくない行きたくないと言ってて、妊娠がわかった時解放されたような気持ちが少しあったのを覚えてる。会社辞めないにせよ他の部署に行けないかなぐらいには考えていた。
いまはただただ終わってしまったのが悲しい。
積んでいた本を毎日読もう、とか、
色々考えてはいたけど。
平日毎日同じ時間に起きて、同じ場所に行って、同じ空間で働いていたそのリズムが急に無くなる心許なさったら無い。
きっとまた別の楽しみがあるんだろうけど、今はただただ寂しい。
大学では工学部ではない理系だったので右も左も分からないなりにがんばってみようと思っていた。
悪く言えば自分の能力に絶望して夢を諦めることになり都落ちした気分での就職だったのでやぶれかぶれだったというほうが近いかもしれない。
相性というか、背景の差とか常識の差みたいなものがあって、自分から見ると無駄の多い職場だなあと感じて研修期間が終わり本配属された。
本来の業務はいわゆる故障解析で、歩留まりを上げていくのが使命だった。
せっかくだから色んな所に首を突っ込み改善できそうなところは提案をしたり、自動化したり、それらのドキュメンテーションを書いてみたりした。
プログラミングの経験は皆無だったが、理論系卒が工学部に負けられんという謎のプライドでVBAから、Rやら自社製品の解析用環境の割と珍しいタイプのスクリプト言語など（特定されそうだからぼかすけど。）
とりあえず手が出せそうなものは何でも調べてみてありものを改造してみたり勝手に作ってみたりして提案していた。
物怖じしない新人がぎゃーぎゃー騒いでいるぐらいのものだったと思うが、何にせよいくつかの改善が上手く実務にハマって成果として認められたりしだしたのが1年目。
この辺で気付いたことだが、製造業のITリテラシーは驚くほど低い。製造業と一般化するのはフェアじゃないかもしれないから厳密に言えば弊社の、という意味だが。
なんせまともにプログラムを書いたことが無い新人が半年で身に着けた程度のスキルで書いたプログラムで、1日かかってた仕事が1時間で終わったりするのだ。
ようするにMS officeの達人みたいなのがいっぱいいて、Ctrl+CとCtrl+Vが機能のすべてだと思っているということだ。
（そして彼らの口癖は「忙しい」だ、会議中も左手はCtrl+CとCtrl+Vを叩き続けている。）
2年目に気付いたのは、弊社エンジニアのITリテラシーが低くとどまっている要員のひとつに、実はITインフラチームがことのほかマトモだということがある、ということだ。
製造中のセンサーデータやらテストデータやらETL的にはおそらくえげつない部分で、かなり優秀な人間が居て上手くぶん回し切っている様子だった。
無骨だが使いやすいイントラ上のwebページが用意されて、グロテスクな部分を気にせずクリックだけで上述のデータを整ったものとして引っ張ることができた。
だから逆に言えば下々の人間はコピペでなんとか恰好を整えられるのだった。
彼らはモダンな発想があって、あるいはお偉いさんが「ビッグデータ」とか言い出したのかもしれないが、ともかく、HadoopやらAWSやらそういったものを導入しようと試みているらしかった。
私はそれに感動した。なんせWebスクレイピングみたいな方法で他人が社内プラットフォームや社内WIKIに上げた報告をまとめたり、製造時データと紐づけたり、それからグラフ描いたりみたいな業務が増えていたからだ。
それっぽく表現すればデータ分析屋さんということになるのだろうが、どぶをさらっているという表現のほうが近かったかもしれない。
何にせよそういったものを一気通貫、自動化できるポテンシャルがあると感じられた。
SQLもjavaも書いたことなんて無かったが、1年前やっていたことを考えれば同じことだ。何にせよ歓迎だった。しかも管理はIT持ちだ。餅は餅屋に頼むべきだ。それもできれば美味い餅屋に。
ところがその「ビッグデータ」プロジェクトは人手不足か、資金不足か、あるいは生みの苦しみか、ことのほか時間がかかっていた。（あとで聞いた話、外部コンサルで外れを引いたらしい）
自分もドメインの知識からの助言とか想定される使い方についての意見を伝えていったし（有難迷惑だった可能性は否定できないが）、もう少し待てばモノになると信じていたし、実際そうなった。
具体的な話ができないのだが、客先で起こった不良の原因をつきとめ、その改善効果の確認の為に数十億行のデータが活用された。彼らの力が無ければ常識的な時間では終わらなかった仕事だった。
残念だったのは彼らの優秀さの割に一般のエンジニアのスキルがあまりに低かったということだ。つまりそのプラットフォームを使いこなせる人間が著しく少なかったのだ。
そして上述の足踏みをしていた期間に心象を悪くしていたという問題もあった。とっかかりが難しい割に不安定だというレッテルを張られてしまっていた。
もうすこし悪いことに、同時期に企業買収が起こった。我々は黒字を出していたが同業他社（厳密にはその親会社に）に買われることになった。
そういう時に起ることは不要な冗長性の削減だ。子会社として存続する場合は知らないが、競合他社に吸収合併ということは、多くの部署にとってそのカウンターとなる部署が相手側にも存在するということだ。
つまりどちらにもある部署は統合するか一方を無くすかという戦争が始まるのだ。ITも例外ではない。（ITインフラ部署の無い会社はさすがに無いはずだ）
一方で製造業の本懐である「製品を作り、売る」という部分は比較的守られる。それこそが根源的な資源であり、利益を生む仕組みであり、既存の顧客への説明が必要だからだ。
そして私の仕事は歩留まり改善であり、故障解析であり、データ分析だ。何が起こったか。
（ここで簡単のために旧弊社を（旧）A社、買収した側の競合他社を（旧）B社と呼ぶことにする。）
今の旧A社から引き続いている業務をB社のプラットフォームで行えるように転換せよという下命である。
旧B社の製造データに対するアプローチはA社とまったく異なっていた。Web UIは美しく整っており、それっぽいグラフが簡単に表示され、A社側のお偉いさんからも好評を得ていた。
だがそのバックエンドは控えめに言って酷いモノだった。いくつもの情報を正常に保存できておらず、「それっぽい何か」を素早く返答することを第一義としているように見えた。
そして上述のように器用貧乏街道を歩んできた私に投げられたのは次の言葉だ
「増田くん、B社のプラットフォーム使うことは決定事項だから、君が自動化してたやつ全部そっちで動くようにしといて。よくわかんないけどプログラムとかてきとうにできるでしょ？」
もちろんhtmlもjavascriptもphpもRoRも一行も書いたことが無いのが当時の私である。
果たして旧A社のプラットフォームはB社のプラットフォームのデータソースのような扱いを受ける羽目になり、私はjavascript本格入門を片手にB社の事業所に出向くことになった。
そこで散々「旧A社のプラットフォームは遅い・使いづらい・不安定」と貶されながらチマチマとグラフを表示するページを書いている。
クオリティの低いバックエンドを作る集団が書いているサーバーサイドphpの酷さは素人目にも分かるレベルで筆舌に尽くしがたいものがあるが、
反面教師だと思って耐える日々だ。
最近分かったことは旧B社のバックエンドスクリプトがデータを引っ張るついでに意図的に旧A社のプラットフォームを攻撃しているということだ。DDoSとまでは言わないが、悪意100%である。
いわく旧A社のプラットフォームを畳むためには旧B社のプラットフォームが優秀であることを示す必要があるとのことである。（つまり旧A社プラットフォームが不安定かつ重くなることを意図しているらしい）
旧A社から継続されてる業務はまだそこ使ってるんですけど・・・
それはもちろん旧A社の上司に報告したが「見て見ぬふりをしろ」とのことだった。旧A社のITで何度もお世話になったひとに伝えると「知ってるけどね・・・」と悲しい目をして苦笑いしていた。
旧A社ITはその優秀さでそれらの攻撃をいなしつつあるようにも見える（私も素人に毛が生えたレベルだが、ソフトウェアエンジニアリングのレベルが二回りぐらい違うように見える）
そして私はいつまでソフトウェアエンジニアの真似事を続けてキャリアを消費していけばいいのか、もうダメかもしれない。
酔っているからとりとめのない内容になるかも。
本人に言えとか、増田に書いてどうなるとか言われるんだろうが、本当にただの愚痴だから、この記事でどうこうしようってわけじゃない。
ただ吐き出させてくれ。
うちみたいな弱小ベンダーに新卒で入ってきた後輩がガチの天才プログラマだった。
だが、その手の天才の御多分にもれず協調性に難ありで、大手をふられてきたのだろう。
入社後の研修期間中、そいつは1週間で3万行のHaskellのコードを書き、独自の社内wikiシステムを完成させた。
超使いやすい。
研修終わって俺の下でプロジェクトに参加するようになっても、使いづらいったらありゃしない。
まず、俺がやれと言ったことをやらない。
もっとエレガントなやり方があるのに、なんでそんなやり方をするんだと言ってきかない。
それはな、お前の好きなエレガントな解法で解決できるのは、お前の目の前にある問題だけだからだよ。
システム全体、保守、運用、人材確保、全領域から見た折衷案しか、エンジニアリングでは解法として採用されないんだ。
お前の馬鹿にするPerlだって、30年にも渡る資産の蓄積には、いくらお前一人が頑張ったって、勝てやしないんだよ。
でもこいつ、本物の天才だし、うちみたいなところで腐らせておくには惜しいんだよな。
少し使った感じ、Qiitaのコンセプトは
程度に思えたので、Twitterでつぶやく程度の記事を書くようにしている。
Twitterと違って流れないので、自分用技術メモとしては十分有用だと感じている。
他人のQiitaの記事で、僕がgistに置いたパッチを当てているくせに
Qiitaの利用者にはQiitaに書いた記事の品質を高めるインセンティブが無いのだ。
ゼロでは無いかもしれないが、個人のブログサイトに比べると格段に低い。
そんなサイトに集客力があるような渾身の記事を書く気にはならない。
いい記事を書けば自分のブログで100ブクマ稼げるレベルの人は
自分のブログに書いた方がいいと思うし、実際自分はそうしている。
何度も人に教える作業はドキュメント化すべきだ、と思って今までいろいろな文書を作ってきた。
詳細な解説から、簡単なTipsまで。図や具体例も入れてわかりやすく、平易な言葉で書くことを心がけたり、自分なりに気を使った。
作成した文書は社内wikiやまとめページにカテゴリ分けと一行の概要を付して簡単に見つけられるようにした。
タイトルもできるだけ内容がわかるように、かつ長くなり過ぎないように。
無論それでなにか報酬がもらえるわけではない。
教える立場の自分が少しでも楽するためと、後々残る人たちのためにもなればと思って作った。（頼まれて作ることもあるけど）
でもな、作ってもだーれもまともに読まん。
ここにやりかたは書いてあるからまずはそれにそってやってみてね、と言っても結局ほとんどすべて直接教えることになる。
質問は大体その文書に大きく書いてあること。
しかも一回教えてもまず覚えてくれないから、何度も聞いてくる。
これに同じこと書いてあるから今後はこれ見てと言っても無駄。絶対聞いてくる。教えないとその作業をほおりだすかものすごいまわりみちの自己流手順でやりだす。
読んでわからなかったならこちらの作り方がまずかったのかなと思うけど、目を通してすらくれない。
知ってると楽できるtips集、書いても誰も自分では見つけてくれない。
こっちから能動的に「こんなのがあるよ、使うと楽できるよ」と言って初めて「すごい！こんなのあるなんて！もっと早く知りたかった〜」みたいなー。
全部徒労だったなー。
一般的な技術だったら個人ブログにtipsや手順書くんだけど、こっちは人の役に立ってるみたいですごく充実感あるわ。
検索からの流入もブクマもあって、Twitterでも言及されてたりしてさ。アフィつけてないからどっちにしろ無報酬なんだけどそれだけで書いてよかったなって思うよ。
