(追記あり) 時事ネタ 参院選で思い出した 山田太郎と三橋貴明 (どちらも経営コンサルタントだったりする)

ブログテーマに合致しない、政治的な内容だけど。

 

20時までが締め切りなので書きなぐり。

敬称略

 

b.hatena.ne.jp

 

このあたりを読んで思ったのが

 

  • kz78 山田太郎さんは応援したい」「山田太郎さんを持ち上げて騒いでる奴らがうぜえ」が今んとこ拮抗してる
  • mahalmahal この人6年前の比例で30000そこらしか個人票を取れてないのよ。つまり、原点がメチャ低い。余裕で落選でも6桁行けば3倍。そういうインパクト残せそうって意味では、この人の票を伸ばすのは面白い実験ではあるかも。
  • sekiryosekiryo でも俺達が結集すれば当選させられる!と仲間内だけでワイワイやってるうちに世間的にも大多数だと思い込んで極端な行動で関係無い人の顰蹙を買ったり落選でまさか落ちるとはとヤケになりそうな気配も漂ってきたな。

 

2010年の三橋貴明でも似たような

「周りが変に盛り上がって(ネット上で)顰蹙を買った」とかの現象もあるかもしれない。

 

まあ、個人的には山田太郎の主張

著作権違反の親告罪や過剰な表現規制への反対姿勢

 (クリエイターが萎縮することは、国家レベルで考えても大いに不利益)

だけでなく

・諸産業の生産性向上

 (それも、個々の製品というよりはシステムとして)

・食で安全保障

 (攻めの農業とかいうけど、農協含めそのくらいの気概がほしい)

障がい者雇用

 (高齢者や障がい者を社会のお荷物とみる風潮はどうか?)

 

などにも同意。

 

余談だが、

表現規制障がい者雇用に関しては三橋もほぼ同じスタンス。

生産性向上などは、若干ベクトルが違うけど大筋は似ているような。

 

以上

 

追記 7/12

 

得票数にびっくり

 

山田太郎は落選したが、30万票近い得票を得たのにはびっくり

 

www3.nhk.or.jp

 

上記リンク先を見ると、新党改革の得票の50%程度。全ての有効票の0.5%程度を得たことになります。

 

限られた時間と情報を使い下した、私としての評価は80/100点 で 投票した。

個人的な評価としては、一見ありがちな平凡(といっても能力自体は高い)泡沫候補って感じに見えますが・・・。

 

土曜日に書きなぐった、個人的には山田太郎の主張~ のくだりの部分

プラス、自分の主張が全部通らないまでも部分的に通そうとする駆け引きのうまさ。

サイトに掲載されていた動画の中で、高齢化社会と年金のところで減点。

 

減点理由: 

今の高齢者が平均的には多くの資産をもっているが、これが相続などによってほかの世代に割り振られたりする。年金として高齢者されたものが消費に使用されることを考慮していないなどの、エコシステム全体への理解不足。

 

 

とはいえ、即刻「だからダメ!」ってほどでもない。 80点。合格!

*1

 

追記 7/12 ここまで

 

*1:80点出せる候補なら十分だよ

この年になって感じた。プログラミング哲学や開発思想が重要だと感じた話

あいかわらずエンジニアは俺一人。そしてWebシステム的な部分も、そんなにたいしたことをやっているわけでもなく、だいたい俺一人で済んでしまう現状。*1

 

需要あるかないか分からないけど、俺得として広く知られている、個人的にたどり着いたプログラミング哲学をそれぞれ2件、取り上げます。

 

まずは、広く知られているものを

 

