  |
はてなキーワード: トラブルシューティングとは
Windows10Home(64bit)でソリティアとかマインスイーパーやらMicrosoftのゲームを起動したら
「お使いのアカウントで Microsoft xxxx は現在利用できません。エラー コード: 0x803F8001」
とのメッセージが出るからググったら以下のような解決策が見つかるがどれを実行しても解決しない
・WindowsUpdateで最新の状態にする
・ 「Windowsストアアプリ」のトラブルシューティングツール実行
・wsresetを実行
・cmdで「PowerShell -ExecutionPolicy Unrestricted -Command "& {$manifest = (Get-AppxPackage Microsoft.WindowsStore).InstallLocation + '\AppxManifest.xml' ; Add-AppxPackage -DisableDevelopmentMode -Register $manifest}"」を実行
トラブルシューティングの経験値を得るって意味ではいいかもしれんが、別に苦労せずにトラブルシューティングをマスターしても良い訳で
次のレジストリを適用することで治り、正常にWindowsUpdateができるようになりました。
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsSelfHost\Applicability]
"BranchName"="fbl_impressive"
"Ring"="WIF"
更新の履歴 を確認すると2017/8 頃からWindowsUpdateが適用できていないようでした。また、いくつかのUpdateでは（再起動は何度もしているけれど）再起動が必要です というステータスでした。
・Windows 10 Insider Preview 16278.1000 (rs3_release)
・2017-11 x64 ベース システム用 Windows 10 Version 1703 の累積更新プログラム (KB4048954)
更新サービスに接続できませんでした。後で自動的に再試行されますが、今すぐ手動で確認することもできます。この問題が引き続き発生する場合は、インターネットに接続していることを確認してください。
日本語フォーラムを見つつ、以下の作業を行いまいしたが改善しませんでした。
https://answers.microsoft.com/ja-jp/windows/forum/windows_10-update/windowsupdateで更新が/745a1c4c-4c92-481e-b5ac-39ae55cd7139
Windows 10 - Windows Update に失敗する場合の対処法
方法 1 : トラブルシューティング ツールを実行する
方法 2 : BITS トラブルシューティング ツールを実行する
→ エラーで終了
Q:Windows 10 Service Registration is Missing or Corrupt
のレジストリ対応（上記）を試したところ、正常にWindowsUpdateができるようになりました。
OS 名: Microsoft Windows 10 Pro
OS バージョン: 10.0.15063 N/A ビルド 15063
OS ビルドの種類: Multiprocessor Free
[01]: Intel64 Family 6 Model 142 Stepping 9 GenuineIntel ~2611 Mhz
BIOS バージョン: Microsoft Corporation 231.1737.770, 2017/06/09
ホットフィックス: 3 ホットフィックスがインストールされています。
[01]: KB4022405
[02]: KB4048951
[03]: KB4048954
誰かのご参考に慣れば幸いです。
情弱というよりはマシンを扱えないという話になってくるんだけど
自分はWindowsが好きでOSはWinをずっと使っている。
携帯だけは学生時代に「安いから」という理由で一家全員でiPhoneに機種変をしたので、AQUOSAndroidを一台使って以降は5sからずっとiPhoneだ。
さてここからが問題なのだが、家族が全くMacOSを使いこなせていなくて本当に辟易する。
我が家には父親の購入したiMacがあり、自前のPCを持っている私以外は全員iMacでiPhoneを管理している。
機種変する度に
「増田、なんかわかんない！データ移行ちゃんとできるかな！？」って父母妹3人からくる。
父に至っては自分がユーザー名とパスワードを覚えていないのを棚に上げてAppleに問い合わせる情弱ぶりなので本当に恥ずかしい。なんでMac買ったの。
まあもとより母、妹はPC触らないので仕方ないとは思うんだが、父が自分でトラブルシューティングできないのは問題だと思う。
先日も機種変してiTunesで同期をしようと思ったら、MacOSのSierra(?)への更新が入って、管理者の名前とパスワードが分からないと丸2日悩んでいた。
なんでMac買ったの(2回目)
結局その問題は私がその一回前の機種変の似たようなトラブルシューティングを思い出してものの10分で解決したんだが、いい加減誰か一人は使いこなせるようになってくれ。
この間は「webページからクリックポストの伝票印刷したいんだけど印刷ページが出てこない！」って騒いでた。
ポップアップブロック解除で1発だった。
Appleユーザじゃないのにメインで使ってる家族より使えるんだけど。
https://anond.hatelabo.jp/20180127211654
上記の増田見て自分で常日頃思ってることをなんとなく書いてみる。
社内SEの新人がよくやらされることになるサポート業務という名のトラブルシューティングなんだけど、
個人的に思うのは「トラブルに遭遇してそれを乗り越えてきた人でないとやる意味が薄いのではないか？」という事。
もしホントに社内SEで新人が入ったなら、トラブルシューティングなんてやらせても
トラブルに遭遇してるエンドユーザーと一緒に悩むことしかできず、結局教育係が手取り足取り教えることになる。
教育にコストがかかりすぎる割に間違った方向に進みやすいのもヘルプデスク業務の難しいところ。
碌な基礎知識もなくいきなりトラブルシューティングを任されると、大抵の新人は
場当たり的な対応しか身につかず、そのトラブルがなぜ起きたのかという根本の原因を探ることができない。
なぜならトラブルシューティング担当にはひっきりなしに問い合わせが来るからだ。
前に片付けた問題で浮かんだ疑問は他の案件を片付けながらなんて調べられないし
そもそも何かを学べるような問い合わせばかり来るわけではないからだ。
というか、問い合わせの8割ぐらいは「みんなパソコン苦手なんだな」っていう知見しか得られない。
そして1割5分ぐらいは「根本的な解決をする金がない」という知見しか得られない。
残りの5分ぐらいはその後のトラブルシューティング係として身になる知見が得られるが
その5分を当てにしてトラブルシューティング係を続けるとトラブルシューティング以外の経験が積めなくなっていく。
トラブルシューティング係として有能になればなるほどトラブルがそいつに集中するようになるからだ。
トラブルシューティングから得られる知見は他の社内SE業務でも問題なく得られる知見であり
ほどんどの先輩はそれがわかっていて、誰もやりたがらないけど誰かがやらなければならない仕事を新人に押し付けている。
だから、個人的に自分が思うのは、トラブルシューティング係は定年間際の年長者がやるべきだと思っている。
基礎も学んで、様々なトラブルに見舞われながらも定年間際まで生き延びてきた生き字引の皆さんなら
ユーザーをなだめすかしてヒアリングする事も、トラブルの解決策も自身の経験から行えるだろう。
そしてシステム更新のリリース当日に休日出勤なんていう面倒なことは経験を積むために後進に任せて
ゆっくり休んでくれればいい。
とにかく、新人を経験必須のトラブルシューティングにいきなりぶち込む、なんていう無駄な教育をやる企業がこれ以上出てこないよう祈るばかりだ。
そもそも、経営者とエンジニアに求められる資質が１８０度真逆。
その違いは、仮説と事実の扱い方において顕著。
エンジニアに求められる能力は、仮説と事実を切り分ける能力。仮説と事実の切り分けがないトラブルシューティングは目も当てられない。
いっぽう経営者に求められるのは、仮説を事実と思い込める能力。かの有名なスティーブジョブズの「現実歪曲空間」は、それを裏付ける好例。
彼の思考の熱量が現実を凌駕し、多くの人の心を動かす。だがこのとき、現実は歪曲されているため、必ずしも事実に沿ってはいない。
生物系の研究室で、捏造が生まれるきっかけを見てしまった。その研究室のPIは研究不正とは程遠い性格で、PIに悪意がなくてもこういう状況だと捏造が起こりうるんだなということを目の当たりにしたので、ケーススタディとして書き記しておこう。
PIは専門性に合わせて分業させるタイプであったので、複数の研究テーマにおいて、上流のこの解析はXXさん、中間はYYさんがやって、下流はZZさんが、という風に割り振られていた。その中で、最も上流の過程を担当しているXXさんは、外部からの仕事も含め、大量の仕事に追われて疲弊していた。性格的にNoと言えずに萎縮しやすく、タスク管理が苦手で、積み重なった仕事で完全に首が回らなくなったXXさんは、とうとう、プレッシャーに負けてしまい、やっていなかった予備実験を「やってうまくいった」ということにしてしまった。
XXさんがやろうとしていた実験系はあまりうまくいっていなかったが、元々難しいことが知られている系であったので、判断が難しかった。PIはXXさんが基本的なトラブルシューティングはしているものだと思い込んでいたところが不幸の始まりであった。PIは、XXさんの問題ではなく現象特異的な難しさだとひとまず判断し、本番で下流の実験系（他の複数の人が担当）まで一通りやってみろという指示を出したが、うまくいかなかった。その後、研究室内で問題点を一つずつ洗い出していったところ、結果的に上流過程にも遡り、予備実験のポジコン/ネガコンすら取れていなかった事が判明した。研究の組み立て方も行き当たりばったりでおかしかった。その事実にたどり着くまでが大変だった。忙しい事を理由に実験系の組み方や実験ノートが複雑怪奇になっていて、本人もよくわからなくなっていたこともあり、なかなか基礎データが出てこない。ようやく出されたデータを根気強く追っていくと、さらに別の不自然な点が発覚する。そうなるとPIの叱責を受けたり、他のメンバーに追求される。検証のための追加実験を命令されたXXさんは、実験がうまくいかずに次のプログレスまでにやりきる事ができなかったが、データがないと再び怒られると考えて自分に不利益な結果を隠そうとし、ネガティブなスパイラルに嵌っていった。PIは問題のデータのあぶり出しも「信じたくない」という心情が先で対応が後手後手になったように思う。PIの対応はXXさんの不正を導いていたが、PI自身は無自覚だった。純粋にデータの不完全さだけを気にしていたら、こうはなからなかったかもしれない。ある時、PIがこれは本気でヤバイ、と気づいて、ようやく修正軌道に乗った。
それなりにお金を費やし、関わっていた人々の４年間は無駄になったが、これを放置していたら、と思うとゾッとする。共同研究先には「なにやら忙しくて大変そう」とは思われていたものの、そこまで大ごとだとはバレていないようであった。この研究テーマに関しては膿は出し切ったと思うので、本人もそれなりに反省したようだが、その後のことはわからない。こうなるとこれまでのXXさんの仕事ぶりも気になる。後日、XXさんのかつての所属先の人々にそれとなく愚痴ったところ、やはり似たような問題があったんだなと思わせる雰囲気であった。三つ子の魂百までとはいうが、更生できるのもまた人間だ。XXさんはその分野で有名ラボ出身者であったこともあり、◯◯先生から信頼されている愛弟子で、学振取得者で、と周囲から一目置かれていた。研究の世界で底辺の争いに生き残るにはどうしたら良いか、考えさせられた経験だった。
こういう記事があると、ネット上では「自分のいる環境ではありえない、実験ノートはこう書いてほにゃらら」という人が湧き出てくるのだけど、自分自身はいざ知らず、共同研究者がこういう人だというケースだったら足下を掬われるかもね、と思う。世の中には、悪意を持って研究不正に取り組んでいる研究室もある一方で、この研究室は事件が起きた時の対応の仕方には問題があったけれど、元々真面目に研究する人ばかりだった。XXさんの性格や研究室の状況が掛け算になった結果、他の研究室より不運な方向に転がってしまった。世の中の多くの研究室には大なり小なり似たような課題が潜在的にあるかもしれない。自身の心がけや予防法だけではなく、事件が起きてしまった時にどうするか、というロールプレイングまでしたら良いかもしれない。
＜ PIとしての教訓 ＞
・メンバーを疑うと思うと辛いが、データで冷静に議論できる環境を作る事を心がける。感情は抑えて、相手がネガティブデータでも相談しやすい空気を作る。
・PIという上下関係がある以上、自分がどんなに「フラット」に接しているつもりでも、相手はプレッシャーに感じているかもしれない事を忘れてはいけない。
・生物系にありがちな、専門性に合わせて分担する系の研究テーマがある場合、博士課程院生やスタッフについては、自分の制御可能な範囲での研究テーマを推進できるように環境を整えておく事が万が一の保険になる。不正行為に対して、巻き添えを食らった人々の将来を担保することもPIの大事な責任である。
・メンバーの業務量がオーバーフローしていないか注意し、個人の性格に基づいて、それをコントロールするのもPIの責任である。
・同僚を疑うと思うと辛いが、我々はデータ教信者であるので、心情はひとまず脇に置いて、データで冷静に議論する事を心がける。
・捏造を暴くのは憔悴するので、不正に気づいた時点で、自分へのダメージとどの程度深入りするかの対応をよく考えたほうがいい。手を引けるなら手を引く。また不正をしているメンバーがいる事をPIに忠告しても聞き入れてもらえない事がある。したがって、いつでも静かにさっと撤退できるようにしておく。研究室で分業制を敷いている場合には、自分の制御可能な範囲での研究テーマを推進し、業績に影響が出ないようにする。（博士過程の学生の場合には、そもそも分業しないほうが良いが）
「パラノイアRPGにおける。一般的にそうだと信じられている間違った理解と。そのツッコミ。」
http://togetter.com/li/1016711
上記記事内におけるツッコミに、あまりにもルールブックの記載とかけ離れた記述があるようでしたので指摘を。
＞他のPL達の反逆を暴き処刑することで、成り上がっていくゲームです
まったく違います。トラブルシューティングするゲームです。
パラノイアにおいてトラブルシューティングとは反逆者の処刑のことであり、ミッションの達成自体は重要視されません。
ミッション遂行に必要であるために反逆者を処刑するのではなく、反逆者を処刑することがトラブルシューターの目的です。
トラブルシューターを任ぜられたPCの目的 (=PLの行動指針) は 1) 生き残ること 2) 成り上がること 3) その他個人的目的 となります。
反逆者を処刑しコンピューターの信頼を得られればセキュリティクリアランスは昇格します。（昇格したキャラクターをプレイする機会があるかはさておき）
(ルールブック p3)
(ルールブック p158)
パラノイアでは、ミッションは必ず存在してはいるものの、（コンピューターを除いて）誰もこれを真剣に捉えていません。これにはもっともな理由があります。大抵のミッションは自殺祭りや当てのないボット探し、プログラムエラー、あんまり込み入っていて意味不明なんで GM も解っていないような陰謀といったものでできています。PC がミッションの目的を達成する事が期待されていなかったり、そもそも許されていなかったりする事もよくあります。PC が目的を解っていない事だって珍しくありません。ホラーアドベンチャーが玉葱を慎重に剥いていくものだとすれば、パラノイアのミッションは玉葱をレーザーで燃えカスにするようなものです。
(ルールブック p10)
こういった義務の他に、君のトラブルシューターには個人的目標がいくつかある。多くはアルファコンプレックスの市民なら皆持っているもので、大抵の市民は以下の様な優先順位をつけている。
1. 生き延びる！
3. 金持ちになる。
こういう普通の目標のほかに、他の市民とは違った目標を持っているかもしれない。
5. （任意） 自分と同種の能力を持つミュータントを見つけ出し、保護する。
6. （任意） 旧算世界の遺産を見つけて、集め、あるいは転売する。
パラノイアのキャッチコピーは「気を抜くな！誰も信じるな！レーザーガンを手放すな！」ですね。
PC間の不信と裏切りを助長するのがパラノイアのGMの仕事です。
(ルールブック p42)
(ルールブック p42)
何かやったプレイヤーにご褒美をあげれば、その行動を繰り返すでしょう。ですから、仲間のキャラクターを裏切ったり、死の罠から賢くも逃げおおせたり、創造的であったり滑稽であったりしたら、ご褒美を出します。本当に輝かしい動きをしたキャラクターには成功と昇格を与えましょう。輝かしい行動には常に報酬を！
好きにしていいんですが。
(ルールブック p42)
GM 用ルール第一条。全てを預かるのは貴方であり、貴方は常に正しいのです。我々がここに示すルールはあくまでガイド、ゲーム中に何を起こしたいか決まってないときに使ってください。起こしたいことが決まってるならルールは無視してください。我々は貴方のお役に立てるパワフルな道具になるよう全力を尽くしてルールを書いておりますけれども、どうもこのルールが気に食わないということでしたら、間違ってるのはルールの方です。良いルールは貴方を大いに助けてくれるでしょう。でも悪いルールというのは、叩きのめし、拷問にかけ、ロボトミー手術を施し、即時処刑にかけるためだけに存在するものです。
ただこのあたりは、本当に「ＧＭがヒャッハーするゲーム」という誤解があったり。ルールを出来る限り適用しようと努力する（全部守れと言ってるわけじゃないです）ＧＭが他システムより少ないので。
「そのＧＭ、信用できる？」ってところに尽きるんです。
パラノイアでは、GMがルールに則り公平に判定していると信用される必要はありません。もちろん、GMがPLを楽しませようとしているということについては信頼される必要があります。
(ルールブック p42)
貴方が何を起こしたいか決まっているなら、（プレイヤーに見せずに）1d20 を振り、出目を無視します。必要なら、いろいろな表と結果を照らしあわせている体を出すのも有りでしょう。そうして、起こしたいことが起きたことにします。
ダイスという道具は、プレイヤーに自分自身で運命を決めているような幻想を持たせるには便利なものです。こういう幻想は良いものではありますが、でもダイスを振るときはプレイヤーの視界から隠し、ついたての後ろで振ると良いです。気に入らない目が出たら、それはダイスが間違ってます。好きな出目に変えちゃいましょう。出目に関する信用が減耗したり完全にお亡くなりになったりするかもしれませんが、経験から申し上げれば別段たいした影響はありません。
TV/Web会議をはじめとしたITによるコラボレーションツールがこれだけ充実・高度化した現代でも、人は出張する。理由は明確で、物理的に現地にいる必要性はなくならないからだ。面と向かって討議しなければならない込み入った話であったり、現地での署名や式典など儀式的な意味合いがあったり、または「わざわざ日本からそちらに行く」ということで事の重要性を訴えるパフォーマンス的なニュアンスを含んでいたり…と、その必要性はさまざま。
特に中間管理職の場合、出張には大きな投資とリスクが伴う。投資とは、移動や事前の段取りなどの時間的なもの。リスクとは、日本の仕事から一時的に離れなければならないところ。
この内、後者については信頼できる部下さえいればさほど心配すべきことではない。だが、自分が不在時でもその部下に日本での仕事を任せきることができるのであれば、そもそも自分は日本必要はない。ダブルで管理体制を悠々と構えさせてもらえるほど会社も甘くはなく、常にギリギリで回せという体制図になっていることがほとんど。
そのため、自分が日本の仕事から離れるというリスクは、前述の時間的な投資で軽減を試みることになる。王道は出張期間中の部下の仕事を可能な限りTo-do、つまり「やるだけ」の状態にする。その上で発生する問題は、極力部下たちで自律的に対応・解決してもらう。ワークフローシステムなどの「型」が必要な承認以外は、彼等に決めてもらう。ただし気を付けなければならないのは、このTo-do化をやりすぎると部下は「そんなに心配(＝私達を信頼してない)なんですか？」と思われること。だから部下の部下にまでは指示はしない。「だいたいこんな感じで！あとは頼んだ！」程度。ここで結局のところ問われるのは、当本人が部下に寄せる信頼に裏打ちされた「任せる勇気」なのかもしれない。
このように「自分は本当に出張に行って大丈夫か」を確かめるのと並行して、出張自体の段取りに入る。
まずは航空券。会社によっては決まった代理店を使うことが多い。これはアシスタントや秘書がいたら任せるのもいいが、自分でやったほうがよい。出張のスケジュール詳細と航空券の調整を並行するのが一番効率がいいからだ。出張中の打ち合わせ＞その他の人と話す時間(公式の会議とは別の声掛けや激励)＞日本の状況を気にする時間＞自分の作業時間(まとめ/ラップアップ資料作成など) の優先順位で、発券期限ギリギリまでスケジュールを綿密に詰める。ゆるいスケジュールだといたずらに出張期間が延び、狙った成果も出ない。そうは言っても、夜は必ず空けておく。大抵なんらかの誘いは来るし、自分の作業時間がつぶれた場合のバッファにもなるからだ。
はじめていく会社、またはお客さん/クライアントではファシリティ面も注意したい。作業場所、Wi-Fiなどの兵站系は向こうでバタバタするほど無駄なことはない。数回行っている拠点/支社なら、総務・情報システム系の人と仲良くしておきたいところだ。それ以降、直接的にトラブルシューティングもお願いできる。
ここまでは、誰しも部下や後輩を持ちながら出張する人なら普通に考えていること。ここからは部下のみならず上司もいる、中間管理職特有の話。
中間管理職は、誰か偉い人の右腕的なポジションで出張に帯同することもある。でも基本、他の誰かで済むならこういう出張は断る。その断り方はその上司との関係にもよるが、自分の場合「絶対行けないわけではないですが、たちまちアノ仕事がこのくらい遅れそうですね、あとコノ仕事はこれくらい質が下がりそうですね」とか返している。「うわ、なんかめんどくせーこいつ」と思わせたら勝ち。回避した後「ご一緒できなくて残念です点帰ったら色々お土産話聞かせてください、帰国日にどこか日本食でも予約しときますよ」とした上で、自分の身代わりとして犠牲になった人もあわせて誘っておくまでがセット。2次回はその犠牲者とサシで。テンプレだとバレていても、断ったことに見合う仕事を日本でしっかりとして、帰国後に彼等をねぎらえばいい。
上司帯同型の出張には、上とは逆に、自分の出張に上司がオマケでついてくるというパターンがある。本当に必要なときはこちらから言うのに、「ここは俺がいないと始まらんだろう」と言わんばかりにしゃしゃり出てくる。バンコクや一昔前の広東地方など夜の世界が充実している地域に行くときはとくにそう。さすがにこれは向こうからオファーしているので、「いえ、来なくていいです」などと無碍に断りにくい。それがゆえにこのケースは本当に面倒くさい。とはいえ、それ逆手にとる方法もある。ややこしい会議、言い換えれば程度権威をもって場を制することが必要な会議を予定にねじこむ。そしてそこだけに意識を集中してもらう。当然シナリオもこっちで用意する。使えるものは「親」でも使うスタンス。
だがこれには大きな代償がつきまとうことが多々ある。経験上では、しゃしゃり出てくる上司に限って、出張に不慣れなことが多い。移動中やたらと街中で立ち止まって写真を撮りたがる。反スパイ法がいまだ絶賛プロモーション中だと考えられる中国ではやめてほしい。安全面もそっちのけ、南米なのに財布がポケットから見えてたりとか…。たまに今夜は別行動で…とか言うと怒る/すねるのも勘弁してほしい。出張に来ると毎晩飲み会だと思ってる。じゃあ日本で毎晩飲み会してるのか？と。昨晩の夜の世界での出来事の反省会をオフィスでやるのもやめてほしい。
こういう上司は、頭のどこかで出張≒旅行と捉えている。発想からして狂っている。また、こういう上司は最上部に書いた部下の仕事は全然ケアしてないから、社内クレームがひとつ下の上司に、つまり自分にやってくる。そして出張前の各種調整なども日本と現地のアシスタント同士に任せっぱなしだから、いざ現地についてあたふたする。挙句の果てには文句を言いだす。フライトが朝早いだの、空港ラウンジが遠いだの。
もちろん、これはすべての上司がそうというわけではない。あくまでひとつの傾向。だがかなりの割合でこうなのも事実。対応は唯一、現地の駐在員をお土産で買収する。出張前にリクエストを募り、それを現地到着時に進呈する際、「じゃあ夜はあのおっさんの面倒頼んだぜ」とする。夜のアテンドは現地駐在員はお手の物、餅は餅屋。
よく本などでは「上司は部下の下僕」と言う。こんなこと書いている本は読んで理解はできるが、体現するのは難しい。だから自分がそういうポジションになったとき、少なくとも部下の足を引っ張るような存在にはならないようにと、上記をメモっておこうと思う。
大学の一般教養でPascalを習った程度。専門課程に入る前に文法はすっかり忘れた。専攻は都市工学だからその後プログラミングとは縁はなかった。卒業前に第一種情報処理技術者の資格だけはとれてたのでプログラミングの何たるかとかオブジェクト指向なんかも知識としては知ってた。
大学卒業後にデスクトップユーティリティーのメーカーで技術営業をやった。顧客に製品仕様を説明するのが主な仕事なのでパワポばかり使ってた。その会社ではLinuxのソフトも販売してたから、Linuxのコマンドは打てるようになった。そこでシェルスクリプトを習得しようと思ったがあえなく挫折。
その後ネットワーク機器のメーカーに転職。トラブルシューティングでLinuxをさらに使うようになった。そこではHTTPプロキシを主に扱っていたので、HTTPプロトコルについては一通り知識を身につけた。その知識を実際にLinux上でシミュレーションしてみたくなり、Cを習得しようと思ったがやっぱり挫折。
部署移動でメールサーバーを扱うようになった。SMTPプロトコルの知識は身についた。ここでもSMTPをLinux上でシミュレーションしてみたくなり、こんどはperlを習得しようと思ったがやっぱり（ry
今はExchangeを扱ってる部署で働いてる。ここではExchangeメールのメタ情報をMySQL上で扱ってるから、SQLのSELECT文くらいは見よう見まねで使えるようになってる。
そんな俺も部下を持つようになり、デスクワークの時間が増え、比較的自由な時間が持てるようになった。そんなときにはてブでみかけたCoursera(https://www.coursera.org/)で本当に偶然に「初心者のためのプログラミング」というコースを見つけた。
Programming for Everybody
https://www.coursera.org/course/pythonlearn
コース自体は英語だが、別に教授と会話するわけではないし、Python文法以外は条件分岐や繰り返しといった過去に挫折しながらも知識としてだけはぼんやりと覚えていたことの繰り返しだ。英語が少しくらいわからなくても、図を見ていれば何を解説しているかくらいはわかる。
結論から言えば、このコースを受講したおかげでいままで断片的に持っていた知識 -単語だけは知っていた「オブジェクト指向」、「条件分岐や繰り返し」「アルゴリズム」などなど- がパズルのピースのようにかっちりと組み合わさり、Pythonが難なく習得できた。いままでにシェルスクリプトやCに挫折したのがウソのようだ。Linux、HTTP、SMTP、SQLといった周辺知識も余すところなく役に立った。何のことはない、Pythonの標準ライブラリを使えばHTTPやSMTPのシミュレーションなんて簡単にできたのだ。以前トラブルシューティングで夜中まで手作業でちまちまやっていた作業は、全部Python一発で解決したんじゃないか。
このコースをきっかけとして、俺の人生（といってはおおげさだが）が大きく変わった。小さいところで言えば、自宅PC上でバックアップにつぐバックアップでわけのわからなくなったフォルダ構造の中から、同一のファイルを探し出し削除できるようになった。（傍から見れば何を大げさなと思うかもしれないが、ここ10年くらいの俺の中で最大の懸案だったのだ。）仕事でも日次で発生する業務をバッチ化したり、繰り返し発生する手作業を全部Pythonで自動化した。（経営陣へのレポート作成とかそんな類のものだ。）おかげで残業どころか定時前に帰宅できるようになり、自由な時間はさらに増えた（笑）
ひとつ言語を習得してしまえば、あとは同じことの繰り返しだ。増えた自由時間を利用して、いまはPHP、JavaScript、jQueryを身につけて何かWebサービスを立ち上げようと目論んでいる。出来上がったら、またここでそれまでの道のりを紹介したいと思っている。
こんなことが自分の身に起こるとは、1年前の自分には想像すらできなかっただろう。それまでは「Webサービス」なんて言葉は自分とは一切縁がないと思っていたから。
欲を言えば10年前、いや5年前でもいいからこのコースに出会ってPythonを身につけていたら、今とはまったく違った人生を歩んでいたかもしれない。
コースを開講した教授との相性もよかったのだろう。彼の人柄にも好感をもてたし、「for Everybody」というだけあって、非常にわかりすい説明だった。英語だということを差し引いてもこのコースはおすすめだ。
たくさんのコメントありがとう。こんなチラ裏の文章がホッテントリ入りしてかなりびびっている（笑）
いくつかのコメントに返答したい。
こういう反応があることは投稿したときに予想はしていた。だが、何がきっかけでプログラミングを身につけたのかを具体的に書かないと、何の役にも立たない本当のチラ裏になってしまうので、コース名を書くことにした。だがこのコースをはてブで見つけたのは単なる偶然だ。このとき見つけたのがドットインストールのRuby講座だったら、Coursera→ドットインストール、Python→Rubyになっていただけのことだ。ここで言いたかったのは、断片的でも一度触れたことのある知識は後になってどこで役に立つか分からない、ということだ。Steve Jobsも言っていたが、「人生を振り返ったときに点と点をつなぐことはできるが、その点がなんの役に立つかをあらかじめ予想することなんてできない」ってやつが自分にも起こった、それだけのことだ。
なお、Courseraのこの教授は自分の授業内容をすべてオープンにしている。http://www.pythonlearn.com/ 教科書さえもここで無料で手に入る。Courseraに登録するのに抵抗があり、自習上等という人はここで俺が受けたのとまったく同じ内容を確認することができる。ちなみに授業はすべてYoutube上で公開されている。
これについてはまったくその通りだ。ただ、もう新たな言語を覚えることにまったく抵抗がなくなったのと、PHPとRuby on RailsがWebサービス界ではメジャーらしいので、とりあえずPHPもやってみよう、くらいの軽い気持ちで思いついただけだ。ひょっとしたら実際にはPython+Djangoとかで開発するかもしれない。
長文につき失礼します。
お互いに照れくさい気分になりながらも雑談した。
当時は子供だったと思っていたけど、今見ると女子高生だろうか、
そうだ、あの頃はそんな仕事していいたな
昔話になるが、新卒で入った糞みたいなブラック企業を辞めて完全にモンスターを狩猟する仕事をしていた。
両親は怒り狂っていたが、俺は頑なに精神病だの言って回避していた
したら、丁度良いって話になった。細かい話は後述するけど、俺は実は器用貧乏だ。水道の出が悪いとかPCが壊れたとか、トラブルシューティングを主にやっていた頃もあったからってのがよかったらしい。
どうも自治体で人を雇って便利屋さんみたいなのに活躍してもらうって話だったらしい。
実際の仕事は、なんだろう。ワンボックス乗って町内を適当に走る。そうすると、町民が良いところに～～！って声かけてきて乗り込んで送ってあげる。無料でね。
後は事前に連絡貰えれば車の送迎とか、家電の調子が悪いとか、PCの使い方がわからないとか、スマフォに切り替えたんだけど意味不明だよ！とか
色々あったけど、それなりに対応していた。ぶっちゃけ給料は糞安いんだが、食べ物貰ったり、ここは日本の糞田舎なのにチップみたいな感じで、「これとっといて」とかでお金貰ったりしてたなぁ
で、一日中そんな事をしているわけじゃなくて、ベース基地は交番。
田舎の交番なんて場所も悪いし、外出してる時にある程度色々できて、車も出せる自分がいてくれたら助かる～って事で
何故よく交番に来ていたのかは本人曰く「学校にいれば同年代の人はいるけど、地元じゃ一番若いの警備員さんだから」って感じで話し相手になって欲しかったらしい。
まぁ自分も女子中学生に何も感じない、ちょっとした妹ぐらいだ。場所も交番だし、警備員としてそこそこ顔も広かったから両親も何も言わなかったようだ。
（br)
再会しても、どうしたもんかな。私も彼女も上京してきて、出会ったわけだけど、私は自分をもっと奮い立たせる為だったけど
彼女は本格的に水泳部を続けたくて両親に反対を振りきって上京して、今は生活費の為に部活も忙しいけどバイトもしなくっちゃ！って満面の笑みでいった。
心苦しかった。彼女は笑っていたけど、私も奨学金あったりするので、そういうのがどれだけ辛いかはわかるつもりだ。
何か、私が役に立つことはないか？と言ってみたけど、なんもないです～って言われてしまう。
手前味噌だが上京してから色々あって、一部上場企業のコンサルタントなんかしていて、年収は決して低くはない。
でも、この子は固いというか両親の教育がいいのか、意味もなく人に施しを受けるのが嫌いなのだ。
だから何も言えないから、彼女が大好物は寿司だと言うから回らない寿司に行った。
案の定彼女は「こんなお店はちょっと・・・」って言ってたけど、もう気にしない。高いネタばんばん頼めばいいの。
あの頃は確かにお金なかったけど、今はもうこれぐらいは余裕で傲れるんだから、遠慮されるとこっちが心苦しいよ。だから奢らせて。
一応納得したようだ。
そろそろ帰らないと不味いなって時間になったので、送ってくよって言ったんだけど
今まで以上に断られてしまった。それは無理にストーキングするのもちょっとな・・・って思ったから
やっぱり何かに悩んでいたようだ。
私はアラサーなので女子高生に好意を寄せるのはいけない事だと思っているけど
でも、彼女の眩しい笑顔を見るたびに、その思いは揺らいでいく。
10年くらいWeb開発業界にいて、ここ最近はRailsでアジャイルな高速開発的なものの周辺にいる。今は開発者〜マネージャの間を行き来しつつ顧客窓口〜実装まで一通りこなしている。
あちこち渡り歩いて色々なエンジニアと一緒に仕事をしたり、お客さんに頼まれてエンジニアの面接やらに顔を出したりすることがあるのだが、ここ最近のWeb開発はますます主力級のゴリゴリ書けるエンジニア（いわゆるフルスタックエンジニアと呼ばれるものも多分ここに入る）と大したことのないエンジニアの差が開いてきたように思う。
主力級のエンジニアは1〜2回がっつり打ち合わせしてプロジェクトの重要点とざっくりラフなイメージを共有すれば、どんなに遅くても1週間もすればプロトタイプが上がってきてお客さんに見せつつ微調整し、いわゆるアジャイルとかスパイラル開発的なことができる。デザイナがいなくてもBootstrapでとりあえず最低限の見た目を作ってくれるので、とりあえずデザイナ無しで開発して最終的にお客さんが気に入らなければWebデザイナに見た目整えさせてテンプレ取り込み、という開発がここ最近のメイン。
ソースコードもフレームワークやRESTfulの基本概念が理解されているコードなので、後日の機能修正の時にそのエンジニアが動けなくても自分がフォローして修正することもできる。
仕事もしやすいし、実質1〜2人の稼働でサクサク進められるのでコミュニケーションロスもなく楽しい。
一方、大したことないエンジニアは前述した流れが全くできない。
まず決定的なのは、開発が遅い。ちょっとしたデザイン無しのCMS（リッチUIなし）をRailsで書くのに1週間かかっても終わらなかったりする。これじゃ生PHPで書くのと変わらないかそれより遅いので、Rails使う意味がない。
次に、品質が低い。できあがったと言われて念のためチェックすると、基本的なCRUDレベルでエラーが出たり、お客さんに見せるプロトタイプだと言っているのに初期データ（seeds）の整備すらされていなかったりする。本人のローカル環境で動いてるけどstaging環境にdeployすると動かないとかはよくある。
パッと見に分からない部分もひどくて、ソースを確認すればあちこちどこかからコピペしてきたコードのつぎはぎで、HTML規約違反やJavaScriptのエラーまで放置されていたり。あと実装しましたと口頭で言っていた機能がソースコードコメントではTODOになっていたこともあった。
最後に、成長しない。開発上詰まった所なんかを主力級エンジニアに聞くのは構わないのだが、表層的な理解に留まり応用が利かない。30分〜1時間も主力級エンジニアの時間を浪費しながらもまた同じ様なところで同じ様なミスをする。自分もよくプチ勉強会みたいな状態になったときには参考図書や技術資料のポインタを投げたりしているのだが、参照先を見て深掘りすることはほぼない。
厄介なのは、こうした大したことないエンジニアも、Railsであればあちこちのチュートリアル記事や書籍を参考に、そこそこそれっぽく見える自作サービスくらいなら作れてしまうという点にもある。
彼らの作るサービスはまさに書籍やチュートリアルサイトのコピペの集大成だが、個人が趣味でやっているサービスとしては十分に動く。そして周りには「エンジニアです。個人でWebサービスも公開してます」となる。サービスの外からは内部のコード品質などはわからない。
プライベートで開発するのはむしろ奨励しているのだが、彼らはその拙い（あえて「拙い」と書く）サービスでもって「俺はもういっぱしのエンジニアだ」と勘違いしてしまっている様に思える。
だが違うのだ、お前が書いているシステムは「とりあえず動く」レベルのものであって、受託開発としてお金をもらってお客さんに納品するシステムや、数千万〜数億の売上を左右するような業務システムではその素人クオリティでは話にならないのだ。
適切な例外処理、担当者がミスしにくい管理画面の設計、お客さんの想定ユーザ数に耐えられるレベルでのスケールする設計、開発者が入れ替わっても保守が続けられるようにするための最低限のドキュメントなど、production level qualityに足りていない部分がいくらでもあって、そこまで考えられて「主力級エンジニア」なのだ。
こうした主力級エンジニアと大したことないエンジニアの谷は以前から感じていたが、ここ最近ではさらに顕著に感じるようになってきたように思う。
例えば、主力級エンジニアはRailsだけでなくミドルウェアやprovisioning（chefとかansible）、最近ではdockerやCI、AWSの新サービスなどについても各自追いかけていて、自分も含めてちょいちょい議論をすることがある。「最近のアレってどうなん？」とか「はてブでやたらXXX流行ってるけど、これって結局数年前のYYYの焼き直しじゃん」みたいな。
そんなところに大したことないエンジニアもはてブやRSSなどで用語は聞いたことがあるので混じってくるのだが、まず前提知識がなさすぎて議論にならない。大体「XXXマジすごいっすね〜（意訳）」で終わっていて、その技術の背景や今後どうなりそうか、自分達が取り入れることで業務効率や開発の楽しさが改善するのかといった視点がない。
他にも、ちょっとしたトラブルシューティングの際も、基礎がなさ過ぎて問題の切りわけができない。問題の原因がネットワークレイヤなのか、ミドルウェアなのか、アプリなのかすら判断できなかったり、そもそもアタリを付けるのが絶望的に遅かったり勘が悪い。
単に作業が遅いというのではなく、問題の切りわけというエンジニアとして最低限できないといけない事すらおぼつかないケースも見かける。
こうした大したことないエンジニアは速度・品質・難易度面で新規開発プロジェクトにアサインするリスクが高いので、必然既存サイトの運用・メンテ（ちょっとしたページデザインや文言修正）といったタスクが回されるのだが、最近この辺りも仕事がなくなってきているように思う。
というのは、お客さん側にRails Tutorial程度の開発知識を持っている元エンジニアや趣味でちょっと触ってみましたレベルの人が増えてきたから。これは恐らくRails特有な所（自作Webアプリ簡単に作れる啓蒙がなされている）がありそう。
ちょっと考えてみれば、文言修正やデザイン修正する程度の作業、外注に頼むと数万かかる上に見積やら稼働確保やらで数日〜数週間待たされるのに対し、担当者が自分でやってしまえばすぐに済む話というのはちょっと考えれば分かるわけで。
# もちろんそれでも保守契約や責任分解点の関係で外注するケースはあるだろうが、Railsを採用するようなWebサービスは速度重視のことが多い
そんな中、この「大したことないエンジニア」の人達はどうなるんだろうなあ、と思う。開発会社ではなくRailsシステムを運用しているユーザ企業に行けば多少は需要あるのかなーとも思うけど、ユーザ企業はできないエンジニア雇うほど余裕もないだろうし。
せめてコミュニケーションスキルが高いとかそういう利点があればいいんだけど、変に自分が「エンジニア」というプライドがあるのか、窓口とか管理方面は率先してやろうとしなかったりもするし。
早めに「エンジニア向いてないよ」と言ってあげるのが良いのだろうか？
ImageJ用のプラグインを書くために、デバッガを設定してコンパイルする方法まとめ。
大部分はtotobookさんのブログを参考にしたけど、３年半経つと変わっているところも増えるらしく、ちょこちょこ必要なステップが増えていた。
totobookさんのブログ: http://d.hatena.ne.jp/totobook/
ちなみに、書いたプラグインはITCNという自動細胞計測プラグインを拡張し、作業フォルダ内の画像をROIごとに全自動で計測し、結果をテキストファイル保存するというもの。
ITCN: http://www.bioimage.ucsb.edu/downloads/automatic-nuclei-counter-plug-in-for-imagej
(ア) http://d.hatena.ne.jp/totobook/20101028/1288277567
(イ) http://d.hatena.ne.jp/totobook/20101030/1288468881
(ア) これをしないとjava.lang.ClassNotFoundExceptionが出てくる
(イ) NetBeansになんか言われるけど無視。コンパイルは通る。
① http://support.apple.com/kb/dl1572
(イ) ツール＞Javaプラットフォーム から、プラットフォームの追加でJava1.6を追加する。フォルダは探してください。
(ウ) プロジェクトの一番上（今回はImageJ）を右クリック＞プロパティ＞Javaソースのクラスパス Javaプラットフォームを、JDK1.6にする。
(ア) 以下のサイトにImageJで実装されているクラスの詳細が書いてある。けど、Google検索から探すのが手っ取り早い。
(イ) http://rsbweb.nih.gov/ij/developer/api/ij/ImageJ.html
(ア) http://d.hatena.ne.jp/totobook/20101030/1288468881
(ア) java.lang.ClassNotFoundException
① ソースファイル１行目のpackages plugins; を削除する。
② jar cvf などのコマンドでコンパイル済みファイルを圧縮すると何故か出てくる。圧縮せず使いましょう。
① ImageJのJavaをver1.7にする方法が見つからなかったので、NetBeansのJavaを1.6にする。詳しくは上に書いた。
新しい職場のイケメンリア充超人のIT能力がすごすぎて死にたい。
オレみたいなブサメン非コミュはガジェットだとかネットの知識しか拠り所がないのに、
それを遥かに上回る知識量。
WinもMacもiOSもAndroidもlinuxのWebサーバも全て使いこなし、ガジェット持ってても結局Twitterとか
2chとかニコ動しか使わないってわけじゃなく、iPadとDJ機器繋いだり、プロジェクタ使ってVJとか
プロジェクションマッピングやったり、そういう技術使ってイベントやったりしてる。
職場のPCのトラブルシューティングは、ほぼ一手に彼が引き受けており、10秒位ボヤーっと
考えてから少ない手順であっという間に解決する。
（私物のパソコン直すのに女の子の部屋に行くことが結構多いってさ。曰く「お茶飲むだけですよ」）
かといってオレみたいなオタをバカにするわけでもなく、どんな人にも分け隔てない態度。
とにかく、要所要所で笑かそうとしてくるのがまた上手い。これがコミュ力か...
お笑い芸人が「最近はイケメンの若手芸人が増えてきていやだ」みたいなこと言ってたけど
まさにそんな気持ち。
この時点では故障しているかどうかは未確認と言う所を注目すべき。
たとえば、ライトが付く場合、次に燃料があるかを確認する。燃料がなけりゃエンジンはかからない。
燃料があってライトが付かない場合、近頃の車だとニュートラルになってないとエンジンが始動できないとか、クラッチを踏みこまないとエンジンが始動できないと言ったシステムが搭載されているのでそれをちゃんとやっているか確認する。古い車だと、エンジン時の状態によっては、エンジン始動時にニュートラルにしてアクセルを踏み込んだ状態でエンジンをかけるとエンジンがスタートできる事がある。
このほかにも故障以前にいろいろと考えられることはある。
これらはみんなマニュアルに書いてあることだよ。トラブルシューティングに先入観を持ってはだめ。一つずつ可能性を潰す必要がある。女性はまずロードサービスを依頼する前に男性に電話をかけてきたという状況から、男性側は自分にある程度の対処を依頼してきているものとして考えている。（おそらくそこからずれているよ！、話をしているうちに男も目的を見失っていくよ！、と言うのがこのコピペの笑いどころなんだろうが）
そこでまず
を等を探っているものと考えられる。
anond:20110818102655を書いた増田だけど共同生活に必要なお金と必要な時間と必要なポリシーのすりあわせを求めるのがなんで「ATMとトラブルシューティング（あるいは体裁）だけ求める現金さ」になるのかわかんない。
男だけの収入に頼る気はさらさらないけど今の日本では女の収入は男の6割だから女の収入だけでやってくのは難しいから、男にも相応の負担をしてもらいたいだけだし、この３つは当然私の側からも提供するものだよ。なんで一方的に提供される前提になってるの？
逆にこの３つすら提供できないような相手とパートナー契約を結ぶ意味ってないと思うんだけど、それすら提供する気がない男性ってのは一体何を提供するつもりなの？一方的に身の周りの世話してくれて無償の愛と癒しをくれる母親でもお望みですか。
同僚Aさんから内線電話がかかってきた。話を聞いてみると、どうやらAさんは、同僚Bさんに助けを求められてヘルプしたものの、原因がよく分からない。と言う状況に陥ったので、そのソフトについて詳しいであろう私に電話をかけてきたと言う状況だった。
困っている内容というのはBさんの端末を新しくしたので、良く使うソフトをインストールしているのだが、そのソフトがうまく動作しないと言う状況らしい。
で、どのように動作しないのかって言う詳細を聞いてみるとこのソフトを使う場合に良くある、特定機種にのみ発生する既知の障害・・・と言うか設定漏れだろうなと言うのにピンと来た。
そのまま電話で説明するのも良かったけど、わりと近い所にいたので、行って画面を私が操作した方が早いなぁと思って、そっちに行くことを約束して内線電話を切った。
ほどなく、私がそこに行くと、そこにはAさんBさんとなぜかCさんがいた。
どうやらこのBさんの端末をセットアップしたのはCさんだったらしい。Cさんは「このソフトが動かないんですよねー。良く動かないんですよ。他でセットアップしたときも動かなかったんですよねー。」なんてしゃあしゃあと言う。
で、私が設定をみてみると案の定設定漏れが発見された。そこで私が「設定が漏れてますねー。ここをこうして登録しますよ。で、動作を確認しますねー。動きましたねー。」と、ものの5秒程度で解決してしまった。
すると、Cさん「そんなのマニュアルに書いてなかったですよ」とか言い始める。うーん。確か社内マニュアルには記載があったはずだなぁと思って「記載してたと思うんですけどねぇ・・・。マニュアルってどこにありましたっけ？」と私が確認してみる。
私もさらーっとHTMLで作成されたマニュアルを流し読みすると、見つけられなかった。うーん。以前とマニュアルのページレイアウトが違うし、編集時に消えたのかなぁ？とか思って、再度頭からもう一度読み直すと、トラブルシューティングとして別ページへのリンクとして記載してあるのを見つけた。
まぁ、確かに分かりづらいけど書いてあるなぁ。と思いつつ、「ここに書いてありますよー。」って言うと、Cさん「あぁ、確かに！でも、ここには型番がHOGE09**系など○○機能がついているパソコンでは、この問題が発生します。って書いてあって、このパソコンって型番がHOGE08**だから、やらなかったんですよねー」とかしゃあしゃあと言う。
うーん。確かに「HOGE09**」とは書いてあるけど、その後ろに「系など、○○機能がついているパソコン」とは書いてあって、一応詳細を読むべき内容だと思うんだけどナァ。と思っていたら・・・Cさんは私の方を向かずに画面に向かったまま「ありがとうございました」と、超適当な謝辞を言う。
あぁ、なんだろ。なんだろ。やってられない。Aさん、Bさんはちゃんとこっちを向いてありがとうって言うのに、あなたはさぁ・・・。
しかも、私とCさん、あなたってほとんど会話したことないですよね？なのにその態度ですか？なめられてますか？そして、大人の社会人としてその他人に責任をなすり付けるような発言ばっかりの態度とかはどうなんですか？
と。言いたくなったが、言えなかった。
まぁ、仲良く無いって言うのと、そのプロジェクトルームからすぐに私はいなくなるけど、残された人たちって私が荒らすだけ荒らした空気を引きずらせるのもどうかと思ったりもしたので・・・。
なんていうか、やり場の無い怒りを覚えたので、ここにチラ裏させてもらった。と、同時に反面教師として自分もこんなことをしないように。と気をつけようと思った。
