承認欲求の抑え方を教えてやんよ
twitterのタイムラインを眺めてたら知人がつぶやいていた。
エベレストより高い自尊心と承認欲求をかなぐり捨てて、マリアナ海溝のように深い寛大さを持てるようになりたい。
— QUANON (@quanon86) 2016, 3月 9
リプしようかと思ったけど長くなりそうだったし、1時間以上前の話題には返信しないというマイルールにより、ひっそりブログに書こうと思う。
さて、この前半部分の承認欲求の抑え方について持論を述べる。（ちなみに元ツイは「捨て方」だけど、それは手段であって目的ではないだろうから別にいいよね）
承認欲求といえばやはりマズローの欲求段階説が想起される。欲求段階説とは、人間の欲求は段階的になっており低次の欲求が満たされると高次の欲求が発芽する、というやつだ。承認欲求の部分でいえば、所属欲求が満たされることにより発芽する。逆説的にいえば、所属欲求が満たされなければ承認欲求は発芽しない。つまり、あえて所属欲求が満たされない状態をキープできれば承認欲求に苛まれることはない。その代わりに今度は所属欲求に苛まれることになるかもしれないけど、それでもいくらかはマシじゃないかと思う。 では所属欲求とは何か？社会的欲求と言われることもあるが、ここでいう「所属」とは社会的な身分とかそういうことではないと思う。ややスピリチュアルな言い方をすれば、「心の拠り処」といったところではないだろうか。悪くいえば「依存」かもしれない。たとえば、会社でも家庭でも何らかのコミュニティでもよい。欲求段階説によれば所属欲求の前段は安全欲求である。つまり肉体的な安全を求めた後は、精神的な安全（安らぎ）を求めるということなのだろう。さらにその状態を盤石に、永続させるためにはその集合体に受け入れてもらわねばならない。そのために自分を認めてもらう必要があり、承認欲求として顕れる。
ようやく本題だけど、ではどうすればいいのか。
- 何かに所属せずに適度に距離を保つ。これは会社を辞めるべきとか人とコミュニケーションを取らないようにするということではなく、精神的な自立を意味する。あくまでも自分は自分。
- 過度な承認欲求は自己顕示欲と認識する。きっと人間が成長するうえで承認欲求というものは大事なんだろうけど、それも度が過ぎれば反対に他者から疎まれることになる。それを意識すれば承認欲求も多少は抑制されるのではないか。ただし正当な承認欲求と自己顕示欲の境界を見極めることは難しいと思う。
これらはあくまで私の持論であり、私は門外漢なので、自信を持って勧めるというはしない。だけどこんなのでも彼の一助となれば幸いである。
ただし私は欲求段階説について深く学んだわけではないので、解釈が間違っているかもしれないことは留意されたし。
--
冒頭で、直接リプせずブログに書く理由をいくつか挙げたが、実はもう一つある。それは私の天邪鬼な性格というか、いたずら心というか、「このブログにたどり着けるかな？」という挑戦でもある。というのも、私は知人に知られることなくひっそりと記事を書くのが結構好きなのだが、Qiitaにひっそり書いていたのが筒抜けだったと先日発覚したからである。そう、これはリベンジでもあるのだ。（まぁそれは大げさで、こんな記事を読んでも読まなくても彼の人生には全く影響しないだろうから、ちょっとした悪戯である）
現実的な方法でこの記事を読むには、RSSを購読していたというパターンくらいしかないんじゃないかと思うけど、その確率はきっと10%もないと思う。
グダグタになってる気がして、ちゃんと推敲したいけどもう眠たいのでこの辺でzzz
プロジェクトマネジメントで大事だと思うこと（チラシの裏）
先日、プロジェクトマネジメントの勘所を聞かれた。
自分にはそんなに大層なことを語る知識も経験もないけど、問われたからには何かしら答えるべきかと思い、
拙いながらも普段自分が考えていることなどを話した。
その際に思いつくままに話してしまったせいで、話せなかったことがあることに気づいた。
チラシの裏にでも補足を書こうかと思ったけど、チラシが無かったのでブログに書こう。
戦略と戦術
プロジェクトを遂行するには、戦略と戦術があったほうがいいと思う。
両者の違いは知ってるだろうし、知らなくてもググればすぐに見つかると思うので割愛する。
なぜ戦略と戦術が必要かというと、戦略というグランドデザインがあれば戦術がぶれにくくなるからである。
状況の変化が激しい開発現場においては、これは結構重要なことである。
他にも戦略と戦術の関係性や重要性についても、ググればたくさん見つかると思うので割愛する。
おそらくシステム開発などに関わらず、一般的な話として書かれている記事が見つかるだろうが、十分にシステム開発にも通じることだと思うので読んでみて欲しい。
考えるべきことと考えなくていいこと
今まで関わってきたエンジニアには、常に考えていないと死ぬ病気なのかと思うほど、やたらと考えこむ人が多い気がする。
考えることは大事だと思うけど、万事がその調子では駄目だと思う。本当にそれは考えないといけないことなのか、まずパッと直感で判断することを薦めたい。
考えなくてもいいこととは、それがもたらす影響が小さいものや他の要因で変化しやすいものなどである。加えて考えても仕方ないものもある。
それを判断した上で、これは考えるべきことだと思えば、じっくり考えればいい。
言うのは簡単だが、そういう人にとっては直感で判断ということも難しいかと思うが。。。
どうでもいいことはなるべく考えないようにして、その分他のことをもっと深く考えたり、おざなりになってることに意識を向けたり、リソースを有効活用するべきだと思ってる。
特に小さいプロジェクトの場合は開発とマネジメントを兼務することもしばしばあり、そんな状況で一つのことに時間を取られたら、他の考えないといけないことがオーバーフローしてしまう。そしてオーバーフローしてしまったのは十分に考えるまもなく決断を迫られるため、それだけは避けるべきである。
現在価値と将来価値
会計には割引現在価値（逆が将来価値）という考えがある。例えば何らかの機械を買う場合、5年後にその機械を除却する際に費用が1万円かかることが明らかとする。この場合、購入時に将来の除去費用も負債として計上することになるが、ここで出てくるのが「5年後の1万円の現在の価値はいくらか」という割引現在価値である。
つまり、現在の1万円≠5年後の1万円、ということである。（一応補足すると、為替レート云々の話ではない）
これは、その金額を貯金するなり投資するなり資産運用により利息などを得ることが可能だからである。
会計になじみがなくても、行動経済学をかじったことがあれば、現在価値と将来価値については縁があることだろう。
前置きが長くなってしまったが、この現在価値と将来価値が、プロジェクトにどう関わってくるかというと、主に優先度の判断をする際に用いる。
例えば、リファクタリングしたい箇所があったとする。今リファクタリングするコストは1である。しかし放置すれば色々な箇所から使用され複雑になりコストは1.5になる。ここで今リファクタリング(1)以上の価値があるものがあれば、それを優先すればいいし、なれけばリファクタリングすればいい。あるいは将来のコスト1.5が許容できなければ今する。
逆の例では、最終的には各機能で監査ログを出さなければいけないことが最初から分かっているとする。各機能の実装が終わってから最後のまとめて監査ログを仕込むとすればコストは1である。しかし、前もって各機能実装時に監査ログを仕込めばコストは0.5である。
後でやるよりは今やった方がいいかなと思うことがあるだろうけど、その際になんとなくではなく、ちゃんとその価値を計算することが肝要。
実際には数値化することは難しいけど、5段階くらいに分類して考えるだけでも随分違うはず。
ちなみに、大体の場合において計算は単利じゃなく複利である。初期のちょっとした投資が後々絶大な効果を発揮したり、放置してた小さな傷が致命傷になったりってこと。
あまりいい例が思いつかず、分かりにくいと思うけど、ニュアンスは伝わったものと思う。（思いたい）
# 読み返して気づいたけど、上記の例では資産と負債が混じっていて一層わかりにくかったかと思う。。。まぁ大意は変わらないので修正しない。
名人に名手なし
麻雀に「名人に名手なし」という格言がある。（もしかすると元は麻雀ではないかもしれない）
名人とは常にその時々の最善手をとり続けるものだという意味である。それは奇をてらうわけでもなく、華もなく、ややもすれば周りで見てる人には凡手のように見えることがある。
しかし、どんな状況にあっても冷静に最善な判断を積み重ねること、またはそれらの組み合わせにより名人を名人たらしめている。
何が言いたいかというと、これを読んでる人はおそらくマネジメントの手法や方法論などある程度の知識などを持っていると思う。 あとは、常に冷静にそれらの武器を使うか（使えるか）どうかだけだと思う。銀の弾丸はないけれど、にんにくや十字架はある。それらをうまく組み合わせて使うことで退治できるのではないだろうか。
あまりプロジェクトマネジメントに関わらない内容になってしまった。
なぜ計画通りに開発できないのか
先日、こんなブログを読んだ。
なぜ開発で見積り失敗して忙しくなりがちなのか(アジャイルな見積りと計画づくり読んだ) - $shibayu36->blog;
で、以前から思うところがあったので、ブログに書いてみる。
というのは、この手の話がされる時「どうやって精度の高い見積り・計画を立てるか」という点ばかりで、「どうやって計画通りに開発を進めていくか」という話が殆ど無い。そこにずっと違和感を覚える。（冒頭のブログ、書籍はタイトル通り見積り・計画について書かれているので当然といえば当然だけど・・・）
「そんなの（計画通りな開発の進め方）なんて基本だし、わざわざ話すことでもない」という暗黙のコンテキストなのかもしれないけど、自分が見聞きする限りでは、あまり分かっていない人が多そうなので上から目線で書かせてもらう。
いつも、「計画通りにいかないな、どうやったら精度の高い見積りができるんだろう」なんて言ってる人に読んで欲しい。
ちなみに、ここで書くセルフとは自分自身のことだったり自チーム・自プロジェクトだったりする。自分が制御・影響可能なもののこと。
また、自身に責任のない外的要因による計画遅れは対象にしていない。そういう場合は、まずその外的要因の発生源に負担してもらうのが基本であるから。例えば、顧客都合による仕様変更であればリスケするなど。
見積りと計画はそんなに悪くない
新人でもない限り、大体の人は概ね妥当な見積りと計画ができているように思う。
ではなぜ計画通りにいかないのか。
まず第一に、本人に計画通りやろうという気がないように思える。
これは、最初に見積りに基づき計画を立てて、それだけで終わってるパターン。
不可抗力な外的要因等で想定外のタスクが発生することがある以上、100%正確な計画なんて無理。だからその分のバッファを計画に組み込む。
しかし、なぜかそこで終わって、日々変わる状況を把握していない、ないしは楽観視している。
麻雀で例えると、半荘開始時に「2万点分和了ってトップとろう」と考えて、以降は点棒状況を把握していないようなもの。自分の点棒が減ればその分余計に和了らないといけないし、他家が2万点分あがるのもまた然り。
あと、元々の計画値とバッファを混ぜるのもあまり良くないと思っている。理由は
- 今バッファがどれだけあるのか、が分かりにくくなる。
- 次に見積りを立てる際に、実際の計画値とどのくらい乖離していたのかが把握しにくいので、見積り精度があまり向上しない。
状況を早く察知する
新人の頃に誰でも一度はリーダ等の管理的立場の人から「進捗遅れなどは早めにアラームあげてほしい」というようなことを言われたことがあると思う。
その一番の理由は、早期に把握出来ればセルフリカバリしやすいからだと思う。
麻雀で例えると、点棒が平たい状況で他家(子)に倍満を直撃された場合（点差が32,000点）、それがラス前だと絶望的だが、開局早々ならまだ希望が持てる。
一発逆転なんて期待しない
うすうす「予定より遅れている」と感じていても、「まだ何とかなる。」と楽観視するケースも多い。根拠があるならいいけど、大抵はそうではない。
早めに対応することが肝要。その場合も一発逆転を狙うのではなく細かく刻んでいく。
色々な可能性と、その場合の対応を常に考る
開発を進めていく上でも戦術があって然るべきだと思っているけど、あまり見たことない。淡々とタスクをこなしていくだけということが多い。
もっとタスクの順を有機的に組み替えたり戦術を立てればいいのにと思う。
麻雀で例えると、配牌開いた時点で「ココがきたらコレを切る。コレが出たら鳴く。ココが入ったらリーチ。」というように色々考えておく。それも自摸和に合わせて毎回考え直す。
ここで大事なのは確率に応じて優先度をつけること。毎回全パターンをシミュレートするのは難しいので発生確率（自摸和る確率、出る確率）が高いものから考えていく。
全体を見る
通り慣れたまっすぐな道路を車や自転車で通るとき、2・３個先の信号を見て、速度を若干調整すると思う。2個先の信号が今赤になったから、このくらいの速度で進めばあの交差点に差し掛かるくらいで丁度青になるかな、という具合に。他にも路側帯を自転車が走っていて追い越そうとする前には減速したり周囲を確認したり。例をあげればきりがないけど、開発も同じことだと思う。
車で例えたから麻雀の例いる？と思わなくもないけど。
他家の仕掛けが入ったら自分の手と場の状況など全体を見て、押すか引くかの判断したり。親リーチが入った際に他家が軽そうな仕掛けを入れたらその手助けをしてあげたり。
まとめ
そういうのが苦手な人は麻雀すればいいんじゃないかな
Open Flash Chartでレーダーチャートを作成
Railsのプラグインopen_flash_chartでレーダーチャートを作成しようとしたんですが、なかなか上手くいかなかったので、結局PHPのサンプルソースをRubyで書き換えました。
RAILS_ROOT/app/controllers/test_it_controller.rb:
class TestItController < ApplicationController def index @graph = open_flash_chart_object(600,300,"/teams/graph_code_radar") end def graph_code_radar chart = OpenFlashChart.new chart.set_title(Title.new('Radar Chart')) values = [30, 50, 60, 70, 80, 90, 100, 115, 130, 115, 100, 90, 80, 70, 60, 50] spokes = ['a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p'] vals = [] values.each_with_index do |value, i| tmp = SolidDot.new(value) tmp.set_tooltip("#val#<br>Spoke: #{spokes[i]}") vals.push(tmp) end line = Line.new() line.set_values(vals) line.set_width(2) line.set_colour('#FBB829') line.set_key('Hearts', 10) line.loop() chart.add_element(line) r = RadarAxis.new(150) r.set_steps(10) r.set_colour('#DAD5E0') r.set_grid_colour('#EFEFEF') spoke_labels = RadarSpokeLabels.new(spokes) r.set_spoke_labels(spoke_labels) chart.set_radar_axis(r) tooltip = Tooltip.new() tooltip.set_proximity() chart.set_tooltip(tooltip) render :text => chart.to_s end end
RAILS_ROOT/app/views/test_it/index.html.erb
<script type="text/javascript" src="/javascripts/swfobject.js"></script> <%= @graph %>
これでちゃんと表示されました。
で、それまでなぜ上手くいかなかったかというと、
Line.new()しているところを、LineHollow.new()とかLineDot.new()としていたからみたいです。
そうすると線の種類はどうやって設定するんだろう？
もうちょっと調査が必要ですね。
ちなみに参考にしたPHPはこちらです。項目名を表示させたかったので以下のコードを追加しています。
spoke_labels = RadarSpokeLabels.new(spokes)
r.set_spoke_labels(spoke_labels)
Flexigridを使ってみた。
Tableを簡単にかっこいいグリッドにしてくれるjQueryプラグインを見つけたので試してみました。
わずか数行で"ものすごいテーブル"に! - jQueryプラグイン「Flexigrid」 - マイコミジャーナル
プラグインのダウンロード等
・Google Codeからflexigrid.zipをダウンロード
・展開したフォルダからflexigrid.js(圧縮版はflexigrid.pack.js)と\css\flexigrid配下のflexigrid.cssとimagesフォルダを任意の場所にコピー
僕はRailsで使いたかったので、以下のように配置
展開フォルダ\flexigrid.js → RAILS_ROOT\public\javascripts
展開フォルダ\css\flexigrid配下全て → RAILS_ROOT\public\stylesheets
なお展開フォルダ\css\imagesに[開く],[閉じる]アイコンが入っていますが、今回は未使用なのでコピーしていません。
※prototype.jsと共存させる場合はFlexigridをprototype.jsと一緒に使う方法 - 電脳戦士ハラキリ -SE道とは死ぬ事と見つけたりを参考に、hideプロパティを置換します。
選択された行を取得する。
Flexigridのデフォルト設定ではTableの各行をクリックすると、その行が水色になります。
これはクリックされたtr要素にtrSelectedというclassを設定しているからです。
（もう一度クリックされた場合はclass属性を削除する）
なので、今選択されている（水色の）行を取得するにはtrSelectedをキーにセレクタを書けばいいです。
jQueryだとこんな感じ。
$(function() { $('#hoge tr').click(function(){ $('.trSelected').each(function(){ alert($(this).text()); }) }); });
ちなみにデフォルトでは、偶数行には'erow'というclassも設定されますので、
if ( $(this).attr("class") == 'trSelected' )
みたいに書くと、正しく動作しません。（セレクタは大丈夫です。）
jQuery-UIにもグリッド入れてほしいです。
Arduinoで3つのLEDを点滅させてみた
先日Arduinoというものを知り、↓これを買ってみました。
- 出版社/メーカー: スイッチサイエンス
- メディア: おもちゃ＆ホビー
- 購入: 64人 クリック: 1,164回
- この商品を含むブログ (50件) を見る
まず、ブレッドボードについて、
電子工作入門:ブレッドボードを使ってみよう
で勉強。
そして↓を見ながら実験。
SecondWave:Arduinoを始めよう
SecondWave:ArduinoでLEDを光らせる
ブログの最後に「次回は、さらにLEDを増やしてみたいと思います。」と
書かれているけど、以降書かれていないようなので自分で試してみました。
スケッチ
まずはスケッチ。LED2個を交互に光らせるコードはあるので、
LEDを3個にするのは簡単。
/*
Blink
Turns on an LED on for one second, then off for one second, repeatedly.
This example code is in the public domain.
*/
void setup() {
// initialize the digital pin as an output.
// Pin 13 has an LED connected on most Arduino boards:
pinMode(13, OUTPUT);
pinMode(12, OUTPUT);
pinMode(11, OUTPUT);
}
void loop() {
digitalWrite(13, HIGH); // set the LED on
digitalWrite(12, LOW); // set the LED on
digitalWrite(11, LOW); // set the LED on
delay(500); // wait for a second
digitalWrite(13, LOW); // set the LED off
digitalWrite(12, HIGH); // set the LED on
digitalWrite(11, LOW); // set the LED on
delay(500); // wait for a second
digitalWrite(13, LOW); // set the LED off
digitalWrite(12, LOW); // set the LED on
digitalWrite(11, HIGH); // set the LED on
delay(500); // wait for a second
}回路
次は回路。今までのサンプルを見て、LEDの-極（短い方）を集約してGNDに繋げてやればよさそう。
ブレッドボード上の4番のラインにLED1(赤)の+極、
5番のラインにLED1(赤)の-極、
5番のラインにLED2(緑)の-極、
5番のラインにLED3(青)の-極、
6番のラインにLED2(緑)の+極、
7番のラインにLED3(青)の+極を差す。
（ラインの番号は何番からはじめてもOKです。）
基板上の11番ピンと7番のラインを、
12番ピンと6番のラインを、
13番ピンと4番のラインを、
GNDと5番のラインをジャンパー線でつなぐ。
これで上手く3つのLEDが交互に点滅するようになりました！
ちなみにLEDの足の長さが足りない場合は、
別のラインに-極を差して、そのラインと5番のラインをジャンパー線で
つないでやれば大丈夫でした。
cpan2rpmでのインストール時エラーの対処方法
こちらのサイトを参考にさせてもらいながらcpan2rpmでインストールしたけどいくつか問題があったので対処方法をメモ。
『Perlモジュールパッケージ管理システム導入(cpan2rpm)』
ちなみに、CentOS5.5でcpan2rpmのバージョンは2.028-1。
まず普通にインストールしようとしてみる。
# cpan2rpm --install URI::Find
すると以下のエラー。
-- cpan2rpm - Ver: 2.028 -- Upgrade check Fetch: HTTP -- module: URI::Find -- Using cached URL: http://search.cpan.org//CPAN/authors/id/M/MS/MSCHWERN/URI-Find-20100505.tar.gz Tarball found - not fetching Metadata retrieval Tarball extraction: [/usr/src/redhat/SOURCES/URI-Find-20100505.tar.gz] Module::Build unloadable Can't locate Module/Build.pm in @INC (@INC contains: /usr/lib64/perl5/site_perl/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl /usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi /usr/lib/perl5/5.8.8 .) at (eval 22) line 2. BEGIN failed--compilation aborted at (eval 22) line 2. -- Done --
なんか、「Module::Build unloadable」って言われてるので、perl-Module-Buildを入れてみる。
rpmforgeをyumに登録してあれば以下のコマンドでOK
# yum install perl-Module-Build
再度インストールしようとしてみる。
# cpan2rpm --install URI::Find
また、エラー。
-- cpan2rpm - Ver: 2.028 -- Upgrade check Fetch: HTTP -- module: URI::Find -- Using cached URL: http://search.cpan.org//CPAN/authors/id/M/MS/MSCHWERN/URI-Find-20100505.tar.gz Tarball found - not fetching Metadata retrieval Tarball extraction: [/usr/src/redhat/SOURCES/URI-Find-20100505.tar.gz] No version found, please use --version option. Stopped at /usr/bin/cpan2rpm line 580. -- Done --
「please use --version option」って言われてるので試してみる。
# cpan2rpm --version 20100505 URI::Find
またまたエラー。
-- cpan2rpm - Ver: 2.028 -- Upgrade check Fetch: HTTP -- module: URI::Find -- Using cached URL: http://search.cpan.org//CPAN/authors/id/M/MS/MSCHWERN/URI-Find-20100505.tar.gz Tarball found - not fetching Metadata retrieval Tarball extraction: [/usr/src/redhat/SOURCES/URI-Find-20100505.tar.gz] Generating spec file SPEC: /usr/src/redhat/SPECS/URI-Find.spec Generating package Signing package (pass phrase required) エラー: マクロファイル内で "%_gpg_name" を設定しなければなりません。 パスフレーズのチェックに失敗しました。 RPM build failed [1] at /usr/bin/cpan2rpm line 1052. -- Done --
根本解決にはなってないかもしれないけど、とりあえず--no-signオプションをつけてみる。
# cpan2rpm --version 20100505 --no-sign URI::Find
ようやくインストール成功！
