A Day In The Boy's Life -68ページ目

A Day In The Boy's Life

とあるエンジニアのとある1日のつぶやき。

9割がバイトでも最高のスタッフに育つ ディズニーの教え方/福島 文二郎
¥1,365
Amazon.co.jp


人を育てるのは人なんだなと改めて思わせてくれる本

あのディズニーの教育メソッドが書かれているわけですが、確かにあれだけの多くのキャストが働いている中で何故みんな同等に親切で笑顔にあふれ、楽しそうな職場になっているのかという点を疑問に思っていましたが、その理由がここに詰め込まれています。


ただ、どれもそんな独特の方法でもなく、自分自身もそんなこといわれたことがあるなぁと思うぐらいごくありふれた教育方針やカリキュラムです。

しかし、現場の環境が人を育てるのに最も適した環境というように、その教育を徹底していることがわかります。

そして、人が人を育てその循環をうまく利用しているんだなという点も。


一般の企業であれば、新入社員に対して一般的な社会人としてのマナーとかは通常教えるでしょうが、それは講師と社員の1対Nの関係で、互いが高めあったりするような雰囲気が作られることはなかなか無かったりもします。

個々がライバル視することはあったとしても、その現場にいる人たち皆が互いを手本としたり、支えあうその空間を作り出すことはなかなか難しいものです。


あれだけの多くの社員がいて、しかもそれがアルバイトということであれば、現場の教育というのが如何に大切なのかという点がわかりますし、あのディズニーの環境というものが決してキャラクターやアトラクションというものだけで成り立っているわけではないということからもその大切さが伺えます。

現場のアルバイトの個々がディズニーという空間を作り出しているということを、現場の人たちが一番よく理解しており、それを支えているのでしょう。


それは、どの企業でも同じことでしょうし、教育の大切さというものを理解はしていると思いますが、なかなか最初の教育カリキュラム以降というのは社員個々に任せきりという現場が多いのではないかと思います。

ただ、単に小うるさく教え込むだけが教育ではなく、現場で自律しあう教育というものがあり、それがディズニーの環境ではよく作用しているんだなと感じることができます。



目次


CHAPTER1 育てる前に教える側の「足場」を固める
01 ディズニーが考える理想の上司・先輩とは?
02 「教える喜び」を感じないと後輩は育たない
03 自分が扱われたように、後輩は人を扱う
04 「見て覚えろ」では後輩は育たない
05 ミッションを正しく理解し、後輩に伝える
06 行動指針をもち、優先順位をはっきりさせる

CHAPTER2 後輩との信頼関係を築く
01 リーダーシップをもって後輩と接する
02 後輩に「いつも見てくれている」と意識させる
03 何か感じたら、すぐに「声をかける」
04 仕事の成果だけに注目しない
05 間違った考えに染まった後輩を変える!

CHAPTER3 後輩のコミュニケーション能力を高める
01 後輩の”存在”を認める
02 後輩に、常に思いやりを持って行動させる
03 価値観を共有する
04 後輩との面談・話し合いは、ここに要注意!
05 後輩の状態に合わせて対応を変える

CHAPTER4 後輩のモチベーションを高める
01 笑顔のあふれる職場を作る
02 仕事の重要性を認識させる
03 「誇り」をもてる環境をつくる
04 指示するときは、必ず「理由」も伝える
05 後輩によい点を見出せば、すぐにほめる

CHAPTER5 後輩の自立心・主体性を育てる
01 後輩に自信をもたせる
02 後輩に「スモールステップ」をもたせる
03 後輩に自立のチャンスを与える



レンタルサーバーをさくらVPSに乗り換えてみました 」から、4ヶ月ほどさくらVPSのサーバー(CentOS5.6)を利用しているんですが、アタックの数がすごい・・・。


で、サーバーでよく利用されているパスワード一覧とかって話題になってたりするので、不正なアタックをする際に利用されているユーザーってどんなもんがあるかを調べてみることに。

