続・Think! Think! Think!

世の中について考えてみる。後、webサイドの知識を書いています。※時々ネタあり。

「嫌われる勇気」を読んで、考えたこと。

本 心理

過去記事です。消えたデータの一部が復旧？できたので。

アドラーの心理学

アドラーの心理学wiki

どもども。天パーなのでこの時期は頭がもさもさしてるundertreeです。w

冗談さておき、久しぶりに胸を打たれるような衝撃を感じた１冊です。

哲学、心理学的な目線でみるととても難しいですが、

この本は、少年と哲人の会話式で作成されていて、

理屈っぽい人は、まさに少年になりきれるので、とても面白く読めると思います。

※ちなみに自分はかなり理屈っぽいです。。。小さいことは屁理屈をいうなと良く言われたな〜

小説的な感じで、想像して、考えて、自然体で読むことをお勧めしたいです。

自己啓発って言葉が入っているが、全くそうではなくて、

悩める少年と悩んできたおじいさんの話って感じかな。

読んでて重要なのは、想像できるか。

あぁーあれはそういうことか。とか、自分って実はそうだったのか。など

身の回りに当てはめて読むことができたら、きっと何か得られると思う。

もし、そう思わなかったら、すぐに閉じて1,2年後また読んで見てほしい。

原因論 => 目的論

ここからは、本から得たことを、少し書いていきたいと思います。

原因論とは コトバンク

簡単にいうと、○○したから○○になった。

例) 小さい頃に犬に噛まれたから、犬が嫌いになった。

目的論とは コトバンク

正直何言っているの？って感じだと思いますが、

簡単にいうと、○○だから○○だと思う。

例) 犬が嫌いだから、小さい頃に噛まれた記憶がいつまでも残っている。

この大きな違いが変わるでしょうか？

原因論は、過去を対象としており、変えられないことを前提としています。

しかし、目的論は、現在を対象としており、変えられることを前提としています。

これは、考え方を少し変えるだけですが、人生が大きく変わることだと思います。

いい大学をでたから、いい仕事につける。と思っている親はよくいますが、

これは対象が過去になっています。

いい大学をでたというのは、過去であり、現在ではありません。

仕事につくのは現在です。

過去によって、未来は決まりません。

決まるのは、現在によってです。

現在実力があるから、いい仕事につけるのです。

今頑張っているから、いい仕事につけるのです。

過去遊んできていても、今から頑張ればいい仕事につけるのです。

さぁーあなたは、原因論と目的論どちらの考えかたをもっていますか？

もしくは、どちらの考え方を持ちたいですか？

過去は振り返るものですが、縛られるものではありません。

これだけは、気をつけてください。

全ては人間関係

全てを人間関係である。

※アドラーの心理学

人類は麺類である。

※カップヌードルミュージアムにあった名言

とまぁーようは、麺とスープの関係はとても大事。

ではなくて、

人を動かす全てのことは、人間関係が元となっている。

って感じかな。

簡単にいうと、

もっとうまくなりたいのだけど、センスがないから駄目だ

という人がいるとする。

心理的には、

そこまでうまくなる必要はないかな

と心のどこかで思っている可能性が高くて、センスの問題ではない。

身近な例だと、頑張っている説がある。

Aさん : 頑張っているけどできない。

Bさん : それ努力がたりないんじゃない。

Aさん : あなたに何がわかるのよ！

Bさん : 頑張ってだめなら、もっと頑張るしかなくない？

・・・

はい。喧嘩。。。

頑張っているけどできない。という人は、

  • 頑張っていると周りに認めてもらいたい
  • しょうがないと自分を慰めたい

と思っているということを、アドラーの心理学では言っている。

ちょっとまった！！

あまりにも非常な心理学だ！と思った人は、心の優しい人かもしれないですね。

しかし、よくよく考えてみてください。

まず、頑張るっていうのは、目的ではありません。

頑張りだけで得られるのは、周りに認めてもらいたいという思いと、自分への慰めです。

