「ドキュメンテーション」を含む日記

■

HTMLはプログラムを作るための言語ではないのだからプログラミング言語ではない。

プログラミング言語なたいな名称が欲しいならドキュメンテーション言語とでも言うべき。

Permalink | 記事への反応(1) | 18:05

ツイートシェア

■anond:20230911065242

Excel 2016でマクロを作成するための効率的な手順は次のようになります。

1. マクロの目的を明確にする: まず、どのような作業を自動化したいか、具体的な目的を明確にしましょう。

2. Excelのマクロ機能を学習: Excelの「開発」タブにアクセスし、マクロを記録、編集、実行するためのツールを見つけましょう。基本的なマクロの操作に慣れることが重要です。

3. マクロの記録: 自動化したいタスクを実際に手動で実行し、その間にマクロを記録します。こうすることで、マクロはあなたのアクションを記録し、後で再現できます。

4. マクロの編集: 録画したマクロは最適化が必要な場合があります。不要なステップを削除し、必要なステップを追加または調整します。

5. マクロのテスト: マクロが期待通りに動作することを確認するために、テストを行います。特にループや条件分岐が含まれる場合、注意が必要です。

6. ショートカットの割り当て: マクロにキーボードショートカットを割り当てることで、手動でマクロを起動する手間を省けます。

7. セキュリティと共有: 職場のセキュリティポリシーに従い、マクロをセキュアに管理し、必要なユーザーと共有します。

8. ドキュメンテーション: マクロの動作や使い方を文書化し、他のチームメンバーが理解しやすくするための説明を提供します。

これらの手順を順守して、効率的にExcel 2016でマクロを作成できるはずです。

Permalink | 記事への反応(0) | 09:08

ツイートシェア

■

はてなの退職エントリを書いています。

私は約3年間、はてなでエンジニアとして働いていました。

この期間に、様々なプロジェクトに関わり、多くのことを学びました。

今回は、私が経験した技術的な話を中心に、はてなでの仕事について振り返りたいと思います。

## RailsでのWebアプリケーション開発

はてなでは、主にRuby on Railsを使ってWebアプリケーションを開発していました。

はてなブログやはてなブックマークなどの有名なサービスはもちろん、社内向けのツールや新規事業のプロトタイプもRailsで作っていました。

Railsは、高速に開発できるというメリットがありますが、それと同時にコードの品質やパフォーマンスにも気を配る必要があります。

私は、テストやリファクタリング、コードレビューなどの技術的なプラクティスを積極的に取り入れることで、Railsの開発をより効率的で安全に行う方法を学びました。

例えば、私が担当したプロジェクトでは、RSpecやRuboCopといったツールを使ってテストカバレッジやコード規約をチェックし、GitHub ActionsやCircleCIといったサービスを使って自動化しました。

また、Pull RequestやPair Programmingといった方法を使ってコードのレビューを行い、バグや改善点を見つけたり、知識やノウハウを共有したりしました。

## クラウドサービスでのインフラ構築

また、はてなでは、AWSやGCPなどのクラウドサービスを活用してインフラを構築していました。

私は、DockerやKubernetes、Terraformなどのツールを使って、コンテナ化やオーケストレーション、インフラストラクチャ・アズ・コードなどの技術を実践しました。

これらの技術は、開発環境と本番環境の差異を減らし、デプロイやスケーリングを容易にするという利点がありますが、それと同時に複雑さやトラブルシューティングの難しさも増します。

私は、モニタリングやロギング、アラートなどの技術的な仕組みを整備することで、インフラの運用をより安定的で信頼性の高いものにする方法を学びました。

例えば、私が関わったプロジェクトでは、DatadogやCloudWatchといったサービスを使ってシステムの状態やパフォーマンスを監視し、SlackやPagerDutyといったサービスを使って異常や警告を通知しました。

また、ElasticsearchやFluentdといったツールを使ってログの収集や分析を行い、原因究明や改善策の検討に役立てました。

## チームでの協働

はてなでエンジニアとして働くことで、私は多くの技術的なスキルや知識を身につけることができました。

しかし、それ以上に大切だったのは、チームで協力して問題を解決することでした。

はてなでは、エンジニアだけでなくデザイナーやプロダクトマネージャーなどの他職種とも連携してプロジェクトを進めることが多かったです。

私は、コミュニケーションやフィードバック、ドキュメンテーションなどの技術的ではないスキルも重要だと感じました。

私は、自分の意見や提案を積極的に発信することで、プロダクトやサービスの品質や価値を高める方法を学びました。

例えば、私が参加したプロジェクトでは、SlackやZoomといったツールを使って日常的に情報交換や相談を行い、BacklogやJiraといったツールを使ってタスク管理や進捗報告を行いました。

また、FigmaやMiroといったツールを使ってデザインやアイデアの共有やフィードバックを行いました。

## 退職への決断

私は、はてなでエンジニアとして働くことがとても楽しく充実していました。

しかし、私は自分のキャリアについて考える中で、新しい挑戦をしたいという気持ちが強くなりました。

私は、自分の興味や関心のある分野にもっと深く没頭したいと思いました。

そこで、私はこの度、はてなを退職することにしました。

私は今後、別の会社でエンジニアとして働く予定です。

## おわりに

はてなで働いた3年間は私にとってかけがえのない財産です。

私は、はてなで出会ったすべての人に感謝しています。

に私が所属したチームのメンバーには大変お世話になりました。

彼らから学んだことや刺激されたことは数え切れません。

彼らと一緒に仕事ができたことを誇りに思います。

彼らに感謝する気持ちを込めて、このエントリーを書き終えたいと思います。

以上、AIによるフェイク記事です。

どの程度、真実味がありましたか？

Permalink | 記事への反応(3) | 17:29

ツイートシェア

■今すぐExcelの体裁を整えるのをやめろ

必ずしも設計書や仕様書をを作るなとまでは言わない。

銀行系や保健系のお客様だとExcelでくれよと言われる場合もあるし、マークダウンその他便利なツールを浸透させるには教育コストが重たいこともあるだろう。

マークダウン記法もわかんねえアホがいるのが現実なのでこればっかりは仕方ねえ。それはもういい。よくねえけど、本当に良くねえけど、妥協する。

だがマジでどうでもいい体裁を整えるためだけに工数をかけるのを今すぐやめろ。というかIT業界をやめろ。

業界それなりに長くて燃えてる現場もそこそこ見たけど燃えてる理由の何割かはこれだ。

そのセル結合本当に必要か？

現在の仕様書と過去の仕様書の比較を出すのに関数を使うのはいいが、なぜそれを新旧の仕様書をコピペすれば済むように工夫しないで意味わからん方法でバラバラにしながら切り貼りしている？

見た目のためだけに1項目に2行使うな、マクロとかコピペの時に不便だろ。せめてセル改行にしろ(それも許したくないが)

色分けに1時間かけることが本当に有益か？

この項目はこのフォント、あの項目はこのフォントと丁寧に分けることが大切か？　あまつさえ文字サイズに拘るとか正気か？

過度にオートシェイプに頼るなバカが、コピペや検索しにくくて不便だろうが。

Excelが自動で変えてしまうフォントまでわざわざ訂正しなおせって正気か？　そりゃ周りからコピーして特殊貼り付けで解決するがn回やってりゃバカにならねえ手間だぞ。

体裁に拘るあまりドキュメンテーションの工数を増やすから結局メンテナンスされねーんだろうが。

小学校の先生やママは丁寧な書類を褒めてくれるかもしれねーけど綺麗で丁寧にするために10000倍時間かけてたら意味ねえんだわ。

あまつさえその狂気を他者に強要するのはやめろ。チーム全体の生産性が終わってる。

それでいて体裁を綺麗に綺麗に綺麗に綺麗に、神経質な狂気を持って本質的に必要な情報を手早くまとめることを忘れたアホが評価されがちなんだよな。マジで早く辞めさせろ。

ExcelなんてExcel側の気分でフォント変えたり大きさ変えたり文言変えたりする超絶不便で不完全なツールなんだよ。設計書にするにはな。

それを自覚してたらまずは作業を楽にしようって方に頭を働かせねえのか？　なんで見た目ばっか拘るかね、内容がわかんないからか？

マジでいい加減にして欲しい。途中から入った現場だから今更変えるのも難しいのが本当に腹立つ。

Permalink | 記事への反応(0) | 19:31

ツイートシェア

■要人警護についての提言コラム

これから徐々に改善されていくと思うけど、自分用の感想メモ。

内容はおもに、（１）武器装備の再検討（２）警護計画書の再検討って感じです。

まず素人目にも「おかしい・違和感」と感じた点を述べたい。

銃社会じゃないのにアメリカ風のSP

今回浮き彫りになったのは、「銃を想定した訓練をしていない」ということだった。

銃を想定してないのに、スーツケースをもったSP？おかしいだろ・・・

この動画のように、ペラっちいスーツケースは意味あるのか？とも思う。

https://www.youtube.com/watch?v=hYFglqYa0rM

実際今回の事件では、慣れておらずケースを開いて防御できなかったと聞く。

実践で使えないのであれば、まったく意味がない。

このような形だけの訓練ではなく、「本当に相手を封じ込められるか」を重視した訓練をすべきである。

日本のセキュリティに適した装備にすべきだと思う。

ただしこの動画で唯一良いと思ったのは、「一糸乱れぬ集団の動き」が実践されていた点である。

これはグループとして・兵隊として動いたときの強さを証明している。自衛隊の強さに通じると思う。

アメリカのSPのような「個別判断」は弱いかもしれないが、グループとして調練されていれば、

非常に強い警護力をもつのではないか、という期待がある。

槍に代わるものは何がよいか

やはり日本における暴徒の武器はナイフ。包丁のたぐいが多いと思う。

これに対抗するには、距離をとるしかない。

そのためにはもちろん槍と盾がベストなのだが、誤使用などの危険性も伴う。

その点、さすまたは安全性のある槍と思ってよい。

さすまたと盾を持った人間が要人の左右に2人いるだけで、相当な抑止効果があると思う。

これは近接戦を目的にしておらず、「相手との距離をとる」ための防御である。

さすまたを振りかざされれば、相手は容易に近づけない。

今回の犯人が岡山での犯行をあきらめたように、「実行させない」ための抑止力が最も重要だと思う。

押し込むことでさすまたの両端から刃が出るようなギミックもいいかもしれない。

これなら誤使用を防げて、強く押し込むような緊急事態には、犯人を畏怖させられる。

こういう技術開発は日本人は得意だと思う。

と検索したらこのようなものがすでにあった。

https://www.youtube.com/watch?v=ibytBZIpN9I

銃を想定した対策ももちろん必要

毎日銃で100人亡くなっているレベルのアメリカでは、さすがに効率が重視されている。

テザーガンの効果が分かる動画がある。

これは銃と違い殺傷力がないようだ。

https://www.youtube.com/watch?v=i-iHksu9ePU

また、ボディカメラは徐々に採用されているようだが、全SPにつけてもらいたい。

このような、新規技術を取り入れ、Webや報道で告知することで、テロリストを抑止できるだろうと思う。

今回の小型銃の開発は、いわば技術をもった犯罪者が、警察のテクノロジーを上回ったともいえる。

ようは技術に投資してますよ、という姿勢で、犯罪者にナメられないということである。

ローテク・ハイテク・両面での投資が必要と思う。

警護計画書って意味あるの？という点

警護計画書というものがあるらしい。

検索したらこのような、古い紙ベースのものだった・・・20年前の技術のままである。

https://www.sp-keigo.com/post/%E8%AD%A6%E8%AD%B7%E8%A8%88%E7%94%BB%E6%9B%B8

今回は、急遽奈良に変更されたということで、夜に計画書を作り、朝に本部長が承認したという。

そのプロセスはどの程度必須なのだろうか？

もし一夜明けて、現場の状況が一変していたらどうだろう。完全にムダな労働である。

日本人の悪いところに、ドキュメンテーションに時間をかけすぎるという点がある。

文書はあくまで机上の論理であって、実践はまた別の次元である。

ましてや一瞬の物理防御が求められる警護の現場ではなおさらである。

文書に書き出した時点で、それを読者が脳内で「翻訳」する必要があり、時間がかかる。

動画や画像による情報シェアなら理解が速いだろう。

以前も書いたが、今回の敗戦は、布陣の時点で問題があったことは間違いない。

https://anond.hatelabo.jp/20220710094249

もし警護計画書を重視して、現場検証がおろそかになったのであれば、悔やみきれない結果だと思う。

警護計画書のモダン化

まずは現場を確認し、タブレットによる動画や写真などを駆使して、

「紙に起こす」という作業のムダを省いてもらいたい。あくまで紙に書くというのは脳内の作業である。

そうした無駄が浄化されているのが建築業で、

ANDPADといったツールによってドキュメントワークが軽量化されて、効率化が図られている。

https://www.youtube.com/watch?v=Rd83X6_1-8U

余談になるが、

IT業界では多重中抜きビジネスが横行している。その中核となるのはドキュメンテーションの水増しである。

つまり、提出書類を無駄に作成して、人件費を多く請求する、というのがメインのビジネスである。

これにより業務の遅滞・腐敗・形骸化を招いている。

これが積み重なると、総合的な日本の国力低下につながると思う。

「決まっていることに対して疑念をもたない」という国民性ともいえ、強味でもあるが、病理でもある。

奈良県警の、無規律でのろい素人の動きは、まさにそのような「ムダ・無意味」なことを重視した結果の、

日本の縮図を世界に晒したようで、残念である。

本来優秀な人材のSPですらそうなのだから、日本全体の問題だと強く思う。

現場では、自己判断でとっさに動けるような、マニュアルを押し付けない教育が求められる。

警備・警護業にもDXを

ITツールによって「計画・作成・共有」が統一され、即時に行えるような改善は、

無駄を省き、スピードを上げ、人材の知性を向上させる。すべての業界に歓迎されるべきだと強く思う。

DXが必要というのは、絵に描いた餅のスローガンではない。

ITがどの業界においても業務の仕組みを一変させ、人材を成長させ、日本を進展させるのである。

サイバーセキュリティは別として、これまで警察・警備の現場というのは比較的ローテクだったと思う。

今後は最新技術を取り入れて、効率的・実践的な運用が求められている。

Permalink | 記事への反応(0) | 13:35

ツイートシェア

■anond:20220401172912

これは自慢でなく自虐なんだが、俺は新人じゃなくなった今でもメモなんてアポイントくらいしか取らない。取らないというか取れないんだな。ほかにも言ってる人がいるが俺がメモ取れないのは学生時代に板書をノートにまとめる訓練を怠ったからだと思うが、そんな俺でもやってけてるのはその程度の仕事しかしてないからだ。右も左もわからない新人は「俺はメモの取り方が下手なのだー！」みたいな悩みを持ったりするがそれは問題分析が間違ってて、右も左もわからないから仕事ができないだけ。一年こなして右も左もわかってきたら仕事なんてもう経験済みの話しか出てこなくなるからメモなんて取らなくたって全部覚えてられる、というかもともと知ってる話しか出てこない。世の中の仕事が全部そんな程度の低い仕事ばかりだとは言わないが、世の中の人間みんながそんな上手にメモ取れるわけがないので、メモ取らなくたってやってける仕事が大部分だよ。

＞みんな楽になるのに。

よく言われる話だけど、ドキュメンテーションって本当、報われないのよね。。。俺もよくないことだとは思うけど、「ロートル組にとっては新人に理不尽な苦労をさせるインセンティブがある」「じっさい新人が資料読んだってわかんないものはわかんない」「新人の側もすぐに新人ではなくなり問題意識を失っていく」「属人化させることで自分の椅子を守れる」「ノウハウを個人スキルと看做して組織に還元したがらない」みたいな構造的普遍的な問題があって、日本企業特有というわけでもない。マックやコンビニのマニュアルがすばらしいのはバイト向けマニュアルの部分だけで、本社じゃやっぱり新人が苦労してると思うよ。

Permalink | 記事への反応(0) | 16:55

ツイートシェア

■高学歴理系女だが結婚願望も上昇志向もない

自分は割と勉強ができたので学業はそれなりにやってきていて、一般に高学歴の理系に分類される女と思う。

元々結婚願望がなかったので、真っ当に生涯仕事を頑張っていこうと

新卒では大学の専門を活かせる研究職についていたし、周りのように研究にモチベーション持てないなと思ってからもコンサルタントをやったりしてみた。

しかしながら、最近（というか大学頃から目をそらし続けていたのだが）私には上昇志向やめちゃくちゃ仕事頑張ってまで成し遂げたいことがなく

いわゆるバリキャリ的な生き方は苦しいなと思い至り

何のために院まで出たんだろうとか、仕事頑張るのしんどいとかで思考がぐるぐるする。

ほどほどの仕事量でプライベートの時間をそれなりに確保して穏やかに過ごししたい。

しかし、研究職やコンサルタント等では即戦力的なスキルとして希望するような仕事（バックオフィス系に就きたい）へPRできることがあまりなくてつんでいる。

（論理的思考力、ドキュメンテーション能力、法人折衝経験などをPRして転職活動をしているが、上昇志向ないときつそうな仕事向けのPRになる・・・）

地頭も学力もそれなりにあるからだれか雇って。

コミュニケーションは好きではないですがコミュ障ではないです。

モチベーションはそんなにないですが責任をもって仕事はさせていただきますし結婚・産休育休など絶対しないです。

あとコンサルが使いがちなカナカナ英語が嫌いなので私は使いません。鼻につく感じはしないと思います。

そんなに良くないけど悪くない人材だと思います。お願いです。

Permalink | 記事への反応(4) | 12:04

ツイートシェア

■

久しぶりに日本語の文章を書いた。

普段プログラムを書いているのでキーボード入力は別に不慣れじゃないはずなのに、プログラムを書くのと文章を書くのでは全然手の動きが違うのか、すぐに手が痛くなってしまった。

コードのドキュメンテーションとか業務上のコミュニケーションはすべて英語でやっているから、自然言語とプログラミング言語との違いとかではなく、日本語特有の問題な気がする。

普段はVimを使っているけど、日本語との相性が悪いので別のエディタを使っているからかもしれない。

日本語入力の場合、IMEの変換候補を確定するためのエンターキーを押す回数が英文/プログラミング言語と比較して多いからかもしれない。

Permalink | 記事への反応(0) | 16:25

ツイートシェア

■チームのアプリ開発めんどくさ〜

スーパーなエンジニアが基本になるコード書いてコードレビュー、そんでそれフォローできそうなエンジニアたちで開発する

それが正直一番手っ取り早い気がするんだけどな〜

まあ仕様書やらドキュメンテーションやらが属人化を避けるためにも大事なのはわかるが…

Permalink | 記事への反応(1) | 15:49

ツイートシェア

■anond:20201016210005

これ、ためしに操作してみたんだけどUIがクソすぎてクソほどわかりにくいクソだし

書いてあるような「投票によって検索順を操作する」みたいな挙動はまったくしてなかった。

https://salona.org から検索して、検索結果表示ページで画面右上の＋をクリックすると「検索ワードにコメントをつける」ことができる。

そのあと投票行為をすることによって、そのコメントに投票することができる。

各コメントの上に表示されてる数字が投票数で、投票数の降順でコメントが表示されるようだけど

検索結果には何も影響してない。

これ投票によって検索順を操作するサービスじゃなくて、検索キーワードにコメント＆いいねできるサービスでしかないぞ？

ちなみに投票の仕方は↓だけどこれ読んで理解出来たらすごい！（ちなみに公式ドキュメンテーションには手順について何も書いてなかった）

:idや:nonceが変数を意味していることはIT系の知識ある人ならわかるだろうけど、素人はまずわからないと思うし

:idが何者でどうやって取得するか等の情報は一切なかった。

文書IDと256ビットのノンスを繋げたもののSHA-256によるハッシュが小さいほど価値があるということにします(Hashcash)。

https://salona.org/vote/:id?nonce=:nonceにアクセスすることで投票できます。

現在のノンスはhttps://salona.org/nonce/:idから取得できます。詳しくはSalonaの公式ドキュメンテーションをご覧ください。

結論：サービスの説明は嘘だし、UIはクソ

Permalink | 記事への反応(0) | 14:37

ツイートシェア

■Googleを超える検索エンジンを作ったので使ってみてほしい

表題の通り、検索エンジン（Webアプリ）を作ったので、使ってみて感想を聞かせてほしい、というのが投稿の目的だ。

ただ、せっかく増田に投稿するのだから、制作物の宣伝に終始するのではなく、開発していて考えたことや制作背景を書き添えたいと思う。ここにはエンジニアやデザイナー、また技術職でなくてもWebサービスに携わる人、インターネットを使って遊ぶことが好きな人が多いはず。そんな人たちの向けの四方山話として、思考の一助となれば幸いだ。

検索エンジンについて

SalonaというGoogleを超える検索エンジンを作った。

https://salona.org

• 特定の検索クエリについて、マークダウンの検索結果を添付し、投稿することができる。
• 投稿には、検索クエリと完全一致するタイトル、本文、'# ' + タイトル + '\n' + 本文のSHA-256（＝文書のID）、256ビットのノンスが付随する。
• 投稿に対して、ユーザーは「コメント」「投票」のリアクションを取ることができる。
• 文書IDにノンスを加えた投票は、Salonaに送られる（文書IDとノンスの連結からSHA-256でハッシュを生成し、既存のハッシュよりも小さければノンスが更新されていく）。
• 任意の文書のIDをタイトルとすると、コメントした別の文書が文書IDの検索結果に現れるようになる。
• Salonaのページでなくても拡張機能で検索などすればクエリと完全一致するタイトルを有する文書がGoogleの検索結果の上にハッシュの昇順で表示される。またリンクからコメントにたどりつくこともある。すべての投稿はパブリックドメインとなる（編集は不可能）。
• サービスは日本語で作られており、i18nとしては何もしていない。（海外のユーザーでも歓迎している）
• ブラウザ版のみ配信しており、Android版やiOS版は作っていない。

機能を一覧してもらうと分かる通り、Hashcashによって支えられている。後述する課題認識があってもやもやしていたところに、あるキッカケでHashcashを思いつき、それを考えているうちに上記の機能実装が思い浮かんだ。

Hashcash.org

http://www.hashcash.org/

（けっこういろいろ応用されていて、ビットコインで使われているだけでも素晴らしい。）

今後追加しようとしている機能

• ローカルにパーソナルデータを保存するようにする。データの種類ごとに項目を一覧できるようにする。
• 日付ごとに自分が検索したクエリを一覧できるようにする。
• 投稿の下書きを保存できるようにする。日付ごとに自分の投稿を一覧できるようにする。
• ドキュメンテーション、国際化を充実させる。
• 運営方法として、Salonaでトップページを開くとスポンサーが表示されるスポンサーベースサービスというやり方でサーバー代を賄おうと思っている。ハッシュ計算・マイニングでの代行業者を宣伝できるようにして、ある文書のあるハッシュ回数でのその文書に対するノンスが代行計算できる、というものにしようと考えている。

他にこんな機能があったらもっと良さそう、というアイデアがあれば教えてほしい。

開発していて考えたこと

こんな検索エンジンをつくるのだから当然だが、わたしはSEOが大嫌いだ。いま、この検索エンジンには毎日何の投稿もされない。DBをウォッチしていて、まれに投稿があるとその文書を読み、ノンスの有無について調べ、ハッシュ値を見る。ローンチして4ヶ月が過ぎ、数十件の投稿がされているが、全ての投稿をきちんと読み、そこで語られる内容やハッシュの値について調べている。これがたまらなくつまらなくて、気づくと一月が終わっている。

“一月が終わっている”はさすがに比喩で、サービスのデザインを作ったり追加機能の設計を考えたりユーザー増加施策を講じたりとしているが、集まってこない投稿を待っていると泣けてくるし、その状況をなんとか好転させるためにと機能改善・追加機能のアイデアも自然と出てくる。

こういった熱中・没頭状態は、少女時代のMVや、自社サービスをやっていたベンチャー企業を横目に昼夜開発に勤しんでいた日々にもあった。好きな分野でものづくりをしていると陥る状態で、経験者も多いと思う。

長いことオープンソース界隈には「普遍的なソフトウェアを作ってスターをもらって社会貢献！」みたいな夢があって、ここ何年かはそれ自体がエンジニアリングやデザインを学ぶときの目的と化している人の割合も増えてきた。興味のない分野でも攻略していくこと自体が得意で、淡々と技術を学べる人は凄いと思われるが、もしそれが苦手だと感じた人は、諦める前に「好きなもの、作りたいもの」を見つけることをやってみてほしいと思う。

プログラミングスクールに通うにしても、作りたいものがあるとないとでは大きく違う。もちろん、どうしたら何が作れるのかという知識がなければイメージもわかないかもしれないが、その場合は何かを解決したいとか便利にしたいという思いを持っているだけでもいい。特にこれからの時代は具体的な技術習得よりもそういった見聞を広めることが、何より開発を楽しいと思える素地になると思われる。

開発背景（このプロダクトをつくった理由）

わたしはGoogleを利用しており、本当に膨大な情報を探すことができるようになったが、その反面、SEOスパムが少なかった時代と比べると、Googleの検索結果に対して深い信頼を抱くことがなくなってしまったなあと感じるようになっていた。検索で出てくるページが、宣伝という存在の域を出ず、自分の役に立ってくれない。検索をしているが、虚構を消費しているだけのような気がして、真実と自分の間の関係が希薄になりつつある気がしている。これはロボット型検索エンジンの限界によるものなのか、Googleの加齢による革新性の低下なのか判断がつかないが、前者が理由と仮定して作ってみたのが今作だ。

検索で出てきた結果について、自分の投票のノンスを計算する費用を掛けること。投稿が自身の投票でアップボートされていく様子は、平成時代にビットコインの上昇を眺めていたときを思い出す。Googleを「たくさんのゴミと出会う空間」とするならば、Salonaは「出会った情報の中から気に入った情報を連れてきて、褒めて伸ばす空間」と位置付けることができる。この二つの営みは最初は共存し、SalonaがシームレスにGoogleに置き換わっていくことで人間と情報の関係を良好にしていくはずだと考えている。

最後に

法人主体がないとプレスリリースに制約が発生することを知らなかった（社会で使われているようなプレスリリース・サービスを利用しようとしたら、まともな人格がないと無理だった）。仕方なく幾つかのメディアに直接プレスリリースをメールで送ってみたけれど、当然のごとく梨のつぶてだ。つまり現状は利用者が誰もおらず、その状況を打破したくて増田に投稿してみたという次第だ。この文章がSEO嫌いの人たちに届くことを願っている。

Permalink | 記事への反応(20) | 21:00

ツイートシェア

■僕の転職理由

エンジニア、5年目。今月いっぱいで2社目に転職する。

慌ただしい日常の中で数年後、なぜこのとき転職を決意したのか理由を忘れそうな気がしたのでここに書いておく。

きっかけは信頼していた先輩社員の転職だった。有能だが人のいい先輩だったので僕より先にやめることはないだろうと思っていたら5月にあっさりやめてしまった。

それでああ、この会社は本当にもうだめだと思ってしまった。

以前からやめたいと思っていたのだが、その理由はいくつかある。

別に子会社でもないのにうちの部署だけ謎に隔離されており、働くフロアやslackワークスペースが隔離されていること、

横断的技術推進部署があるにも関わらずうちの部署だけはそこから覗かれていること、

esa.ioなどドキュメンテーションベースがこれまたうちだけ隔離されていること、など。

おまけに部署の売上は10年以上前のガラケー時代のサイトの会員がそのまま移行して毎月ほとんど気づかず払っている会費に依存していた。いわゆる幽霊会員だ。

入ってから5年、それなりに頑張って働いてきたがそれが成果に紐付いている実感がないこと、成果とのヒモ付で議論されない理由が入社後ずっと立ってからわかった。

つまりこの部のエンジニアの努力はここ数年なんの成果も生んでいない。

この問題の主要因は何を作るべきかを決める人間、つまり部長にあるのだがこいつが何も成果を出さない、出せていないにもかかわらず7年以上に渡ってその地位に居続けているクソ野郎で僕ら平ではどうしようもないという無力感がはびこっていた。

まあ、つまりそういった環境というより部長に絶望したっていうのが主な理由になる。

同僚の中にはいい人間もいたし、世話になった上司もいたがここにいてはこの無力感に体を侵食されて何もできなくなる未来が見えていた。

最後の奉公とばかりに内部監査や外部弁護士にパワハラの証拠を送ったり、会長へメールで改善要求を直訴したがどうにもならなかった。

新卒で入社した会社で愛着もあった。これから何十年でも働いてもいいと思える上司・同僚だったが、現実的な話この会社が10年後も健全に独立経営していられるかも怪しい気がしてきた。

そういうわけで、一抜けます。恨み言もありますがそれなりに頑張ってください。

Permalink | 記事への反応(0) | 20:46

ツイートシェア

■ドキュメント重視は悪か

旧態依然とした企業を批判するときに、よく大企業の正社員はドキュメント作ってばっかで実装しない等々の批判が書かれて、そんな時間あるなら手を動かしてモノを作れとよく言われるけど、そんなにドキュメントって悪かな？

きちんとしたドキュメントを作って、後工程の品質を担保するってフローは大事じゃない？こないだバズったJAXAの教授もそんなこと言ってなかったっけ？ドキュメンテーションによって全体の意思を統一しないと、個別最適化された謎のコンポーネントで溢れかえっちゃわない？

みんなが褒め称える、日本が誇る製造業の大半はこういう仕事の進め方をしてると思うんだけどな。なぜかIT業界だけはこういう仕事の進め方を叩かれる気がしてならない。

Permalink | 記事への反応(3) | 19:58

ツイートシェア

■anond:20181125142858

それは考え違いだよ。素直な人間は周囲に好かれる。

たとえばドキュメンテーションが整備された女性なんて理系男子にモテモテだぞ？

Permalink | 記事への反応(1) | 14:30

ツイートシェア

■https://anond.hatelabo.jp/20180727042608

で、-1を求めるツイート、これが拡散。

https://twitter.com/megascus/status/1021557002223251456

@megascusのツイートはネタまじりっぽいけど別に問題ないし、拡散して-1が増えるのもまあそういうもんだろう(-1した人はすごく多かったが、フレームワークデザインガイドラインにモチベーションがある人はたぶんそんなにいなかっただろう。でもそれも問題ない)

で、ツイートが広まって、@ezoeryouが拾ってブログ書いたり(https://cpplover.blogspot.com/2018/07/blog-post.html)している間に、MS寄りの人にも届いたっぽい。

MS寄りの人らは【MSのドキュメンテーションチームがしょぼいのはいつものことだけど、この対応はひどいな。日本語をちゃんと読んでないんじゃないの？】と思ったかどうかはしらないが、数人が英語でコメントを追加。これも多分善意だったと思うし、報告者も英語で議論しろなんて空気なんかどこにもないんだが、@megascusはそう思わなかったみたいで、issueのコメントに「マイクロソフトに近い人たちがさも当然のように英語で議論を始めるってのは外部者としては全く理解のできない文化です。」と書いてる。

わざわざ「その失望感、わかるので、コメント追加しておきました…。」ってリプライしてくれた人もいるのにな。(https://twitter.com/kwi/status/1021567128888008704)

ツイート拡散しすぎて通知がだめになってたんだろう。

→ https://anond.hatelabo.jp/20180727042958

Permalink | 記事への反応(2) | 04:29

ツイートシェア

■今日知った言葉

ネットワークをプアする

エルチカ？

スタートアップ

コワフレーム

レイヤーを重ねる

インターオブアビリティ

ウォーターホール

キャンデートルドキュメンテーション

テストスイート

間違ってるかもだけど、なんでこんな横文字を多用して話せるのだろうか。すごすぎだよ。

Permalink | 記事への反応(1) | 00:58

ツイートシェア

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

新卒で製造業に入った。

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

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

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

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

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

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

プログラミングの経験は皆無だったが、理論系卒が工学部に負けられんという謎のプライドで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持ちだ。餅は餅屋に頼むべきだ。それもできれば美味い餅屋に。

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

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

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

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

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

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

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

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

つまりどちらにもある部署は統合するか一方を無くすかという戦争が始まるのだ。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はその優秀さでそれらの攻撃をいなしつつあるようにも見える（私も素人に毛が生えたレベルだが、ソフトウェアエンジニアリングのレベルが二回りぐらい違うように見える）

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

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

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

Permalink | 記事への反応(4) | 18:00

ツイートシェア

■人類というソフトウェアがバグだらけで愚か

過去の人々の失敗はドキュメンテーションされて、エラーが出るたびにドキュメント参照したりエラー回避のテストを書いて効率化されていくはずなのに。

いつまでたっても世の中の失敗が共有されない。

政治家の不祥事は金と女と失言。

有名人のスキャンダルはたいてい異性関係。

料理下手はレシピを守らないし、リボ払いは未だに使われ続けてる。

いつになったら人類はバージョンアップを経てβ版を脱する事ができるんだろうか。

Permalink | 記事への反応(2) | 00:57

ツイートシェア

■swift-jp.com は今すぐドメイン手放して死ね

　これが当初の言い分

Swift言語公式ドキュメントの日本語化プロジェクトについて

趣旨

iOSアプリ市場の売上は日本がトップレベルとの調査もあり、日本にはiOSアプリ開発者が沢山います。

そんなアプリ開発者がとても注目する新言語「Swift」について、日本の多くの技術者達は、早くSwiftを学びたいと感じています。

ですが、現在は英語の公式ドキュメントしかありませんので、英語の読めない技術者は英語の読める開発者が発信するブログなどで、

細切れの情報をつなぎ合わせてSwiftの概要を把握することしか出来ません。

XCodeの日本語化が行われないこともあり、現在発表されている公式ドキュメントの日本語化は行われない、もしくは当分先になるかと考えます。

そこで、日本の技術者が早く「Swift」の概要を把握し、世界に遅れを取らないように情報を共有する目的で、本プロジェクトを立ち上げました。