「社内wiki」を含む日記 RSS

はてなキーワード: 社内wikiとは

2019-01-06

技術者(もしくは技術者出身マネージャー)の殺し方

わずもなタイトル釣りです。たぶん、過去に色んな技術者メディア等で議論されてきたのではないかと思う。自身が今の職場で久しぶりに清々しいくらいに経験しているので、備忘録として状況をできるだけ冷静に書き記すものである。参考になりえるとしたら”現職の状況がヤバイんだけど、どうやって現状打破を目論見ながら最悪のシナリオを想定した逃げ道も確保するか”といったところの考え方くらいかもしれない。それ以上もそれ以下も意味はない。

背景

業界についてはあえてぼやかすが、歴史が長い業界だ。自身が参画したのははじめての業界だ。いろいろと勝手がわからないことはある。業界歴史が長いからということではないと思うが、業務フロープロセスが古臭い。逆に私達技術者活躍の伸び代がまだまだある業界でもあると言える。自社事業サービス)を持つベンチャーだ。

技術的なことを包括的担当してほしいということだった。結果的に(他にマネージャがいるのに)ただの人月計算をするおじさんになっている。ベンチャーでそういった担当者がいないのでよくあることだ。

状況

いくつか状況を記載しておく。

状況1 : 期待値コンテキスト不足、ナレッジマネージメントされていない

やり方はどうでもいいか

当初このように聞いていた。目的が達成されれば、もしくは課題解決すれば、ということだと思っていた。しかし、そうではない。

この方法以外認めない

という含みがあり、フォーマティが実はちゃんとあるしかし、そういった期待値コンテキストが不足しているという状態。そしてすべての事柄について隠しフォーマットがあり、それに準拠しなければならない。なぜならこういった背景だから。というものがしっかりある個人的ベンチャースタートアップでは抜けがちな”背景”がしっかりあるのは良いことがと思うが、後発で加入してきた人に対して明文化されていない状態もあり、自身役割としてはそういった期待値の明文化をすることも含まれるのではないかと思った。(しかし、そこにそんなにコストかけんなバカってことにもなった)

Webスタートアップベンチャー界隈ではこういった課題に関しては社内Wiki的なSaaSサービスで全員で知見を同期的に書き出して意見交換をすることでナレッジ化していくといった手法を取っているところが多い気がする。そしてその行為を”文化形成”などと表現しているところもある。しかし、業界的にはそういった文化にはないためすべてはファイルベースでの情報共有となっている。もちろん、そういった手法で十分なケースもあるのだが、一方的に送りつけておいて”これ読んでおいてください”などとして一切の背景を説明されていないのが現状な訳で、背景が不確実なまま自身想像力経験で行動してしまうと業界常識等の地雷を踏んでしまうことが多々あるのでできるだけ不確実な要素をなくしていくといったことにコストをかけることになる。

前に言ったじゃないですか

となる地雷が沢山あるやつ。スタートアップベンチャー限定したあるあるみたいだと思われるのも問題なので、一応書いておくと大手でもある。しかし、大手は割としっかり明文化している。その代りそのフォーマットを厳守することを要求されるし、従業員はその制限の中でいかに最高のパフォーマンスを出せるか?というレースになっているという印象。

これは確実に消耗戦になるやつだ。殺しにかかっている。

状況2 : 課題管理

別にWebスタートアップベンチャー界隈のやり方にこだわるつもりはないが、課題管理表を管理する工数を取る文化は色んな業界にまだ根強くあると思う。具体的な管理手法としては昨今では一般的なIssueベースなのに結局Excelでやることになる。ただのExcelではなくてWBSという形式で欲しがっているケースが多いのではないかと思う。WBSを引くということはアジャイル的な変動的なスケジュールを持つといった管理方法ではなく、割とFixされたウォーターフォール型に近い考え方がある場合にこういったことが起こりやすいのかもしれない。とは言え、何らかのプロジェクトマネージメントツールを使いたい。そしてこれも確実に消耗戦になるやつだ。殺しにかかっている。