自分はあることを達成したいから、やっているだけ。

頑張っているけどできないと嘆くより、どうすれば良いか？が大事だと思います。

  • 人に相談していみる
  • 別のやり方をしてみる
  • 環境を変えてみる

できることは、たくさんあると思います。

目標のために頑張るのか、自己防衛のために頑張るのか、よく考えた方が良いと思います。

どちらかが悪い訳ではないです。たまには、疲れて自分を守りたくなりますからね。

ただ、意識してみるだけでも、大きく人生が変わると思いますよ。

変わるには

よく変わるのは難しいといいます。

でも、変わるのは簡単です。

でも、変わるのは難しいです。

ん？どっち？

変わろうと思うことは、簡単です。

変わることは、難しいです。

そう、変わろうと思うことは、今すぐにでもできます。

しかし、変わろうと思ってもなかなか変われないのが、人間です。

おすすめとしては、

  • 環境を変える
  • 考えを変える

です。

この２点を返ることで行動が変わります。

行動が変わると、人生が変わります。

ちょっと最後の方、雑になりましたが面白いとか、奥が深い。

と思ってもらえたら、ぜひ「嫌われる勇気」を読んでみてください。

そして、一緒に語れると楽しそうですね♫

本当に？それは間違ってない！？ってことも、

少年が哲人に攻め込んだ質問をしているので、

最後までしっかりと読めるとぱっと霧が晴れると思います。

ではでは、次は技術について書きます！

それと最後に！

人を変えることはできません。変えられるのは自分だけです。

この辺りも、課題の分離ということで、とても面白く記載されているので、ぜひ読んでくださいb！

嫌われる勇気 自己啓発の源流「アドラー」の教え

嫌われる勇気 自己啓発の源流「アドラー」の教え

Amazon

「ショーシャンクの空に」をみて考えさせられたこと。

映画

過去記事です。消えたデータの一部が復旧？できたので。

ショーシャンクの空に

とても人間味のある映画だった。

２つ心に残る言葉があった。

１つは、「心の豊かさを失っちゃ駄目だ」 という言葉。

心の豊かさってなんだろう。

  • 感性がいい人?
  • 優しい人?
  • 大人な人?

どれも間違いではないが、

私は、自由で希望に溢れた人を想像する。

逆に豊かでない人は、

固定概念に縛られ、決められた世界で決められたように生きる人

を想像する。

ぱっと出てくる心豊かな人のは、坂本龍馬かな。

固定概念にとらわれず、大きな夢、希望を持ち、自由な発想と行動をして生きた。

とにかく、希望を持ち、動いてみると思ってたより、世の中は広いし、色々な人生がまってますよってことかな。

本当に自分がそうなんだよね。今思うと狭い枠しか知らなかったなと思う。

しかし、まだまだ世の中は広いから、固定概念にとらわれず、もっと広い世の中を見て、体験していきたい。

２つ目は、「シャバが怖い」

これはとても印象に残る言葉だった。。。

小学校から中学校

中学校から高校

高校から大学

大学から社会人

同じ様な体験をすると思う。

今までいたなじみの場所から、まったく知らない場所へ歩みだす。

ここで２つの人間がいると思う。

  • 知らないことへ恐怖する人間
  • 知らないことへ希望を感じる人間

たったこれだけの違いで、人生は大きく変わると思う。

正直50年刑務所にいたら怖いけど、普通の人はそんなことはないと思う。

なので、ぜひ新しい場所と旅立つ人は、知らないことへ希望を感じて、旅だってください。

とにかく、とてもよい映画で色々な人がお勧めするのもわかる。

これからも、自由な発想と、希望をもって生きていきたいと感じた今日でした！

ps.

こういう考えって書けるけど、技術ってどうも書く気になれないな〜・・・

自分の中で完結してしまう。。。

技術や設計概念を日常に例えて、説明とかすれば書く気するかな。

それと、