以下、4ヶ月間でSSHによる不正ログインを試みたときに利用された上位30のユーザー一覧。


134187 root
 35070 admin
 19524 test
 13251 oracle
 12382 user
 10441 backup
  8593 web
  8288 mysql
  7986 amanda
  7436 robert
  7108 info
  7056 paul
  6918 guest
  6823 eric
  6617 michael
  6579 download
  6536 adam
  6480 student
  6384 martin
  6268 patrick
  6241 matt
  5905 sales
  5435 sarah
  5196 www
  5125 alberto
  4988 upload
  4817 master
  4680 cyrus
  4669 sam
  4116 bruce

左側の数値は不正アタック数。

rootだけで10万回超えている・・・。

oracleとかmysqlユーザーとか、ソフトウェアをインストールする際に作る必要があるよく知られたユーザーというのは、危険かもしれませんね。

あと、テスト的に作ったユーザーと思われるtestとか、Web関連(webとかwwwとか)のユーザーもよく利用されているようです。



SSHの不正なアクセス数を集計する


今回集計を取ったユーザーの元データは、/var/log/btmpのデータです。

これ自体はバイナリファイルなのでそのままでは見れないので、専用コマンドのlastbを使います。


# lastb
____     ssh:notty    mail.sozwezdie.c Tue May 17 23:52 - 23:52  (00:00)
bugs     ssh:notty    www2266ua.sakura Tue May 17 23:16 - 23:16  (00:00)
warren   ssh:notty    www2266ua.sakura Tue May 17 23:16 - 23:16  (00:00)
trudi    ssh:notty    www2266ua.sakura Tue May 17 23:16 - 23:16  (00:00)
tonel    ssh:notty    www2266ua.sakura Tue May 17 23:16 - 23:16  (00:00)
therese  ssh:notty    www2266ua.sakura Tue May 17 23:16 - 23:16  (00:00)


このデータを元に、下記のようなワンライナーで不正なアタックをしたユーザー一覧を集計します。


# lastb | awk '{print $1}' | sort | uniq -c | sort -nr | head -30


余談ですが、似たコマンドとしてlastがありますが、こちらは最近ログインしたユーザーを出すものです。

lastコマンドが参照しているのは、/var/log/wtmpファイル。

何れにせよほっとくとかなり大量のログが溜め込まれるのでローテーションを仕込んどいた方が無難かもしれません。

4ヶ月間ほっといたらbtmpファイルは800MBほどに膨れ上がってましたから・・・。


って、ことでとりあえずSSHはパスワード認証使わずに公開鍵認証を使うように設定を変更しました。





プログラマはプログラミングをしていないという現実 @ A-Listers


書いてあることが当てはまりすぎて笑ってしまった。

SIerからソフトウェアベンダ、企業内の社内情報システム部門まで多くのプログラマには上記に書かれていることが当てはまる人は多いかと思います。


個人的には、本当にプログラミング(または特定の技術分野としてのエンジニア)だけをしたいのであれば、ラボや研究機関といったところに入らないと無理なんじゃないかと思ったりします。



プログラマの仕事の現実


プログラマがプログラミング以外の仕事をしなければならないのは、入り組んだ技術の話はプログラマでしかわからないことが多いからです。

営業やプロマネは顧客との要件を決められても、内部仕様についてはプログラマやアーキテクトにお任せということになりますし、顧客との話のネタになるのはその内部仕様に言及することが多くあったりします。


技術営業という肩書きでエンジニアが営業に同行して顧客企業まで足を運び説明や質問に回答するということはよくありますし、ユーザーからの問い合わせもヘルプデスクやサービスデスクにそのソリューションがあればそこで返答できるものも多いでしょうが、数多く寄せられる問い合わせの中ではそのストックしたソリューションから解決できないものも多々出てきて、プログラマなど実際にそれを構築して仕様を熟知するメンバーエスカレーションされることになります。


