  |
はてなキーワード: プラクティスとは
Wantedlyを使って転職すると、採用担当がマメな人ならWantedly上でその会社のメンバーに追加してくれる。
そうすると同じ会社のメンバーのプロフィールがお互いに見られるようになるんだけど、最近また転職したくなってきてちょっと困ったことがある。
転職向けにプロフィールを充実させようとは思うんだけど、その動きって他の社員にも見えるので、要は辞めようとしてるのがバレてしまうのではないか、と懸念しているのだ。
そういうものだと開き直るか、あるいは応募者向けに情報を充実させるという体で動くのもアリかもしれないけれど、それでもどこか抵抗感がある。
残暑という夏の名残が秋の長雨に流されていっても、晴れることがない気持ちを抱えながら「蛍火の杜へ」を見ていた。
艦これの川内にそっくりなおてんば娘の蛍が出てきて、映画早々にお茶が喉に詰まった。エンドクレジットでやっぱり同じ人が声を当てていた。
手がつけられないあの時分特有の闊達さがはしゃぎ回る黄色い声に出ていて、それだけで消えたくなる。
夏休みの宿題に全く手をつけてなかったが、子供達はちゃんと宿題を終えただろうか。
夏だけの逢瀬という縛りを破って距離感を一気に縮めたら消えて無くなるのは、まるで長続きしないバッドプラクティスな夫婦みたいだ。
身にしみて辛い。
蛍は夏の夜の盛りにしか光らない。夜の帳に涼しさと共に光る淡い旋律。
真冬にコタツからあの淡い光を思い出そうとしてもうまく描けまい。
ギンがいなくなった後、蛍はギンの住んでいた山神様と妖怪の山にほど近い山里で、
アジャイルのプラクティスはマイクロマネジメント的なものが多い。
これらのプラクティスを，アジャイルの文化であり精神であるところの「自律」なしに導入したらどうなるか。
日本の管理職のマイクロマネジメント好きと相まって，地獄のようになるのは想像に難くない。
だからエモいと言われようがなんだろうが，アジャイルはその文化や精神の理解なしに導入してはいけないのだと思う。
アジャイルを手法のように扱い，アジャイルのプラクティスだけをあたかも「アジャイル」であるかのように勧めるコンサルタントやトレーナーは危険極まりない。
（CIやCDのようなマネジメントにあまり関係のないものを，「アジャイル手法」ではなく，単に業務効率化の方法として取り入れるのはありかもしれない）
の方が良い。
追記 :
プログラミング技術はある程度自分で調べればわかるから設計のベストプラクティス教えて欲しいな。さすがにTOPページでjson取ってくんのはあんま良くねーと思っちゃった。俺が作ったんだけど。
追記 : 2015/08/12
社内勉強会を定期的にやってる。今日は分析系の話。傾向を分析するのではなく何を分析するかが重要らしい。っ俺の考えと違うかも知れないがすごく意識が変わった。
てか思った。そもそも、傾向分析する必要あんの？減少傾向であれば回復するのは厳しくねっかほぼ無理じゃね？以下の例がうちの会社がやってること。
会員数が減った → 退会した会員の様々な傾向を分析しよう！
具体的な原因を突き止めてそれらの傾向を分析する的な感じ。
でもそんなのめんどくさくね？
俺の考えは以下。
会員数が減った → SEOを強化（減った数以上に増やす）。そんなチマチマした改善の工数かけんなら新しい機能、新規事業を行う。
つーか、そんなに改善点があるアプリじゃないですよ、って言ってあげたかった。mixiみてよ、足跡消したりクソゲー増やしたのが原因じゃないでしょ。飽きられただけ。あとお客を動かす施策の意味の無さ。メルマガ、お得系。そんなん変わんねーよアホかよ。
っかこんなん考えること自体が嫌だわ。ちゃんと考えてる同世代は偉いし優秀だわ。ホントはちゃんと考えなきゃいけないね。
追記 : 2015/08/14
それなりに偉くなると会議が増える。僕らみたいな下っ端は「いろいろ抱えてて大変だなー」って思う。ように言い聞かせる。そもそも会議ってなんのためにやるんだろう？僕が考えた結果
「モノを実現するための話し合い」
何時間も掛けた結果ってのが不透明なまま。不透明って言い方は違うかな？要はないも得ていない安定の不毛会議。これに気付いてるのは僕ら20代の連中だけ。 上記の定義だと会議は夢物語を語る場だから会社が楽しいかもね。そこは勘違いしちゃいけない、憂鬱でなければ仕事じゃない
追記 : 2015/08/19
会議。議事録の重要さ。簡単で良い。ある程度の発言をまとめておけばそれ見て答えが出るので物事がスムーズにいく。延びる会社ってのはホワイトボードが多いしなー。
ほとんどライブラリ使えるの？とか知らねーよ、だいたい使えるわ。UIの共通化は？出来ねーって言ったでしょ。細かいバグはありそうだけど、相当実用的。でも多分これは導入されねぇな！みんなモチベ低い！
ほかプロジェクトが詰んでたやつ、stackoverflowに載ってたっぽい。もっとGoogle翻訳使えよ！！周知しよ、難癖つけられそう笑
追記 : 2015/08/22
でもプログラミングが出来る環境は維持されるみたいなんで良かった。SIerときは全員技術者だったから良かったな。っか楽。
よく技術者と営業の対立があるけど、極端な話、全員営業やる。全員技術者やる。どっちが良い方向になるかわかんねーよな。
営業はキツイよなー、成果出なきゃやり甲斐が生まれないでしょ。
追記 : 2015/08/24
この状況を覚悟してたけど、まさか想定してるなかで最悪な状況に出くわすとか笑。
「一生面倒みる覚悟がないなら助けるな」
大学教授に言われた言葉が身に染みる。多分あの人は地獄をみるだろう。
追記 : 2015/08/26
面談。褒められた。評価評価うるせぇ。評価＝給料だからあんま興味ねーよそこには。給料で転職したんじゃねーよ、前の会社の方がよっぽど給料いいわ。技術者出身の経営者がいる会社に入りたかったなほんとに。
っかangularjsすごいいいなと。双方向データバインディングとHTML拡張。フロントと完全分離出来るのがあつい。
追記:2015/09/07
夏休み終了。海外はいいなーやっぱ。いろんな人間見てるだけで楽しーわ、ってことで憂鬱な会社始まり。
僕が設計実装した機能を他プロジェクトに移行する案件で同期に任せてたんだけど、いろいろ未完成すぎて仕事増えた。詰みそうなとこ教えて「問題ないっすよ」って言ってたのに問題ありあり詰んだわ。nugetエグい（近々、エグいの書く）。まぁ、回避したから問題ないけどさ。
追記:2015/09/16
ちょー出世した。事業責任者的な感じ。給料もめっちゃあがる。転職して半年、プログラムが楽しくてひたすら組んでただけ。前の職場でも無理矢理リーダーさせられたし、無駄な運は持ってるなーと感じる。ひたすら組んでると開発効率だったり、何が出来るか、未来があるかってのを想像するのが好きなんで、それをキャッキャ言いながら楽しそうに話すことと、詰んだときにゴリ押し回避の方法を生み出すのが得意なんで、出来る奴だなーと思われてるっぽい。
これからはひたすらプログラム組むことは難しくなりそうだなー。あと結果と周りの目、いきなり入ってきた奴が急に出世するから嫌な感じだよね。まだ20代半ばよ、気が重すぎる。まぁ、半年後に急降下する可能性があるから気が楽になったわ。
追記:2015/09/30
今日、いろいろ発表された。なんか抜擢されたからおかしいなーって思ってて、抜擢された奴らを見たらびびった。全員、世渡り上手（俺も）。ちょっとガッカリ。自分でもちょっとコード書ける方だなーと思ってたけど、それが理由ではなかったのね。まぁ、同世代はスーパーエリートばかりなのになんかおかしいと思った。
もうasp mvc飽きたなー。angular楽しいからまだいいけど。
最近はrailsが楽しい！ちょっとしたキュレーションサイトを構築中だけど、コード量がaspと比べるとビビるわ。複数モデル使えるとかビックリマークすげーとか。gemもコレねぇかなーとか思ったらだいたいありそう、何より日本語情報多すぎ！但し、サイトいつ出来るかなー。
追記:2015/10/15
やっぱ感情的な人はあんまり好きじゃないなー。柔軟じゃなさ過ぎ。極端だけど、討論番組とか見てても感情的な人っておかしいからなー。俺も感情だけで転職したけど大失敗だったし。ただ、久しぶりに会いたいって思う人は感情的な人が多い。不思議。
っか雇われの身だったらなにかをやってやるって気持ちで臨むと終わるないろいろと。っかなにもしないでも金貰えることは常に頭に入れておかんと人間的におかしくなるね。
追記:2015/10/19
いやーやっぱ俺のこと好かねー人多いなー。予想通りっすね。つーか底辺突っ走ってきて就活時期にアルバイトしなきゃいけねーなって思ってた俺が降格なんてビビるはずねぇだろボケ。調子乗ってたら激安家賃の家にすまねーだろぅがよぅ！
って感じで愚痴はこれまで。
つーか、整合性は細かい部分じゃなくて決定した時にガツっと決めた方がいいな。まじでいちいち考慮したプログラムかいてられんよ、クソめちゃくちゃなコードになるし。そういう点ではjsはすげー勉強になった。ただ、結構プログラムの本質を突いていてjsも馬鹿に出来んなーと身を持って感じました。常に整合性を保つってのはその場しのぎのコードになりますね。
追記:2015/12/07
好きなことでお金を稼ぐって非常に難しいことがわかった。俺が転職したのもスキルアップじゃなくて好きなことやりたいって気持ちだったのね。すげー勘違いしてた。後悔してもしょうがないから資格を取ろう。
追記:2016/02/11
の方が良い。
追記 :
プログラミング技術はある程度自分で調べればわかるから設計のベストプラクティス教えて欲しいな。さすがにTOPページでjson取ってくんのはあんま良くねーと思っちゃった。俺が作ったんだけど。
追記 : 2015/08/12
社内勉強会を定期的にやってる。今日は分析系の話。傾向を分析するのではなく何を分析するかが重要らしい。っ俺の考えと違うかも知れないがすごく意識が変わった。
てか思った。そもそも、傾向分析する必要あんの？減少傾向であれば回復するのは厳しくねっかほぼ無理じゃね？以下の例がうちの会社がやってること。
会員数が減った → 退会した会員の様々な傾向を分析しよう！
具体的な原因を突き止めてそれらの傾向を分析する的な感じ。
でもそんなのめんどくさくね？
俺の考えは以下。
会員数が減った → SEOを強化（減った数以上に増やす）。そんなチマチマした改善の工数かけんなら新しい機能、新規事業を行う。
つーか、そんなに改善点があるアプリじゃないですよ、って言ってあげたかった。mixiみてよ、足跡消したりクソゲー増やしたのが原因じゃないでしょ。飽きられただけ。あとお客を動かす施策の意味の無さ。メルマガ、お得系。そんなん変わんねーよアホかよ。
っかこんなん考えること自体が嫌だわ。ちゃんと考えてる同世代は偉いし優秀だわ。ホントはちゃんと考えなきゃいけないね。
追記 : 2015/08/14
それなりに偉くなると会議が増える。僕らみたいな下っ端は「いろいろ抱えてて大変だなー」って思う。ように言い聞かせる。そもそも会議ってなんのためにやるんだろう？僕が考えた結果
「モノを実現するための話し合い」
何時間も掛けた結果ってのが不透明なまま。不透明って言い方は違うかな？要はないも得ていない安定の不毛会議。これに気付いてるのは僕ら20代の連中だけ。 上記の定義だと会議は夢物語を語る場だから会社が楽しいかもね。そこは勘違いしちゃいけない、憂鬱でなければ仕事じゃない
追記 : 2015/08/19
会議。議事録の重要さ。簡単で良い。ある程度の発言をまとめておけばそれ見て答えが出るので物事がスムーズにいく。延びる会社ってのはホワイトボードが多いしなー。
ほとんどライブラリ使えるの？とか知らねーよ、だいたい使えるわ。UIの共通化は？出来ねーって言ったでしょ。細かいバグはありそうだけど、相当実用的。でも多分これは導入されねぇな！みんなモチベ低い！
ほかプロジェクトが詰んでたやつ、stackoverflowに載ってたっぽい。もっとGoogle翻訳使えよ！！周知しよ、難癖つけられそう笑
追記 : 2015/08/22
でもプログラミングが出来る環境は維持されるみたいなんで良かった。SIerときは全員技術者だったから良かったな。っか楽。
よく技術者と営業の対立があるけど、極端な話、全員営業やる。全員技術者やる。どっちが良い方向になるかわかんねーよな。
営業はキツイよなー、成果出なきゃやり甲斐が生まれないでしょ。
追記 : 2015/08/24
この状況を覚悟してたけど、まさか想定してるなかで最悪な状況に出くわすとか笑。
「一生面倒みる覚悟がないなら助けるな」
大学教授に言われた言葉が身に染みる。多分あの人は地獄をみるだろう。
追記 : 2015/08/26
面談。褒められた。評価評価うるせぇ。評価＝給料だからあんま興味ねーよそこには。給料で転職したんじゃねーよ、前の会社の方がよっぽど給料いいわ。技術者出身の経営者がいる会社に入りたかったなほんとに。
っかangularjsすごいいいなと。双方向データバインディングとHTML拡張。フロントと完全分離出来るのがあつい。
追記:2015/09/07
夏休み終了。海外はいいなーやっぱ。いろんな人間見てるだけで楽しーわ、ってことで憂鬱な会社始まり。
僕が設計実装した機能を他プロジェクトに移行する案件で同期に任せてたんだけど、いろいろ未完成すぎて仕事増えた。詰みそうなとこ教えて「問題ないっすよ」って言ってたのに問題ありあり詰んだわ。nugetエグい（近々、エグいの書く）。まぁ、回避したから問題ないけどさ。
追記:2015/09/16
ちょー出世した。事業責任者的な感じ。給料もめっちゃあがる。転職して半年、プログラムが楽しくてひたすら組んでただけ。前の職場でも無理矢理リーダーさせられたし、無駄な運は持ってるなーと感じる。ひたすら組んでると開発効率だったり、何が出来るか、未来があるかってのを想像するのが好きなんで、それをキャッキャ言いながら楽しそうに話すことと、詰んだときにゴリ押し回避の方法を生み出すのが得意なんで、出来る奴だなーと思われてるっぽい。
これからはひたすらプログラム組むことは難しくなりそうだなー。あと結果と周りの目、いきなり入ってきた奴が急に出世するから嫌な感じだよね。まだ20代半ばよ、気が重すぎる。まぁ、半年後に急降下する可能性があるから気が楽になったわ。
追記:2015/09/30
今日、いろいろ発表された。なんか抜擢されたからおかしいなーって思ってて、抜擢された奴らを見たらびびった。全員、世渡り上手（俺も）。ちょっとガッカリ。自分でもちょっとコード書ける方だなーと思ってたけど、それが理由ではなかったのね。まぁ、同世代はスーパーエリートばかりなのになんかおかしいと思った。
もうasp mvc飽きたなー。angular楽しいからまだいいけど。
最近はrailsが楽しい！ちょっとしたキュレーションサイトを構築中だけど、コード量がaspと比べるとビビるわ。複数モデル使えるとかビックリマークすげーとか。gemもコレねぇかなーとか思ったらだいたいありそう、何より日本語情報多すぎ！但し、サイトいつ出来るかなー。
追記:2015/10/15
やっぱ感情的な人はあんまり好きじゃないなー。柔軟じゃなさ過ぎ。極端だけど、討論番組とか見てても感情的な人っておかしいからなー。俺も感情だけで転職したけど大失敗だったし。ただ、久しぶりに会いたいって思う人は感情的な人が多い。不思議。
っか雇われの身だったらなにかをやってやるって気持ちで臨むと終わるないろいろと。っかなにもしないでも金貰えることは常に頭に入れておかんと人間的におかしくなるね。
追記:2015/10/19
いやーやっぱ俺のこと好かねー人多いなー。予想通りっすね。つーか底辺突っ走ってきて就活時期にアルバイトしなきゃいけねーなって思ってた俺が降格なんてビビるはずねぇだろボケ。調子乗ってたら激安家賃の家にすまねーだろぅがよぅ！
って感じで愚痴はこれまで。
つーか、整合性は細かい部分じゃなくて決定した時にガツっと決めた方がいいな。まじでいちいち考慮したプログラムかいてられんよ、クソめちゃくちゃなコードになるし。そういう点ではjsはすげー勉強になった。ただ、結構プログラムの本質を突いていてjsも馬鹿に出来んなーと身を持って感じました。常に整合性を保つってのはその場しのぎのコードになりますね。
追記:2015/12/07
好きなことでお金を稼ぐって非常に難しいことがわかった。俺が転職したのもスキルアップじゃなくて好きなことやりたいって気持ちだったのね。すげー勘違いしてた。後悔してもしょうがないから資格を取ろう。
追記:2016/02/11
フレキシブルなチームを目指す場合に、最も必要なのは、チームを停滞させないこと。
世にあるなんちゃら開発の殆どは、この状況を未然に防ぐため、予防的なプラクティスを提案する。
ぶっちゃけ、停滞しないチームは進み続けるので、後は仕事量の問題です。と、だいたいごまかされるのが本のお決まり。
停滞の原因はいくつかある。ぱっと思いつくのは
萎縮。
プロジェクトメンバーが萎縮してる状態で、個々への責任が超えてる状態。
これはミスや失敗が発生した場合に、本人が責任を追っている思い込みすぎているか。か、過度に個人の責任に追わせている。
比較的、分かりやすいのが特徴だが、責任の塩梅という対処の難しさから放置されやすい。
無関心。見抜くのが難しい。
一見チームは滞りなく進んでいるように見えて穏やかに死に向かってる場合が多い。
外部刺激によって改善されるいことが多いが、これも力の塩梅によっては反発やさらなる無関心を呼ぶ
予防的なプラクティスと書いたが、それと同時に改善にも効果的なモノが多い。
朝会は、単なる進捗共有会だと利用されてしまうことが多いが
チームの信頼関係が弱い場合、そのリズムを共有することで信頼関係を築く。
さらに、個々のメンバーのリズムがおかしい場合、それをリセットする場にもなる。
追記歓迎
| 言葉 | 意味 |
|---|---|
| 議事録 | 気が変わる前の意見 |
| 非機能要件 | 実装するかは気分次第 |
| 確認しておきます | 今日は帰ります |
| オブジェクト指向 | オ○ニー |
| 偉い人の意見 | パルプンテ |
| ちょっとした仕様変更 | ザキ |
| 客先担当者の急な交代 | ザラキ |
| 要件定義から見直し | ザラキーマ |
| 確定した仕様 | 幻想 |
| WBS | Sはサグラダファミリア |
| キーマン | 鬱病になりにくいことがわかってる人 |
| ベストプラクティス | モジュール化されてません |
| 増員 | 導入教育で作業が止まる |
| それは新しい方法ですね | 問題がおきたらお前が対応しろ |
| 操作手順書 | 唯一多少参考になる設計ドキュメント |
| 備考 | 最も重要な考慮事項 |
| ＸＸはリスク | 問題が起きる(起きてる)けど俺は知りません |
| 試験のエビデンス | 誰も見ないけど一番手間のかかるもの |
| ペアコーディング | 今日はだるいから流すわ |
| すべての入力パターンを網羅したテスト | 1ケース0.1秒で実行しても宇宙が終わるほうが早い |
| フレームワークのバグ | 仕様です |
| カバレッジ100% | 不具合だらけですがコンパイルエラーはありません |
| トレードオフ | この仕事やるのと休日出勤どっちがいい？ |
| 動きます | 完成度10% |
| 一部のエラー処理がまだ | 完成度20% |
| 誰かの独自フレームワーク | お前はしぬ |
| 会社の独自フレームワーク | みんなしぬ |
主観は人によって違うのでやむをえないが俺の立場は以下のとおり。
俺：今までの解釈の延長線上にあるから、少なくとも新たな問題はない。(9条の改憲するときにかかる時間やコストに言及したのは、君の主張のデメリットや矛盾をつくためにすぎない。俺は先の解釈変更や今般の安保法制のための程度なら9条の改正は不要との考え)
少し付け加える。
今までの解釈が憲法の範囲内だというなら今般の法制もすでに枠にはまっている。
時の政権に特に9条に関する限り、事実上ほぼ無制限の解釈の自由があることになると見ることが可能なのは事実だ。
しかしそれは、現在の制度自体がもつ欠陥(統治行為論により9条に関する限り行政府の一部門が合憲性を事実上最終的に判断する制度)に起因している。制度の欠陥を安部首相がついたとみてもよい。
これが9条だけの話ならばまだしも、他の条文にまで援用されると確かに恐るべきことになる。
補足）
原語がデモクラティズムではないことにそれは現れている。したがってデモクラシーによって守られるべき価値がデモクラシーそのものによって毀損されるのはゆるされず、その価値とは「国民の幸福」である。
なお、侵略が許されないのは、それによって得られたなにかをわれわれ日本国民はもはや「幸福」とは呼ばないからである。
また、近代のデモクラシー以前から国家は存在している。デモクラシーを採用しない国民国家はありえるが、国民国家の基盤がないところに近代デモクラシーは不可能。さらに国民国家は国家の一種に過ぎず、国家は領域、人民、暴力によってなる。(つまりよりもっとも野蛮な国家すら、領土や人民の防衛はその責務である。ましてや現代日本においてをや)
より下部にあるより基礎的な層への脅威はそのままわれわれのデモクラシーへのより根源的な攻撃でもある。これへの防御を表層の制度の字義的解釈に拘泥して阻害したり、それをもってデモクラシーの破壊と叫ぶのは本末転倒。むしろ表層にある制度の欠陥が露呈したとみて、制度の改善をこころみるべきである。
制度の改善が著しく困難な時には、より基礎的な価値を防衛するために統治機構はさまざまな方便を考え出す。
今回の解釈変更も、そもそも安保と自衛隊を黙認するための統治行為論もそれだ。
これについては、まあ、君にはそう見えるかもしれんという感じか。
俺にとって外国の侵略が君が考えるよりは重大な危機と考える理由の一部は「論点の背景にある価値観の相違」の補足に述べたつもりである。多少分かりにくいかも知れないが、筋道はおえるのではと思う。
ところで君は先に大戦の惨禍を縷縷述べ、その原因を国家の暴走にもとめた。
そして、それへの反省あるいは対策として、立憲主義の厳格なる遵守を要求していたように見える。わたしの考えもまた私の主観では立憲主義を厳格に遵守するものであるがそれはともかくとして以下の点を指摘する。
天皇親政により立憲政治を絶命させようとした二・二六事件は立憲主義を逸脱した昭和天皇の勅命によって頓挫させられた。先の大戦はやはり立憲主義を逸脱した昭和天皇の聖断によって収拾された。
デモクラシーが前提とする立憲主義の手続きを墨守することによる不利益はデモクラシーのコストとして甘んじて受けるべきだというなら、昭和天皇は指をくわえて見ているべきだったということになる。
もし本当にそう歴史が推移したならば、前者についてはより早く大戦に突入する結果を招いたことであろうし、後者については惨禍がどれほど拡大したかはまったく俺の想像を越える。
こうした歴史をどう考えているのか。
なんかレイヤが混ざってる気がするな。
確かに最適化っていうのはプラットフォームに依存するんで、ハードやインフラが変化すれば不要になるものも多いよ。でもさ、ハードの進歩を1年待つより今出すことに意味があるってことはよくあるわけさ。
このゲームエンジン重いけど最適化しても次世代機ならどうせ無駄になるんだから、最適化やめましょう、ゲームタイトルは次世代機出た後にリリースしましょう、とか言ってたらいつまでたってもワクワクするものは出てこないよ。
で、アプリのプラクティスが下層に影響されるのはそのとおりなんだけど、例えばかつて中央のCPUで処理してたのが分散してローカルで処理しましょうってなってそれがまたサーバにアプリ乗っけようってなってそこからさらにいやクライアントにも振ろうってなって、でもこれって決して単に行ったり来たりしてるだけじゃなくて、スパイラルを描いて少しづつ昇ってるんじゃないかな。環境が一巡したときに、昔の技術のうち汎用性の高いものだけが蒸留されてさ。
脆弱性につながるバグというものがあって、それは入力チェック（バリデーション）で防げることもあるということだろ。
逆に言えば入力チェック（バリデーション）してないことで作りこんでしまうバグの中には脆弱性を生むものも多々ある、と。
言っていることは何もおかしくない。言葉の定義がみんなちょっとずつズレてるから間違っているように見えるだけだ。
私はそこまで単純に言い切れない。
文字だと思っていた値が謎のバイナリだったとしてもアプリケーションはほとんどの場合正しく動くとしたら。
高々100文字程度だと思っていた文字列が100KBくらいあったとしてもアプリケーションはほとんどの場合正しく動くとしたら。
アプリケーションの外部仕様を「ゆるく」設計してしまうこともあるんじゃないのか。
そして、その仕様に沿って入力チェック（バリデーション）を「ゆるく」実装し、
実際、アプリケーションにはバグがないのだから、これで問題ないことになるだろう。
しかし、入力チェック（バリデーション）がゆるいと、周辺ライブラリの潜在的なバグを踏む可能性がそれなりに高いから
安全のためにも、アプリケーションの外部仕様は「問題ない範囲で厳密に」設計しておけ、というプラクティスは何か間違っていだろうか。
何にイラついてるかって、「人気エントリに入ってきてウザい」「なんだよ焼き直しじゃねえか」「はてブやたらついてる」「PV稼ぎかよクソ」「英語勉強記事と同類だわ」「入れるべきって、あんたの仕事環境や趣味嗜好を根拠にすんな」「また全部MacVimじゃねえの」とかそういうことを思うわけ。
とは言え自分もそういう記事を参考にトレンドを知ったりしてお世話になってきた部分もあるんだけど、じゃあ自分も同じように紹介して還元したいかっていうと、そうじゃない。だけど需要はあるみたいだ。みんな、良いアプリを知りたいんじゃなくて、自分の作業をもっと楽に早くできないか考えてるんじゃないかな。
アプリはあくまで道具。どんな目的を達成するために、どう組み合わせて、どういう手順でそれを使うのか。それを導入すると、どういう人がどう嬉しいのか。それをはっきりさせてほしい。それが理解できないままインストールするなんてことはしたくない。
だから、業種や職種、OS、作業目的を明示したレシピを公開して共有するサービスがあれば素敵じゃないか。例えば、
といった感じでぱっと自分の思いついたものを適当に上げてみました。
で、投稿されるレシピに含まれるアプリの統計を取ってトレンドを探ったり、時代の移り変わりに応じてレシピをバージョンアップしたり。黒い画面に抵抗がある人はそれが含まれるレシピを省いて検索。同じ作業目的でも効率に差が出るレシピには知識要求レベルも割り当てることでステップアップ形式にするとか。
これらを充実させていけば、目的に特化したレイアウトで規格化・整理した状態で横に並べて比較参照でき、それに慣れた人々はエゴに満ちた中途半端なブログ記事のクソデザインで邪魔なサイドバー、冒頭のよくわからない挨拶、わざわざ自サイトでそれをやることにイラついて糾弾が加速し、次第にアプリ紹介記事は消えていくことになるでしょう。そして結局何を目指しているかというと、
ということなのです。会社としての強みとしてそういったノウハウを抱え込むのもよいですが、なんかもっと高レイヤーで競いあったほうがいいんじゃないのとか思うわけです。業務フローをオープン化したらプレイヤーのスキルが汎化されて、より人材の流動性も高まって、もっと人間にしかできないようなことで悩めるようになるんじゃないでしょうか。
HTMLとCSS, JavaScriptはちょっとだけ分かる
dotinstallとか見てブラウザでタイマー作ってわーいって喜んでるくらいのスキル感。
→本を買ってやるのは安上がりだけど途中で挫折しそう
→じゃあお金稼ぎながら学んだらいいんじゃ
バイト始めることになった
バイト始まる
課題を出されて、できたら業務に入れる
誰も教えてくれない
ググってググってググりまくる
ひーひー言いながら2~3週間でなんとか終えた
なんとかなった
このときくらいにパーフェクトPHPを読んだ。FWは、つくれる！
あーようするにURLを受け取って振り分けたり、DBからデータ引っ張ってきて画面に表示させたりするのね
分かった気になる←分かってない
GET/POSTでごにょごにょすればいいんだね楽勝だわ←全然分かってない
FuelPHPを聞きかじって、何をトチ狂ったのか在宅でwebサービスの受託をやる
まあ良い経験になった
フレームワークいくつかやって、web開発のいろんな概念やtipsがたくさん頭に入ってきて、
あーあれかーくらいには思えるようになった
DBのCRUD操作, ORM, DBマイグレーション, RESTfulとは, コマンドラインでコード生成,認証周りのプラクティス ...
さて、バイトが本格的？になってくる
一人で開発 責任おもい
でもなんか躓いた。
書いたコードに自信が持てない
これでいいのか不安になって手が進まない
セキュリティで手直しはたくさんもらった
フレームワークにはDB操作のライブラリがちゃんとついてるのにそれ見ずに自分でSQL組み立てて案の定エスケープしてないし、とか
でも、なんとか完成させた
プッシュして、マージされて、できちんと本番環境で動いてる。やったね。
Rubyを知った
PHPと違って()が殆ど無いし、;ないし、do~endとか何だよって感じだった。
Railsも知った
それからは空いている時間の大半をRubyとRailsにつぎ込んだ
まずはRailsTutorialをやってみた
テスト周りでつまづいたけどなんとか終わらせた
dotinstallやらミニツクやら、検索して出てきた記事・チュートリアルはとりあえず手をつけて学んだ
はじめはRubyを理解せずにRailsをやっていたけど、すぐにRuby自体に興味が出てきた
はじめてのRuby・はじめてのプログラミング・たのしいRuby・プログラミング言語Ruby... 入門系の本を乱読した
PHPでさんざん苦労していたからか、Rubyでオブジェクト指向を学ぶとなんの無理もなく頭に入ってきた
その後、パーフェクトRubyで標準ライブラリやらGemやらSinatra（支那虎じゃなかった）やらについて学んだり、
メタプログラミングRubyで黒魔術を学んだりした。巻頭のMatzの言葉痺れたなー
バイトのほうも何とかこなせるようになってきた 成長すげー
Vagrantをかじる
AWSでいろいろ遊ぶ
webスクレイピングとか検索APIとか使ってムフフな画像をアハーンしたりして遊んでた
Rubyで言語をつくろうだの、スクリプティングを極めようだの、JavaとRubyがどうだの。
メタプログラミングだの、デザインパターンだの、テストだの、リファクタリングだの。
借りられる本は借りて済ませた。全部買ってると破産する
他にもRubyとつかない本もいろいろ。
プログラマが知りたい97の何とか。いい本
Rubyの関数オブジェクトからのつながりで関数型プログラミングにも手が伸びる
OOPと全く違う。
就活はじめるよー
まあ、エンジニア枠で探すことにする
エントリーめんどくさい
ので、1社受けて落ちたら次の会社エントリーするという作戦にした
無計画玉砕作戦
とはいえ、なんとかなると思ってやってく
気を揉む期間
やたらパララックスつかってゴテゴテにしてるわりに、何が言いたいのか伝わってこない
せめてよく使ってる言語くらいはのっけておいて欲しい。
で、１社選んで応募して、選考が始まった
面接、失敗したなと思ったところもあったが
嘘つかない
知らないことを知ってるように話さない
は通せたので良かったと思う。
で、進んでいって最終面接。これもなんかよく分からないうちに終わってた
相手が適宜フォロー入れて話しやすいようにしてくれたのは覚えてる
うん、ぜひ当社にご入社いただけたらと思いますとのこと。やったね。
前から気になってた会社ではあった。勝手にリスペクトしてた会社。
自分が憧れてる技術者さんたちが在籍してる会社でこれから働くことができる
いろいろと運が良かった。嬉しい
他の会社はどうしようかな。
受けてみたい気もするけれど、エントリーがめんどくさい
続けるかどうかは未定だけど、ひとまず休憩することにする
私は大規模・小規模、それこそものすごい人数でのチームや、自分一人のプロジェクトまで経験してきた。化石のような連邦事務局でもクールなシリコンバレーの会社でも働いたことがある。私は１２種類以上のプログラミング言語を学び使っていた。私の時代には ウォーターフォール/BDUF (big design up front), 構造化プログラミング, トップダウン, ボトムアップ, モジュラーデザイン, コンポーネント, アジャイル, スクラム, エクストリーム, TDD, OOP, ラピッドプロトタイピング, RAD, その他思い出せない様々な手法が生まれた。 でもそれらで上手くいってると思えるものは一つもなかった。
（ 注：ここで書いてある「ソフトウェア開発手法が上手くかない」の意味について説明させてほしい。それらはソフトウェア開発のプロセスや、ソフトウェア開発そのものについて予測性や再現性を提供していないという意味だ。ほとんどのソフトウェア開発手法はプログラミングに工学風のプロセスを提供してくれる。しかし、上記の理由でそれだけでは不十分だ ）
チーム生産性・幸福度・メンバーのつながり・１日あたりのコード量・人月・コードの品質・製造された成果物、、、そういったもの以外でソフトウェア開発手法が上手くいってるか、いってないかを図るものはあるのだろうか？
もちろんどんな手法論だって、それに合わせた正しい指標を使えば上手くいってるか・いってないかが計測できる。しかし一番肝心の問題 ーー予算と期限内で要求を満たす事ーー について定常的に結果を図れる開発手法を見たことがない。
上記は私の経験則だけど、僕の知ってる殆どのプログラマは同じような事を経験している。それらの話から言えるのは「ソフトウェア開発手法について厳密な研究は存在しない。なぜならソフトウェア開発上のすべての要素をコントロール事が出来ないからだ」
こんな思考実験をしてみよう、
２つのプログラマのチームがある。どちらも要求・期間・予算はしっかり確定していて、同じ開発環境・プログラミング言語・開発ツールを使うとする。一つのチームはウォーターフォール/BDUFをつかう。もう一つのチームはアジャイルテクニックを使う。
この思考実験にはもちろん意味がない。メンバー一人ひとりのスキルや性格、お互いにどんなコミュニケーションを取るか、そういったことの方が開発手法よりも大きな影響を与えるのは明らかだ。
アリスター・コッバーンが２００３年に"People and methodologies in software development" (http://alistair.cockburn.us/People+and+methodologies+in+software+development) という記事でまとめている。
" 人と人の間で、更には刻々と経過する時間の中で変化するメンバーのキャラクターこそがチームの振る舞い、結果に影響する最初の要因だ。 "
私がプログラミングを始めた1970年当時、開発体制はプロジェクトマネージャー・ビジネスアナリスト・シニアプログラマと言った階層構造でガッチリと管理されていた。開発言語やツールを選ぶことは許されていなかった。私はいくつかの大きく複雑なプロジェクトに関わっていたが大体上記の様な働き方だった。成功したプロジェクトもあれば上手くいかないものもあった。
今は開発言語やツールに合わせて、開発手法・働き方をプログラマが選ぶのが当たり前になっている。アナリストやらがプログラマを監査することは殆どなくなった。プロジェクトマネージャーは"リーダー"・"スクラムマスター"という形で矮小化され、管理職の権限は無力化され「チームの意見をまとめる事」以外は何も出来なくなっている。
ガントチャート・スケジュール・ドキュメントを使った「厳格なマネジメント」は"ユーザー"や"ステークホルダー"の関与を省かせて、"ユーザーストーリー"を要約していた。今や私の周りではまともな大人が監督してるとは思えないプロジェクトばかりだ。プログラマのカウボーイスタイルのコーディングを放っておいてるのに、彼らは自分好きな手法を適用するか作るかさせて、１９８０年代以上に決め事・儀式だらけだ。
実際、今のプログラマは１９７０年代のCOBOLの現場以上に手法論について厳格で、盲信している。実際私が最近関わるプロジェクトは、大体の場合何も価値を生み出さないのに一人か二人のメンバーが開発したプロセスや"ベストプラクティス"を背負わされてるものばかりだ。
プログラミングチームが手法論を採用する（多くの場合チームの数名か、一人のいじめっ子が決めるのだが）と、やがて厳格に従うように要求を始め、やがてそれは宗教になる。そうなることではじまる無自覚な攻撃が、手法論やテクノロジーが生産性を高めるより早く、チームの生産性を下げてしまう。
私の経験から言わせると、アリスター・コッバーンの論文やフレデリック・ブロックスの「銀の弾丸はない」http://www.cs.nott.ac.uk/~cah/G51ISS/Documents/NoSilverBullet.html で述べられているように、プロジェクトを成功させるにはチームメンバーが共通のビジョンを共有する事（その本では「コンセプトの統合」と呼ばれている）が必要だ。特に何かの手法論を指しているのではなく、これと言ったプロセスがない場合でも同じだ。私はプロジェクト管理ツールの「完了」ボタンをクリックするだけのチームで働いことがあるが、何故か分からないがBDUFやアナリストの監査の元で働いていた昔よりも気分が悪いものだった。
私はプログラマは様式やツールにこだわるより、同僚の話にもっと耳を傾け、もっと一緒に働くことに注力したほうが良いとおもう。そしてプログラマは手法論やプロセスについてもっと疑って掛かった方が良いと思う。そうすればみんな魔法の様に生産性が上がる、間違いない。多分プログラマが社交的なスキルを高めるのは他の職業より大変な事だと思う。（私は必ずしもそうだと思っていないが。）でもそういったスキルを鍛える事は、手法論を試すより事よりはるかに元が取れる、間違いない。
これの翻訳です。
http://typicalprogrammer.com/why-dont-software-development-methodologies-work/
注1 '14/02/11 まだ半分しか翻訳してません。（明日完成予定）
本当に優秀な人ほどすぐやめる。
マッキンゼーに代表される、硬直化して一方的かつ定型的でヒエラルキー構造のいわゆる「アメリカン」な考え方。
サービサーとしての意識が低く、抽象化したノウハウを持っていることが常に正しいという態度。
コンサルフィーが法外なため大企業しか知らず、企業経営の基本に無知であり、それを自覚するチャンスがない世界。
長くいる人は、これらが体に染み込んでしまっているのだ。
弁舌が立ったり、ベストプラクティスを知っていたり、お偉いさんに教えを説いたりしていても、社会復帰は難しいのだ。
現場経験なくマネージメントだけで本当に食べられる人はごくわずかだ。
多くの人は「何かすごい経験をした」という歪んだ充実感を持っている。
特に、コンサルがもてはやされた時代にキャリアのピークが重なった人はなおさらだ。
長年コンサルをやっていたキャリアの人と交わる場合は、彼らのバックグラウンド・特性・使いどころをよく見極めてお付き合いすることをおすすめする。
