カテゴリー別アーカイブ: よもやま話

モチベーションを管理する

ここ最近仕事が落ち着いてすごく時間ができた。それ自体はいいことなのだが。
悪いことにすごくやる気が起きない。
途中まで読み進めていた本や、塩漬けしていた個人プロジェクトなどやるべきことはあるのだが一日のほぼすべてを睡眠に費やしてしまった。

ダメだなーとなんとなく思いながらも相も変わらず体は惰眠を貪っている。
なぜモチベーションが起こらないのか、どう行動したらいいのかというところをぼんやりと考えた。

まず何もやる気が起こらない、と言うのは言い換えると何も体験することがない状態とほぼ等しいと思う。
自分が富を得たり成長したりすることがない反面、失敗してリスクを負ったり気分が落ち込むこともない。
つまり何も変化のない平衡状態だといえる。

ではなぜ何も変化のない状態に身をおきたがるのかというと、単純に体験を積む行為自体がエネルギーを消費するからである。
いわゆる面倒くさい。ということである。

もうちょっと掘り下げると面倒くさいと思う理由がさらに一つあることに気がついた。
そもそもリターンを欲していない場合、リターンがほしいがそのリターンが得られないと思っている場合、または頭ではリターンが得られそうだと思っていてもその実体験を積んでいない(リターンを得られるという確信がない)場合には特に面倒くさいと感じる。
ようするに面倒くさいというのは行動コスト対リターンのパフォーマンスが悪いと思っている行為とも言いかえられる。

例えば仕事の依頼が来てそれに対応することを考えてみよう。
これは自分の中でこの行為を行った実績がある。その為行動コストは少ない。
また行為の対価としてお金を得られることが見込める。
その為リターンも得られるため、モチベーションは悪くなさそうだ。

じゃあコンビニにご飯を買いに行くという行為はどうだろう。
これも自分の中で行為を行った実績があるため行動コストは少ない。
またそもそも腹が減っているという原始的な欲求を満たすことができるためリターンを得られる。

また更に行動コストというものを分解して考えてみる。
行動が完了したとみなすのは、いわゆる目的が達成できたという点である。成功するとも言える。
対して目的を達成できなかった場合を失敗と定義しよう。

この時に今までに体験したことのない新しい目的地に達する場合は、当然そう安々とは行かないだろう。
こうすればうまくいくだろうという計画を練って実施する際には何度か計画通りに行かないこともある。
そのたびに計画を細かく修正しながら進める必要があり、成功(目的を達成する)ためには非常に労力を要する(だろうということを今までの人生で学習している)
対して失敗するのは簡単である。そもそも何もしなければいいし、計画がうまく行かなかった時点で諦めてもいい。
成功を得るためには全ての工程をこなさないといけないのに対して、失敗するのはいつでもできる。

対して一度成功した体験を再度実施するのは極めて簡単である。
どういうリスクが有りどうすればそれを回避できるかなどをすでに知っているからである。

で、話を戻してなぜ新しい行動する意欲が起きないかというとコスパが悪いと思いこんでいる点にあると解釈した。
成功して初めてリターンが得られる。失敗したことにより得られるものはないと思っている。

というわけで考え方を変えることにした。

まず失敗の定義であるが、細かい点でうまく行かなかったとき(仮にこれを細かい失敗とでも呼ぼう)。これは失敗とは呼ばない。
目的を達成することを諦めた時点で初めて失敗と言える。

逆に細かい失敗は、成功とも解釈することができる。
なんでかというと、「目的に対してこういう計画で試してみたがうまく行かなかった」というリターンを得られたと解釈できるから。
最終的な成功に向けて計画を修正すれば良い。

人間はDNAレベルでじっとはしていられない。
日々成長できる何かがあればそれは十分に価値があるリターンと言って良い。

新しいことをやる際には、細かい成功体験を積み重ねていくしかない。
むしろ新しいことをやる際の細かい失敗に対応する体験が一番のリターンだ。

同じところぐるぐる回っているだけじゃ面白くないでしょう。
同じことを繰り返し続けているのはそれこそリスクだ。


MVCというデザインパターンはもはや十分ではない

概要

今さら私が提示するような話でもないほど同じような話はネット上に腐るほど存在しているだろう。
にも関わらず不思議とシステム開発の現場レベルで見てみると、昔と変わらない手法をずっと続けていたり、また優秀なアーキテクトに恵まれていない現場などはひどく絡みあったコードと格闘していることは多い。
改めて近代的なデザインパターン・アーキテクチャとは何かということについて自分なりに詰めてみようと思う。

初めてに言ってしまうと、ずばりこの記事の着地は ドメイン駆動設計(DDD)への招待である。
同じような疑問を感じている人の何かヒントになればと思う。

人々はオブジェクト指向を手にした

