読者です 読者をやめる 読者になる 読者になる

どこぞのエンジニアなマネージャーのブログ。

Perlとかviとかcssとかjavascriptとか(rubyとか)git >> https://github.com/rozary hatenaIDがrozrayなのはtypo

「TECH TALKS -ソウゾウ×グノシー×エウレカ 技術トップが語るこれからのエンジニア組織-」に行ってきた。

ちょっと日付が経っているのですが参加してきました。

久しぶりに組織のお話。
学びがあったので、ちょっとザクザク絞って箇条書きにしてみた。

組織、チームのフェーズに合わせてマネージャーを合わせていくのはよいなと。

それでいうとCTOはチームの立ち上げ時に基礎づくりってのは有る手。
その後は、チームを大きくしていくのが得意な人に託す。
0→1
1→10
10→100
みたいなフェーズ訳の話も思い出す。

インセプションデッキは、マネージャーを置かなくてもチームを動かすことができるとか。

最近インセプションでっきやってないなー。

基本少人数チーム。

関係ないけれど、LeSSを勉強してみたい。

PJを対ユーザーよくしようというのがPJの責任者。

システムを良くしようというのが横軸の責任者。
やっぱりPJまたぎつつチームにがっつり入るのは大変だよなー。

そもそもあんまりリファクタやらない。

ユーザーメリットがなければやらない。

これは面白いなって思ったこと。

抽象的なものを投げられる人をリーダーにする。
この表現はなるほどと思った。
そこからエンジニア観点でタスクを形成して進められる人は強いなーと。

また開催されたら参加したい。


f:id:i47_rozray:20161124205504j:plain

第5回CodeIQ感謝祭「食欲とプログラミングの秋」に行ってきた。

勉強会 備忘録

ほんのちょっとずつ、時間取れ始めたかなぁと。
またブログを書き始めてみる。
振り返ってみると、4年くらい書いてなかったのね。

09月24日に開催された「CodeIQ感謝祭」について、参加した振り返りを以下の流れで。

  • 感想まとめ
  • キーワード
  • 各々の振り返り << だらだら長いやつ。

感想まとめ

  • 初参加!!
  • 採用とエバンジェリスト話に興味をひかれていってきました。
  • とても良かった!
  • ずっとホールにいたので今度はブースとか懇親会とか参加しよう。

キーワード3つ

  • スキルも大事だけれど、カルチャーはより大事

スキルは伸ばせる。
カルチャーはなかなか変えられない。

  • 自分ごと化

当事者意識とも

  • 探求力

質問力ではなく探求力という言葉がオススメ

残りは備忘録的にツラツラと書き残しておく。
※あ、ちなみに自分の勝手な解釈が交じるので、講演内容とは違う所がままあると思います。

続きを読む

エンジニアはプロジェクトマネジメントを知るべきか知らざるべきか。

ボクの答え

「知るべき。」という自分の答えは先に言っておく。

知って、正しく進むプロジェクトなのか否かを判断するべき。
可能であれば、自分でプロジェクトマネジメントをすべき。
もっと可能であればプロジェクトマネジメントしながらエンジニアリングもすべき。
※自分のエンジニア欲求とプロジェクトの成功の為に。

エンジニアリングのスペシャリストという目指すのもあるが、
どんなスペシャリストでも解決できない物もあると思う、
それは時間とお金と人。よくいう有限なリソースですね。

どんなスペシャルであったとしても、
適切に調整されたプロジェクトでなければ、
こなしきれない問題もあると思うのですよ。
一般的にはね。

※いや、もしかしてそれをも凌駕するスペシャリストなのかもしれない。
「どんな無理難題でもそれを超越し周りに成果を及ぼす人」だ。そんな人がいれば、
その人に合わせたマネジメントを行うだけだ。

エンジニアがいくら頑張ってもプロジェクトという観点では越えられない壁があるのではないか?
※逆にプロジェクトマネジメントがいくら頑張っても越えられない壁もあると思うけどね。
青い銀行とかね。
と思うわけです。

