  |
はてなキーワード: セキュリティポリシーとは
これまで多くのガイジを通報して凍結してきたんだがその過程で分かった事はXはマジで無能って事
問題発言繰り返してるガイジを普通にプロフィール欄から通報するだけじゃ殆ど凍結されない
そいつのガイジ発言を一つ一つ指定して20個ぐらい通報すると漸く凍結される
大体ガイジはQアノンとかネトウヨみたいな特定の集団に属してるのがマジで多いからXの場合だと「＠ガイジの名前 特定の単語」で検索すると大量にガイジ発言がヒットするからそれを通報するだけ
特定の単語っていうのは差別用語とか～～人みたいなのを指定するだけでいい
なのにこんな事すらまともにXは出来ない無能だから入手可能な情報を確認した結果このガイジはセキュリティポリシーには違反してないと判断しましたとか舐めた事を言ってくる
そのせいでQアノンかつネトウヨみたいな特定危険指定クソガイジが凍結されずにフォロワー数4桁まで生き残って社会に害悪を撒き散らしてる
そしてクソガイジの中でも特に極まってるガイジオブガイジは凍結されてもまた別のアカウント用意するからほぼ無意味で終わってる
昔から酷かったが今じゃトップすらガイジで最近はアメリカで吊し上げ食らうほどまでになったな
Excel 2016でマクロを作成するための効率的な手順は次のようになります。
1. マクロの目的を明確にする: まず、どのような作業を自動化したいか、具体的な目的を明確にしましょう。
2. Excelのマクロ機能を学習: Excelの「開発」タブにアクセスし、マクロを記録、編集、実行するためのツールを見つけましょう。基本的なマクロの操作に慣れることが重要です。
3. マクロの記録: 自動化したいタスクを実際に手動で実行し、その間にマクロを記録します。こうすることで、マクロはあなたのアクションを記録し、後で再現できます。
4. マクロの編集: 録画したマクロは最適化が必要な場合があります。不要なステップを削除し、必要なステップを追加または調整します。
5. マクロのテスト: マクロが期待通りに動作することを確認するために、テストを行います。特にループや条件分岐が含まれる場合、注意が必要です。
6. ショートカットの割り当て: マクロにキーボードショートカットを割り当てることで、手動でマクロを起動する手間を省けます。
7. セキュリティと共有: 職場のセキュリティポリシーに従い、マクロをセキュアに管理し、必要なユーザーと共有します。
8. ドキュメンテーション: マクロの動作や使い方を文書化し、他のチームメンバーが理解しやすくするための説明を提供します。
nginx、PHP-FPM、Laravelという構成なのですが、failed (13: Permission denied)というエラーが表示されて動きません。どうしたらよいと思いますか。
「failed (13: Permission denied)」というエラーは、通常、Nginxがアクセスしようとしているファイルやディレクトリに対して必要なパーミッションがない場合に表示されます。このエラーを解決するためには、以下の手順を試してみることができます。
Nginxがアクセスしようとしているファイルやディレクトリのパーミッションを確認します。ファイルやディレクトリが適切なパーミッションであることを確認し、Nginxが読み取りや書き込みを行えるようにします。
Nginxがアクセスしようとしているファイルやディレクトリの所有者とグループを確認します。Nginxの実行ユーザー（通常はwww-dataやnginxなど）がファイルやディレクトリの所有者やグループと一致するか確認し、必要に応じて所有者やグループを変更します。
サーバーがSELinuxを実行している場合、SELinuxのセキュリティポリシーがNginxのアクセスを制限している可能性があります。SELinuxを無効化するか、適切なセキュリティポリシーを設定することで問題を解決できる場合があります。
Laravelプロジェクトなどの場合、アプリケーションの一部ファイルが壊れている可能性があります。再度アプリケーションをデプロイしたり、必要なファイルを再生成することで問題を解決できるかもしれません。
上記の手順を順番に試してみてください。また、エラーが特定のファイルやディレクトリに関連している場合、具体的なパーミッションや所有者情報を提供していただければ、より具体的なアドバイスをすることができます。
ワイが代わりにchatGPTに聞いてやったやで
中継サーバー上の電子メールは、暗号化されていない場合は、中継サーバーの管理者や攻撃者によって盗み見られる可能性があります。ただし、多くのメールプロバイダーは、暗号化された通信プロトコル（例：TLS）を使用して、中継サーバー上の電子メールを暗号化しているため、中継サーバー上で盗聴される可能性は低いです。
2.電子メールが送信される過程で、怪しい第三者が設置したサーバーを経由して送られることはあり得るのか？
インターネット上のどこかに、怪しい第三者が設置したサーバーが存在する可能性はあります。このようなサーバーを使用して、電子メールを送信すると、そのメールが第三者によって盗聴、改ざん、または中断される可能性があります。
3.電子メールが送信元のクライアントと受信先のクライアント間のP2Pで暗号化される技術は何があるのか？
P2Pで暗号化された電子メールを送信するために使用できる一般的な技術には、Pretty Good Privacy（PGP）、GNU Privacy Guard（GPG）、またはS/MIMEがあります。
4.「3.」の実現は中小企業で導入するのは難しいものなのか？
PGP、GPG、S/MIMEなどの技術を中小企業で実装することは可能ですが、技術的な知識とスキルが必要です。また、P2Pで暗号化された電子メールの受信側も同じ技術を使用する必要があります。中小企業では、公開鍵暗号化を使用したエンドツーエンド暗号化を提供するメールサービスを利用することが簡単で効果的な解決策となる可能性があります。
5.中継サーバーを経由するなら、メールアドレスは容易に漏洩し、迷惑メールが来るのはそれで漏れたのが原因？
中継サーバーを経由することによって、メールアドレスが漏洩する可能性があります。この漏洩によって、スパムメールの送信元として使用される可能性があります。
6.例えば、会社のPCのWiresharkから、ネットワーク上を流れるデータを盗聴し、隣にいる社員のメール内容を盗み見することは容易に可能なのか？
Wiresharkなどのネットワークプロトコルアナライザーを使用して、ネットワーク上を流れるデータを盗聴することは可能です。ただし、一般的には、電子メールの内容は、中継サーバー上で暗号化されているため、中継サーバー上での盗聴による情報漏洩がより問題となります。また、会社のネットワーク内でのデータ盗聴は、セキュリティポリシーや監視機能の設定によって防止される場合があります。
fabio pereira alves
@fabinhopcb
返信先:
@◯◯◯◯
さん
時給精算
1日平均収益1万～5万円
入手可能な情報を確認した結果、fabinhopcbさんはTwitterのセキュリティポリシーに違反していないと判断しました。ご期待に沿えず申し訳ありません。今後このアカウントがTwitterのポリシーに違反した場合はお知らせいたします。
このアカウントをブロックできます。その場合、このアカウントはあなたをフォローしたり、あなたのツイートを表示したり、あなたにメッセージを送信したりできなくなります。
このような報告はTwitterのポリシーの改善に役立てられます。Twitterでは、ポリシーの内容と適用方法の見直しを続けています。Twitterのポリシーに違反している可能性のある事例を見つけた場合は、今後も報告をお寄せください。
Twitterのセキュリティポリシーによると、Twitterで禁止されている行為の概要は次のとおりです。
暴力を称賛または賛美すること
他の人の危害を願うこと
アイデンティティ（人種や性別など）を理由にして暴力を助長したり、脅迫または嫌がらせを行ったりすること
必ずしも十分な情報に基づいて判断が行われるとは限りません。そのため、この判断が間違いだと思われる場合は、もう一度報告することができます。
いや……まあ確かにこれだけだと違反してるとは言い切れないだろうけど、このあとに闇バイトとかに誘い込もうとしてるのは明らかじゃん……
機会的に上辺が完全にアウトコースに入ってるかを雑に判断して終わりって銀行や役所じゃないんだから……
驚いたわ。
新卒で就職してから、（敢えて分類するなら）Web系ベンチャー的な会社にずっと居たんだが、某大手SIerと提携してプロジェクト進めることになったんだわ。名前は出せないけど、みんな知ってるあの会社だよ。
こういう会社の評判はネット上でよく耳にするけど、それは誇張されたものだと思ってた。実際、そういう会社は社会的に成功してるんだし、社員も高学歴の人がほとんどなんだから、使っている技術が多少古臭くても、仕事のレベルは高いんだと思ってた。だが、そんなことは全然無かった。
うちの技術者が10分でできるようなことが、何回も会議をしたり、書類を埋めたり、向こうの上司の承認を得たりで、3ヶ月くらいかかる。そんだけ会議した後、やったのは、テンプレートからAWSのEC2インスタンスを起動していくつか必要な初期設定をしただけ。
言い忘れてたが、プロジェクトの内容はうちの製品を向こうの会社名義で売るということ（いわゆるOEMというのか？よく知らん）。
で、開発者向けのAPI等のドキュメントが既にWeb上に公開されてたんだが、なんか上司がはんこ押す書類と一緒にしなきゃいけないという理由で、これをエクセルに転記させられた。向こうの指定した方眼紙フォーマットにな。CSVなどに出力して一括でコピペすることさえできないストレスは想像を絶するものだった。エクセルにスクリーンショット貼り付ける作業で精神病むのも納得。
他にも意味の分からん制限が多かった。セキュリティポリシー的に、Google Drive等の外部サービスで情報を共有するのはNGだというんだが、上司がCCに入ったメールで送ったあとならOKらしい。んで、そういうメールを受信したらSlackに転載したりする馬鹿みたいなスクリプトをたくさん書いた。書き始めたらすぐに向こうの意味不明な運用に合わせたシュールでカオスなプログラムになった。もちろん、これも実際動かすには承認に何ヶ月もかかる。
こいつらの仕事の出来なさは、もうプログラミングができないとかそういう次元を超越してる。
当初のイメージでは、「使ってる技術が最先端ではないだけで、仕事の段取りとかはちゃんとしているのだろう」とか思ってたが、そんなことは全くなかった。
技術とか以前の問題。意味のあることと無いことの区別がついていない。「そういう段取りになっている」という理由でただ言われたことを作業的にやるだけ（まあ、一定レベルの知的労働を流れ作業に帰着させるのはある意味すごいとも言えるが）。
俺の関わった連中が例外的にひどかったと思いたいが、まあ、現実問題そういうことはないのだろう。
俺の大学の同級生も、NとかFとかNとかHとかの付くSIerに就職していったが（上記の会社はその1つである）、こういう仕事をしているなら完全に人材の無駄遣いだと思う。コンビニパートのおばちゃんとかで変わり利くもん。
これからエンジニアとしてキャリアを築きたい学生とかは、絶対にこんな会社に入っちゃいけない。まともなスキルは全く身に付かないぞ。
都内の小学校でPTAの会長をしています。仕事ではIT系のプリセールスをやっているSEです。
今年度はGIGA構想、プログラミングの必修化、コロナに伴うオンライン授業対応とかIT系の話題が多かったので、学校関係者や教職員・PTA関係者・教育委員会とも学校のIT化の話をすることが多かったのでちょっと思う事を書いてみます。
個人的に思うことはたくさんあったのですが、お互いにちゃんと理解されていないと思う事が特に多かった校内LAN（校務LANと言う方が一般的かもしれません）の話を書いてみます。
一部不正確なところはあると思いますが、詳しい方のご指摘があれば適宜追記していきたいので教えてもらえると助かります。
こんなことを書いています。
・ 校内LANの最大の問題は過剰なURLフィルター。このような構成になっている意義はあった
・ ZOOMによる保護者会開催は保護者が思っているより画期的だったのではないか
・ 結果としてインターネット分離は無くなっていくのでは？
なぜ校内LANはインターネットに繋げないのか？と言う話は日本年金機構の大規模なサイバー攻撃の被害の話にまで遡ります。この話の再発防止策として総務省は2017年までに省内LANとインターネットLANを分離するようなインターネット分離を実施することになりました。文科省もこれを受けてインターネット接続は都道府県の教育委員会の管理する代理サーバーからインターネットに繋ぎ、校内LANはインターネットに繋げないような環境になっていきました。
詳しい話が気になる人はこの辺の文書を読んでみてください。
自分はそれ以前がどう言う状態だったのか逆にあまり知らないのですが、ここでの大事な話としてIT技術者をそれなりの規模で抱えておけないような公共の組織で標的型攻撃や高度な攻撃から守る手段としてこのようにしたことは一定の意義があったのではないかと思います。
この辺の話をしていると、教職員もなぜこうなったのか理解していないまま不満を述べていることも多いようにも思えます。
学校のIT化の問題は最近は教職員の対応などが課題に上がることが多い気がしますが、次に多いのは学校のネットワークについての不満です。校内LANが上記のような感じなのでWi-Fiも飛ばせないし、URLフィルターが過剰すぎて教職員は文科省が出したオンライン教材にもつなげないような状態になりました（YouTubeが禁止リストに入っているため）。当然ZoomやTeamsで会議を開くこともできませんでした。（インターネットLANから開催すると大変。禁止されていたのではないかと思います。）
Wi-Fi の話はともかくとしてここで問題なのは元々のインターネット分離を実施する上で今回のような過剰なURLフィルターは必須では無かった事ではないかと思います。
これは代理サーバーからインターネットを閲覧する（プロキシーとは違います。詳細は割愛。）、という仕組みであったため教職員が動画サイトなどを常時閲覧されるとサーバーのスペックが過剰になるため、市民の税金でそんなぜいたくな環境を立てるわけにもいかない、とか本来教職員のインターネット閲覧は節度を持った最低限のものであるべきだ、というような考え方によるものであったのではないかと推測しています。本来のITセキュリティとは関係が無い話ですが、政府系や学校系のIT投資では一般的な考え方なので当時のその発想を批判することも個人的には難しいのではないかと思います。
昨年の緊急事態宣言下では学校が閉鎖された際に上記の問題が大きくクローズアップされました。文科省が矢継ぎ早に出したオンライン教材を教職員は全く見れないし、リモート授業やオンライン授業を無理やりでも暫定でもいいからやろうとしても教職員のインターネット閲覧は非常に限定的だったためほぼ検討の余地がありませんでした。
ここで着目されたのはGIGA構想で配布が始まっていた端末でした。この端末は回線が無い家でもネットにつなげるようにSIMカードが入っていたため、この端末を使ってZOOM会議などを急遽実施できるようになりました。Zoomが教育機関向けに無償解放したのも大きかったと思います。SIMカードが入っていたのはおそらく授業の際に使う学習系のシステムにはインターネット接続が必要ですし、回線の無い家からも使えるようにするためにこのようになっていたのではないかと思います。
ここで重要なのは教職員がSIMカードを使った直接のインターネット接続を行って保護者会などの校務を行うのは当初のインターネット分離の考え方から言うと完全に抜け道になる手段になる可能性があったのですが、文科省も含めてこのような方法によるオンライン会議の実施をこのタイミングで容認したことでした。配布端末にはSkySeaなどでURLフィルターを配布しているようで当然閲覧制限はあるのですが、「端末をある程度教育委員会で管理しているならインターネットLANを経由したインターネット接続には拘らない」と言う暗黙のルールがこのタイミングで生まれたように思えます。文科省からも「これまでのITセキュリティに縛られることなく早急な実現方法を検討してほしい」と言うような主旨の通達を出しています。
>>文部科学省としては、全国的な長期休業というこれまで類を見ない緊急時であること、各学校や家庭で ICT 環境が様々であることを鑑みると、平常時における学校設置者や各学校の一律の ICT 活用ルールにとらわれることなく、家庭環境や情報セキュリティに十分留意しながらも、まずはその積極的な活用に向け、現場を最もよく知る教員が家庭とともにあらゆる工夫を行えるよう対応いただきたいと考えています。 <<
このような意味でZoomによる保護者会実現はやや硬直化しつつあった校内LANの仕組みに風穴を開けるきっかけになりました。
多くの保護者は対応の早い私立校などとの比較で、オンライン授業やリモート授業が実施されない状況に不満を持っていたと思うのですが、個人的には画期的なことだったと思います。これにより、PTAのオンライン会議などでも校長先生などがオンライン参加出来るようになりました。
私の区では今年度の端末配布で10億円近い投資をした（区の負担が10億だったかどうかは知りません）と聞いており、来年度には一人一台を実現し、6月くらいには配布物のオンライン化を進めると聞いています。（教職員は全く詳細を聞いていない状態なので本当に実現できるかは微妙ですが。。）私の区は渋谷区のような先行した地域ではないのでこれでもかなり頑張ったのではないかと思います。
当初はすでにプログラミングが必修化されているのに端末配布は2025年くらいまでにやろうかと言っていた事を考えるとコロナ禍でGIGA構想は大幅に進んだのではないかと思います。
これからはG SuiteやO365も使うことになり保護者会のオンライン開催は今後も続くであろうことを考えると、残念ながらそれなりの投資が無駄にはなりますがインターネット分離は廃れていくのでは無いかと思います。多少の調整をしても今のインターネット分離の仕組みのママ積極的なSaaS利用や頻繁なオンライン会議の開催を想定することは難しい、と考えるのが自然なためです。
文科省のインターネット分離の期限が2017年だったので2022〜2024年を契機にどんどん廃止されていくのでは無いかな、と予測しています。おそらくら総務省や文科省もこのくらいのタイミング、もしくはもっと早い段階でこの辺の指針を出すのではないでしょうか。
業界的な用語で言うなら、なんでも隔離して守るのではなく、いわゆるゼロトラスト的な発想による端末運用を目指していく、と言う方向を目指すことになると思います。結果として時代に合わせた形に軌道修正されていくことになったのではないかと思います。
＃で、何が言いたいの？と言われると困ってしまうのですが。。
大企業ではほとんど採用されていると思うが、メールゲートウェイ型のセキュリティアプライアンスで、添付ファイルが
ついていたら暗号化解除して中に含まれるファイルに悪意があるマクロ、プログラムが含まれるものがないか検査して
OKだったら送信許可、NGなら削除されましたの通知だけを送るなどをしている。
従いスキャンできないと、一律でメールは削除、若しくは添付ファイルは削除されましたの通知のみ送られる。
企業のセキュリティポリシーとしてこうしているところはあります。ウイルス感染対策の検知対策確度を上げるため。
さらに、ローカルPCにウイルススキャンが入っていて添付ファイルをローカル保存するとき、開くときにスキャンが
メールゲートウェイ型アプライアンスで、企業のインバウンド/アウトバウンドメールを一律、
チェックしたいんじゃないのかな。それなりに意味はあると思いますが、例えばgmailだと、
これまで暗号化解除(解析&解除)でチェックしていたと思われるが、CPUリソース食いまくりな事
や実効性への疑問(ほかの対策若しくは、複数対策を組み合わせる事での効率化)があって、
添付ファイルはチェックされず送られるか、削除されて何も通知されないみたいです。
> 3、なんで毎回同じPWじゃないの？
同じパスワードだとそれが漏れたり、第三者に知れたら容易に暗号化解除して見れてしまうから。
> これは1の通り、プロキシサーバーでスキャンできる仕組みを作る必要があるってことでいい？
プロキシーサーバではなくてメールゲートウェイ型アプライアンス(古くはオンプレでInterscanなり、、最近は知らんけど)
> この場合既存の仕組みを使えないし、クラウドサービスにロックインされるし
> 腰が重いのもわかる気がする
なにか同等のサービスがあると思う。
とりあえず、G Suite(旧google apps)だとgmailのメールフィルタ機能が標準装備でゴミメールはだいぶ減る。
メールソフトへの実装があまりはやらなかったのもあるし、暗号化強度の問題もあったのでは。(推測)
公開鍵暗号方式の実装したもので使いやすいもの、若しくは この手の送り手/受け手が正しい人かつ、
悪意を持ったプログラムが含まれないことを担保できるメール送受信の仕組みを作ればよいと思う。
インターネット自体は、自律分散系システムなので送ったものが必ず届くという確証もないし、
日経の記事へのブクマ見て、みんなみかか好きすぎだから、少し書く。
今でもICTだー！って旗降ってるけど、みかかは独自製品作れないんだから、商社的やり方しかできないのに、サービスの話してるのもなんだかなぁ。中身のイメージなく、客はICTって触れこんどけばひっかかるだろうって思ってるなら客なめすぎ。
あと、ここのグループってバリバリできる人が3年くらい企画の立ち上げしたら転勤して（もしくは転職しちゃって）、後釜にわけのわかんないポンコツが座るんよね。
立ち上げるパワーはあっても属人的で続かないというか、会社がその人の功績とか、サービスのコツみたいなのわかってなさすぎるのよ。
中で働いている中堅以下はさすが大企業だなーと思うくらいの人がいるから、そこのとこはすごいんだけど、やり方が体系的じゃないというか…。たぶんその人たちは転職したらもっと給料もらえるけど、安全圏の立場に満足しちゃってるんだろうな。
みかかはそういう日陰にいるスーパーマンで耐えているフシがある。
ただ、偉くなる人は政治に長けた人かな。
それで、これからのみかかさんだけど、ここ数年、株価がイケイケで、企業価値って言葉が連呼されて上からの圧が苦しいみたいで、すぐに成果が出そうなプロジェクトとかに飛びつきがちな感じがあるのがちょっと気になるけど、100発打って1発当たればいいって戦略が取れるならいいんだろうけど、そこはやっぱり省庁と同じインパール気質あるからどうなるかなー。
在宅推奨であのガチガチのセキュリティポリシーが柔軟になるならちょっと嬉しい。
https://note.com/mmeducation/n/n9ab23ea5a385
色々思うところがあるんだけど一点だけ。
"今は前代未聞の非常時、緊急時なのに、どうして学校で、なかなか危機感ないところが多いのか。 "
殆どが文科から自治体に向けたメッセージだしそれはやってくれって感じだけどそれを自治体すっとばして現場に向けんなよ。
まずここ最近のニュースもこと教育現場関連になるとまじで忘れ去られてて違和感あるんだけど、前提として俺らだって国民でありできるだけ家にいて身を守らなきゃいけない立場だってことを忘れんなよ。新生児や高齢の家族がいる職員だって大勢いんだよ。
職員の出勤を校務に差し支えない範囲で押さえて(努力目標8割在宅勤務)みたいになって、みなさんパソコン持ち帰ってくださいって言われて持ち帰った自治体支給のくそ重い端末だって、セキュリティポリシーで Google 関連サービスも Dropbox も YouTube も閲覧できない。zoom だってブロック対象。そんな状況でどうやって ICT を活用した双方向の授業なんてやれっつーんだよ。
乗りたくない電車に乗って通勤して、ただでさえ家庭からの問い合わせの電話とか心配な子への個別の電話連絡とか今後の対応を検討する会議に追われてて、そんな中「組織のを使うのは危険だから自分らでなんとかヨロタノ」ってわけ？自分の端末と通信範囲使ってやれっつーの？おかしいだろ。
頼むから環境整備してくれ。セキュリティ設定見直すなり自宅でやれってんなら在宅勤務環境整えるための手当て支給するなり。
他にも課題はたくさんあるんだけどさー各家庭の ICT 環境の問題とか。初めにも言った通り自治体への発信は是非やって自治体も応えてください。採用された年にあったセキュリティ関連の事故防止研修で「Gmail とか、Google Drive とか、オンラインでデータを共有する類いのサービスは全て不可。色々ありますが、便利なものはだいたい禁止、と思ってください笑」なんて言われた現状が今もなお続いていて、首相が言うような「これを機に教育現場の ICT 化を急激に加速」なんて実現するわけがない。
やっぱり日本郵便のクリックポストのサイトの認証局がおかしくて、
「TAIWAN-CA」と「GlobalSign nv-sa」が何のタイミングか分からないが切り替わってる感じがする。
認証局の種類って OS って関係あるの？（なんか言ってることがトンチンカンだが）って思うし、
「TAIWAN-CA」と「GlobalSign nv-sa」が何かのタイミングで入れ替わってる挙動が怪しいんだけど、
これってなんなの？
詳しい人いないですか？
clickpost.jp では、悪意のあるユーザーによって、パスワード、メッセージ、クレジット カードなどの情報が盗まれる可能性があります。詳細
NET::ERR_CERT_COMMON_NAME_INVALID
clickpost.jp では通常、暗号化して情報を保護しています。今回、Google Chrome から clickpost.jp への接続試行時に、このウェブサイトからいつもとは異なる誤った認証情報が返されました。悪意のあるユーザーが clickpost.jp になりすまそうとしているか、Wi-Fi ログイン画面で接続が中断された可能性があります。データのやり取りが行われる前に Google Chrome によって接続が停止されたため、情報は引き続き保護されています。
clickpost.jp では HSTS が使用されているため、現在アクセスできません。通常、ネットワーク エラーやネットワークへの攻撃は一時的なものです。しばらくするとページにアクセスできるようになります。
Firefox はセキュリティ上の潜在的な脅威を検知したため、clickpost.jp への接続を中止しました。このウェブサイトには安全な接続が必要なためです。
どうすればいいですか？
clickpost.jp は HTTP Strict Transport Security (HSTS) と呼ばれるセキュリティポリシーが設定されおり、Firefox は安全な接続でしか通信できません。そのため、このサイトを例外に追加することはできません。
この問題はウェブサイトに原因があり、あなたにできることはありません。ウェブサイトの管理者に問題を報告するのもよいでしょう。
ウェブサイトは証明書で同一性を証明します。clickpost.jp は無効な証明書を使用しているため、Firefox はこのサイトを信頼しません。この証明書は次のドメイン名にのみ有効です: spay.com.tw, mp.spay.com.tw, mypay.tw, gw.mypay.tw, 39buy.co, biz.spay.com.tw, corp.spay.com.tw, qrcode.39buy.com.tw, query.onecardpass.com, zeapi.mypay.tw, zepay.mypay.tw, no.onecardpass.com, mgt.onecardpass.com
【追記】
ちなみに推奨環境のスマホからでもエラーが出たのでやっぱ向こうがおかしかったんでしょ！ぷんぷん！
＞ 各部署ごとにセキュリティポリシーを割り当てるというのが無難な考え方なんだと思うよ。
＞ 自由度あげた方がいい部署、セキュリティ度を上げた方がいい部署、それぞれ違う。
＞ その上で、社内でネットワークを分断するのが合理的だと思う。
本来はそうなんですよねー。よくわかる。でもこれの管理ぜーんぶ情シスでやるの？って気がする。
もうそろそろGUIからコードを、コードをGUIに戻せる仕組みがあって各部署のじょうしがやってくれよって思う。
＞ ただ、一番のネックは、情報漏洩や攻撃の踏み台（親会社や取引先への攻撃）であって、その時の損害額は、中小企業だと会社無くなる可能性もある。
＞ それを考えたら、場当たり的に突貫工事するものではないんだけれど、このご時世しょうがないんだろうな。
情報セキュリティポリシーに不特定多数の人が出入りする公共の場所では仕事をするなと書いてあるなら仕事しなくていい(どころかしちゃいけない)んじゃね
SNSで仲良い（と思っていた）友人が写真アップロードしてたから
「それ、場所わかるからやめた方がいいよ、◯◯でしょ？」って教えたら
PCできて対人関係で得したこと一度もなかったけど、ここまで辛い思いをしたのは久々。
ソーシャル含めた包括的なセキュリティの仕事やってるけど、お客さんにとってはセキュリティとかネットリテラシーとか「よく分からないけど守らないと怖いもの」でしかないってのもすごく感じる。プレゼンの方法工夫しても一個でもマルウェア検知したら大騒ぎするし、セキュリティポリシーも何度言っても「とりあえず全部禁止！」ってのに決めるし。何も起きないことが普通って思われるし、なんだかなあ。報われない。
京都大学 安岡氏はブログで以下のような発言をした。 https://srad.jp/~yasuoka/journal/611343/
このOrarioは、京都大学のKULASISにずっと不正アクセスを繰り返していて、正直なところ私(安岡孝一)としてはアタマに来ていたのだ。
また、自分の発言がorarioへの営業妨害にあたることを自ら認めている。 https://srad.jp/~yasuoka/journal/611364/
来月30日以降Orarioが、学生の所属大学、所属学部・学科、性別、卒業年度、登録時間割の匿名加工情報を、第三者に販売営業するつもりなら、私の昨日の日記はOrarioに対する営業妨害だ。
ところが、mala氏による分析(https://gist.github.com/mala/f2b7659f78bb396bf1eb6788be38a72d)があってからは、不正アクセスといわなくなった。
そのかわり、京都大学のセキュリティーポリシーに違反しているというようになった。
https://srad.jp/comment/3203194
だからと言って、京都大学のセキュリティーポリシー [kyoto-u.ac.jp]に違反して、京都大学の全学情報システムその他を利用するようなプログラム等を開発運用することは、全く認められません。それはOrarioに限ったことではありません。セキュリティポリシーをしっかり読んでから、出なおして来なさい。
そして、ひろみちゅ氏の見解(https://twitter.com/HiromitsuTakagi/status/858306861895884800) が出てからは、何もいわなくなった。
安岡氏の主張が完全に間違いであることは誰の目にも明らかとなったわけだが、「単位を取り消す可能性がある」発言を取り消さないばかりか、orarioが「不正アクセスをした」という事実無根のデマを打ち消すこともせず、自ら認めた営業妨害を黙認し続けているあたりは非常に悪質であるといわざるをえない。
彼は嘘つき先生といわれることに不快感を示していることからそうはなりたくはないと思っているはずだが、今は彼の嘘が少なくとも京都大学ではまかり通っている状態である。
これは、イギリスやアメリカで起きているPost-truth現象に似ていると思う。
学生はどういう思いでいるのだろうか。
正しいことを正しいという社会を目指しているのではないのか。
何のために学んでいるのだ。
現在大学の中でOrarioのアクセスがどうこうという問題が起きているようだが、
ひとまずこの記事については、下記URLにある、京都大学の専門家であらせられる記事について、一人歩きしてる感があるので、
もう少し彼のような上流側（という表現で良いかどうかは不明だが）の専門家ではなく、
下流でプログラムをガッツリ書いているほうの専門家として私(匿名で失礼)が纏めたいと思う。
https://srad.jp/~yasuoka/journal/611343/
Orarioの芳本大樹が書いた『時間割アプリの「Orario」の特性と安全性について』(2017年4月17日)という文書を読んだ。このOrarioは、京都大学のKULASISにずっと不正アクセスを繰り返していて、正直なところ私(安岡孝一)としてはアタマに来ていたのだ。
Orarioの特性と安全性について、本当にスクレイピング技術をクライアント端末側で行っているのであれば、
この部分は間違いではないと私(匿名で失礼)は考えている。
この部分の書き方、実に大学教授らしい逃げ道を多く用意していて。
KULASISにずっと不正アクセスを繰り返していて
上記発言、これは本来「開発時の検証段階」の話をしているのであれば「正解」、である。
逆に今のOrarioの通信についてを不正アクセスとしているのであれば「正解ではない」、である。
何せ、開発者が勝手にアカウントを使って入り込んで様々な検証を行う必要があるため、
KULASISサーバに対してクラッキング/ハッキングを行って根こそぎどうこうしたなどという大がかりな不正アクセスではなく、
あくまで大学側が定める規約規則から若干外れた使われ方がされているという意味の不正アクセスである。
（そもそもスクレイピングなんて技術を使う連中はID/PASSWORDがない状態でのサーバへの不正アクセスなどできない
開発時は「京大のKULASISアカウントをもったユーザが開発に携わっていないのであれば」押し出してきている京大の規約によれば、不正アクセスにあたるのかもしれない。
個人的には当たらないと感じるが。
京大の規定に定められたユーザが「特定のブラウジングツール（Orario）」により、
KULASISにアクセスしているのだからアクセスとしては不正ではない。
本当にスマートなWebスクレイピングで行われているのであれば、Webブラウザと全く同じ動きをするはずで、
それを不正アクセスと断罪してOrarioは不正というのは表現が汚いと考える。
これはコメント欄にもあるが、
https://srad.jp/comment/3196554
また、ChromeやSafari（及びその他マイナーなWebブラウザ）なども御校のWebサーバーよりコンテンツデータを取得し、HTMLを構文解析し画面表示を行っていますが、これらはセキュリティポリシーには適合しているのでしょうか？
ご大層にはっておられるリンクを流し読みをする限り、そんな厳格に何かを定めているわけではないように思われる。
それ故、実際にOrarioがスマートフォンによるスクレイピングを行っているのであれば、
Webブラウザの一種とも言えなくはない為、これを不正と断ずるのは、「正しくない」だろう
京大のユーザが開発に携わったかを証明できない以上、彼にとっては不正なのかもしれないが、
ここでそれをOrarioは不正アクセスと断ずる論理性が私(匿名で失礼)にはわからない。
他にもこの部分
Orarioアプリでは「Webオートメーション(Webスクレイピング)」と呼ばれる技術を用いています。この技術により、利用者様のスマートフォン（にインストールされているOrarioアプリ）に学生アカウント（大学ID・パスワード）を入力すると、自動で当該利用者様の教務用ページから時間割の生成に必要な情報のみを取得し、Orarioアプリの時間割テーブルに当該利用者様の時間割を生成・表示することができるという仕組みとなっています。
全く信用できない。少なくとも先月以前、OrarioからKULASISへのアクセスパターンを解析した限りでは、そんな風なアクセスパターンには見えなかった。嘘を書くのもいい加減にしろ。
Webスクレイピング技術に関して、なぜアクセスパターンが問題になるかが一つ疑問である。
下記のOrarioが出しているPDF(http://www.orario.jp/wp-content/uploads/2017/04/Orario%E3%81%AE%E5%AE%89%E5%85%A8%E6%80%A7%E3%81%AB%E9%96%A2%E3%81%99%E3%82%8B%E8%A6%8B%E8%A7%A3.pdf)にあるように、簡単にいうならばID/Passwordを利用したPOST通信を行い、その返答値をスクレイピング（切り貼り）している。
それをアクセスパターンを解析で一体何が取れるのか？という部分が、この辺りが分かる自称専門家の私(匿名で失礼)にもさっぱりわからない。
もっというと、「そんな風なアクセスパターンには見えない」、というならば、セキュリティの観点上公開すべきではないだろうか、
逆に一体アクセスパターンを見て私(匿名で失礼)も何を行っているのかが気になるところである。
ただでさえ、不正アクセスという言葉をつかって攻撃しているわけだから、
アクセスパターンを公開して断罪すべきだし、セキュリティ観点からみても他大学との共有はすべきで、
学生に対してもその証拠を出して止めさせるべきだろう、というのが個人的見解である。
学生の求める「単位」をつかって脅しをかけている時点で、お察しだが……。
そもそも上記で述べた開発時のほぼ不正アクセスと考えられる通信についてを「アクセスパターン解析で見つけた」というのであれば理解ができるが、
現在すでにスクレイピングが確立している通信に関して、アクセスパターンでOrarioかどうかを判別するのが可能かというと何とも言えないと思う。
（ご丁寧にOrarioが通信用のUserAgentにOrarioの文字を含めているなら別だが……
（もちろん、アクセスログを見て、ログインページからWebスクレイピングしたいページへ遷移するまでの時間を取るとあまりに短すぎる、という話ならやれるかもしれないが……。
たとえKULASISが京都大学がオリジナルで開発した大学教務事務パッケージだとしてもそうだろうと考えている。
同様に日立や富士通も同じような大学教務事務パッケージがあるが、
基本ログ処理がザルでろくにuser-agentの確認もできない大学も多く存在したりすることを知ってる自分としては、
本当だろうか？嘘を書くのもいい加減にしろ？ と思う。
UIが糞（システムのスマートフォン対応がノロい）だからアプリが流行るということに気づくべき。
富士通、日立にしてもそうだが、APIを提供したほうがいいのではなかろうか。
とくにKULASISだったか何だったは、京都大学謹製と聞いている（違ったら失礼
少なくとも他の大学教務事務パッケージではなかったと記憶している。
であれば、京都大学がAPIを提供し大学側で専門家を集めてOrarioを超えるものを作ってはどうか？
実際大学でこういうことをやろうにも、問題になってくるのは予算で。
教務、事務、学務、図書館、など様々な縦割りが存在し、それぞれがそれぞれの予算でそれぞれのシステムを入れている。
これが実に糞で。
一つの大きなシステムを入れ替えるとなると、横との連携をとって全ての組織の号令をとらなければならない。
ここまで問題になってくるとやはりその辺りの対応の遅さが問題なのではないかと考えている。
大学がアホ → 学生に良い物を提供したいという思いがあるならもっとフットワーク軽くしろ
教授がアホ → 曖昧な表現で、素人を先導しようとするのが見え見えで気に入らない
Orarioアホ → コメントにもあるけどやり方が汚いのは確かだから甘んじて受け入れろ
以上です
http://d.hatena.ne.jp/saebou/20151221/p1
「非常勤講師」とは雇用契約を結んでいない。１コマいくら、学期単位で委嘱している。たとえばブコメにあるように民間の人に来てもらって講義してもらう場合とか、あと奇妙な話だが内部の教員が本務以外の他学部で講義を持つ場合も非常勤講師扱いになっている。単価には幅があるが概して安い。これはターム制導入以前からはっきり言って安すぎるし、ターム制に移行したための負荷の増加というのも正直あまり考慮されていないだろうと思う。脱線するがターム制は前総長時代に秋入学だなんだでさんざんぐだぐだやったあげく妥協の産物として任期ぎりぎりに制定された間に合わせの制度という印象がある（学部によってタームの時期違ったりする）。ただ準備に充分な時間があったとしても非常勤講師の人件費にお金が回ることはなかっただろうなという気もする。国立大学法人の予算に余裕はないが、中でも教育部門は深刻だ。一番お金を持っている大学でこれだから他は推して知るべし……というところだと思う。
「教職員」の定義は「雇用契約を結んでいる教員および職員」であるので、非常勤講師の多くはそれに該当しない（上にも書いた通り例外はある）。“非常勤講師は東大と雇用契約が無く、「教職員」ではない”というのはその定義の上では全くその通りである。とはいえそれだけ聞いたらわけがわからないのは間違いない——というかともすれば心無い言葉にも聞こえるし、ブログ主にはそう響いたのだろう。説明の際に言葉が足りなかったものと思うが、申し訳ない話だ。非常勤講師の皆様が居なければ大学の講義・授業はとても成立しない。人事制度用語としての「教員」には該当しなくとも、教育を担う重要な方々であるという認識は事務部門として当然に持っている。
ただ、その定義の上では“「教職員」でない人に学生を教えさせてい”ること自体は必ずしも問題とは思わない。学生を教える人と必ず雇用契約を結ばなければならないとしたら、今度は民間の人に講師を引き受けてもらうことが兼業規定とかの兼ね合いで難しくなったりするだろう。
それと、講義を委託するのであっても、すなわち結果さえ伴えばどうやっても自由、ということではなく、やはりある程度やり方についても指示をする、ということ自体は充分あり得る。そこは委託の形態次第だ。しかしブログ主がここにひっかかっているのは本質的には雇用形態の問題ではないと思える。
余談だが、「非常勤」という言葉には別の意味がある。まあ、このブコメにある通りなのだが、
defy1 非常勤講師ってのは職名というよりいわゆる単発バイトの名称であって、国公立大における非常勤教職員（パート教員）とはまったく別。国公立と私学の文化的・制度上のギャップも大きそう。
「教職員」の中にも「常勤」と「非常勤」があるのだ。ただ、学内ではほぼ通じる言葉だが多分正式な用語ではない（逆に「非常勤講師」は正式なタームの筈である）。ざっくりいえば常勤の人は月給で働き、非常勤の人は時給で働く。
と「教職員」にも８通りの形態があると考えていただければよくて、「非常勤講師」はこの中にそもそも入らないというのは上に書いた通り。
ブログのコメント欄で出てくる「東京大学特定有期雇用教職員」「東京大学短時間勤務有期雇用教職員」「東京大学特定短時間勤務有期雇用教職員」という呪文のような職名はそれぞれ「常勤-教員/職員-任期あり」「非常勤-教員/職員-任期あり」「非常勤-教員/職員-任期あり」を指している。あとのふたつがどう違うかは自分にもわからない。
まめちしきとして、職名に「特任」とついている人は任期ありである。報道で「特任教授」とか「特任助教」とかいう職名を目にすることも多いかと思うがあれはそういう意味だ。常勤か非常勤かは区別がつかないので、例えば月に１回だけとか勤務してる特任教授なんてのもいる。
ちなみに非常勤の任期なしというのはもはや存在しないが、国の頃から在籍している人には経過措置でまだ残っている。何十年も同じ研究室にいる秘書さんなんてのは代表的な例だ。
閑話休題。
データベースの話は初見では自分もブコメに書かれていたのとほぼ同じ、データベース（あるいは電子ジャーナル？ 具体的にはどのようなものか、元記事のコメント欄で質問もされているが結局ここはあいまいだ）の配信元との契約が関係しているのではないかと推測していた。アクセスできる範囲を非常勤講師にまで広げてしまうと金額が大きくなりすぎるし、それまでは使えていたのは契約違反だった、という話だと“去年までアクセスできていたのは契約違反であり、非常勤講師が勝手にアクセスしていたという扱いになる”という記述と整合する。これは単純にお金の話なので乗り越えるのが難しい。上にも書いた通り教育にかけるお金は厳しい状況だ。
ただ、ブログのほうのコメント欄を見るとそもそも学外からのアクセス権がもらえないという話が出ている。それであれば情報セキュリティポリシーの話になる。コメント欄にある通りポリシー上「教職員」以外には原則として学外アクセス権を与えていない。“去年までアクセスできていた”のであればそれは運用がいいかげんだったということでそれはそれで問題だ。
アクセス権についてはどこかで線は引かなければならないのだから、雇用関係のある／なしの間で線を引くのはそこそこ妥当な線であるようにも思う。しかし非常勤講師に全く学外からのアクセス権が与えられないのは確かに不便が起こりうるし、そこは個別に融通を効かせて欲しいところであるとは個人的には思う。改善されると信じたい。
# 単にアクセス権を得るということであれば週数時間でいいから何かの名目で（非常勤）教員として雇用されるのが多分近道であったと思うのだがその辺りを相談できる先生はいなかったのかな……。データベースの契約の話だとフルタイムにはカウントされないだろうけど。
## もちろんそれでは本質的な解決になっていないし、それこそ本務先との兼ね合いもありそうで、近道ではあっても回答ではない。
情報ヘルプデスクの開始時間についてはターム制導入に際して運用が追いついていない顕著な例で、これも契約の変更が伴うので時間はかかるが改善されると信じたいところではある。が、学内には始業時間が８時３０分の部署はこれまでも普通に存在していたのにヘルプデスクはずっと９時からだったので変わらないかも知れない気もする。
UT-roamについてはさすがにその応対をした人がなにか思い違いをされていたと思う……のだが情報部門も常に人数足りてない感じは否めず、各部局の情報担当が汗を流して頑張っている印象はある。その意味で“本郷の誰かがボランティアでやってる”はあまり笑えなかったりする。
取材については詳しいところはわからないが、本部の広報部門の職員数は大学の規模に比すれば信じられないほど少ない。なので本部に問い合わせれば（個別に対応することが不可能なので）全て禁止と言われるのではないかと想像する。しかし部局によっては独自の広報担当があって、現実問題として部局が独自に取材を受けることは妨げようがない——という気がしないでもない。歯切れが悪くて申し訳ない。いずれにしてもこの点については大学全体の問題であるように思う。
意欲的な授業を行ってくれていたらしい先生が去っていくことを残念に思う。大学側に積極的な悪意はないと信じたいのだが、直接の応対がどのようなものであったかは知りようがないし、時給が安いのと広報がうまくいっていないのはまあ事実だし、“非常勤講師が研究・授業用に学外からデータベースを使えるようにするとか、クラスサイズを小さくするとか、そういう教育環境の改善には全く関心が無いようです”と言われたときにそんなことはないと言い切れる材料を自分は持っていない。
あとこの手の記事がホッテントリに入るとだいたい複数の「大学事務ってクソだな」みたいなブコメがつくのでなるほど大学事務というのはこのように見られているのだなと毎度思う。思うし、まあそれがまるっきり的外れでないことも実際あることは認めざるを得ない。自分にできることはクソでない仕事を毎日していくことと確かにクソである仕事を少しでもあらためようと努力することしかない。
アノニマスの坊や達、こんばんは
僕だよ。
前回の記事
ハッカーになりたい君たちの要望に応えるべく再び黄泉の国から舞い戻ってきたよ。
ハッカー…素晴らしい響きだ。
皆それになりたいと思う。
ハッカーになりたいという若い子は恐らくクラッカーみたいなのになりたがっているだろう。
中高生くらいならばなりたいと思っても、どうなるのか誰も教えてくれない。
親切な人たちが教えてくれるYahoo知恵袋などで『ハッカーになりたいです』とか書くとどうだ？
「貴方のいっているのはクラッカーですね？ハッカーとは別物ですよ」
清く正しい中学生がなんだか気を利かせて、「ホワイトハッカーになりたいです」とか「ハッカーになりたいです違法行為はしません」
などなど、変に気を使っている。
そうだ！なろう！！裏の世界の人間になろう！！そして世界を変えるんだ！！
ハッカーと言っても色々居るわけだ。
撮り鉄とか葬式鉄とか、ウィルスをばらまくハッカーとか、脆弱性を見つけて小銭稼ぐハッカーとか、OS作るハッカーとか、セキュリティポリシー精読して炎上させるハッカーとかね。
ウィルスというのは細胞を持たないが遺伝子をもつ最小の生物なのだが、細胞を持たないため非生物とも言われている構造体だ。非生物らしく結晶化もできる。
宿主となる細胞に増殖をしていく。
そのウィルスがコンピュータ世界に入り込み進化したものがコンピュータウィルスと言われていて、生命の謎を握る存在なのだ。
こう言われてもピンとこないだろうから、君たちにわかりやすいモノで表現するとすると
つまり『電光超人グリッドマン』に出てくる怪獣のようなものだと思ってくれればいい。
ブラック、そう闇と言われるハッカーたちは自分や自分の所属する集団のために違法行為を厭わない連中だ。
プログラマはスキルによってその仕事のスピードは20倍にも40倍にも開きが出ると言われている。
その特A級のハッカーはウィザードと言われるが、そのとおり魔導士のような不思議な力を使う。
しかし謎の力の仕様変更により納期は変わらず工数が9人月になった。
にもかかわらずだ納期は間に合い、しかも！稼働時間も3人月分しか計上されていない。
これは何処かのタイミングで時を止めていると言われている。
たまに勤務管理システム上は有休になっているが、入館ログには出勤の形跡があることがある。
これは休みと仕事の状態が重なり合っている量子力学的な状態を不思議な力で作り出しているのだ。
量子コンピュータは0の状態と1の状態が一つのビットで同時に表現できると言われているが、ブラックハッカーはすでに人間の身でありながら実現しているのだ。
事実量子コンピュータはブラックハッカーの脳を再現する形で実現しようとしている。
量子コンピュータを作っている企業の下請けに大量のブラックハッカーが居るのもそういうわけだ。
ウィルスをばらまくハッカーもいると言ったがブラックハッカーもその能力を持っている。
例えばインフルエンザやエボラ出血熱などを持って出勤するのも彼ら得意技の一つだ。
また、違法行為も厭わない。
どんな違法行為をやっているかは良い子の皆が真似をしてしまっては困るのでとてもここでは言えないがね…
ブラックハッカーたちは暗黒の存在とは言え我々の社会には無くてはならないものになってしまっている。
闇が深い金融業界や、日本国政府もこのブラックハッカーに頼らざるえなくなっているのだ。
おそらくマイナンバーではブラックハッカーのそうそうたる面々が集うことになるだろう。
どうだろう。
なる方法は簡単だ。
「神はXをつかうのか？」という質問について答えようと思う。
良い質問だ。
でも、いつだったか1000年位前の公会議で神はXを使うという事になったんだよ。
裏の人間は黒い画面を好み、黒い画面でいろいろやろうと思っていた。
だが、次第に艦これもやりたくなってきた。
そのうち艦これやりたさに信仰を捨てWindowsに走るものや、過激派組織APPLEに見を投じる者も出てきた。
しかし信仰心の篤い者達は我慢したBashでなんとかやろうと我慢した。
VimでTwitterをやったり、Wgetでテキストサイトを見たりしていた。
だが、XVIDEOSの誘惑には勝てなかったのだ。
その当時のハッカーたちはLinuxでもXVIDEOSを見るシステムを開発しようとした。
それが『XVIDEOS Window System』つまりXだ。
Xは黒い画面とXVIDEOSの間から妥協として生まれたが、そのうちそれでも良いかという空気になりXは流行った。
なんとDMMに登録するとAVの動画も見れるサービスがあることをしることになった。
Linuxでは艦これは出来てもDMMの動画を見ることは出来ない。
悪しきWMVで公開されてDRMがかかっているし、ストリーミングも何故か映らないのだ！！
XVIDEOSの細切れで続きが何処にあるかわからないAVよりも、有料だけども安心して見れるDMMのほうが良いというものが増え
そうやってLinuxは信者数を減らしてしまい今では生きる場所は裏社会のみになってしまったのさ。
そういう経緯があるので、神はXを使っていることになっている。
受託開発やSIer、そこで採られる人月での見積と契約はスタートアップ・Web系・ベンチャーな方々から軽蔑されがちです。
けれど社会のインフラや企業の基幹を担うこともある重要なシステムでは残念ながらこれらの手法をとらざるを得ないのが現状となっています。
これを打破するイノベイティブでエポックメイキングでパラダイムシフトな変革は期待されていますが、文化や慣習、人手不足とレガシーコードはなかなかそれを許してくれません。やり玉にされがちなSIerのスタンスだけに帰せる問題ではないのです。
そんな状況でもわれわれSEは社会の繁栄のために、愛する（現在の/未来の）家族のために、そしてご飯を食べていくために働く必要があります。
しかし、この業界で難しいのは流動性が高い割にキャリア形成が難しいこと、自分の精神的・肉体的な健康を損ないやすいという問題があることで、苦労されている方も多いかと思います。
そして働く人が多いにもかかわらず、会社・システム・プロジェクト固有の用語や知識が多いことやセキュリティポリシーに抵触するか微妙なこともあってかなかなかノウハウや知見が共有されていないように感じています。一方で個々のプロジェクトに埋没している問題が共有されていないことへの懸念もあります。
今回は、これを打破するためにアドベントカレンダという不思議文化に乗ってみなさまがこれまで得てきたノウハウをドキュメント化していただけないかというご提案になります。ノウハウの共有は日本のソフトウェア開発文化の発展に、問題の共有は社会（発注企業・元請け上層部含む）への啓発につながればと期待しており、なにより自分がみなさまの環境に興味を持っています。
ぜひ、書いてみませんか？
トラックバック・ブクマを送っていただければここにリンクを貼っていきます。増田でも可ですし、重複・フライングも気にしません。