DRY (Don't Repeat Yourself)原則(同じものを作らず共通化)

 

私は昔初めてRuby on Rails を触れたときに知り、今になってありがたさに気づきました。

 

同じ事を繰り返すな という主旨ですが、特にWebアプリケーションなどを作るときに、参照するモデル(DB、テーブル)などが異なるだけでやりたいことは同じ。みたいなケースも多々。

 

文字列の整形みたいな機能なんか特に。

 

KISS&YAGNIの原則(簡潔に単純に/必要になってから追加)

 

これらの考え方は、コードを書く前の段階。何を実装するか(もしくはしないか)で役立った。

 

今の仕事でよくあるのが、「顧客が本当にほしかったもの」のたとえ話に出てくる、木の枝にタイヤがぶら下がっている画像のような、

 

「本当に必要なものは、それほど複雑でもなく多くもない」ものがほとんど。

 

各部門の担当者などに相談しながら進めて、いらないものは省いて早く作るが、

あとから拡張できるように作るようにした。

 

ココから先は、個人的にたどりついたもの

 

ハードコーディングが許されるのは、練習までよねー(設定ファイルなどで読ませる)

 

 

開発規模が大きくなる、別のシステムでも同じ仕組みを使う、・・・などのときに重要。 

 

プログラミング言語、環境などの入門書(特に、10日で覚える何たら入門系)・・・だけでなく全般で、サンプルコード内に文字列や設定などが直接記述されていることはおおいです。

 

たとえばこんなの

 

<pre>File.read("lib/example.txt")</pre>

 

ただしこれらは「特定のメソッドや機能などを説明するために、単純に書いた」だけであるので、実際に納品、実運用する環境下ではやってはいけません。

 

前の会社で働いていたとき、とあるプロジェクトで定例処理を書いていたときに、還暦近いエンジニアの指示で徹底されていた。高々数十行のスクリプトでも納品、共有するものなら・・・大事。

 

逆にAPIの動作検証など、個人的な使用だけで終わるようなものなら「それではやく終わる」なら、使っても良い。というのが個人的見解。

 

設定はどうやって読ませるのか?もちろん引数や設定用ファイルに記載。

特に Rubyではyamlが使えた

 

仕事をはやく終えて、遊びに行こうー(うん。重要)

進捗管理ツールの講習会に参加したときに聞いた話。

特に、いわゆる「Web系エンジニア」にありがち。*2

 

そう。俺もみなし残業労働形態なんだ。

 

(加筆するかも)

 

 

 

 

*1:少ない労力で多くの業績を上げられるのであれば良いが、エンジニアとしては物足りなく感じる今日この頃

*2:使用している言語や環境が、更新が激しいこともあるかもしれないが、それ以上に労働感の変化もあると思う。

ここ1年くらいで身についた、Webエンジニア力について記述する

 

 

この1年間で俺のRuby力はどれくらい伸びただろうか?を書きながら思い出したこと。

 

rojiuratech.hateblo.jp

 

Qiitaに投稿するとき、極力概要や環境を記述するようにした

大学ではもちろん、中学、高校の理科の実験レポートでも、

「何が目的で、どんな条件で実施しどんな結果を得られたか」ははっきりと書く必要があったはず。

 

これを、Web上でもどんな環境で何をしたかったかを極力書くようにした。

たとえば下記のように。

 

qiita.com

 

このことを意識したのは、プログラムやサーバ設定などの調べごとで検索したときに、

バージョンなどの環境の違いによって無効なケースがあり、そこでハマることが多々あったため。*1

 

異なるジョブの相手に、うまく響くようにした

2016年5月現在、社内にWebエンジニアは私一人。Webチーム内の他のメンバーは

デザイナーやディレクターなどの、「プログラムや環境設定に関して理解はあるが、この分野の作業は余り得意でない」という状況。

他方私の場合、ビジネスモデルやマーケティングが大事だということは知っていても、この場面ではどんなことが重視されるかは余り詳しくない。

 

そこで、「こちらの意図しないアクセスは望ましくないので、指定したルートから以外は全部跳ねます」みたいな話をすることも多々。

 

現状では、Webチームのメンバーには画面遷移などに絡めて、

部門には私以外のメンバーを介して説明することが多い。*2

 

gemや各種プラグインを使うときは、Githubの中身をよく読もう

これもよく言われていることだけど、

ソースも解説も。英語だけど、論文に比べれば読みやすい。

 

残業ゼロを目指す、余ったリソースは拡大生産に割り当てる

 

給与形態がみなし残業なので、原則時間外手当はない。*3

 

夜にソワソワしながらグダグダのコードを試したりするのと、

楽しみながらコードを考え、書くのでは気分も生成物もちがう。

 

さらに言えば、長時間労働ノーサンキューな社風がある。

 

以上!

 

 

 

 

 

*1:これを読んでいる皆様も、経験あるかと思います

*2:正規表現とか、不正アクセスホワイトリストとか、ダイレクトに話すとうまく通じにくい

*3:入社以来みなし残業時間以上の時間外労働をしたことはない。

この1年間で俺のRuby力はどれくらい伸びただろうか?

昨年のkawasaki.rb LT大会で、タイトルのようなテーマで発表をした人がいた。

 

ここ1年くらいのRubyに関わる話

昨年春 kawarsaki.rb 初参加。

 

夏~秋、ソースコードの改修にRubyを使用。

文字コードが統一されていない大量のソースファイルに対し

特定の項目を抽出、置換など。出力時はUTF-8で統一。

 

この頃のソースが・・・まあひどいこと。

ファイル名や設定をハードコーディングしていたり、

多数のメソッドがずらずらと書いてる

「前世紀のC言語の教科書に書いてありそうな内容」だった。

 

その場ではよいものの、応用が利かず・・・

何度も書き直していた。

 

秋:Railsのブートキャンプに参加

Railsに関しては「どこでどういう挙動をしているのか分からない」ので、なんとなく抵抗があった。

 

それを一気にぶち破るべく、11月の三連休にELITES CAMP に参加。

3日でRubyのコード作成からMVCモデルの生成、デプロイして公開まで一通り体験。

 

ただし・・・その場で全ての動作をマスターすることはできず、

この場では、ドライビングスクールというよりはスキースクールと化してしまった。*1

 

この時点ではscaffoldで必要なものを生成し、少しカスタマイズする程度。

 

このブートキャンプでは、gem同士の干渉が原因のトラブルでてこずったので、

macの開発環境ではBndler使ってgemを個別に管理するようにしました。

 

冬:Railsで社内向けアプリケーションの作成を開始

 

などと言ってたら、社内で業務補助ツール開発の話が出てきた。

使用言語などの細かい指定がなかったので、Ruby on Rails の利用決定。*2

 

一つ一つは簡単だけど、あわせ技になると厄介

 

CSVから必要な列だけとってきて、DBの形式にそろえて投入する」というと簡単に実装できそうですが・・・。

 

少し掘り下げると、文字コードや表記ぶれなどの、自動化するにはややこしい問題が多数。

 

さらに・・・Railsプロジェクトを作っては捨ててみたいなことをしていたので、

macのディレクトリが汚い状態に。

 

春:良い型が大事と気づく

 

将来の開発、運用を考えると一通りのものがそろった仮想環境を用意して開発や試験を実施したいとか、取らぬ狸の皮算用を考えつつVagrantに手を伸ばす。

 

そこで関連書籍を読んだら「Vagrant道」なる記述があり、一定の作法にのっとれば

いつでもどこでも同じ環境を得られるとのこと。

 

そして・・・これに触発され?合気道を始める。*3

ここで「洗練された、合理的な動作」が大事だと感じる。

 

 そして・・・。

 

今までのコードが見ていられなくなる。

Railsだと、受け取ったデータをいろいろ加工してDBに書き込むような処理を

すべてコントローラーに書いていたり、やたらに多くのメソッドが存在し、引数だらけになっている。

ビューに大量のコメントアウトやDB参照があったり。

 

 

ただし、過去に書いたコードが恥ずかしく感じるのは成長した証拠ともいいますので・・・。*4

 

 

 

*1:一通りのことは体験できたが、どうやればいいかを噛み砕き、モノにしたとは言いがたい。

*2:社内にエンジニアは俺一人。

*3:ガチ勢だらけ。

*4:上記LT大会の発表より

その場ではマイナーな専門職の振る舞い方

今の会社に入って、また新しい年度を迎えた。

 

いろいろなプロジェクトが動き出しているけど、この職場にはWebエンジニアは私一人しかいないのは相変わらずだが。*1

 

 今この場では、Webエンジニアは私しかいない

 

なんどか扱った「非IT企業内のSE」にありがちな、なにやっているんだかわからないと思われているところはまだある。部署内外両面で。

 

・・・と書くと、コミュ障っぽいが、実際にはこんな問題

部署外:Webデザイナーとエンジニアでの役割分担がわかりにくい。そして、パッと見てわかりやすいものを扱っているデザイナーにくらべ、「殺風景な画面に向かってむすっとしながらにらめっこしているやつ」という感じになりやすい。

 

部署内:重視している分野が異なる。デザイナー、ディレクターは表示内容などのUI/UXを重視しているのに対し、エンジニア(私)は不正なアクセスとか、DBから正しくデータを取得しているかなどの方を重視している。

 

どちらもありがちだけど、それによって失われるものは大きい*2

 

それに対する、私が取り組んでいる解決策

部署外:極力他の人と接点を作る。昼休みに弁当広げて一緒に食事をするとか、何気ない雑談に加わるとか。加えて、できるできない系の質問にかんしては、少し間を置いて奥に眠っている真の課題を探してから回答するなど。

 

部署内:技術的な話は部署外の対応に近いが、あれこれ対話すると本当に必要なものがポロっと出てくるケースが多いような。あと、不要な作業を防ぐためにも、方針は事前によく理解してもらう。

 

部署内外問わず:我々の目標は、納得いくWebシステムを作り運営することではない。

その先の売り上げ目標などを成立させることだ。という意識。*3

 

*1:ベタなラノベやアニメのタイトルっぽいですね

*2:仕事が円滑に進まないどころか、こういうことが原因で退職するITエンジニアも多い。

*3:だからといって、不具合のあるWebサイトを作ってもいい。ということはない。目標達成のための手段という認識

Vagrant道で感じた、型や哲学から入ることの必要性

Web上にソフトウェアなどの情報があふれている昨今、この手の技術的情報はWeb上にあふれているから、分からないことがあったら検索結果をかいつまんで解決すればいいじゃない・・・。

 

だがこうしてかいつまみ、重ねた知識や技術が、実はちぐはぐで合理性を欠いたものを生み出す危険と、それをさけるために正しい型から入る必要があると感じた話。

 

Vagrant(ベイグラント)との出会い

昨年 kawasaki.rbのLT大会(だったかな?)でその存在を知った。

が、その時は仮想マシンを動かすboxが、誰がアップしたのか認証がないとのことで使いたくなかった。

その後Elites Campでその有効性を知った*1

 

その後、開発元のhashicorpがboxの配布サイトを開設したことを知り、利用開始。*2

 

そして今まで、VirtuaBoxで開発環境作るときに、設定を微妙に操作することに使えるツールくらいの認識しかなかった。

 

Vagrant家元の書いた動物本を手に取る

本来の使い方は、こうではないんだろうと思っていたので、参考書籍を手に取る。

 

実践 Vagrant

実践 Vagrant

 

 

1.2 Vagrant

まだ、Vagtantもインストールしておらず、Vagrantがどう動くかも見ていませんが、実際の作業環境におけるVagrantの高レベルのワークフローを理解しておくことは、非常に重要です。それらの原則をまとめたおのが、「Vagrant道」です。

 

以下、この項ではVagrantを使った業務の流れが記述されていています。

ざっと読んだ感じでは

 

開発者(プログラマ)は環境を呼び出せばいつでも指定の環境で使い慣れたインターフェイスを使った開発をすることができる。

運用技術者(インフラ・サーバエンジニア?)は、環境設定をスクリプトで記述する。

業務終了後は、仮想環境は停止させたり、あるいは破棄してもよい。

そして、作法にのっとった記述、手順を踏んでいればどこでも同じ環境を用意することができる。

 

 といった印象をうけました。

 

最初は違和感を感じたものの、もう少し読み進めているとこれまで何か致命的な取違えをしていたかもしれないということと、ああそういうことか。ということに気づいた。

 

開発者が考えている(と思う)、正しい使い方

 

・Boxは、原則的には素のOS

・仮想環境で使いたいソフトウェア類とその設定は、シェルスクリプト

 Chef、Puppetなどに記載し、Vagrant up するときにプロビジョニング

 (仮想サーバにインストール)する。

・仮想環境上で開発、検証などをしたいソフトウェアのソースは、ホストOSと

 ゲストOSで共有するフォルダに配置する。*3

・「Vagrantの環境を配布する」行為は、指定バージョンのOSで用意された素のBoxと

 その中使用するソフトウェア類のインストールと設定記述である。

 

私がやっていた、誤った使い方

・Vagrantfile には、IPアドレスなどの設定を記述し、動かしたい環境に合わせる。

・仮想サーバには、その都度ファイルをアップロードする。

・Boxに、各種ソフトウェアをインストールして配布する。

 

そういう使い方もできるが、作者は推奨していない。

 まさに外道というか邪道。

 

だから、まず開発者の意図を理解することが大事と感じました。

 

*1:「僕のマシンでは動いていたんだけど、環境が異なったら動かなかった」現象が発生し青ざめた。

*2:altas.hashicorp.com ユーザ登録しなくともboxのダウンロードは可能

*3:だから、プログラマは慣れたツールを使って開発することができる

セルフブランディングと職場でのマーケティングの話

タイトルだけ見ると、「社内で要領よく生き延びようとする、変な分野で意識高そうな嫌な奴」っぽいですが。

 

先日、タイムラインで「大手メーカーの自社システムエンジニア、基幹システム、セキュリティなどの企画開発・・・」みたいな求人を見かけた。*1

 

学生時代の私なら、専攻分野からIT系職種に就くときの理想ケースと考えるだろう。*2

数年前の私なら、理想だけど手に届かないものと考えるだろう。

今の私なら、コレジャナイ。流派が違う。と考えるだろう。

 

なんてことを考えてたところで、下記の記事を読んだ

 

 

paiza.hatenablog.com

 

ここで働きたいな…というような企業が、どんなことをしていてどんな人材を求めているか分析し、ペルソナを立てるような話。

 

 コレ読んで、自分と会社(で従事している業務)がどんな状況で何をすべきか?ということを考えてみた。

自己のマーケティング(セルフブランディング

私の強みって…特定のプログラミング言語やサーバ環境ではなくて、自己客観視とフットワークの軽さ。*3

逆に弱みは、目標を見失うと何をしていいのか分からなくなり、効率が下がる。

実現したいことは、我々の商品やサービスが売れた!こと。

避けたいことは、自力でどうにもならない状態に陥ること。業界や職種の衰亡は絶対避けたい。

 

・・・と考えた場合、実現したいことは、アプリやクラウドサービスなどの「Web上で提供するものが商品」、ECやシェアビジネスなどの「Webを媒体とした仲介行為」、オウンドメディアなどの「自社や商品の認知度を上げる行為」などの「攻めのIT」で達成できそう。

 

逆に、業界自体が先細りだったりするとマズイ。

 

職場でのマーケティング

1:職場では、私に何が求められているか?

2:事業計画の達成のために、何をするべきか?

 

の、2つの観点が必要になってくる。

 

差し支えない範囲で書くと、自社の弱点補強系の手段の提供を素早く行うことが求められている一方、自社の潜在的な強みをレバレッジを掛けて強化できるようなことが必要と考えている。

 

意識にズレが存在することは、今まではつらかったけれど、今は楽しんでいたりする。

 

なお、前者は手法が難しくないが、必要なものを確定するための意識合わせが必要。

後者は何が必要かはわかっているが、達成するための手段模索が大変。

 

*1:キラキラ系社内SEですね

*2:専攻分野は経営工学。企業活動を分析してよりよくする方法を試行するような分野。その道具としてITが使われる

*3:ハッカー的な見地から行けば邪道かもしれませんが、私の場合はあくまで事業計画を達成することにより重きを置いています