キレる女 懲りない男 著者 : 黒川伊保子

これ超おすすめ！

ここまで男女の思考は違うのか！というのは驚愕した。。。

うまくいかないのも当たり前だった。

これも出来れば、ブログかきたい。

ショーシャンクの空に [DVD]

ショーシャンクの空に [DVD]

Amazon

codeigniterのガラケー対応 & ガラケーの行方について考えてみた。

技術 経験談

過去記事です。消えたデータの一部が復旧？できたので。

ガラケーとは

ガラケーガラケーと良く聞くがガラケーって何よ！？と皆さん思いませんでしたでしょうか？

知っている人はおなじみですが、

正規名称は、「フィーチャーフォン」です。

フューチャーではないのでご注意ください。

※スマートフォンの次は、まさにフューチャーフォンがでそうだが。。。

そして、ガラケーというのは、日本独自に発展した機能がついているから、 ガラパゴス携帯 = ガラケーと呼ばれるようになりました！

主に、赤外線、電子マネー、ワンセグなどが日本独自の進化と言えるみたいですね。

本当に独自すぎて、世界で売れなかったのが残念ですね。。。

一部のユーザには多機能は喜ばれるが、世界規模にもなると、どれだけシンプルかが、かなり重要になってくる。

simple is the best!!

ガラケー対策

今回対応させて頂いている案件で、ま・さ・かの！！

ガラケー対応がありました。

大きく分けて３つ対策する必要があります。

  1. セッション管理(cookie)
  2. 文字コード
  3. SSL(証明書)

セッション管理

なななななんとガラケーは、cookieが使えない機種があります。

cookieが使えない => session_idが保持できない => sessionが使えない…

oh! my! session!

ログイン処理や、カート機能や、一連の動作で必要な情報が保持できません。

では、どうするか？

  • あきらめる
  • あきらめる
  • あきらめる
  • ステートレスで実装する
  • あきらめる
  • あきらめる
  • session_idをcookie以外に保持させる
  • あきらめる
  • がんばる？

まぁーおすすめはあきらめるです。

後ほど普及率など含めて、数字出しますが、アプリでこれだけ成功している事例があるってことは、ガラケー所持者見捨てても、問題ないと言っているようなもの。

しかし、ガラケーしか見れない、ガラケーだけに特化したすごいサイトを作ったら、

２台もちしている裕福層や、使いやすさにこだわった人たちなど、熱量の高い人たちへ面白いアプローチが出来るかもしれない。

ここで言いたいのは、PCもスマフォもモバイルも！というのは、贅沢だ！

いや、正直いうと実装、テストが辛い。。。ということ。

ユニットテスト、E2Eテストの自動化まで作っている時間があれば大歓迎だが、なかなか難しい。

実装はともかく、テストは単純に考えてPCだけに比べて3倍だ。。。

でも、ターゲット層の関係もあり、対応が必要こともあります。

で、今回はお決まりのcookieが使えないガラケーのみsession_idをパラメータで保持するよう対応しました。

単純に

  • sessionを読み込むときに、URLのパラメータからsession_idを取得する
  • sessionの書き込み時に、新しいsession_idを生成して保存 & URLにセットする
  • 遷移時にURLのsession_idを保持するようにする

対応になる。

セキュリティ上あまりよくはないが、毎回新しくsession_idを生成していて、一時的サイトでもあるので、問題はないと思う。

codeigniterって、ごりごりいじれるから怖いけど、使いやすい！！

コードもわかりやすいから、フレームワークの勉強には適してるかも。

ドキュメントもしっかりしているから、初めて触ったが、問題なくいけた。

文字コード

これがかなりハマった。。。

通常は、

ともに、UTF8の対応をしている。

しかし、ガラケーは基本 SJIS !!!!

そして、PCなどと共存でもあるので、

  • DB = UTF8
  • php = UTF8
  • HTML = PC: UTF8, MB: SJIS

となる。

ここまでもOK。