特にシステムトラブルともなると、その原因の追究やログの捜査やトラブル報告書の作成に多くの時間をとられたりします。

まぁ、これはプログラマ自身が出したバグということなので身から出た錆ともいえるでしょうが、運用上のトラブルということになると、その操作方法や機能の不備ということも指摘されたりして、それを回避・解決するための案を出すことにもなったりします。

そして、その機能を改善することへの既存のシステムへの影響調査や工数の算出などプログラミングとはかけ離れたしごとをする羽目になったりもします。


まぁ、この辺はシステムのライフサイクルと共存するエンジニアの仕事のあり方による影響が多いのかもしれません。

要は本来プログラミングをするというのは開発フェーズでの話ですけど、システムを構築していくには設計やテストといった工程もあり、全体を見渡せば開発フェーズに割く時間というのはそれほど多くありません

そして、なによりも開発期間よりも保守・運用のフェーズに当たる期間の方がはるかに長くなるわけです。

システムを無事にリリースして、次のプロジェクトへ移行したとしても前のプロジェクトの保守の中で出てきた課題や問い合わせへの対応というのは多く発生し、プログラマの本来の仕事の妨げともなっています。


ただ、プログラマという仕事がプログラミングだけしているというのは、結構昔のイメージで今はシステムの形態とともにその仕事の範囲や役割というものも拡大してきているのだと思ったりもします。



その他のプログラマのお仕事


先のサイトで書いてある16の項目以外に、個人的にプログラマの仕事してあるのは下記のようなものがあったりします。


  • バグ再現のための試行

ユーザーからの問い合わせは、何もすぐに判断できるようなものばかりではありません。

そのようなものはテスト段階で数多く潰せるので、むしろリリース後に問い合わせがあるのはユーザー環境によるものだったり、特定の入力条件や操作条件に合致した場合など、レアケースのものの方が多かったりします。

それらについて、わかりやすい表現で問い合わせされることもまた稀で、数少ない情報からそのバグが再現しないかと試行錯誤したりします。


多くは開発・テスト環境というものが存在するでしょうが、そこに実際に入力したデータを投入してみたり、本番環境から移行してみたりと、その準備のためにも多くの時間がとられたりもします。

まぁ、どうしてもわからない場合は、「システムの調子が悪かったので、もう一度やり直してもらえますか」とか、お茶を濁して逃げることもあったりしますがね・・・。


  • 開発メンバーへの教育やレビュー

これはエンジニアに限った話ではないでしょうけど、他のメンバーへの教育にも多くの時間を取られます。

チームをリードする立場だったり、アーキテクトの役割を担った場合は、使用するフレームワークや開発環境、コード標準の書き方などの開発規則を周知・教育するのにも時間をとられるでしょう。


それらを確認するためにコードレビューをすることも多くなりますし、開発ライブラリの利用方法を書くにするためにサンプルのソースコードを読んだりすることにも時間がかかります。

ひどい場合はソースを書く時間よりソースを読む時間の方が長いということもあるかもしれません。


  • システムへの影響調査

先にも書きましたがシステムへ改修を加える場合は、まず現在運用しているシステムへの影響調査というものをさせられることが多かったりします。

それによりどれくらいの工数で改修が行えるかや、改修を加えることでどういったシステム上の影響や運用の変更が必要かということを洗い出したりするわけです。


さっさとソースを変えてしまいたいという衝動を抑えながら、頭の中で改修後のイメージや画面がどう変わるかのイメージを練っていったりします。

この時点はやるかやらないかというのがはっきりしない場合が多かったりしますので、下手に手を出すこともできませんし、顧客側もそれによってどういう悪影響があるかなんてわからずに言ったりしていますので、その辺を分析して実施可否の判断材料を洗い出す作業に追われたりします。


で、それなりの時間をかけて報告した結果、「そんな面倒なことになるならやめましょう」とか一言告げられて完了したりすることもしばしばあるわけですね・・・。