リモートワークと1on1 | F's Garage
東京のネット企業が近しい街に集積するぐらいならともかく、毎週1on1で上司と部下の対面で話そうなんて流れが定着していく今日この頃。某社のフルリモートの記事が頭の中に残っていて、なんとなくあるモヤモヤを書き出してみる。 非同期かつオンラインコミュニケーションの限界は、「あえて言わないこと」と「不満や意見が存在しない」の区別がつかないこと。非言語的コミュニケーションに問題が寄るが故に、変数のnullと””の区別がつかないプログラミング言語仕様みたいなものだ。ベタな表現をすると「顔色が見えない」ことでの意思が共有できているかを把握することの難しさが無視できない。 よく海外でのディスカッションでは、発言しないやつはその場に存在しないことと同じだという話を聞くが、不満や問題を適切に表現できないことを断罪し、それでビジネスが伸びるのなら誰も困らない。 遊びならともかく、仕事においてチャットによるコミュ
昔いた会社のこと | F's Garage
いくつか会社を経験してきたけど、ここ最近、一番思い出すのは、何社か前の受託を生業にしていた会社のこと。 多分、会社の規模や、抱えている状況が類似しているからなんだと思う。 当時、僕もマネジメントについては初めてで付き合い方に、すごく悩んだことがある。どうやって同じ方向、望む方向に向いてくれるだろうか、とか考えていた。そういう時は、休日はプールに行って泳ぐんですよね。プールに潜ってる時は極端なことを言えば生死に関する状態なので、生存を維持するために、何も考えなくて、ただそのことに没頭できる。 一方、土曜の夜とかに埼玉くんだりから、六本木のABCとかツタヤに行って、マネージメントの本だとか、当時、光り輝いていたライブドアの堀江さんの本を読んだり、またソフトウエア開発プロセス関連では、トム・デマルコの本を代表とする、マネジメントや開発プロセスをどうやったらうまく進められるか？について読んだりして
サービスか受託か。Webサービスを作るということ | F's Garage
先日、某SIコンサル社にいる方が、まだ転職を悩んでるという前提でのカジュアル面談に臨んだ。その人の転職理由というのは、僕が受託の会社から転職した時に言っていたこととそのままだったので、是非、本面接に進んで欲しいと思った。 その一方で、受託からWebサービスに来る人に、よく言うことして、 「受託からWebサービスに来ると、ファンタスティックな案件がなくなってつまらないかもしれないですよ」 と言う話をする。これはどういうことか？というと「技術的チャレンジ」を求めるならば、筋の良い受託の会社にいる方が楽しくて、Webサービスはコードを書いている瞬間から技術的なレガシーを産んでおり、先々に渡って最初の選択の影響を受けるので、あなたの技術力の定義が「話題の言語でコードを書けること」であるならば、Webサービスはあんまり勧めません、という話をする。 当時僕がいた会社は、技術の共通化がまだ進んでおらず自
モバツイ最終日なのでメモをしておく | F's Garage
モバツイ最終日だった。 せっかくなので、一つの思い出だけ書いておこうと思う。こういう愚痴は今日だけにしておく、という話。 まだ、UUベースで２万人とかそのぐらいのWebサーバ１台で回していた頃。 当時は、まだ１人で開発していた。 改めて思うと、あの頃の開発速度が最速だったなと思う。 何故最速だったか？というと、 １．使ってくださるユーザーさんがいたので楽しい ２．使ってくださるユーザーさんがいたので直すべきissueが存在する ３．使ってくださるユーザーさんがいたので、責任が重い この３つがあったからだと思う。 更に言うと、 4. 自分がオーナーだったので全責任を自分で負える ということもあったと思う。もしかしたら、これが一番大きいかも。 Twitterで起きる問題はリアルタイムなので、外出先の飲み屋から、サーバにログインして直でソースコードを直していた。例えば、バレンタインデーの時にTw
誰と働いているかという視野のエンジニア評価軸について | F's Garage
うだうだ記事を書く。あんまりブロガーさんのように、懇切丁寧に説明する意識はない。うざかったら途中で離脱推奨です。 とある理由で、本番のデータを修正することになった。休日だったので僕が対応したのだが、その部分のデータ修正の経験がなかったので、ソースコードから調べて依存関係を解決するSQLを書き、Slackを通じてコードレビューをお願いして、無事修正タスクは完了した。 所要時間は、作業開始から40分。 日常的にソースコードをいじっていて、データ構造を熟知しているメンバーなら、５分もかからないで終わる作業だろう。もしそうならば、８倍の速度差が生まれている。 その８倍の速度差が顧客満足度に影響をおよぼすのであれば、その人は、僕よりも8倍速で得られる顧客満足度の分だけ、仕事ができると評価ができる。 その人材がいれば5分、いなければ40分。この差はとても大きい。その差が大きいと思うのであれば、そういう
フルスタックエンジニアよりデュアルスタックエンジニア | F's Garage
（言葉遊びみたいな記事を書きますね。その上、用語の使い方が間違ってたらごめんなさい。） 一時期、フルスタックエンジニアって言葉流行りましたよね。ふと、要件どこまでだっけ？と思って調べようと思ったんですが、日本語で調べると、妄想が暴走してロクな話が出てこなそうなので、英語の方で調べてみるとわかりやすい。 What is a Full Stack developer? Server, Network, and Hosting Environment. Data Modeling Business Logic API layer / Action Layer / MVC User Interface User Experience Understanding what the customer and the business need. 個人的には、ネットワーク監視やデプロイなどのインフラ運用
【マネジメント論】大技を繰り広げられなくなる、スト２足払い的タスクの罠 | F's Garage
この話、誰に言っても通じない話なのですが、 かつての名作にストリートファイター２ってゲームありますよね。 僕は、そんなに得意なゲームじゃないんですけど、ゲームセンターの対戦プレイでこれをやると喧嘩になるという戦い方があるそうです。 それが、 「最速の足払いをひたすら使って、相手の大技を封じる」 というものです。スト２が面白いのは、大技は相手に巨大なダメージを与えられますが、技を繰り広げる前に、ちょっとしたダメージしか与えられない小技である足払いを食らうと、大技が出せなくなってしまう作りになっています。 それ故に、ひたすら足払いで防御することで、相手に徐々にダメージを与えていくという技があります。 何せ、技を出そうとすると、足払いで潰されるわけですから、姑息な技とイライラされるので、対戦で足払いで勝つと喧嘩になることもあるそうです。 似たようなことが、僕らの日常のタスクマネジメントにおいても
インターネットにおける情報非対称性とサイレントマジョリティ | F's Garage
これまでライフログが失敗した理由、ツイートのネガポジ判断がポンコツな理由、A/Bテストが絶対的に欲しいと思う部分に共通するインターネットの特徴が一つある。 ・インターネットには、何かの意思を持って発信された情報しかアウトプットされない。 ということ、つまり、 ・一つ発言から顕在化した問題点があったら、そのN倍は暗黙的に同じことを考えてる問題がある可能性を考慮すべき。 というあたり。ただし、それについての定量的な証明はネットからは不可能である。ないものはないからだ。 これと類するものに掲示板の書き込みのコスト問題というのがある。 ネットでは、誰かが何かをアウトプットしないことには、その意思を確認することができない。 しかし、書き込むためには強いアウトプットの意思が求められる。そのパワーが弱いと、書き込むことすら面倒くさくてやらない。反論される可能性まで考えると何も言わないほうがマシだからだ。
PHPを使う成長するサービスにおけるエンジニア採用の視点 | F's Garage
BASEは、昨年末のメルカリ社との関係性が高まったことを期に改めて採用を強めている。中心となるのは、強力に事業を推進するところにコミットしてくれるエンジニアの募集だ。 先日、リブセンスの桂さんに当社にお越しいただいて、結構ハードな対談を収録した。 BASEえふしん×リブセンス桂 CTO対談（前編）―今求められるエンジニアは、自分の会社から「はみ出ている人」― 桂さん、バシバシ、突っ込んでくるもんだからついついハードな発言をしているかもしれない。 最近、思っているのがどうやってPHPを扱う会社で優れた人材に来ていただけるか？という部分。 PHPは、多分、今も昔も中心なんだか周縁なんだかわからない立ち位置にいる。PHPをPHP市場だけで捉えると、高トラフィックなサービスを経験するという、「良い経験をしてきたエンジニア」は、藤本さんところのグリー社、グリー出身者、最初からPHPを活用していたYa
2016年、Slackを仕事に使う時に知ってほしい古くからのネットリテラシー | F's Garage
高校１年の時にパソコン通信を始めて、知らない人とコミュニケーションをし始めてから、もうかれこれ25年以上経ってます。はじめてパソコン通信でチャットをした時の感動、情景、相手のハンドルネーム、話した内容の一部は今でも鮮明に覚えています。 その後、いろんな人とネットを通じて出会っては去って行くのを見てきました。中には僕がコミュニケーションを通じて傷つけた人もいるでしょうし、問題を起こして自滅して去っていった人もいました。僕自身は、インターネットの時代になってからも、淡々とTwitterもFacebookもブログも書き続けているわけですが、情報発信をどう続けていくか？については、なんとなく感覚としては板についてる気がしています。 ただ最近、会社のSlackでも、過去に見てきた「非対面が故の期待と現実の差異」に戸惑ったり、ミスコミュニケーションが増えた気がしています。もし、それが仕事の生産性を阻害
プロダクト指向派におけるWeb開発言語の選択 | F's Garage
ずっとPHPについて考える機会が多かったのだが、PAY.JPをきっかけに、PyconJPにもスポンサーを通じての参加や、イベントにも少しだけ関わらせていただいてたから、Pythonの魅力を探る機会も増えた。 よくよく聞いてみるとPythonの魅力は、試行錯誤のしやすさということにあるようだった。データ解析に強いというのも、研究者が試行錯誤をするためのライブラリがそのまま実戦にも投入できるというところがポイントとしてあるらしい。そもそもデータ解析ライブラリそのものはC言語で書かれていて、グルー（糊）としての試行錯誤言語としてのPythonという使い方が一番人気のようだ。 何故、そこが重要なのかというと、Googleの検索ランキングアルゴリズムに振り回されるSEOの構図が典型例で、データ解析はスクラップアンドビルドの典型例で、一度決まったデータ解析手段において作られたエコシステムは、遠くないう
枯れた技術思想が危険な時代 | F's Garage
昔、WindowsNT4の頃に、ひどい目にあったIT技術者はWindowsを感情的に嫌うひとが多いです。その反動からか、BSDやLinuxの安全思考は力強いブランドを得て、BSDはMacのベースOSとして活用され、LinuxはサーバOSとして世界中を席捲する流れになりました。 ところが最近、Linuxや周辺を取り巻くソフトウエアのセキュリティ問題が大きくクローズアップされています。 オープンソースは多くの人の目に触れるから脆弱性が見つかってもすぐに修正されるという問題は、最近新たな価値観に変わりつつあるように思えます。 ・人間は必ずバグを作りこむ ・人は間違ってないと信頼しているものには、驚くほど関心を持たない。 ・メジャーなソフトウエアでもびっくりするような不具合があった。 結局のところ、「枯れたソフトウエア」が実は枯れていなかったというのが流れで、セキュリティ問題は、全ての時計の針を最
UIデザイナー募集で困ってること | F's Garage
トレタCOOのkengochi氏がUIデザイナーについての記事を書いてた。 UIデザインの価値 | Parallelminds BASEでも、ずっとこの辺の職種も募集していて、来月１人入るんだけど、実はUIデザイナーの募集はすごく困っている。 というのも、今、BASEでほしいUIデザイナーとは、 ・いわゆるWebデザイナーではないし、 ・いわゆるフロントエンドエンジニア（JavaScript実装特化型）の人でもない。 というところ。まさしくkengochi氏が書いてる「のりしろ」重要 じゃぁコアスキルって何？ってのを、経験者採用の理想を言えば、 １．D.A.ノーマンの本ぐらいは読んだことがあって、ユーザインターフェースを意識しながらユーザビリティの高い設計ができて ２．ビジュアルデザインのスキルもあって、カッコいサイト、サービスが作れて、 ３．ちゃんとユーザーさんのことを意識できて（つまり
UI/UXでいいじゃん | F's Garage
作業してる息抜きにブログ UI/UX言うな論は、あたかもUIがUX全体を規定してしまうが故に起きる意識の齟齬にあると思っている。 あたかもwikipediaをwikiと言ってしまったり、JavaScriptをJavaと言ってしまいエンジニアの不安を掻き立てる人たちへの不安に近いものだろうか。 まぁそもそもUXという言葉が非常にわかりにくい。わかりにくいと言えば、その昔は「システム」という日本語が日本にはなかったと、芝浦工業大学で初めてのカタカナ学部である「システム工学部」と言う名前を日本に持ち込んだ時の話を聞いたことが有る。 僕に認知だと芝浦工大のシステム工学部は言うほど古い学部ではなかったが、なんとその時代の手前まで「システム」という言葉がなかったというのは驚きだ。そりゃソフトウエアで日本が勝てないわけだ。物質主義とでも言うのだろうか。僕が製造業にいたとき、ソフトウエアはオマケみたいなも
「負債」は「資産」です。ご注意を / 医者に風邪引いてるんですって言うな 〜 非エンジニアに知ってほしいこと、エンジニアに知ってほしいこと | F's Garage
「負債」は「資産」です。ご注意を / 医者に風邪引いてるんですって言うな 〜 非エンジニアに知ってほしいこと、エンジニアに知ってほしいこと 例により当たり前のようなことを偉そうに書く記事 toエンジニア向け ■「負債」は「資産」です。ご注意を。 ソフトウエアエンジニアの人たちは「技術的負債」という言葉を使うが、会計に慣れてないと、ものすごーーくネガティブなニュアンスを含んでいるような気がしてしまうが、会計上の「負債」というのは「資産」に分類されることも忘れずに。 負債は利息を払ってるから早く返そうぜ、という文脈もあるだろうが、同時に「負債もお金を稼ぐ功労者なのだから、そこはリスペクトして、うまくやろうね」という視点もあるってしかるべき。これはうまく両立されるべきで、その気持ちがうまく同期できてないとエンジニアの側が辛くなるんじゃないかな。 特に経営者で苦労された方であれば、そんなことに動じ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