後何あるの？って思うのは、普通ですよね！

勉強不足でした。。。

form(post)にも文字コードの指定ができるらしいです。

formのattributeのaccept-charsetってやつですね。

これによって、post時に自動でutf8に変換してくれるようです。

codeigniterは、defaultのcharsetをutf8にして、formヘルパーを使っていると、自動的に付与してくれるようです。

よしできたー！！！

と思うのが普通です。

何とauだけ、文字化けしました。。。

auの機種はformのaccept-charsetでutf8に変換されていないようでした。。。

色々調べて行き着いた結果、問題はcodeigniterでした。。。

サニタイズするときに、UTF8前提で行っているので、SJISのまま処理されていた、auの文字は見事に意味不明な文字列になって出力されていました。。。

これだ時間かけて、コードの修正は3行！！

まぁエンジニアあるあるですね。

ちなみに、コードははれないのですが、

coreの中のUtf8.phpのサニタイズしているとこで、UTF8に変換してやればOKです。

SSL

これはまだ確定ではないのですが、

元々作成した証明書がガラケー対応でない可能性が大！

そういえば・・・

ある案件でハマっている人いたなーと。

調べてみたら、結構対応していないSSLが多いみたい。

SSLのランクによっても違うみたいだし。

ここは資料がたくさんあるので、証明書とるときに対象の証明書が対応しているか確認すれば良いと思います。

がぁーと書いてきて、疲れたので、残りはまたの機会にします！

スマフォの発展の速さはすごいから、そこについて調べて見たいと思う。

webデザイン css基礎

開発

過去記事です。消えたデータの一部が復旧？できたので。

本日２記事目！

ども。考えごとしてるとよく寝落ちするundertreeです。

※仕事中はちゃんと起きてます！

最近フロント側を対応することも増えてきて、javascriptはだいぶ使えるようになったが、

cssの基礎の部分の理解が曖昧だったので、まとめ。

要素

ブロックレベル要素内に、インライン要素は含めることはできる。 インライン要素内に、ブロックレベル要素は含めることはできない。

○ <div><a href=xxx >sample</a></div>
× <span><h1>sample</h1></span>

基本的には、bodyタグ内に直接インライン要素を設定することはできない。

× <img src=xxx alt=xxx>
○ <div><img src-xxx alt=xxx></div>

ブロックレベル要素

ブラウザでの表示に際してもひとつの「ブロック（通常改行を伴う表示上のまとまり）」として扱われます。

  • div
  • h1
  • ul
  • table

etc...

インライン要素

ブロックレベル要素の内容として用いられるもので、文書の構造を構成するというより、ブロックレベル要素内の特定の部分になんらかの役割や機能を持たせる要素です。

  • span
  • img
  • a

etc...

位置(postion)

文章フロー = 記載通りに表示される流れ

相対位置配置(relative)

文章フローから相対的に指定分を適用する。

絶対位置配置(absolute)

文章フローから取り除かれ、画面左上から絶対的に指定する。

フローティング(float)

  • left
  • right

通常のレイアウト指定は、主にフローティングを使用。 ３カラムは、３つともleftで構成されている。

幅を縮めることで、可変的に下にずれるので、レスポンシブデザインにも対応しやすい。

cssの優先度

http://www.stylish-style.com/csstec/base/order.html

要素 ポイント
*（全称セレクタ） 0ポイント
p,h1　などのタグ 1ポイント
.sample（classの場合） 10ポイント
#sample（IDの場合） 100ポイント

複数使用した場合は、ポイントを足していき、 足したポイントが一番大きい設定が優先される。

要素の指定方法

要素などの複数条件指定

空白なしで、つなげる

div#new{
}

子孫要素指定

空白でつなぐ

div #child{
}

要素の状態を表す

:(コロン)でつなぐ

a:hover{
}

グループ化

,(カンマ)でつなぐ

div #first, div #second{
}

スコーピング

スコープの制限範囲 sample

  • モジュール毎
  • ページ毎