状況3 : SPOF

とにかく割り込みタスクが全員から投げられる。(WBSで欲しがるのに)具体的な優先度や期日もない。下手すれば”何をしてほしい”といったコンテキストもない。すべては投げられた人のMy Wayで処理されることになり、ナレッジマネージメントおざなりになっているような状況ではスーパー属人化する。こういった状況は”投げられる人が投げる相手がいないからPlaying Manager化していること”が原因でも起こる。人事計画次第では解決できる可能性のある問題ではある。しかし、そういった見通しがない場合しんどい。これも確実に消耗戦になるやつだ。殺しにかかっている。

まとめ : 確実性と不確実性に切り分け

自身としては”確実性”のある部分については"可能な限り確実に"しておきたい。それは具体的にいうと"今見えてる課題で緊急度が高いもの"の対応だ。これは"確実に飛び越えられるハードル"という意味ではなく、"確実に解決しなければならない課題"という意味だ。もちろん、そういった課題がなぜ緊急性が高いのか?というコンテキスト説明についてはコストをかけて説明しなくてはならない。地道ではあるが方法はそれしかない。しかし、そういったことを経験しておくと”自分言葉でわかりやす説明する”といったスキルがつく。そういったスキルが欲しい方にはおすすめする。また、確実に処理したことでかつて不確実だったものの具体性があがることもある。もっと理想を言えば不確実なものの具体性を上げるためにどう確実化していくか?というスケジュールの引き方をしても良いと思う。

問題メンバーそれぞれのスペシャリティ、経歴、興味、個性がまだわからないことを前提にした説明必要で”相手が何からからないのか?”がわからない状態だ、色んな補足情報ゼロから入れながら説明すると物凄いコストになる。かといってあまり上から目線でモノを言ってしまうと後のチームビルディングにおける心理的安全性にも影響するため、嫌がらずできるだけニコニコしながら説明するしかない。これは一種の”信頼貯金”に将来つながってくるものだと思う。

しかし、何事も限度はある。それを自身で見極めないと確実に消耗戦は始まる。殺しにかかってくるのだ。

今後

さて、正直困っている。というか疲れている。

ライフスタイルへの影響度

