寄稿のご依頼を頂きまして、転職に関する記事を書きました。
能ある鷹は爪を隠すではダメで、能ある鷹は爪を出してアピールしないと何も始まらないぞ、という所を重点的に書いています。
よろしくお願い致します。
寄稿のご依頼を頂きまして、転職に関する記事を書きました。
能ある鷹は爪を隠すではダメで、能ある鷹は爪を出してアピールしないと何も始まらないぞ、という所を重点的に書いています。
よろしくお願い致します。
献本御礼・・・ではなく、ウチの取引先の社長さんに「SEOってなんっすか?」って聞かれて上手く説明できなかったので本書を購入しました。
基本的な考え方が整理できて良かったです。もっと速く知りたかった。
本書の最後の方にチラッと書いてあるのですが、これって大事なんじゃないかなって思いました。
SEOって検索順位を上げることでサイトに来てくれる人を少しでも増やそうということで、要は上位に表示させることを言うんでしょ・・・っていうのは違う、と。もちろん上位に表示できなければ陽の目を浴びることはないんだけども、広告で成果を出すのとSEOで成果を出すのは、アプローチが異なると本書では書かれています。
広告の場合は販促がメインになるし、極端な話をすればリスティング広告を打てばすぐに上位に表示されるようになる。でも、SEOはあくまで検索エンジンの大まかな仕組みを知り、その上で検索する人が役立つコンテンツを作り情報が流通されていく中で上位表示を目指していくものなので、やるべきことが全然違ってくるし、長期的に見ると強いのは・・・? ってことですね。
という概念があって、上述したようにコンテンツの質をベースにリンクを介して情報を拡散していくことで検索する人に取って意味のあるコンテンツにするアプローチと、検索エンジンが抱える構造的な不備を利用して価値のあるコンテンツであると見せかけるアプローチがあるそうです。前者がホワイトハット、後者がブラックハット。へー。
ホワイトハットのやり方はとても地味で時間を伴うけど、後者なら上手いことやればすぐに上位表示が可能になる(そういう時期があった)そうです。ブラックハットの代表な手法が自作自演でリンクを貼ってリンクを稼いでいるように見せかけるものですって。でた!SEO業者ってやつだ!
そんな業者ははやく死ねばいいのに・・・と単純に言えない事情があります、と。そういった被リンクのあるサイトに対してペナルティを与えると、リンクを張るサイトが意図的にほかのサイトを順位を落とす(ネガティブSEOと言うそうです)ことになるので、バランスを取らざるを得ない状況になっている、と。
政治的なことがSEOの世界でもあるんですねぇ。
すごく地味。ホントに地味。プログラミングもそうだけど。
検索されうるキーワードを吟味して選定を行い、Googleさんがインデックス出来るようにマークアップして、検索してきてくれた人が最大限喜ぶコンテンツを頑張って作って、少しでもシェアしてくれる努力を続ける。参入障壁はゼロ。競合や後発はいくらでも出てくる。この状況で継続的に改善・努力をしていける会社さんは、そうそう多くないと思うわ。
逆に言えば、潜伏期間を耐え忍んで頑張ってきた人たちのみ、SEOの成果が享受できるのかもしれませんね。
・・・そんなことをちょっとでも思った方にこそ、本書を当たってほしい。「10年使えるSEOの基本」という主題の通り、本書は検索エンジンを取り巻く技術が変わっても影響を受けない普遍的なポイントに絞って、真っ当に検索エンジンと付き合う視座を提示してくれています。これを読んだあとには、「よし、SEO対策を行うべくSEO業者に見積をもらおう!」とはならないはずです。そんな死亡フラグを立たせないようにするのも、我々Web技術者の役目の一つだと思います。
Webサイトの保有コストは限りなくフリーに近づいている時代が来ているからこそ、地道にサイトを「経営」していくアプローチをしっかり固めて行きましょう!
実業之日本社、酒井様より献本御礼。
ITシステムの罠31 システム導入・運用で絶対に失敗しないための本
酒井様いわく、何故使い勝手の悪いシステムが生まれてしまうのだろう、という疑問が本書発刊のきっかけとなったそうです。
本書は外資系コンサルのATカーニー社にてハーバード大のMBAを卒業された超エリートが監修をされております。システム部門、ユーザー、経営の3者が共通言語を持てるようになるまでの「罠」を31点挙げられております。ERP導入したけど現場で使っているのはExcelや野良システムっていうのはあるある過ぎますね。パッケージのカスタマイズを前提にするならスクラッチで組んだ方が結果的に安いケースが多いとかね。あるよね。
正直なところ、本書を読んでだいぶ悲しくなりました。挙げられている失敗談の多くがITがブラックボックス化しすぎている。成功裏に導くほうが難しいぞ・・・っていう読後感。ATカーニーさんの事例が元になっているのでしょうから、フィクションではなく実際の現場で起こっていることなんでしょう。残念です。
本書で挙げられている罠の中で最も悲しい事例が、事業会社の部長さんが新規事業開発の為に取引先のITのベンチャーの技術者を引き抜いて内製部隊を作ったけど、仕様の策定権が内製部隊にないので全くスピードが出ない上に何を作っていいかも不明瞭で、当然のようにゴミのような成果しか出せず、このチームの処遇に困ったという話です。内製回帰の失敗事例、結構多いみたいだね...。
ITプロジェクトほど最初の1歩目から間違えたら後工程全てが駄目になるものはないな、と本書を読んで改めて痛感しました。1歩目は多くの場合要件定義の工程でしょう。
要件定義の工程は、食べ物のレシピを作るような工程です。「トマトソースパスタ」を作って皆で食べようと仮定します。でも、「トマトソースパスタ」のレシピって千差万別ですよね。トマトソースパスタの味の違いをレシピを見ても分かる人ってそうそういないよね。実際には口に入れないと(試食しないと)分かんないですよね。ユーザーはパスタを作る料理人じゃないし、プロが設計書を見てもそこからROIを判断するのは原則困難です。
上記のような状態が本書でもある「経営とITが共通言語を持てない」状態です。もう見飽きたぞ、この光景。なので、どの種のプロジェクトよりも、ITは撤退の決断が重要になります。間違いが発覚した所まで全てを巻き戻してやり直すしか無いので、間違ったことを頑張って推進しないで下さい。本書で挙げられている罠が複合的になって、役満クラスになっちゃいますよ。
本書の残念な所はもう1個あります。全体的に論理展開が雑です。効率化・可視化・最適化・具体化・・・左記のような「XX化」という言葉がかなり多いので、尻切れトンボ。コンサルさんはこのXX化が大好きですね。XX化というのはビジネスにおける「通っぽい言葉」で、これほど費用対効果が不明瞭なものもない。でもそれなりに筋が通せるし、同時に銀の弾丸っぽい。僕にとってはNGワードです。
最も残念なことは、この本を読んでもあなたがITシステムの導入に失敗する可能性は引き継き高いことです。失敗談を100個並べて穴が空くまで読んでも、失敗の兆候は経験でしかわからない。だけど、僕はシステム導入・運用で絶対に失敗しない方法を知ってます。タダで教えますね。自分で作って下さい。自分で作ったものを導入して運用して下さい。仕様を考える人と実際にプログラムを書く人を同一人物にして下さい。これだけです。
なんで失敗しないかと言うと、仕様の策定者と実装者が同一になれば、ユーザーと経営とIT部門で共通言語が持てるからです。本書の主題は、ITがと経営の間で共通言語が持てないままビジネスとITが分断されてしまうことがITプロジェクトの失敗の元凶にあるという警鐘です。共通言語が持てない理由、ひとつだけですよ。自分たちで改善できないからです。改善できない理由? 管理できないからです。管理できない理由?自分で手を入れていないからです。逆説的ですけど、失敗したくないなら失敗のリスクを取らないと絶対に失敗するんだよね〜。
僕が書いた絶対に失敗しない方法が極論すぎるとお考えの方も多いでしょう。是非、本書をあたって下さい。僕の言いたいことの輪郭が、より鮮明になること請け合いです。
ITシステムの罠31 システム導入・運用で絶対に失敗しないための本
発表資料はこちらにございます。
www.slideshare.net
お金の流れについて知ったから良いエンジニア人生を築ける理由にはならないんですけど、会社組織と無関係では生きていけないので... 会社組織の論理ってものがあります、と。その上で仕事とお金の関係だけは精査して整理しておかないと色々不幸なすれ違いもあるんじゃないかなってことで、その辺をまずお話させて頂きました。現場に居続けるのもなかなか難しいチョイスになると思いますし。
この資料を作るにあたって本屋さんや図書館で経営学と書いてある本を結構読んだんですが、どの本でも組織運営について多くのことが書かれておりました。会計の話は触れていない本も多かった。ビジネスモデルの構築であったり経営戦略理論であったりというのは、時代が変わると再定義されてきている感が強く、結局何の話なのっていう尻切れトンボ感がね...
ただ、経営を語るにあたり全く色褪せない概念が「Do the right things.」と「Do the things right.」の2つ。これは車の両輪です。まずは自社にとってのrightを定義すること。これが最も重要です。なぜなら、間違ったことを正しく遂行することが起こりえるからです。ちなみに、「Do the wrong things right」は、最悪の状態です。
下記は英語で書いてありますけど、わかりやすく書いてあって勉強になります。
次に、正しいことを正しく行う。つまり組織設計を行っていく事が必要です。ひとりでは何も出来ませんし、自分ができても全く意味が無いので... 組織として強くあるためには、組織の設計が必要です。
当然ですが、人間には意思がありますし、誰も自分以外にはなれません。他人の思考を操って自分が望む結果を出すように強いることもできません。なので、直接動かすことが出来ない人をいかに動かすか(動いてもらうのか)が、一番重要なことだと思っています。組織運営の肝ってここだと思っていて、その際に僕が気をつけていることが後半部分のスライドです。
ホンマは下記の話で1時間引っ張りたいんですが、さすがに厳しかったです。懇親会で少々させて頂きました。
本日の発表資料です #bpstudy pic.twitter.com/kaX6K0Cj7v
— やきう大好きござ先輩 (@gothedistance) 2015, 4月 28
これで合計3回BPStudyに登壇しまして、なんと最多登板タイに踊り出ました。BP社さんということで、次は僕が最近お気に入りで使っているPythonのFlaskの話をして、ハーラー単独トップに躍り出たいと思っております。
それでは、また。
録画放送の準備が整っております。どなたでも会員登録を頂ければ、無料でご覧頂けます。
前編の内容としてはこんな感じです。
この前編の内容は、僕が2010年頃に抱いていた問題意識が根本にあります。自分の働きは会社の経営に資するものでなければ、その仕事は意味がなくなってしまい会社運営の負担になってしまいます。それを「そんな仕事をアサインした経営陣無能」では終わらせるのではなく「この状況下で成果を出す為には何が必要で何をやめなくてはならないか」と考えてもらいたいな、と。チーム運営でも同じような状況になるでしょうから。
意外と多くの人が、自分の会社がどこで儲けているのか語れない。漫然と自分の働きとは関係なしに会社が存在するもんだと思ってる。そのギャップに気づくのが、自分の仕事がなくなるまでというのは遅すぎる。
— やきう大好きござ先輩 (@gothedistance) 2010, 11月 13
それでは、どうぞお楽しみ下さい。
はてなブックマークカウンタを見たら、ブログの累計ブックマーク数が40,000を超えました。みなさま、ありがとうございます!
2006年4月からはてなダイアリーを始めたので、今年で10年目ですか。我ながらよく10年もブログをやっていられるものです。30,000に到達したのが2011年10月なので、3年半ほどかかりました。更新頻度が激落ちしたので当然なんですが...
gothedistance.hatenadiary.jp
gothedistance.hatenadiary.jp
何度でも言いますが、このはてなブックマークという仕組みが無ければ、今の自分はありませんでした。勝手に感謝してます。はてなのユーザーであることが恐らく最大の貢献だろうと思っていますので、はてなから脱藩することはございません!栗栖社長!ご安心下さい!え!あんたはいらん?!
累計が20,000前後の頃はブックマークを頂くことが少なからずモチベーションになっていましたが、流石に4万となるとモチベーションにはなりません。ブクマされる為に書こうとは思わないですが、自分の面識のない誰かに伝わるのはリスクもやりがいもあるので、モチベーションの一因となって細々と続けることができています。通常はリスクが圧倒的に高いんですけど、なんとかバランス取ってます。リスクを取るのが好きな性分なんですね.... '`,、('∀`) '`,、
あと、自分は文章を書くのが何を差し置いても好きです! 言葉で何かを表現するのはいつだって面白いです。
これからも弊ブログが、いつも読んで下さる読者の方のお役に立てればと思います。
BPStudy#92 - connpassとBPStudy#91 - connpassに連投するから献本オネシャスしたら、寛大な佐藤社長より頂いたので御礼の書評を書きます。
以下、本書をあたって感じたことを書き連ねます。
これ、相当便利ですよね。flaskをやるようになってから知ったんですが、結構衝撃でした。pythonの実行モジュールを指定すれば、複数バージョンでPython動作環境が作ることができる。phpだとvirtualenvに該当する仕組みがないのが辛みあるし、ビルドオプションも多いし、色々だるい..。
BP社ではシンプルな原理原則がありました。
ヘルシーな運用を心がけたいものです。
本書はではこんな感じで分割されていました。
ApplicationとDomainで別のモデルに分けているんですね。ApplicationではDomainModelの処理を呼び出すだけに留めておき、Domainに変更が発生する場合は全てそちらに処理を書く。複数のDomainModelが係る場合は、ApplicationModelを経由して呼び出すようです。
永続化される状態を持つオブジェクトとアプリケーションで利用するオブジェクトは違うことが多いので、そこを分割統治しているようです。MVVMに近いなぁと思いました。ViewModel→ApplicationModelみたいな感覚を覚えた。
Ansibleの標準モジュールで構築できないような作業は無駄か間違ってるから、削除するか手順を改善するようにしている、とのこと。環境構築は簡単であれば簡単であるほど望ましいはずなので、自動化ツールを使ってバッドノウハウが溜まらないように留意しましょう。
僕が特に面白いと感じたのは上記ポイントですが、本書ではドキュメントであったりチケットの作り方やテストのやり方なども書いてあり、仕事をする上での要点がうまくまとめてあります。本書はPythonの入門書籍ではなく、あくまでPythonで仕事をする人のための書籍です。ただ、他言語に見識のある方がPythonで開発するってどうなんだろって興味をもった時、本書をあたればPythonのコードを見つつ現状の作業環境と対比できるので、勉強になって面白いはずです。
ビジネス+IT様よりご依頼を頂きまして、記事を寄稿しました。先日公開した
エンジニアのための経営学の業務改革の部分を重点的に書かせて頂いた記事です。
原則、会員登録が必要なサイトさんですが、今なら非会員の方でも読むことが出来ます!
どうぞよろしくお願い致します。
おはDで有名なビープラウド佐藤治夫 (@haru860) | Twitter様よりご依頼を頂きまして、お話をさせて頂きます。BPStudy91,BPStudy92と連投でございます。
皆さんに「会社を見る目」を養って欲しいと思っていますので、その為の視座やヒントをご提供したいと思っています。
残念なことに、僕を含めて多くの方は何らかのお仕事をして対価を得て社会生活を営んでいかねばなりません。つまり、何かしらの貢献をして「会社に自分の居場所をつくる」ことが求められます。その場所にいる理由がないなら、お互い不幸です。
この視点がすっぽり抜けてしまうと、色々不幸なことがあります。スキルアップ(自分磨き)にご執心な方ほど、会社での居場所を失いがちです。スキルを身につけたら万事OKではありません。Javaが好きでJavaの勉強をしてJavaのOSSツール出してる所に入社したら、終始PHPのレガシーコードをメンテナンスするような話も枚挙に暇がありません。
会社を見る目を身に付ければ、初めて立体的に自分の仕事を見直すことが出来るようになります。そして、不幸なすれ違いが減り、自分がやっていきたいことと会社がお願いしたいことが高密度でリンクするようになると思っています。そうすれば、自社の先も読めるようになりますし、お客様のお困り事も一歩進んだ観点から見えてくるようになるんです。
そーゆー話を中心に、自分の身を守る視点と自分の能力を活かす視点から、「エンジニアは目の前のものさえ作ればよい」という幻想をぶち壊していきたいと考えています。
べき論というのは「義務を果たすこと、理想を実現しなければならないこと」などを強く主張することだけど、何も生産的な要素がないなぁとつくづく感じました。
べき論で自分の考えが無駄に縛られて精神的な自由さが奪われてしまう。べき論はしないことも同時に規定するので、自ら望んで板挟みになるようなもんだ。「すべき」と「しないべき」の板挟みの果てにできるのは「かくあらねばならない」という強烈な固定観念。強烈なリーダーシップを発揮することもあるが、思考の引き出しが1つしかないので、切羽詰まると正論(**であるべきだ)としか言えなくなってしまう。
べき論は終わりがない。言われたら言われるほど、自分に課されている義務や理想が膨らんで負担が大きくなってしまう。本当はミニトマトぐらいの大きさでしかないのにね。そして、その精神的負担は常に付きまとう。終わりが無いから。何を言ってもべき論で返されたら、これほどめんどくさいものもない。すべきと言っているのは自分がそうして欲しいから言っていることが多い。他人が共感できない自分だけの正しさというのは、非常にヒステリックに映る。
べき論では地に足の着いた議論にならない。置かれている立場が考慮されないので、「もう大丈夫」とも言えないし「こうしよう」とも言えない。よくわからないゴールだけが語られ、話の腰を強烈に折ってしまう。「できてたらやってんだよ」「それがダメだってわかってるよ」という憂鬱な気持ちが出てしまう。色々と「○○すべき」って言われたのに全然出来なくて結果が出なくて自分は...って自分を追い詰めてしまう。心の新陳代謝が出来なくなる。最もアカンやつ。あなたに否があるわけじゃないのに。
べき論では捨てていいものが捨てられなくなる。べき論は万能すぎて、森羅万象に対して○○すべきと言えてしまう。勉強はすべきだし、結婚はすべきだし、風邪は引くべきではないし、ミスはすべきではないし、太るべきではないし、仕事は頑張るべきだし。捨てていいものはいくらでもあるはずなのに、べき論が作り出すステレオタイプな理想に潰されてしまう。
僕は中小にいるので会社全体が見えるから特に感じますが、「こうすべき」「やめるべき」では間違いを正そうとしなくなります。べきだったよね〜よね〜ですよね〜で風化して同じ問題が再燃する。責任の追求をしなくても良いから丸く収まるけど、トップのミスとして認めればすぐに改善できるのに。やっちゃダメなことを決めて、やらないことを決めて、やれることにフォーカスする。そうしないと、異なる立場の人間をまとめて組織力をUPすることが出来ない。
人生は「やる」「やらん」「好き」「嫌い」の4つだけで充分です。今日も一日、適当にやってればよろしいと思います。