#new{
}

#new h1{
}

#old{
}

#old h1{
}

cssボックスモデル

スクリーンショット 2014-05-16 8.20.31.png

マージン(margin)

マージンは、要素とその周辺の他の要素との間の余白領域です。それぞれの端からどれくらい の空間を空けるかを指定します。要素に背景がある場合、このマージンは空で透明になります。

ボーダー(border)

ボーダーは、境界となる線(または他のスタイルで使われる装飾)です。ボーダーの太さ、スタイル、色を指定できます。

パディング(padding)

パディングは、要素の境界の内側にある余白領域です。それぞれの端の内側の内容との間にど のくらいの空間を空けるかを指定します。

コンテンツエリア(contents area)

コンテンツエリアは、要素の最も内側の領域で、要素の内容が含まれます。他のプロパティとの間の幅や高さを設定できます。

ps

今の現場にきてから、結構javascript学んだなので、

今度は、javascriptについて書こうかな。

mysqlの日付けについて

開発

過去記事です。消えたデータの一部が復旧？できたので。

どうも。 せっかくの土日で超いい天気なのに、体調不良で引きこもっているundertreeです。。。

あぁ自転車（ロード）に乗りたい。

最近ERD書いてて、作成日と更新日の日付けの管理にすごく悩んでて、時間もなかったので、

マイナーなtimestampで進めていたのですが、再度別のERDを書くことになったので、

気になったので調べました。

結論

5.6.4以降であれば、5byteになるので、datetimeが適切かな。

5.6.4以前であれば、timestampで運用しつつ、2038年に近づいたら、datatimeに変更もあり。

※しかし、データが多いと変更が困難かも。。。

mysqlは、後方互換性を担保しているので、5.6.4以降になることを見据えて、

はじめからdatetimeでやっておくのが、一番いいかも。

カラムのストレージ容量とかは、サーバのメモリ増強とかスケールでなんとかなるので。

日付け型のカラム

MySQLの日付型の扱い方や機能をまとめてみました

DATETIME

日付 + 時刻

表示形式 : YYYY-MM-DD HH:MM:SS

範囲 : 1000-01-01 00:00:00 ~ 9999-12-31 23:59:59

DATE

日付

表示形式 : YYYY-MM-DD

範囲 : 1000-01-01 ~ 9999-12-31

TIMESTAMP

によって異なる

日付 + 時刻

表示形式 : YYYY-MM-DD HH:MM:SS

範囲 : 1970-01-01 00:00:00 ~ 2038-12-31 23:59:59

ストレージ容量

スクリーンショット 2014-05-18 14.56.01.png 引用元

注意点

不正な日付が入力された場合は 指定フォーマットに全て0が代入された値が入力される。

フォーマットは、変更可能だが、全ての日付に適応される。 例) YY-MM-DDなど

検索について

int型で保存して、使用する

MySQLでDATETIME型のデータを高速に検索する方法

int型で保存して、表示するときに変換して使用した方が3~5倍高速になるらしい。

mysql5.5以上ならdatetimeでも速い？

日付けの型にINDEXを使用する場合

datetime型など日付け用の型の検索の場合は、 BETWEENを使用することで、INDEXを使用した検索が可能。

timestamp => datetimeに型を変更

timestamp => datetimeに型を変更しても問題ないか確認

※計算や関数を使った場合の違いなど、細かい確認はしていないので、ご注意ください。

あくまで、過去のデータが 0000-00-00 などに消失、破損しないか確認したものになります。

-- 作成したテーブル

CREATE TABLE `date_test` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `created_at` timestamp,
  `updated_at` timestamp,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8;

-- 確認

desc date_test;