昨今のソフトウェア製作の設計パターンは変化しているのだろうか、ということをまず考えてみよう。
「コンピュータの登場から今まで」のような大きなくくりで見た時には、ソフトウェアの設計パターンは大きく変化していると断言していいだろう。(といってもそんな昔に私は生まれていないが)

時代ごとに変化する大きな要因の一つに、偉大な先人たちが開発してきたコンピュータ言語がある。
昔はアセンブラ・C言語などの、手続き型言語が大部分を占めていた時代があるが、この頃開発においてドメインに着目するというよりかは手続きそれ自体に着目している。
これは言語のパラダイム的にやむを得ない部分が大きいが、いずれにしてもプログラミングされたその内容はそれぞれが意味をあまり持たない。個別には意味がわからない処理の連続が、結果として業務ロジックとして存在している。

その後時代は流れてついに人類はオブジェクト指向言語を手にする。このオブジェクト指向というのはプログラミングパラダイムの革命の一つと言っていいだろう。
オブジェクト指向によってドメインモデルと実装がかなり親和性を持って結合できるようになったのである。
そしてコンピュータ資源も豊富になってきた今、高級言語を使っていればあまりメモリなどの資源を期にすることもない。
実装都合でねじ曲げてきた手続き型への束縛からも開放されつつある。

これが爆発的となり、様々なツールなどが世にでる。sbtなどのマルチプロジェクトを取り替えるような機構ができたりして、その実装性能よりも、実装とドメインモデルをどれだけ近づけて、人間の脳に理解しやすいようにプログラミングを行う時代になっている。

MVCの誕生

Web業界ではそれまで多くのシステムは cgi と呼ばれる仕組みを利用してシステムを実装していた。
これは先程の話で言うとオブジェクト指向の誕生前で、割りかし手続き型の側面が強かった。

これがオブジェクト指向の出現によってMVCというデザインパターンの実装が用意になり、それをサポートする多くのフレームワークが誕生した。
多くの(初級)開発者たちはとりあえずMVCすればそれなりに構造化された実装を手にすることができた。

MVCの功として、まず多くの初級開発者たちにとって開発の目印になってくれたことである。
それまでとくらべてエンジニアたちの一種のヒントのようなトピックを投下して議論の対象となった。

また実際そのデザインパターンはシステムがあまり大きくないうちは非常に効率的に開発できる(ように見える)ためそれほど規模の大きくないシステムにとっては問題がそれほど露呈しない場合も多い。

MVCは銀の弾丸ではない

実際MVCのすべてが否定されるべきものではない、一種のアンチパターンとして利口なUIパターンなどというものがあるがそういった多くの場合はとらないでおくべき選択肢を序盤に排除してくれるような働きをしている。

ただ単純にMVCという一言で対応するにはシステム開発はそれほどシンプルではなかったという話である。

個人的に思うところは MVC の表す Model の責務が大きすぎるのである。
そのため人によって解釈が異なったり、またそもそもそこの設計を怠ったりということで大きなシステムに対応できなくなっているパターンをよく目にするように思う。

具体的によく目にするのが Model 内部にDBレイヤへのアクセス処理などが記述されていて、どんどんモデルが膨らんでいくなどのようなことである。

本来のクラスの責務をしっかり検討する必要があり、MVC を拡張するようなよりドメインとマッチした設計思想が必要なのである。

DDDへの招待

そこで DDD である。昔からあったのかもしれないが、最近特に多く目にするようになってきた。

DDD とはドメイン駆動設計の略称であるが、これはドメイン(業務ロジック)に特に着目して、それをいかに齟齬なく実装に落としこむかということに着目した設計手法である。

実際かなり具体的な設計思想を(先人たちの経験の蓄積として)もっており、これらを盛り込むことでシステムが大きくなってきた際にも拡張性がある実装を担保できる。

たとえば具体的には先程の話で一緒くたに Model と称していたものを Entity や ValueObject など(他にもいろいろあるが)いうようなより詳細なドメインモデルに落としこむ。
これによりMVCで取り扱っていたものを、より適切な責務へと分割することができる、、、などなど

その内容については長くなるのでまたの機会に割愛するが、DDDのバイブルである下記の書籍に目を通すと良いと思う。一度目を通しておいて損はないです。


【AD】フリーランスを応援します

何度か本ブログでも取り上げていますが、自分の腕で生き抜いていきたいと考えているエンジニアほど、独立すべきだと思っています。

とはいえ不安、何をどうしたら良いかわからない。など悩みは尽きないと思います。

そんなあなたに、とりあえず相談してみることからオススメします。
今の仕事をすぐ変える必要はなく、リスク無しでフリーランスのライフスタイルを明確にすることができます。

私のオススメは断然下記の「株式会社レバレジーズ」です。
取り扱っている案件数が豊富で、フリーランス界隈では実績も豊富でサポート体制も充実しております。



独立を考えているエンジニアの方は、まずは登録してお話を伺ってみてはいかがでしょうか?


標準化できていない話なんて結局つねにつきまとう

よもやまです。

いきなりですが僕はfrontendの開発がつきまとう案件というのがあまり好きではありません。

理由としてはブラウザによる依存性を吸収しにゃならん。ということがあるからです。

言わずもがなChrome, FireFox, Safari, そしてみんな大好きIE。

Ecmascriptという企画はありますが、細かいところでその挙動は異なり、開発はもちろん動作検証まで担保しなきゃならんとなるとその労力はなかなか馬鹿になりません。

jQueryが開発されているため今ではだいぶ楽になっているかと思いますが、すべて仕様が統一されていればそもそもする必要のない苦労かとも思います。

なので私はかなりより好みしてサーバ側の開発を選択しています。

開発している対象が上級言語のWEBアプリケーションということもあり、各OSのディストリビューションで提供されている処理系ではソースコードの移植性は担保されているわけですから。

一回書けばどこでも動くわけです。これは本当素晴らしい。

ところが、最近C言語などで記述されたリソースに触り始めました。

触れてびっくり。というわけではないが今まで当たり前ことに気づいていなかっただけなのですが、各種UNIXのディストリビューションに依存性がかなりあり移植性を担保するのはかなり大変なわけですね。

例えば、イベントハンドリング一つに関しても各種ディストリビューションで異なります。それらはlibeventというeventの依存性を吸収してくれるライブラリなどを用いることでコードの移植性を高めることができます。

これは言ってみればまるでブラウザごとの依存性をjqueryが吸収しているような構図と一緒ではないか・・・

posixという仕様もございますが、当たり前ですが定着されてからの仕様にフィードバックされるそもそもの流れだったり。
仕様にない振る舞いとかは実装依存とかあったり。そもそも100%って無理なんですよね。

この手の話は結局どこへいってもつきまとうな。

と思った話。


Macでのe-Taxの利用はやめたほうが無難

みなさん確定申告の準備はいかがでしょうか。そろそろ今年も始まりますね。
かく言う私も今年から確定申告をしなければならい立場になりましたのでいろいろ準備進めています。

いろいろ調べてみるとe-Taxというネット上から確定申告をすべて済ませることができる良さ気なサービスが有ったので使ってみることにしました。
そこで掲題にもありますが、Macでいろいろハマりました。
ブラウザによって動いたり動かなかったり。依存を吸収できていないっぽいようです。

chromeはまあ、公式にサポートしなかったのでできないのはなっとくなのですが、サポート対象であるsafariでもダメでした。
特に初めてやるんだったら素直にウインドウズ使っておくほうがトラブル少なくて済みそうです。
同じような人もいると思うのでいろいろ書いておこうかと思います。

  • サポート対象とか

    公式サイト見てみると、国税庁の味気のないページとはちがって26年度の確定申告特集ページは今どきっぽい感じに仕上がってます。

    そこからetaxの手続きに進むことができます。
    すると初めに環境を確認するようなページが出ます。

    私の環境は Mac OS 10.9のsafari 7.0.6とあるな。うん大丈夫そうだと思いましたこの時は。

    safariの場合

    個人情報などを入力してページを進んでいきます。
    最終的に確定ボタンを押すことになり、登録したメールアドレスに仮確定のメールが飛んでくる。。。はずなんですが。
    ・・・画面真っ白。何度やっても最後のページで画面真っ白になります。

    こちらの入力した情報が変なのかなと思って、条件など変えて3回くらいやり直した。が結局わからずでした。

    chromeの場合

    ダメ元でchromeでやってみた場合、safariでひっかかっていた場所は正常に通過出来ました。
    ですがその後、電子証明書のパスワードを入れるところで、パスワード入力フォームが表示される前に「パスワード入力が確認できました」というような表示がされてダメです。

    この辺javaのアプレットっぽい機能を使用しているらしく、そもそもjavaのインストールをする必要もあり、さらにデフォルトのセキュリティレベルでは禁止されている操作なのでセキュリティレベルを下げる必要がある。
    そもそもセキュリティレベル下げること自体ちょっと抵抗が。公的な機関がこんなでよいのかと。。
    私は仕事柄そういうの慣れているからいいですが、これ素人がわかるのか?と思ったり。
    (下準備でルート証明書を手作業で追加してくださいとか、正直おしっこちびりました。こわい)

    これだから税務署では確定申告サポートを手厚くやっているんでしょうね。
    これはお年を召した方には絶対に無理だなーと思います。
    結局私はvmでウインドウズも入れていたのでそちらで登録し、無事に電子証明書の登録まで完了出来ました。
    素直にウインドウズで申請するほうがトラブルが少なくて良さそうです。

    余談ですが、うまく行かずに何度も登録を試行錯誤していたせいで後日、国税局?税務署?から電話がかかってきました。何事かと思いました。怖かった。