忙殺されてしまったりするとどうしても以前のライフスタイルや状況と比較することすらできずにいることがある。気をつけたい。ある人は独身かもしれないし、ある人は配偶者子どもいて育児家事などのタスクを抱えているかもしれない。自身は家庭の事情もあり家庭運用タスクももっているライフスタイルなので、ワークがライフ侵入してくると大きな問題として認識する。実際に今、そういった状況が起こっている。(もちろん、それなりの待遇場合家庭内で調整して検討しても良いとは思うがあくま運用可能状態であることは前提である

そういった判断ができにくい状況にあるということを一度立ち止まって認識するということが大事だ。さもなくば遠慮なく消耗戦に持ち込まれ、殺しにかかってくるのだ。

定時内のパフォーマンスで測る

実際、定時外(邪魔の入らない時間)でのパフォーマンスに大きく依存する状況が続いている。死にたい体調不良等でリモート勤務にしたときの捗り具合がヤバイ(笑)しかし、本来、定時内のパフォーマンス自身の力量や限界を測るべきだ。そして無理なことは無理という勇気を持つことも大切だ(自戒)。

https://youtu.be/0sEM3UKuRw4?t=28

あれもこれも含めてオンボーディングコストと見れる可能

完全に気力・体力との勝負ではあるという前提ではあるが、少し粘ることで状況が外的要因等により改善したりすることもある。内的要因であることが理想的ではあるのだが…そこは自身の気力・体力と相談して”いつまでこの船に乗るか?”を決めていくべきだろう。自身でその状況を変えたい!と思うモチベーティブな人間はその限りではないが、その状態でいられる状況とそうではない状況もあるということは言っておきたい。

代表と合わない

多くのベンチャー場合代表哲学経営方針事業方針に深く影響しているというか、そのまんまそれが方針になっている。そして多くの求職者はその”綺麗な上澄みだけを抽出した部分"だけを読んで共感して入社することになる。しかし、入社してみると違うと感じることもある。感じるだけじゃなくて、実際に言っていることから違うこともあるだろう。しかし、それが会社だ。と最近思える程度に大人になった。

それって理念に反してませんか?

みたいなことを言えるなら良いと思うが、言えないならそれはすでに消耗戦の始まりであり、いつでも殺しにかかってこれるヤツだ。

自分が楽しめているか

正常な判断が困難な場合、こういった指標評価することにはなる。自身仕事が好きな方ではあるので割と参考にする。そして、楽しめていない。もちろん、苦しいときもあることは承知の上だが、この状況を具体的に変えていくモチベーションも沸かないのでそれに輪をかけている。これは確実に殺しにかかっている。

まとめ

現実問題として不確実的で抽象度の高いタスクを集中砲火されてしまい、自分優先順位を決めにくい状態が起こっている。自分の手に余る程度であれば良いが(多少の無理なら許容する)、確実にこのままでは消耗してしまうことは目に見えているので、年末年始や週末を利用して(週末は邪魔割り込みが入らないか作業やすいという悪循環にもなっている)自分なりの"働きやすさ"を作ろうと必死だ。しかし、それが自身限界を超える前に構築できなかった場合、最悪倒れる。その前に転職も見据えた行動を取るべきだろう。ということで行動するしかないので行動している。

おかげさまで既に数社からリファラルで引き合いがある。しかし、こういった状態であることもご存知なため(笑)、あまり良い状況(良い印象を与えることができる状況)とは言えない。迎え入れる側も気力・体力が満たされた状態の人に来てほしいに決まっている。しかし、命辛辛逃げようとしている脱北者みたいな人たちにはそういった余裕がない。それとそういった状況において転職先を正常に判断できない可能性もある。また同じ状況になりやすい。気をつけたい。というか面談ときに”他に聞きたいことはありますか?”というところで聞く質問はそこだと思う。

全てはここに帰するのではないかと思う。

期待値を明文化しろ

さて、生き残れっかな(CV : 野沢雅子

2018-12-22

今日から産休に入った、寂しくなった。

新卒入社して3年目。

今年の夏頃に妊娠がわかって、その時は嬉しい反面今後に対する不安の方が大きかった。ただパートナーが大いに喜んでくれたのが良かった(一方で目一杯喜べない自分が少し嫌になったのもあった。)

ただ、原因不明体調不良が何に起因しているかがわかってホッとしたのもあった。

不安いっぱいで両親には半分泣きながら電話で伝えた。こっちがこんなな調子なので親もちょっと困惑してた、でもめでたいことだから、と。

後々LINEで改めておめでとうと届いた。

父親はせめて丸々3〜4年は…と言ってた、ちょっと早いよ、と。

私もそう思う。

新卒で入って右も左もわからない1年目、

環境に慣れてきたものの全体はまだ見通せてない2年目、3年目になってこれから、というところで。

妊娠がわかった後上司には数日してすぐ報告した。

自分風邪の諸症状だと思っていた、びみょーに高い微熱身体ダルさはつわりだったのだ。

最初の3ヶ月ぐらいは貧血になりがちで通勤中にフラフラする事も多かった。

体も疲れやすく、仕事が終わった後はそのままソファに転がっていつのまにか寝てる…みたいな生活が続いた。

パートナーはそんな私をダラけていると感じている節があった。お皿を洗う気力も無いぐらいめちゃめちゃに眠たくて、寝転がる前に洗えばいいじゃんと言われるけど食後に10分も立ってられなくなってた。

これぐらいの時からブラの締め付けがキツく感じ、窮屈な服を着ると気分が悪くなった。

常に微熱状態みたいな頭のモヤモヤ感に、このまま働いていけるのか不安になった事もある。

吐き気もあったけど日中我慢できる程度にマシだった。でも唾液が止まらなくて気持ち悪くてずっとガムやらハイチュウやらを食べて気を紛らわしていた。

晩御飯梅干し茶漬けばっかり食べてた時期があった。お茶漬けを食べられればいい方で、だめな時は桃やプラム、梨を食べていた。

丼や麻婆豆腐に入ってる刻んだ長ネギが食べられなくなった。

カルボナーラが好きで作ったのに、一口食べたらもう食べられない…ということもあった。飲み込めないし、なんか胃が拒否するのだ。

食べたあとどうしてもダメで全部リバースしてしまう事もあった。鍋物うどんダメなのか。

寿司生物から食べない方がいいけど私はサーモンのお寿司が食べたくてたまらなかった。お寿司が食べたくてイライラした。

このあと1年はお寿司が食べられない。キレそうであった。

私の想像していたつわり、というかテレビアニメ漫画で知っていたつわり(妊娠)の知識って、

登場人物トイレで吐いてもしかして妊娠…となる(吐くのは1回だけ)

・酸っぱいもの無性に食べたくなる(食の好みが変わるだけで、食べられなくて辛いとかは無い)

お腹が大きくなる(お腹の小さいうちは辛く無い)

だったので、

大きなギャップがあった。

親しいだれかに妊婦が居たらもっと違ったんだろうけど。

から出産が大変だったという話は何度か聞いたが、妊娠中が大変だった話は聞かなかった。

そもそもつわりの程度にも個人差があるらしく、

ほとんど同じ時期に妊娠した同級生殆ど全くつわりが無いと言っていた。

会社はぽつぽつ休みがちになった。

気を遣って貰ったのか、仕事スポットで入るような細かいものほとんどで、量も少なかった。

なんなら仕事のない日も多かったので、これはこれで何か社内ニートみたいでちょっと嫌だった、ような気がする。

とにかく自分の体調がコントロールできず、ふだんの6割程度のパフォーマンスしか出ないことに苛立っていた。

秋ぐらいになって、一個案件を任せて貰えることになった。

つわりの諸症状は夏と比べると大分良くなってた。吐き気も無い。

でも、やっぱり日によって体調とメンタルが崩れてしまうことがあってぽつぽつと休む暇あった。

終わってから何週間か経ってだろうか、

朝、焼けるような腰?背中?の強い痛みで目が覚めて痛みで動けなかった。

その日はそのまま休んだ。おやすみの連絡を入れてからしばらく経って痛みは治まった。

そこからずるずる1週間休んだ。

夜中や早朝に身体がひどく痛む、のももちろんあったけど、出社してもどうせやる事無いしなあ、とか、苦手な人に会うの嫌だなあ、とか考えるうちに行かなくなってた。このまま産休に入ってしまいたいとも思ってた。

なんとか踏ん切りをつけて出社した。

ちょうど評価の時期で、この半年評価が返ってきた。

冬になって大きめの案件アサインされた。

多分これが休み前の最後仕事になるだろう。

最後だし、あと振り返りでもっとこう出来るといいね!と伝えられていたのもあったので、とにかく頑張ろうと思った。

昨日、自分担当分をすべて終わらせて、

引き継ぐものは引き継いだ。

最終出社日、お世話になった人にお菓子を配って、デスクを整理して、社内wikiを書いたりしながらのんびり過ごした。

戻ってくる、産休と育休が終わったら職場に戻ってくるけど、

ああこれで最後なんだなと思った。

何か気を緩めると涙が出てきそうなので、先日のセールで注文した液タブのことを考えた。コンビニで受け取って帰ろう。

駅前たこ焼きを2船買って電車に乗った。

家に着くとまたなんともさみしい気持ちがこみ上げてきた。

春夏ごろはむしろ会社行きたくない行きたくないと言ってて、妊娠がわかった時解放されたような気持ちが少しあったのを覚えてる。会社辞めないにせよ他の部署に行けないかなぐらいには考えていた。

いまはただただ終わってしまったのが悲しい。

今日からずっと仕事もなくどう過ごせばいいんだろう。

積んでいた本を毎日読もう、とか、

勉強しよう、とか、練習しよう、とか

色々考えてはいたけど。

平日毎日同じ時間に起きて、同じ場所に行って、同じ空間で働いていたそのリズムが急に無くなる心許なさったら無い。

きっとまた別の楽しみがあるんだろうけど、今はただただ寂しい。

2018-06-26

手順書で腐っていく社内wiki

スクリーンショット!矢印!丸で囲った!わかりやすい!最高の手順書!

実際にやってみると古いUIで使い物にならない

手順書手順書

ララバイ手順書

2018-06-06

使われてるクラス仕様書ぐらいまとめやがれ

社内wiki存在せず上司聴くしか疑問点解決できないってなんやねんほんま。

コード見て動き理解しろって言われても限界あるよ…

2017-05-16

http://anond.hatelabo.jp/20170515130428

マークダウン記法で書いてるよ。そうすることでいつかredminegithubを使いますってなった時にコピペで即社内wikiが作れるから

2017-05-12

製造業新卒で入って数年経過したけどもうダメかもしれない

新卒製造業に入った。

大学では工学部ではない理系だったので右も左も分からないなりにがんばってみようと思っていた。

悪く言えば自分能力絶望して夢を諦めることになり都落ちした気分での就職だったのでやぶれかぶれだったというほうが近いかもしれない。

相性というか、背景の差とか常識の差みたいなものがあって、自分から見ると無駄の多い職場だなあと感じて研修期間が終わり本配属された。

無駄が多いという感想は本配属後も変わらなかった。

本来業務はいわゆる故障解析で、歩留まりを上げていくのが使命だった。

せっかくだから色んな所に首を突っ込み改善できそうなところは提案をしたり、自動化したり、それらのドキュメンテーションを書いてみたりした。

プログラミング経験は皆無だったが、理論系卒が工学部に負けられんという謎のプライド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に上げた報告をまとめたり、製造データと紐づけたり、それからグラフ描いたりみたいな業務が増えていたからだ。

それっぽく表現すればデータ分析屋さんということになるのだろうが、どぶをさらっているという表現のほうが近かったかもしれない。

何にせよそういったもの一気通貫自動化できるポテンシャルがあると感じられた。

SQLjavaも書いたことなんて無かったが、1年前やっていたことを考えれば同じことだ。何にせよ歓迎だった。しか管理IT持ちだ。餅は餅屋に頼むべきだ。それもできれば美味い餅屋に。

ところがその「ビッグデータプロジェクト人手不足か、資金不足か、あるいは生みの苦しみか、ことのほか時間がかかっていた。(あとで聞いた話、外部コンサルで外れを引いたらしい)

自分ドメイン知識からの助言とか想定される使い方についての意見を伝えていったし(有難迷惑だった可能性は否定できないが)、もう少し待てばモノになると信じていたし、実際そうなった。

具体的な話ができないのだが、客先で起こった不良の原因をつきとめ、その改善効果確認の為に数十億行のデータ活用された。彼らの力が無ければ常識的時間では終わらなかった仕事だった。

残念だったのは彼らの優秀さの割に一般エンジニアスキルがあまりに低かったということだ。つまりそのプラットフォームを使いこなせる人間が著しく少なかったのだ。

そして上述の足踏みをしていた期間に心象を悪くしていたという問題もあった。とっかかりが難しい割に不安定だというレッテルを張られてしまっていた。

このころ私は入社3年目に突入していたが、

もうすこし悪いことに、同時期に企業買収が起こった。我々は黒字を出していたが同業他社(厳密にはその親会社に)に買われることになった。

そういう時に起ることは不要冗長性の削減だ。子会社として存続する場合は知らないが、競合他社に吸収合併ということは、多くの部署にとってそのカウンターとなる部署相手側にも存在するということだ。

まりどちらにもある部署統合するか一方を無くすかという戦争が始まるのだ。IT例外ではない。(ITインフラ部署の無い会社はさすがに無いはずだ)

一方で製造業の本懐である製品を作り、売る」という部分は比較的守られる。それこそが根源的な資源であり、利益を生む仕組みであり、既存顧客への説明必要からだ。

そして私の仕事は歩留まり改善であり、故障解析であり、データ分析だ。何が起こったか

(ここで簡単のために旧弊社を(旧)A社、買収した側の競合他社を(旧)B社と呼ぶことにする。)

今の旧A社から引き続いている業務をB社のプラットフォームで行えるように転換せよという下命である

旧B社の製造データに対するアプローチはA社とまったく異なっていた。Web UIは美しく整っており、それっぽいグラフ簡単に表示され、A社側のお偉いさんからも好評を得ていた。

だがそのバックエンドは控えめに言って酷いモノだった。いくつもの情報を正常に保存できておらず、「それっぽい何か」を素早く返答することを第一義としているように見えた。

そして上述のように器用貧乏街道を歩んできた私に投げられたのは次の言葉

増田くん、B社のプラットフォーム使うことは決定事項だから、君が自動化してたやつ全部そっちで動くようにしといて。よくわかんないけどプログラムとかてきとうにできるでしょ?」

もちろんhtmljavascriptphpRoRも一行も書いたことが無いのが当時の私である

果たして旧A社のプラットフォームはB社のプラットフォームデータソースのような扱いを受ける羽目になり、私はjavascript本格入門を片手にB社の事業所に出向くことになった。

そこで散々「旧A社のプラットフォームは遅い・使いづらい・不安定」と貶されながらチマチマとグラフを表示するページを書いている。

クオリティの低いバックエンドを作る集団が書いているサーバーサイドphpの酷さは素人目にも分かるレベル筆舌に尽くしがたいものがあるが、

反面教師だと思って耐える日々だ。

最近分かったことは旧B社のバックエンドスクリプトデータを引っ張るついでに意図的に旧A社のプラットフォーム攻撃しているということだ。DDoSとまでは言わないが、悪意100%である

いわく旧A社のプラットフォームを畳むためには旧B社のプラットフォームが優秀であることを示す必要があるとのことである。(つまり旧A社プラットフォーム不安定かつ重くなることを意図しているらしい)

旧A社から継続されてる業務はまだそこ使ってるんですけど・・・

それはもちろん旧A社の上司に報告したが「見て見ぬふりをしろ」とのことだった。旧A社のITで何度もお世話になったひとに伝えると「知ってるけどね・・・」と悲しい目をして苦笑いしていた。

旧A社ITはその優秀さでそれらの攻撃をいなしつつあるようにも見える(私も素人に毛が生えたレベルだが、ソフトウェアエンジニアリングレベルが二回りぐらい違うように見える)

この不毛な戦いはいつ終わるのだろう・・・つらい・・・

そして私はいつまでソフトウェアエンジニアの真似事を続けてキャリアを消費していけばいいのか、もうダメかもしれない。

そもそも私はエンジニアなのだろうか・・・少なくとも職位にはそう書いてあるけど・・・

2015-02-19

仕事のできない天才プログラマの後輩

酔っているからとりとめのない内容になるかも。

本人に言えとか、増田に書いてどうなるとか言われるんだろうが、本当にただの愚痴から、この記事でどうこうしようってわけじゃない。

ただ吐き出させてくれ。

うちみたいな弱小ベンダー新卒で入ってきた後輩がガチ天才プログラマだった。

だが、その手の天才の御多分にもれず協調性に難ありで、大手をふられてきたのだろう。

入社後の研修期間中、そいつは1週間で3万行のHaskellコードを書き、独自社内wikiシステムを完成させた。

超使いやすい。

ただし、その1週間、そいつは1日も会社に来なかった。

研修終わって俺の下でプロジェクトに参加するようになっても、使いづらいったらありゃしない。

まず、俺がやれと言ったことをやらない。

もっとエレガントなやり方があるのに、なんでそんなやり方をするんだと言ってきかない。

それはな、お前の好きなエレガントな解法で解決できるのは、お前の目の前にある問題だけだからだよ。

システム全体、保守運用人材確保、全領域から見た折衷案しかエンジニアリングでは解法として採用されないんだ。

お前の馬鹿にするPerlだって、30年にも渡る資産の蓄積には、いくらお前一人が頑張ったって、勝てやしないんだよ。

でもこいつ、本物の天才だし、うちみたいなところで腐らせておくには惜しいんだよな。

Matzみたいに、全く新しいことを初めて、勝負しろとは言ってるんだが。

2014-12-06

Qiita価値がわからない

僕には重量級の記事Qiitaに書く人が理解できない。

少し使った感じ、Qiitaのコンセプトは

社内Wikiに書くくらいのライト記事を共有しあおう」

ゴミ記事が多い問題は人力でのタギングランキングで解決」

程度に思えたので、Twitterつぶやく程度の記事を書くようにしている。

Twitterと違って流れないので、自分技術メモとしては十分有用だと感じている。

しかサイト全体としてゴミ記事が多い問題は残る。

他人Qiita記事で、僕がgistに置いたパッチを当てているくせに

僕のブログ記事にはリンクしていないものがあった。

しかも、そのパッチは最新版では不要になっており、

僕の元記事アップデートしているのだが、

Qiita投稿はいつまでもそのままだ。

最初に気づいたときはクソ野郎が居るもんだなと思ったが、

今はQiitaがそういうサイトなのだと考えを改めた。

Qiita利用者にはQiitaに書いた記事品質を高めるインセンティブが無いのだ。

ゼロでは無いかもしれないが、個人のブログサイトに比べると格段に低い。

そんなわけでQiita全体の記事品質は低い。

そんなサイト集客力があるような渾身の記事を書く気にはならない。

いい記事を書けば自分ブログで100ブクマ稼げるレベルの人は

自分ブログに書いた方がいいと思うし、実際自分はそうしている。

でも、たまにQiitaにすごいブクマ集めてるナイス記事が上がってたりするんだよね。

なぜなのか。自分が知らないインセンティブがあるんだろうか。

2014-10-23

社内ドキュメント制作不毛

何度も人に教える作業はドキュメント化すべきだ、と思って今までいろいろな文書を作ってきた。

詳細な解説から、簡単なTipsまで。図や具体例も入れてわかりやすく、平易な言葉で書くことを心がけたり、自分なりに気を使った。

作成した文書は社内wikiまとめページカテゴリ分けと一行の概要を付して簡単に見つけられるようにした。

タイトルもできるだけ内容がわかるように、かつ長くなり過ぎないように。

無論それでなにか報酬がもらえるわけではない。

教える立場自分が少しでも楽するためと、後々残る人たちのためにもなればと思って作った。(頼まれて作ることもあるけど)

でもな、作ってもだーれもまともに読まん。

ここにやりかたは書いてあるからまずはそれにそってやってみてね、と言っても結局ほとんどすべて直接教えることになる。

質問は大体その文書に大きく書いてあること。

しかも一回教えてもまず覚えてくれないから、何度も聞いてくる。

これに同じこと書いてあるから今後はこれ見てと言っても無駄。絶対聞いてくる。教えないとその作業をほおりだすかものすごいまわりみちの自己流手順でやりだす。

読んでわからなかったならこちらの作り方がまずかったのかなと思うけど、目を通してすらくれない。

知ってると楽できるtips集、書いても誰も自分では見つけてくれない。

こっちから能動的に「こんなのがあるよ、使うと楽できるよ」と言って初めて「すごい!こんなのあるなんて!もっと早く知りたかった〜」みたいなー。

全部徒労だったなー。

一般的技術だったら個人ブログtipsや手順書くんだけど、こっちは人の役に立ってるみたいですごく充実感あるわ。

検索からの流入もブクマもあって、Twitterでも言及されてたりしてさ。アフィつけてないからどっちにしろ報酬なんだけどそれだけで書いてよかったなって思うよ。

自分でどうにかしたいって気持ちがあるかないかって、ぜんぜん違うよね。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん