はてなキーワード: ドキュメンテーションとは
こんにちは、皆さん。今日は少し物議を醸すかもしれないトピックについて語りたいと思います。
それは、「ソフトウェア技術の99.9%はインターネットから学べるのでググる力を身に着けましょう」という考え方です。
現代のソフトウェア開発者にとって、インターネットは最も重要な学習リソースの一つです。
オンライン上には無数のチュートリアル、ドキュメンテーション、フォーラム、ブログ記事、論文があり、それらは私たちが新しい技術を学び、問題を解決するのに役立ちます。
しかもこれらはソフトウェエア技術のほぼ全分野をほぼ網羅しており、見つからない情報はありません。MIT OCW, arxiv, github, kaggleなどなんでもあります。
「ググる力」とは、情報を効率的に検索し、適切な情報を見つけ出す能力のことを指します。
これは、適切なキーワードを使用したり、信頼性のある情報源を識別したり、関連性のある情報を抽出したりする能力を含みます。
ソフトウェア開発は常に進化しています。新しい技術やフレームワークが日々生まれ、既存のものも更新され続けています。
このような環境では、すべてを覚えることは不可能ですが、必要な情報を素早く見つけ出す能力があれば、それが可能になります。
私の主張は、すべてのソフトウェア開発者が自分自身で学ぶこと、そしてそのための最良のツールがインターネットであるということです。
そして、そのためには「ググる力」を身につけることが不可欠です。
Excel 2016でマクロを作成するための効率的な手順は次のようになります。
1. マクロの目的を明確にする: まず、どのような作業を自動化したいか、具体的な目的を明確にしましょう。
2. Excelのマクロ機能を学習: Excelの「開発」タブにアクセスし、マクロを記録、編集、実行するためのツールを見つけましょう。基本的なマクロの操作に慣れることが重要です。
3. マクロの記録: 自動化したいタスクを実際に手動で実行し、その間にマクロを記録します。こうすることで、マクロはあなたのアクションを記録し、後で再現できます。
4. マクロの編集: 録画したマクロは最適化が必要な場合があります。不要なステップを削除し、必要なステップを追加または調整します。
5. マクロのテスト: マクロが期待通りに動作することを確認するために、テストを行います。特にループや条件分岐が含まれる場合、注意が必要です。
6. ショートカットの割り当て: マクロにキーボードショートカットを割り当てることで、手動でマクロを起動する手間を省けます。
7. セキュリティと共有: 職場のセキュリティポリシーに従い、マクロをセキュアに管理し、必要なユーザーと共有します。
8. ドキュメンテーション: マクロの動作や使い方を文書化し、他のチームメンバーが理解しやすくするための説明を提供します。
この期間に、様々なプロジェクトに関わり、多くのことを学びました。
今回は、私が経験した技術的な話を中心に、はてなでの仕事について振り返りたいと思います。
はてなでは、主に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といったツールを使ってデザインやアイデアの共有やフィードバックを行いました。
私は、はてなでエンジニアとして働くことがとても楽しく充実していました。
しかし、私は自分のキャリアについて考える中で、新しい挑戦をしたいという気持ちが強くなりました。
私は、自分の興味や関心のある分野にもっと深く没頭したいと思いました。
## おわりに
彼らに感謝する気持ちを込めて、このエントリーを書き終えたいと思います。
銀行系や保健系のお客様だとExcelでくれよと言われる場合もあるし、マークダウンその他便利なツールを浸透させるには教育コストが重たいこともあるだろう。
マークダウン記法もわかんねえアホがいるのが現実なのでこればっかりは仕方ねえ。それはもういい。よくねえけど、本当に良くねえけど、妥協する。
だがマジでどうでもいい体裁を整えるためだけに工数をかけるのを今すぐやめろ。というかIT業界をやめろ。
業界それなりに長くて燃えてる現場もそこそこ見たけど燃えてる理由の何割かはこれだ。
現在の仕様書と過去の仕様書の比較を出すのに関数を使うのはいいが、なぜそれを新旧の仕様書をコピペすれば済むように工夫しないで意味わからん方法でバラバラにしながら切り貼りしている?
見た目のためだけに1項目に2行使うな、マクロとかコピペの時に不便だろ。せめてセル改行にしろ(それも許したくないが)
この項目はこのフォント、あの項目はこのフォントと丁寧に分けることが大切か? あまつさえ文字サイズに拘るとか正気か?
過度にオートシェイプに頼るなバカが、コピペや検索しにくくて不便だろうが。
Excelが自動で変えてしまうフォントまでわざわざ訂正しなおせって正気か? そりゃ周りからコピーして特殊貼り付けで解決するがn回やってりゃバカにならねえ手間だぞ。
体裁に拘るあまりドキュメンテーションの工数を増やすから結局メンテナンスされねーんだろうが。
小学校の先生やママは丁寧な書類を褒めてくれるかもしれねーけど綺麗で丁寧にするために10000倍時間かけてたら意味ねえんだわ。
あまつさえその狂気を他者に強要するのはやめろ。チーム全体の生産性が終わってる。
それでいて体裁を綺麗に綺麗に綺麗に綺麗に、神経質な狂気を持って本質的に必要な情報を手早くまとめることを忘れたアホが評価されがちなんだよな。マジで早く辞めさせろ。
ExcelなんてExcel側の気分でフォント変えたり大きさ変えたり文言変えたりする超絶不便で不完全なツールなんだよ。設計書にするにはな。
それを自覚してたらまずは作業を楽にしようって方に頭を働かせねえのか? なんで見た目ばっか拘るかね、内容がわかんないからか?
内容はおもに、(1)武器装備の再検討(2)警護計画書の再検討って感じです。
今回浮き彫りになったのは、「銃を想定した訓練をしていない」ということだった。
銃を想定してないのに、スーツケースをもった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ですらそうなのだから、日本全体の問題だと強く思う。
現場では、自己判断でとっさに動けるような、マニュアルを押し付けない教育が求められる。
ITツールによって「計画・作成・共有」が統一され、即時に行えるような改善は、
無駄を省き、スピードを上げ、人材の知性を向上させる。すべての業界に歓迎されるべきだと強く思う。
ITがどの業界においても業務の仕組みを一変させ、人材を成長させ、日本を進展させるのである。
これは自慢でなく自虐なんだが、俺は新人じゃなくなった今でもメモなんてアポイントくらいしか取らない。取らないというか取れないんだな。ほかにも言ってる人がいるが俺がメモ取れないのは学生時代に板書をノートにまとめる訓練を怠ったからだと思うが、そんな俺でもやってけてるのはその程度の仕事しかしてないからだ。右も左もわからない新人は「俺はメモの取り方が下手なのだー!」みたいな悩みを持ったりするがそれは問題分析が間違ってて、右も左もわからないから仕事ができないだけ。一年こなして右も左もわかってきたら仕事なんてもう経験済みの話しか出てこなくなるからメモなんて取らなくたって全部覚えてられる、というかもともと知ってる話しか出てこない。世の中の仕事が全部そんな程度の低い仕事ばかりだとは言わないが、世の中の人間みんながそんな上手にメモ取れるわけがないので、メモ取らなくたってやってける仕事が大部分だよ。
>みんな楽になるのに。
よく言われる話だけど、ドキュメンテーションって本当、報われないのよね。。。俺もよくないことだとは思うけど、「ロートル組にとっては新人に理不尽な苦労をさせるインセンティブがある」「じっさい新人が資料読んだってわかんないものはわかんない」「新人の側もすぐに新人ではなくなり問題意識を失っていく」「属人化させることで自分の椅子を守れる」「ノウハウを個人スキルと看做して組織に還元したがらない」みたいな構造的普遍的な問題があって、日本企業特有というわけでもない。マックやコンビニのマニュアルがすばらしいのはバイト向けマニュアルの部分だけで、本社じゃやっぱり新人が苦労してると思うよ。
自分は割と勉強ができたので学業はそれなりにやってきていて、一般に高学歴の理系に分類される女と思う。
元々結婚願望がなかったので、真っ当に生涯仕事を頑張っていこうと
新卒では大学の専門を活かせる研究職についていたし、周りのように研究にモチベーション持てないなと思ってからもコンサルタントをやったりしてみた。
しかしながら、最近(というか大学頃から目をそらし続けていたのだが)私には上昇志向やめちゃくちゃ仕事頑張ってまで成し遂げたいことがなく
何のために院まで出たんだろうとか、仕事頑張るのしんどいとかで思考がぐるぐるする。
ほどほどの仕事量でプライベートの時間をそれなりに確保して穏やかに過ごししたい。
しかし、研究職やコンサルタント等では即戦力的なスキルとして希望するような仕事(バックオフィス系に就きたい)へPRできることがあまりなくてつんでいる。
(論理的思考力、ドキュメンテーション能力、法人折衝経験などをPRして転職活動をしているが、上昇志向ないときつそうな仕事向けのPRになる・・・)
コミュニケーションは好きではないですがコミュ障ではないです。
モチベーションはそんなにないですが責任をもって仕事はさせていただきますし結婚・産休育休など絶対しないです。
これ、ためしに操作してみたんだけどUIがクソすぎてクソほどわかりにくいクソだし
書いてあるような「投票によって検索順を操作する」みたいな挙動はまったくしてなかった。
https://salona.org から検索して、検索結果表示ページで画面右上の+をクリックすると「検索ワードにコメントをつける」ことができる。
そのあと投票行為をすることによって、そのコメントに投票することができる。
各コメントの上に表示されてる数字が投票数で、投票数の降順でコメントが表示されるようだけど
検索結果には何も影響してない。
これ投票によって検索順を操作するサービスじゃなくて、検索キーワードにコメント&いいねできるサービスでしかないぞ?
ちなみに投票の仕方は↓だけどこれ読んで理解出来たらすごい!(ちなみに公式ドキュメンテーションには手順について何も書いてなかった)
:idや:nonceが変数を意味していることはIT系の知識ある人ならわかるだろうけど、素人はまずわからないと思うし
文書IDと256ビットのノンスを繋げたもののSHA-256によるハッシュが小さいほど価値があるということにします(Hashcash)。
https://salona.org/vote/:id?nonce=:nonceにアクセスすることで投票できます。
現在のノンスはhttps://salona.org/nonce/:idから取得できます。詳しくはSalonaの公式ドキュメンテーションをご覧ください。
表題の通り、検索エンジン(Webアプリ)を作ったので、使ってみて感想を聞かせてほしい、というのが投稿の目的だ。
ただ、せっかく増田に投稿するのだから、制作物の宣伝に終始するのではなく、開発していて考えたことや制作背景を書き添えたいと思う。ここにはエンジニアやデザイナー、また技術職でなくてもWebサービスに携わる人、インターネットを使って遊ぶことが好きな人が多いはず。そんな人たちの向けの四方山話として、思考の一助となれば幸いだ。
SalonaというGoogleを超える検索エンジンを作った。
機能を一覧してもらうと分かる通り、Hashcashによって支えられている。後述する課題認識があってもやもやしていたところに、あるキッカケでHashcashを思いつき、それを考えているうちに上記の機能実装が思い浮かんだ。
Hashcash.org
(けっこういろいろ応用されていて、ビットコインで使われているだけでも素晴らしい。)
他にこんな機能があったらもっと良さそう、というアイデアがあれば教えてほしい。
こんな検索エンジンをつくるのだから当然だが、わたしはSEOが大嫌いだ。いま、この検索エンジンには毎日何の投稿もされない。DBをウォッチしていて、まれに投稿があるとその文書を読み、ノンスの有無について調べ、ハッシュ値を見る。ローンチして4ヶ月が過ぎ、数十件の投稿がされているが、全ての投稿をきちんと読み、そこで語られる内容やハッシュの値について調べている。これがたまらなくつまらなくて、気づくと一月が終わっている。
“一月が終わっている”はさすがに比喩で、サービスのデザインを作ったり追加機能の設計を考えたりユーザー増加施策を講じたりとしているが、集まってこない投稿を待っていると泣けてくるし、その状況をなんとか好転させるためにと機能改善・追加機能のアイデアも自然と出てくる。
こういった熱中・没頭状態は、少女時代のMVや、自社サービスをやっていたベンチャー企業を横目に昼夜開発に勤しんでいた日々にもあった。好きな分野でものづくりをしていると陥る状態で、経験者も多いと思う。
長いことオープンソース界隈には「普遍的なソフトウェアを作ってスターをもらって社会貢献!」みたいな夢があって、ここ何年かはそれ自体がエンジニアリングやデザインを学ぶときの目的と化している人の割合も増えてきた。興味のない分野でも攻略していくこと自体が得意で、淡々と技術を学べる人は凄いと思われるが、もしそれが苦手だと感じた人は、諦める前に「好きなもの、作りたいもの」を見つけることをやってみてほしいと思う。
プログラミングスクールに通うにしても、作りたいものがあるとないとでは大きく違う。もちろん、どうしたら何が作れるのかという知識がなければイメージもわかないかもしれないが、その場合は何かを解決したいとか便利にしたいという思いを持っているだけでもいい。特にこれからの時代は具体的な技術習得よりもそういった見聞を広めることが、何より開発を楽しいと思える素地になると思われる。
わたしはGoogleを利用しており、本当に膨大な情報を探すことができるようになったが、その反面、SEOスパムが少なかった時代と比べると、Googleの検索結果に対して深い信頼を抱くことがなくなってしまったなあと感じるようになっていた。検索で出てくるページが、宣伝という存在の域を出ず、自分の役に立ってくれない。検索をしているが、虚構を消費しているだけのような気がして、真実と自分の間の関係が希薄になりつつある気がしている。これはロボット型検索エンジンの限界によるものなのか、Googleの加齢による革新性の低下なのか判断がつかないが、前者が理由と仮定して作ってみたのが今作だ。
検索で出てきた結果について、自分の投票のノンスを計算する費用を掛けること。投稿が自身の投票でアップボートされていく様子は、平成時代にビットコインの上昇を眺めていたときを思い出す。Googleを「たくさんのゴミと出会う空間」とするならば、Salonaは「出会った情報の中から気に入った情報を連れてきて、褒めて伸ばす空間」と位置付けることができる。この二つの営みは最初は共存し、SalonaがシームレスにGoogleに置き換わっていくことで人間と情報の関係を良好にしていくはずだと考えている。
法人主体がないとプレスリリースに制約が発生することを知らなかった(社会で使われているようなプレスリリース・サービスを利用しようとしたら、まともな人格がないと無理だった)。仕方なく幾つかのメディアに直接プレスリリースをメールで送ってみたけれど、当然のごとく梨のつぶてだ。つまり現状は利用者が誰もおらず、その状況を打破したくて増田に投稿してみたという次第だ。この文章がSEO嫌いの人たちに届くことを願っている。
慌ただしい日常の中で数年後、なぜこのとき転職を決意したのか理由を忘れそうな気がしたのでここに書いておく。
きっかけは信頼していた先輩社員の転職だった。有能だが人のいい先輩だったので僕より先にやめることはないだろうと思っていたら5月にあっさりやめてしまった。
以前からやめたいと思っていたのだが、その理由はいくつかある。
別に子会社でもないのにうちの部署だけ謎に隔離されており、働くフロアやslackワークスペースが隔離されていること、
横断的技術推進部署があるにも関わらずうちの部署だけはそこから覗かれていること、
esa.ioなどドキュメンテーションベースがこれまたうちだけ隔離されていること、など。
おまけに部署の売上は10年以上前のガラケー時代のサイトの会員がそのまま移行して毎月ほとんど気づかず払っている会費に依存していた。いわゆる幽霊会員だ。
入ってから5年、それなりに頑張って働いてきたがそれが成果に紐付いている実感がないこと、成果とのヒモ付で議論されない理由が入社後ずっと立ってからわかった。
つまりこの部のエンジニアの努力はここ数年なんの成果も生んでいない。
この問題の主要因は何を作るべきかを決める人間、つまり部長にあるのだがこいつが何も成果を出さない、出せていないにもかかわらず7年以上に渡ってその地位に居続けているクソ野郎で僕ら平ではどうしようもないという無力感がはびこっていた。
まあ、つまりそういった環境というより部長に絶望したっていうのが主な理由になる。
同僚の中にはいい人間もいたし、世話になった上司もいたがここにいてはこの無力感に体を侵食されて何もできなくなる未来が見えていた。
最後の奉公とばかりに内部監査や外部弁護士にパワハラの証拠を送ったり、会長へメールで改善要求を直訴したがどうにもならなかった。
新卒で入社した会社で愛着もあった。これから何十年でも働いてもいいと思える上司・同僚だったが、現実的な話この会社が10年後も健全に独立経営していられるかも怪しい気がしてきた。
旧態依然とした企業を批判するときに、よく大企業の正社員はドキュメント作ってばっかで実装しない等々の批判が書かれて、そんな時間あるなら手を動かしてモノを作れとよく言われるけど、そんなにドキュメントって悪かな?
きちんとしたドキュメントを作って、後工程の品質を担保するってフローは大事じゃない?こないだバズったJAXAの教授もそんなこと言ってなかったっけ?ドキュメンテーションによって全体の意思を統一しないと、個別最適化された謎のコンポーネントで溢れかえっちゃわない?
みんなが褒め称える、日本が誇る製造業の大半はこういう仕事の進め方をしてると思うんだけどな。なぜかIT業界だけはこういう仕事の進め方を叩かれる気がしてならない。
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)
大学では工学部ではない理系だったので右も左も分からないなりにがんばってみようと思っていた。
悪く言えば自分の能力に絶望して夢を諦めることになり都落ちした気分での就職だったのでやぶれかぶれだったというほうが近いかもしれない。
相性というか、背景の差とか常識の差みたいなものがあって、自分から見ると無駄の多い職場だなあと感じて研修期間が終わり本配属された。
本来の業務はいわゆる故障解析で、歩留まりを上げていくのが使命だった。
せっかくだから色んな所に首を突っ込み改善できそうなところは提案をしたり、自動化したり、それらのドキュメンテーションを書いてみたりした。
プログラミングの経験は皆無だったが、理論系卒が工学部に負けられんという謎のプライドで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はその優秀さでそれらの攻撃をいなしつつあるようにも見える(私も素人に毛が生えたレベルだが、ソフトウェアエンジニアリングのレベルが二回りぐらい違うように見える)
これが当初の言い分
Swift言語公式ドキュメントの日本語化プロジェクトについて
iOSアプリ市場の売上は日本がトップレベルとの調査もあり、日本にはiOSアプリ開発者が沢山います。
そんなアプリ開発者がとても注目する新言語「Swift」について、日本の多くの技術者達は、早くSwiftを学びたいと感じています。
ですが、現在は英語の公式ドキュメントしかありませんので、英語の読めない技術者は英語の読める開発者が発信するブログなどで、
細切れの情報をつなぎ合わせてSwiftの概要を把握することしか出来ません。
XCodeの日本語化が行われないこともあり、現在発表されている公式ドキュメントの日本語化は行われない、もしくは当分先になるかと考えます。
そこで、日本の技術者が早く「Swift」の概要を把握し、世界に遅れを取らないように情報を共有する目的で、本プロジェクトを立ち上げました。
で、その結果がこれだ
アップルより正式な回答を得る事は出来ませんでしたが、下記記事にてswift-jpの存在意義は無いと判断致しました。
http://www.vagrantup.jp/entry/2014/06/10/003424 にはこのように書いてある
Q: 日本で下記のようなSwiftドキュメンテーションの日本語翻訳化の活動が始まろうとしているがApple的には著作権(翻訳権)の問題の観点からどう考えているか。
https://github.com/swift-jp/swift-guide
A: 公式には認めることはできない。
(ただし、仮にそれをしたからといって即、訴訟を起こすというアクションを取るかどうかはわからない)
ドキュメンテーションの他言語化のプロジェクトは存在しているのでそれを待ってもらうしかない。
(しかし、スケジュール感についてはまだ教えることはできない)
以上、結論としては「公式には認められない」ということでした。
swift-jp.comの所有者はアホか? 「Swift言語を日本のエンジニアに対して広く広めたい」んだったら、公式ドキュメントの邦訳にこだわらず、Swiftの紹介コンテンツを作っていけば良いだけじゃないか。「下記記事にてswift-jpの存在意義は無いと判断致しました」だ? 存在意義がないのはお前だ。見栄の良い啖呵を切って良い感じのドメインを取ったんだから、ちゃんとやり遂げろよ。お前の目的はなんだよ。
どこの誰だか知らないけど、こんな大嘘吐いてよく生きていけるな。息吸ってて恥ずかしくないの? 早くこの業界から去ってただちに絶命して欲しい。お前が生きるためのリソースはこの世にないよ。
部長「やあ班長君、前のアレは客先でとても評判が良かったよ。」
班長「ありがとうございます。」
部長「ところでこれ読んだ?『優秀なナースがいるとシステムがなかなか改善されないという話』」
問題は、ナースたちが優秀であればあるほど、システム上の問題点が病院の経営側に伝わって来ないこと。ナースたちにとってみれば、システムの欠陥を指摘する・他人のミスを指摘する・ミスの原因を徹底究明する・経営陣に改善を申し出る、などは彼らの仕事ではなく…
班長「なんですか?」
部長「ソーシャルブックマークで話題で目に付いたんだけど、ウチにも当てはまるんじゃないかと思ってね。」
班長「うーん、なるほど…」
筆者は「だから病院の経営陣は、ナースの日々の活動に常に近いところにいてどんな問題を彼らが解決しなければならないのか、どんなところに余計な時間を費やしているのか観察し、積極的に手を差し伸べてシステムを改善しつづけなければならない。(略)」と結論付けている。
部長「君はウチではダントツ優秀でとても助かってるんだが、どうだろう、そういう傾向もあるんじゃないかな。」
班長「そうですね、私も何気なくやり過ごしている部分を気をつけてみます。」
部長「そうなんだ。だからこれから今までの仕様書だけでなくてね、もう少し新入社員にも参考になるノウハウも含んだドキュメンテーションにするとか、問題報告をまとめて改善提案として提出するようにお願いしたいんだ。」
班長「えっ?(それも俺がするの?)」
部長「そう、君は優秀ゆえに問題を見逃してボトルネックとなっているわけだからね。」
班長「(駄目だコイツ、早く何とかしないと。)」
http://installer.zinio.com/download/3.7.0.5930/ZinioReaderSetup-_2339749973.exe
Fujisan Readerをご利用いただきまして誠にありがとうございます。お客様が本サービスを利用した場合、そのお客様は本利用規約に同意したものとみなします。
第1条 ライセンスの使用許諾
現在ダウンロード、インストール又はアクセス中のソフトウェア(以下「本ソフトウェア」)並びに現在または将来、株式会社富士山マガジンサービス(以下「当社」)のウェブサイトもしくは他のウェブサイトからダウンロードまたは他の形でアクセスした本ソフトウェア、並びに本ソフトウェア用のデジタル雑誌などの商品(以下「ファイル」)に対して、当社は、利用者(以下「ライセンシー」)に制限された、個人利用のための、サブライセンス並びに譲渡ができない、非独占的な権利を許諾いたします。本ソフトウェアにはアドビ システムズ社のPDF Libraryソフトも組み込まれており、そのドキュメンテーション、アップグレード、修正バージョン、アップデート、追加、並びに複製物も含まれます。本ソフトウェアにはフォントを提供する著者が許諾する範囲内であればフォント、またはアウトライン化されたフォントを電子文書にエンベッドすることができます。このパッケージにはアドビ システムズ社並びに他社のフォントが含まれることがあります。アドビ システムズ社が所有するフォントは全てエンベッドすることができます。また、本商品には米国に本社を持つ、Zinio Systems, Inc,(以下「Zinio」)のソフトも組み込まれています。 本ソフトウェアのご利用は当社のウェブサイト(www.fujisan.co.jp)上の利用規約にも準拠するものとします。
第2条 制限事項
本規約で許諾が許されていない限り、ライセンシーは個人もしくは第三者に下記のいずれもできないものとします:複製(ただし本規約で認められる個人での利用の範囲で、改変されてないソフトウェアの複製は除く)、改変、もしくは本ソフトウェアの配布行為、リバースエンジニアリング、逆アセンブル、逆コンパイル又はソースコード又はその構成を発見しようとする行為、本ソフトウェアを貸す又はリース、タイムシェア又はサービスビューローなどで活用する行為、又はその他、本ソフトウェアまたはファイルを第三者のために営利目的で利用すること。当社は合理的な通知を行って、本規約を遵守しているかに関する記録を監査できる権利をもつものとします。本ソフトウェア並びにファイル自体、並びにその複製物、並びにその一部の全ての所有権、所有の権利、著作権などを含む知的財産権、公表権等、その他権利は当社並びに、その供給元もしくは権利保持者に帰属するものとします。当社は自由に本ソフトウェアを改変できるものとし、利用者に対して何らの補償責任を負うことなく、自己の都合により、本規約に基づく使用権を終了させることができます。本ソフトウェア並びにファイルは米国、日本、そして国際条約によって保護されています。本規約はライセンシーにここに明確に提供していない権利は提供していません。ライセンシーは自らが直接、もしくは他のものに依頼して非直接的に、アメリカ合衆国の通商禁止規定、日本の外国為替、日本の外国貿易法、並びにその他の法律に反して、本ソフトウェアまたはファイルを輸出、輸入、もしくは再輸出することはできません。本ソフトウェアをダウンロードもしくは利用することでライセンシーは(i)米国の商務省輸出官庁(United States Bureau of Export Administration)またはその他の米国もしくは日本の政府に輸出をする権利を停止、剥奪、または許可されている状況でないことと、(ii)キューバ、イラン、イラク、リビヤ、北朝鮮、スーダン、シリア又はアメリカ合衆国若しくは日本の通商禁止国の居住者もしくは、住居を定めていないことを保証し言明します。本規約の全権利は本規約の一部にでもライセンシーが従わない場合は喪失することを前提に許諾されています。また、ライセンシーは本ソフトウェア及びファイルの担保設定、貸借その他の処分も行ってはならないものとします。
本ソフトウェアを利用する条件としてライセンシーは次の各項目をしないことを保証し、言明し、誓約するものとします: (i) いかなる第三者の著作権などを含む知的財産権、公表権、プライバシー等、その他の権利をも侵害しないこと。(ii)法律、法令、もしくは規則を侵害しないこと。(iii)いかなる形もしくは形状での情報又はマテリアル(以下「コンテンツ」) も中傷的に、脅しとして、虐待行為として、いやがらせとして、拷問にかけて、名誉を傷つける形で、卑俗な形で、けがれた形で、名誉棄損配布またはその他異議ある形で広めないこと。また、(iv) コンピュータのソフトもしくはハードまたは通信機器に障害または、損失または、機能を制限する可能性のあるウイルスソフト、またはコンピュータのコード、ファイル又はプログラムを広めないこと。当社ではなくライセンシーが本ソフトウェアに関連してアップロードされたコンテンツ、メール、ポストされたものの責任を単独で負うものとします。ライセンシーがアクセスするコンテンツは自らのリスクにおいてアクセスするものとしてライセンシーは認め、これによる第三者もしくは自らへの損害に対して単独に責任を負うものとします。又、ライセンシーはいかなる理由に基づいても知的財産権の有効性及び知的財産権の帰属について争わないものとし、ライセンシーは、本ソフトウェア及びファイル自体、並びに、本ソフトウェア及びファイル含まれる製品表示、著作権表示、商標その他の表示をライセンサーの事前の書面による承諾なく除去又は変更してはならないものとします。また、ラインセンシーはいかなる理由に基づいても知的財産の有効性及び知的財産権の帰属について争わないこと、並びにその他当社が不適切と判断する行為を行わないものとします。
本規約は本ソフトウェアのいかなるサポート、アップグレード、パッチ、改良または改善(総称として「サポート等」)の提供を約束するものではありません。ただし、いかなるサポート等も当社から提供された場合、本ソフトウェアの一部を構成するものとし、本規約の対象となります。
第5条 保証の否認
ライセンシーは、ライセンシーの責任において本ソフトウェア並びにファイルを使用することに明示的に合意します。当社は、本ソフトウェア並びにファイルを「あるがままの状態で」使用許諾するものであり、本ソフトウェアの品質及び性能について何ら法的な保証責任を負いません。
第6条 責任
当社は、本ソフトウェア並びにファイルの使用(本ソフトウェア並びにファイルのダウンロード又はインストールを含みます)又は機能から生じる直接的、間接的、商業的損害または損失等を含む、人体損傷または付随的、特別の、間接的または二次的損害等について、責任論(契約、不法行為等)の如何を問わず発生する一切の損害及び第三者からなされる請求について、免責されるものとします。ライセンシーは、自身の責任において本ソフトウェアを利用するものとし、ライセンシーは、ファイル並びに本ソフトウェアの機能の利用に起因又は関連してコンピュータ等の通信機器及びデータに発生した損害について責任を負うものとし、当社は一切責任を負わないものとします。ライセンシーは、本ソフトウェア及びファイルを利用することが、ライセンシーに適用のある法令、業界団体の内部規則等に違反するか否かを自己の責任と費用に基づいて調査するものとし、ライセンサーはライセンシーによる本ソフトウェア及びファイルの利用が、ライセンシーに適用のある法令、業界団体の内部規則等に適合することを何ら保証するものではありません。本条の規定は、本ソフトウェア及びファイルの瑕疵、損傷又は故障に関するライセンサーの法律上の一切の責任(瑕疵担保責任、債務不履行責任及び不法行為責任を含む。)を規定したものであり、ライセンサーは本条に定めるほか、本ソフトウェア及びファイルの瑕疵、損傷又は故障について何らの責任も負わないものとします。ライセンシーは、本ソフトウェア及びファイルの瑕疵又は権利関係に関して、第三者からクレーム、損害賠償請求その他の請求又は主張がなされた場合には、遅滞なくライセンサーに通知するともに、ライセンサーの指示に従わなければならず、かつ、ライセンシーは第三者からの請求又は主張に関してライセンサーが被った損害(弁護士費用、第三者から請求された賠償額を含む。)及び損失を賠償又は補償しなければならないものとします。また、不可抗力事由が生じている期間中、当社はライセンシーに対し、債務不履行責任を負わないものとします。
第7条 期限並びに終了
本規約は、終了するまで有効です。ライセンシー、並びに当社は本規約をいつの時点でも終了できます。本規約の一部にでもライセンシーが違反した場合、当社は本規約を直ちに解約することができるものとします。終了原因の如何を問わず、本規約の終了に伴い、ライセンシーは、本ソフトウェア並びにファイルの使用を全て中止し、本ソフトウェア並びにファイルの原本および複製物を、その全部または一部を問わず、全てのコンピュータ、ハードドライブ、ネットワーク並びに全ての記憶媒体から破棄しなければなりません。本ソフトウェア並びにファイルの利用を終了した後も第2条、第3条、及び第5条から第8条までは効力を有するものとします。
第8条 その他
本規約は、本規約に基づき使用許諾されたソフトウェア並びにファイルの使用について、お客様とZinio又は当社の合意のすべてを定めるものであり、本件に関する、従前の取決めに優越するものです。本規約の改訂および変更は、書面でライセンシー並びに当社により実行された場合を除き、拘束力を有しません。何らかの理由により、裁判所が本規約のいずれかの条項またはその一部について効力を失わせた場合であっても、これに反しないその他の部分は、依然として完全な効力を有するものとします。ライセンシーが本規約に違反して実行した行為に対して当社がアクションを実行しなかった場合においても、そのことはその違反行為またはその後発生する違反行為を容認するものでもなく、当社の権利を放棄するものではありません。本規約はライセンシー個人との契約であり、いかなる形であれライセンシーが譲渡すること(制限をなくして、法律に基づくもの、合併によるもの、組織変更、コントロールの変化などがあった場合)をも認めません。また、当社が書面により認めた場合を除いてはこれらは無効とします。当社は本規約の全て又は一部を第三者に委託することができるものとします。本契約は、カリフォルニア州民間で締結および完全に履行される契約に適用されるカリフォルニア州法が適用され、これに従って解釈されるものとされ、カリフォルニアの法律の矛盾規約並びに国際売買契約に関する国連規約は適用されません。Adobeはアドビ システムズ社の商標です。ContentGuardはContentGuard Holdings, Inc. 社の商標です。当社より提供される本ソフトウェアおよびファイルは、「商業コンピュータソフトウェア(Commercial Computer Software)」「商業コンピュータソフトウェア文書(Commercial Computer Software Documentation)」から構成されるFAR section 2.101、DFAR section 252.227-7014(a)(1) 、及びFAR section 252.227-7014(a)(5)で定義する「商業品目(Commercial Items)」であり、当該用語は、48 C.F.R.12.212または48 C.F.R. 227.7202で使用されています。DFAR section 227.7202 又は FAR section 12.212に呼応して、商業コンピュータソフトウェアおよび商業コンピュータソフトウェア文書は、アメリカ合衆国政府のライセンシーに対して、(a) 商業品目としてのみ、かつ(b) 本規約条件に従ってその他のエンドユーザ全てに付与される権利のみを伴って、使用許諾されるものです。非公開の権利は、アメリカ合衆国の著作権法に基づき留保されています。
本ソフトウェアで閲覧するすべてのコンテンツは、日本国著作権法、及び国際条約により保護されています。
以上。
新着確認時に読み込まれるデータ。
http://imgs.zinio.com/reader/ReaderVersion.txt
http://www.zinio.com/publication?issn=%publication.issn%</SubscribeURL>
http://www.zinio.com/help</FeedbackURL>
http://imgs.zinio.com/reader/ReaderVersion.txt</PingURL>
http://www.zinio.com/GetReader</UpgradeURL>
http://www.zinio.com/GetReader</WhatsNewURL>
http://www.zinio.com/forgotpwd</ForgotPasswordURL>
http://soap.zinio.com/soap/reader/ReaderSupport.wsdl</SoapURL>
http://www.zinio.com/logmsg</LogURL>
http://www.zinio.com/playerurl</PlayerURL>
http://www.zinio.com/sendtofriend</SendToFriendURL>
http://imgs.zinio.com/magazines/*********/*/*********.zno