+------------+-----------+------+-----+---------------------+-----------------------------+
| Field      | Type      | Null | Key | Default             | Extra                       |
+------------+-----------+------+-----+---------------------+-----------------------------+
| id         | int(11)   | NO   | PRI | NULL                | auto_increment              |
| created_at | timestamp | NO   |     | CURRENT_TIMESTAMP   | on update CURRENT_TIMESTAMP |
| updated_at | timestamp | NO   |     | 0000-00-00 00:00:00 |                             |
+------------+-----------+------+-----+---------------------+-----------------------------+

3 rows in set (0.00 sec)

-- 適当にinsert

select * from date_test;

+----+---------------------+---------------------+
| id | created_at          | updated_at          |
+----+---------------------+---------------------+
|  1 | 2014-05-18 06:09:53 | 2014-05-18 06:09:53 |
|  2 | 2014-05-18 06:10:03 | 2014-05-18 06:10:03 |
|  3 | 2014-05-18 06:10:04 | 2014-05-18 06:10:04 |
|  4 | 2014-05-18 06:10:05 | 2014-05-18 06:10:05 |
|  5 | 2014-05-18 06:10:05 | 2014-05-18 06:10:05 |
+----+---------------------+---------------------+

5 rows in set (0.00 sec)

-- timestamp => datetimeに型を変更

alter table date_test change created_at created_at datetime;

-- 変更後確認

select * from date_test;

+----+---------------------+---------------------+
| id | created_at          | updated_at          |
+----+---------------------+---------------------+
|  1 | 2014-05-18 06:09:53 | 2014-05-18 06:09:53 |
|  2 | 2014-05-18 06:10:03 | 2014-05-18 06:10:03 |
|  3 | 2014-05-18 06:10:04 | 2014-05-18 06:10:04 |
|  4 | 2014-05-18 06:10:05 | 2014-05-18 06:10:05 |
|  5 | 2014-05-18 06:10:05 | 2014-05-18 06:10:05 |
+----+---------------------+---------------------+

5 rows in set (0.00 sec)

desc date_test;

+------------+-----------+------+-----+---------------------+----------------+
| Field      | Type      | Null | Key | Default             | Extra          |
+------------+-----------+------+-----+---------------------+----------------+
| id         | int(11)   | NO   | PRI | NULL                | auto_increment |
| created_at | datetime  | YES  |     | NULL                |                |
| updated_at | timestamp | NO   |     | 0000-00-00 00:00:00 |                |
+------------+-----------+------+-----+---------------------+----------------+

3 rows in set (0.00 sec)

不合理だからうまくいくについて考えてみた。00

心理 本

はいー 連続更新！

不合理だからすべてがうまくいくの感想について書いていきます。

そもそもなぜ読もうと思ったか

エンジニアとして、日々理屈や論理の中をぐるぐる思考してるが、日常に戻るとそれはうまく機能しないことが多々ある。

それは感情で動いてるからなんだろうな。と軽くしか考えていなかった。

しかし、ある時ネットを徘徊してると、行動経済学っていう単語が目に付いた。

経済学っていうとお堅い数式で、論理的に計算されてるイメージだった。

行動ってつくとどうかわるんだ？

行動経済学（こうどうけいざいがく,英: Behavioral economics）、行動ファイナンス（英: behavioral finance）とは、典型的な経済学のように経済人を前提とするのではなく、実際の人間による実験やその観察を重視し、人間がどのように選択・行動し、その結果どうなるかを究明することを目的とした経済学の一分野である。

By wiki

実際の人間。

あぁーこれ自分が考えてたことと一緒だ。っと思った。

日々エンジニアやってると、論理的に考えてしまうが、ユーザは実際の人間であり、論理武装の上に作られた、仮想の人間ではない。

これを読めば、何か新しい発見ができるかなーと思い読み始めました。

報酬と結果の関係

第1章のテーマですね。

たくさん報酬与えれば、効果が期待できるはず。

より、成果主義を取り入れよう。と始まったのがここ最近？

よくあるパターン

⚪︎⚪︎やったから、いくらね。

  • ゴミ捨てしたから10円
  • お手伝いしたから、100円
  • 1時間働いたから、1000円

問題点

