Twitter アイコンステッカーをゲットしたよ！ - FAKELOGを読んで、アイコンシールキャンペーンに挑戦してみました。
欲しい( ⁰⊖⁰)【TAシール毎週プレゼントキャンペーン】@printailをフォロー&RT！抽選で3名様に毎週名刺サイズアイコンシールをプレゼント！ 詳細→ https://t.co/KGP3SYn55w
— 🌈KOSHIKAWA (@ppworks) 2015年2月23日
そしたら、なんと当たりました＼(^o^)／
どこに貼ろう？
どうでもいいですが、私のアイコンTシャツは、Naoto Koshikawa ( ppworks ) の【それいけマンボー稚魚たくさん】Tシャツ ∞ SUZURIから購入することが出来ます。
ステッカー欲しい方はどこかでお会いした時に、ちょうだい！と言って下さい。でも何に使うんですか？
口頭で話したことを文字に起こすことについての続編のような記事です。
消え行く知見や、消え行く情報を文字にすることで永続化させ、密室の議論を無くす。その為に以下のような活動が重要という話を書きました。
何がいいか。
なろうと思えばなれるというのは、どういうことかというと、共有化された情報は、その情報をどう捉えてどう向き合うか情報を得た側が選択してこそ価値が出る。 共有された情報に対して当事者意識を持つかどうかは情報と向き合った人に委ねられるということです。
情報共有にはメリットしかないという話からもインスパイアされました。
情報共有において遠慮はらないと思っています。ノイズになるかも？なんて遠慮は不要です。繰り返しますが、共有された情報に対して当事者意識を持つかどうかは情報と向き合った人に委ねられるからです。情報共有がノイズだと思うのであれば、ノイズをノイズとして処理できない受け取り側に問題があります。
チームが自律的に自走するためには、チーム内のモチベーションを高い状態にキープすることが大事になってきます。例えば、思いや感情を共有することで相互理解を深めることが出来る。そして、相互理解を深めると、人は互いに承認欲求が満たされ、モチベーションが高まる傾向にあります。
モチベーション向上のためにも思いや感情の共有は大事です。
slackに#current_status部屋を作ることで、slackを気軽な思いや感情を共有部屋とするのも、情報共有の第一歩として気軽に始められてよいでしょう。
また途中経過、WIP(Work In Progress)な情報についても共有をすると、良いことがあります。
WIPな情報は、より早くより新鮮な状態の情報です。そして、完璧でもないし結論も出ていなかったりします。ただ、思いを共有したり、考えている事を共有するには十分な情報だったりします。
完璧を求めることで、途中経過を伝えることや他の人が当事者意識をもつ機会を損失します。何より完璧な情報は作った人間がそれに固執しやすいという特性もあります。
密室で行わる議論の何が問題なのでしょう。透明性がない、途中経過の分からない議論の結論は上記の理由から、自身が蚊帳の外にいる感覚を得やすいと考えます。たとえ、議論に参加出来なくても見えることが大事で結論がどのように導かれたか、プロセスが見えると人は納得するのです。つまり、WIPでも情報はオープンにすることが重要です。
マネージメント層の議論の結論がこのように密室で透明性のない状態で行われると何が起きるか、組織への不満、不信です。
短い経営経験の中で少なくとも２回この失敗を犯しました。失敗を繰り返さないために、WIPでの情報共有に気を配りたいです。
esaというチーム内での情報共有するためのサービスがあるのですが、そこの紹介文にこうあります。
情報共有ツールに、機能としてWIPが存在するということは、この情報共有ツールがWIPで共有することを正しいものとする哲学があると感じました。
また、qiita:teamでも、タイトルに [WIP] を付けるなど運用でカバーすることは出来ます。
自分たちに適した情報共有ツールを使って、WIPな情報を早い段階から積極的に共有し、よりよいチームを築いていきましょう。
スタートアップ界隈でのRuby on Rails利用率は割と高く感じる。
みんなが使っているから使う？それだけではないはず。なぜ使うのだろう。
railsの特徴を考える。
Convention over Configurationてやつ。規約を決めて、それに沿えば、フレームワークに乗って素早く開発できるようになる。規約で縛ることでRailsに流れる哲学に従うことを強制化している。
外れると痛い目を見る。Railsに乗るということは電車に乗って簡単に遠くまで行けるということ。Railsから降りるということは電車からも降りるようなものだ。中途半端な理解で突き進むと線路からすぐに降りて歩くことになる。
スタートアップでRailsが採用される一番の理由は、 簡単に遠くまで行ける だと思う。ただ、そんなにうまい話はないのだ。簡単に遠くまで行くには、それなりの覚悟が必要だ。規約を守るにはRailsの哲学を理解する必要がある。取っ掛かりとしては、
あたりだろうか。体系だった書籍や公式のチュートリアルは哲学に触れる第一歩としてよい。実際作ることにより規約があるからこその手軽さを体験し、運用からその思想の深さが理解できる。
規約縛りのさらなる魅力はなにか、Railsというレールがあることにより、チームの共通認識として Rails way に沿っているかという基準が出来ることは大きな魅力だ。チーム開発を加速するためにコードレビューの重要性が高まっているが、このコードレビューにおいても Rails way であるか？という観点がレビューの観点となるので、コードレビューを導入しやすいと感じる。Rails wayをベースにして、コードレビューの観点を育てて行けるのは魅力の一つだ。
地域コミュニティは、Sendagaya.rb | Doorkeeperが初心者におすすめ、もうすでにRailsで何かを作っているなら、ゆるふわ Development Club #yurudevもよい。
Railsがgithub上で開発されている事も大きいが、その流れで周辺のライブラリ群(gem)も同じgithub上にて開発されていることが多い。
githubにおけるpull requestの仕組みがこのエコシステムを広める根源となっている。
逆に言うと、エコシステムには貢献する義務もある。gemに不都合や要望があるとき、 自身がエコシステムの一部であることを認識していれば、自然とそのgemにpull requestを送ることになる だろう。
Railsに乗るということは自身がエコシステムに入るということだ。Railsに乗り、OSSに貢献する気持ちを育てよう。pull requestはコミュニケーションだ。自律的行動でしか成り立たない。
pplog開発のコードレビューから学ぶpull requestによる自律的行動とコミュニケーションはそういう事例を書いた記事。
#12 Rails sideshow | mozaic.fm で語られているように、Railsの進化はWebの進化である。
Railsはバージョンアップがつらいという話をよく聞く。フレームワークのAPIは驚くほど早い周期で廃れ、入れ替わっていく。それの影響もありエコシステムを形成するgemもその影響を受ける。つまり、バージョンアップへの追従のために対処しないといけない箇所は非常に多い。
なぜ、それほどまで変わるのか。
進化のために過去を切り捨てることが、Railsが今も進化し続け、多くの人に利用されていて、エコシステムが形成されることの鍵である。過去の互換性を残せば残すほど進化は鈍化し、身動きがとれなくなってくる。その為に良いもののためには捨てる。
追従するために必要なことはなにか。
どれも必要であり、これらは生半可な気持ちでは実践できない。
それでもRailsを使うのは、 規約縛り、 周辺のエコシステム、 webの進化への追従 と言った点に魅力を感じるからであろう。
企業の活動において、railsを選択することはエンジニアリングにおけるただのフレームワークの選択ではなく、重要な経営判断である。 バージョンアップへ追従やテストを書くことを経営陣が意味ある活動であると理解することが大事 だ。
何かしら失敗経験を踏まえて今度は成功するぞって気持ちや今までとは違う理想を描いて転職ってすると思うんですよ。
なので、失敗経験はちゃんと振り返る。どうすれば改善出来るか、どんなアプローチが適切かを分析しないと同じ失敗を繰り返すと思うんです。そして同じ理由で転職を繰り返す。 アプローチは圧倒的に変えないと劇的な変化は訪れないんですよ 。真逆の自分になることも必要かもしれません。また過去の失敗や後悔に論理的な理由付けをしておかないと過去に引きづられ続けます。
理想にどうたどり着くかというアプローチは圧倒的に変えないと以前と同じ失敗をする。理想にはたどり着けない。
理想を語るのは簡単。理想に向かうためのプロセスを見せるべきだし、行動で示すべき。人は議論では動かない、議論の前に行動を。よりよい仕事をしたいなら、不満を口にする前によりよい改善的行動を。
そりゃ入ってみたら思ってたのと違う、よろしくない部分もあるでしょう。文句も言いたくなるでしょう。そういうことに対してのアプローチ、問題提起するか、課題として解決していくか、どういったアプローチが適切なのでしょうか。
会社はチームであることを認識すると経営に知らん顔出来ないし、客人ではいられなくなります。この会社の経営者だったらどう行動するか？そう考えれば他人ごとではなくなるし当事者意識が芽生えると思います。会社は誰かがよくするんじゃなくて一人一人の行動でしかよくならないのです。
割りと大きな会社に2003年の新卒で入った。研修はとても充実していて、本配属される前に3ヶ月間、広尾のNTTか何かの研修センターに通って研修を受けていた。その研修の昼休み、マクドナルドに入ろうとしたらL'Arc～en～Cielのkenがシェイク飲みながら出てきたのがハイライト（私はラルクの大ファンです）
こんなことをやってた（レジュメに書いてあったやつからコピペ）
完成形のレゴを外から見て、その仕様を把握し設計する。
設計から実装まで。パーツを組み合わせて、議論しながらみなでレゴを正確に組み立てる。
完成イメージから忠実に設計し、実装するまでの工程をレゴの組み立てという一件遊びのような題材で学ぶことが出来、楽しい研修であった。
ナニカ、業務アプリケーションを開発。余り覚えてないけどVB.NETって、まあまあ面白かった。
前述のアプリケーションから接続するためのDB設計と構築。DB設計で第三正規形まで叩きこまれた。その辺は大学時代勉強してこなかったことなので未だに役に立ってる。
（当時はCD-ROMから）インストールして、コマンドでゴニョゴニョするあたりをやった。大学時代Linux OSを要らないPCに入れたりしてたけど、だいたい同じようなこと。
プライマリ、セカンダリを隣の席の人のサーバーと連携して構築。隣の席に名前解決するの、なかなかよい体験であった。
OSI参照モデルってやつ。アプセトネデブ。Ciscoルータのコマンドとかお覚えたけど忘れた。TCP/IPは大学時代なぜかやたらハマってて勉強してたので割と得意だった。インフラやネットワークの仕事に就きたかったぐらいである。
なぜかLANケーブル作るところから始まった。ストレートケーブルとクロスケーブルの違いがどうのとか。
このシステム構築の時、完成した後の最後の日かナニカに「今日システムトラブルが起きました。現在の状況を今まで研修で学んだ知識を活かして復旧させて下さい」という課題が出た。
この時学んだのは、ネットワークトラブルはアプセトネデブのブからチェックする！ということ。
物理層のLANケーブルがルーターから抜けており、それを指しても復旧する気配がない。なぜならLANケーブルがクロスケーブルに変わっていたり、ルーターの設定が壊れていたり、とにかく物理層から直していかないと正解にたどり着かないという内容だった。実際にそんなことが起きるかどうかは別として、そういった物理層から疑うという癖はこの時ついた。
今思うと、ものすごい充実した研修だったし、割と今でも当時の学びは活きているかもとか思った。新卒研修、割と良い思い出である。
新卒研修後の配属先発表で、Webアプリケーションエンジニアとなる夢は絶たれた。サーバーやネットワークの運用・保守をやる部署に配属されたのだ。社会人ってそんなにうまく行かないんだなってことを痛感した出来事であった。