つか、エンジニアリングに降りてくる前に、その前で訂正するほうが費用対効果が大きいわけですよ。(不確実性コーン!!

とはいっても、プロジェクトマネジメントをしたからといって成功するわけでもないのですけれどね。

偶然成功することもある、が成功するセオリーというものもある。

じゃあプロジェクトマネジメントができれば幸せか?
というわけではない。
プロジェクトマネジメントもやはり専門領域で、
エンジニアリングと並行するのはとても大変である。
そうなってしまうと、自分の好きなエンジニアリングを諦めなくてはならなくなってしまう?そういったこともあるだろう。
(実際、今の自分はそんな感じ。

だがしかし、自分の成功よりもチームの成功。という観点もある。
だよね、そこは自分が納得するものを選ばなければいけないわけだ。

そんな「決め」の問題のなかで、どうすべきか??

自分の定義する成功に対して、論理建てて行動すべきかと思う。

自分勝手に考える。
やたら頑張る。

ではなく、今までのでの人類の知見があるのだがからそれを知り、
利用するでもよいし、捨てるでもいい。
しかし、それを利用しない手はないんじゃないかと。

結局何をすべきか。

「世の中に不満があるなら自分を変えろ、それが嫌なら耳と目を閉じ口を塞いで孤独に暮らせ。 」

攻殻機動隊の言葉は有名よね。

※自分を変えろというよりも、周りを変えろ。
とか思ったりもするんですけれども

自分の欲求があるなら、それに従うべき。と思う。
「楽に働きたい」でもいいし。
「多くの人に楽しんでもらいたい。」でもいいし。
などなど、なんでもいい。

ただ、それを実現する手段として、適したものは何なのか。

今一度考えて欲しい。

それは、エンジニアなのですか?
それともまた別の手法ですか??

自分の欲求がたとえ「技術一本勝負!!」などであっても、それを実現するためには、
マネジメントが必要だったりしませんか?(自由を勝ち取る為の、周りへの情報共有、マネジメント。)

まとめ

考えだしたらきりがないし、ボクはPMは知っているべき。
という偏見から書きなぐっている所があるので、なんとも申し訳ないのだが。

結果を実現するための手段、スキルは多く深く持つべき。

と思うのです。
それだけ実現の可能性がますと思うから。

ルール以外はノールール。

「AはBだから…Cだよね。って勝手に思っていませんか?」

shibuya.pm行ってまいりました。

勉強会

http://shibuya.pm.org/blosxom/techtalks/201506.html

※以下、talkとは別に項目が立っております。

■nginxの奥深さをいまさら感じた
トラフィック抑えて高速化
gzip_static gzipしたり展開してくれる

その他楽しいオプションいぱーい。
https://speakerdeck.com/cubicdaiya/nginxfalsepahuomansutiyuningu

■Perlingual がすごい
perl のソースを なでしこに!!(phpやjsにも置換できるよ。)
http://e8y.net/post/120535406440/shibuya-pm-17-acme-perlingual(勉強会のブログ)
http://perlingual.koneta.org/(デモページ)

デモおもしろいよ!

■GazelleはISUCON用
前回優勝のkazeburoさん作

2014優勝してきたよ
http://blog.nomadscafe.jp/2014/11/isucon4-isucon.html

ベンチとか紹介とかgitとか
http://blog.nomadscafe.jp/2014/11/gazelle-new-simple-and-fast-plack-handler-for-performance-freaks.html
https://github.com/kazeburo/Gazelle/wiki/Benchmark

■h2o @kazuho
ちょっぱやhttpサーバー
http://blog.kazuhooku.com/

■one source code で「複数のサービスに対応するが schema 構成は微妙にに違います」という要件に直面したら開発はどうすればいいのか、僕なりに何日か考えた上でのややベターな結論のようなもの - @Yappo

これ、資料ないんですけれど、自分にはとてもよいきっかけになるお話だった。

想像するに、スキン替え的なことが必要なときにどうするかとか、
自作のモジュールの仕様変更をどうしようかと考えているのでよかった。

環境変数とかグローバルで処理分岐させるのよくない。
メソッドもあまり。
・クラス、名前空間をわけて管理ぐらいがちょうど良い。
だそう。

その方のISUCON2014の体験談
http://blog.yappo.jp/yappo/archives/000846.html

■その他
技術スライド英語で書こうぜ。
http://tagomoris.hatenablog.com/entry/2015/06/01/210425

Test::Prettyを早速使ってみた。

cpanm Test::Pretty
perl -MTest::Pretty foo.t
    ✓  foo_test1
    ✓  foo_test2
    ✓  foo_test3
    ✓  foo_test4
    ✓  foo_test5

Test::Moreのテストそのまま使えて見た目キレイ!!

久しぶりにマークアップなんかしてみたりした1日。ハマった所をメモ。

css

丸々っと、やったのは実に5年ぶりくらいな気がする。
想定より2倍は時間が掛かりましたな。

ということでハマったところメモっておく。

「display:box;」したら子要素で「text-align」が効かない。

で、今回は右寄せがしたかったので、

width:1.3em;
margin-left: auto;

こんな感じにしておいた。

z-indexは、position指定しておかないと効かない。

z-index:1;
position:absolute;

とかね。
ついでに、absoluteするなら親要素で、

position:relative

してあげること。

子要素のみに反映させるには、">"を使う。

div > span {
  color:#ffffff
}

とか。

なんか、全然忘れていたよ…。
まぁ少しずつ触る機会が増えそうなので、リハビリしていこっと。

進め、現場のチーム開発 〜チーム開発実践入門〜 に行ってきた。

勉強会 DevLOVE

ちょー久しぶりにDevLOVEいってきました。
実に半年ぶり、仕事と学校課題をそっちのけで、無理矢理出席!!

語り手:『チーム開発実践入門』著書の一人、池田尚史氏

今回、自分で考えていた課題は「メンバー同士のプロジェクトの進め方」について考えていたのですが、ちょっとずれていた感じ。
けど、今回もいろいろと収穫がありました!!

流れとしては『チーム開発実践入門』をもとに、
ツールは成功に導く土台という前提として、ツールまわりについてのお話でした。
そして、その後は、前後+お隣さまとのディスカッションをおこないました。

では、気になったキーワードをつらつらと。

チームの課題 - 目標が不明

カイゼンカイゼン」と言うけれども、目標・目的を自分で作れるのであればよいが、
そうでなければ、何をどの方向にカイゼンしたらよいかわからない。

具体的にすると
・普段行っている機能開発を5日から3日へするためには。
・資料作成時間を3時間から1時間へするためには。
など、わかりやすく行うとよいだろうなと思った。

チームの課題 - 要件が不明

目標に対して、どのようにカイゼンしていくのか。
これまた、どの様にカイゼンしたらよいのかわからなければ大変。
なので、こちらも観点を明らかにするとよいだろう。

・汎用性

って…言葉にすると…ム…なんだろパッとでない…。

チームの課題 - 価値が提供できているのか不明

作った機能がどのような結果をもたらしているのか…。
良いも悪いも、明らかにして次への参考にする。

ちょっと具体的じゃないけれど、きっと必要なこと。
(言ってしまえば振り返りですけれど…。)

QAはプログラマーじゃない。

テストって、繰り返し繰り返し地道で大変なこと。
そこを自動化すれば、かなりの効率アップ。
しかし、QAの人たちはプログラマー的な人じゃない人が多い為なかなか自動化できない。

だので、そういう方たちとどうやって協力していくか。

ディスカッションにて

redmineを導入して、半年ほど。
導入にいたって、いろいろ課題がありましたかと伺ったけれども、
エクセル管理がうんざりしていたのでredmineへの移行はすんなりいった。」
「CIについて聞きに来た。
毎回、手動で時間をかけて行っている。
CIを導入できれば楽になる。」
と、いろいろな現場でカイゼンしようとしている話が聞けてエネルギーもらった!

ということで以上。