これは、モチベーション3.0にもあったのだけど、この方式をとると、

ゴミ捨て = 10円

という式が成り立ってしまう。

つまり、10円もらえないのにゴミ捨てはやる必要ない

え？ゴミ捨てって、自分が気持ちよく過ごすためでしょ？！

って思ったあなたは、家庭で知らずに良い教育を受けていたんだと思います。

しかし、ゴミ捨て ＝ ある対価 が成り立ってしまうと、なかなか自主的に動けないのが事実だと思います。

仕事も同じことが言えます。

お金をもらえるからやるという式が成り立つと、もらえない範囲外のことは一切しなくなります。

よくいますよね。

でも、これは誰が悪いのでもなく、人の心理なんだと思います。

また、必ず成果が得られるわけではなく、目的が報酬になるため、クリエイティブなことや、新しい挑戦への期待はできないみたいです。

答えがわかっていることや、単純なことに関しては、効果が期待できます。

どうするべきか

では、どうすべきか。

簡単！

使い分ければOKです。

とりあえず手を動かして欲しい。

単純で面倒なことには、お金で解決すればいい。

なので、バイトに成果主義は良いのかもしれないですね。

クリエイティブなことや、新しいことへの挑戦には、使わないこと。

では、デザイナーや、エンジニアには、成果主義はよくない？

基本仕事に成果主義は、良いと思う。

エンジニア作業が好きでも、好きな作業をできるわけではないし、決められたことをやるわけだから。

しかし、ある一定以上のレベルの職種になった場合（計画の立案や、設計など）、あまり良くないのではないかと思う。

では、 なぜ役員は多額の報酬をもらっているのか。

それは、

  • モチベーションを上がると思っているが、結果に繋がっていないことを理解していない。
  • 会社側が成果にそって報酬を出しているだけで、役員のモチベーションをあげるために行っている訳ではない。

のどちらかになるのだと思います。

※必ずしもとは言いないが。。。

もし、モチベーションや、新しい挑戦をしてもらうのであれば、多額の報酬よりも、 自由にできる権限(自主性の尊重)を与えた方が、モチベーション上がるのでは、ないかなーと思います。

まとめると

  • 報酬と結果の関係は、作業内容によって変化する
  • 単純作業は良いが、クリエイティブな作業には向かない
  • ゴミ捨て = 10円のような条件つけをする時は、よく考えること
  • クリエイティブな作業や、将来性を考えるのであれば、自主性、主体性を尊重すること

個人的な意見としては、結果に対して報酬を与えるのは、良いことだと思う。

しかし、報酬を得るためだけに、結果を出すようになったら、燃え尽き症候群や、 対価に見合わなくなった時点で、終わってしまう。

上記は悪いことではないので、しっかりと認識、理解した上で、使うことがとても重要だと感じた。

タイフーン

台風がすごいですね。

エンジニアはこういうときに、リリースや、よっぽど重要な件がなければ、在宅作業や、仕事で使う知識をつけておけるので、いいですね。

まぁーその人の自主性、主体性に大きく影響するとこですがね。

かなり大雨ですが、これから直撃で風も強くなるので、気をつけてください。

※私の出社は、まだ未定です。

今回の書籍

不合理だからすべてがうまくいく―行動経済学で「人を動かす」

不合理だからすべてがうまくいく―行動経済学で「人を動かす」

Amazon

技術負債について考えてみた。

開発

お久しぶりです。Think 木下です。 はい。

今日はふと技術負債について考えたので、書きます。

技術負債とは

行き当たりばったりなソフトウェアアーキテクチャと、余裕のないソフトウェア開発が引き起こす結果のことを指す新しい比喩である

最初のコードを出荷することは、借金をしに行くことと同じである。小さな負債は、代価を得て即座に書き直す機会を得るまでの開発を加速する。危険なのは、借金が返済されなかった場合である。品質の良くないコードを使い続けることは借金の利息としてとらえることができる。技術部門は欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、立ち尽くす羽目になる

by wiki

負債とは

一般用語としての「負債」は、他人からお金や物資を借りることであり、また借りた金銭や物資のことである。なかでも金銭を借りることや、借りた金銭のことは「借金」と呼ばれている。

「借りる」というのは、将来的に返すという約束のもとに他人の何かを使用することを意味している。将来的に返す約束があるので、法律上は債務に分類される。

by wiki

技術負債は、そもそも何を借りるの？

  • お金？
  • 技術？
  • 人？
  • 時間？

んーどうも技術負債とはいうが、何か借りるイメージではないな。

どちらかというと、費用対効果の認識がずれているだけだと思う。

費用対効果の認識がずれているだけだと思う理由

例えば

  1. すぐに手に入るけど、壊れやすい商品
  2. 時間はかかるけど、壊れにくい商品

があるとする。

よくあるパターンは、1.を買って壊れたのに使っている。

  • もちろん、壊れているから直してから、使う必要がある。
  • もちろん、時間がかかる。
  • もちろん、毎回直す必要があるから、モチベーションさがる。

でも、これって当たり前だよね。

だって、1.を選んだ時点でわかりきっている。

それなのに、対策もせずに、見ないふりをしてきたことが良くないと思う。

じゃーどうするべきか

1. 先のことを想定しておく。

  • 壊れた場合、同じ商品を買う
  • 壊れた場合、壊れにくい商品に買い替える
  • 壊れないように、メンテナンスする
  • 壊れないように、壊れにくいように改修する

2. 現状を考えて対策を打つべき

  • 同じ商品があるか
  • 代わりとなる、より耐久性のある商品があるか
  • メンテナンス、改修する時間はあるか

システム的な話になると、同じ商品、代わりとなる商品は、ほぼほぼない（見えない部分も含めて。ブランドとか）

そうなると、

  • メンテナンスする
  • 壊れないように、壊れにくいように改修する

3. まとめると

  • 壊れて諦めるか
  • 壊れにくいものを買うか、作るか
  • 優秀なメンテナンス、改修チームを作るか、雇うか

だと思う。

はじめから検討しておく点としては、

  1. 使用する期間を決める（１年くらいなのか、１０、２０年使うのか）
  2. しっかりと設計できるか、作り込まれている製品を買えるか
  3. 技術レベルの高い人を雇えるか

になるのかな。

しかし、昨今のビジネスのスピード、コストを考えると、そう出来ない場合は多々ある。

いい加減でも先にリリースするメリットがあるのであれば、それはするべきであって、間違いではないと思う。

しかし、テスト自動化などの導入が後からでも簡易に可能かは、検討しておくべき

  1. ユニットテスト、E2Eなどのテストが、簡易に導入できるか、もしくは、導入されているか
  2. 機能を全て把握しているか

1.は、さぁ導入しようとなったときに、独自フレームワークなどの理由で、導入が難しい場合。 かなりのコストがかかり、現状のシステムにも影響がある可能性が高いため、導入は容易ではない。

2.は、機能の洗い出しからはじめることになり、コードから逆算して見つけることや、色々な人に確認する必要があり、かなりのコストが発生する。

この２点だけおさえておけば、重要度や、関係性を洗い出し、部分的にすぐにテストが導入可能で、徐々に改善していくことは可能だと思う。

ドワンドの技術負債について

システムにコストがかかるだけではなく、人という財産まで失う可能性もあるので、しっかりと検討しておくべき部分だと思う。

既に手遅れな場合は、焦らず専用チームつくって徐々にやって行くしか無いと思う。

なんせ、武器も何も持たず、未知の樹海に突っ込む様なもので、PDCAを回して、徐々に進まないと、人がどんどん消えていく。

自分はお金をもらっても、未知の樹海へは入っていきたくないな〜

お宝が埋まってたら行くかもしれないがw

と思った今日この頃でした。

今後は１週間に１記事くらい書いていきたいと思ってます。