経緯 社内でのプロジェクトマネジメント手法について標準となるものが欲しいという声があったので、半年以上前から暇を見て取り組んできている(あまり宣伝してきてないけど、2012年に今の会社に入ってから社内にアジャイル開発を普及させる活動を細々と続けてきているのです)。 3月くらいのときに自分がドキュメントをつくってみたものも、どちらかというと読み物という雰囲気のものになっていてそれを参照しながらプロジェクトマネジメントをしていこうというものにはなってなかった。 しばらくそのまま放置してしまったのだけど、その後6月頃に認定スクラムマスター研修を受けて熱をもらってもう一度やるぞ！という気持ちになったりしたこともあって、反省を踏まえてテンプレートとなるようなドキュメントの作成を改めてすることに決めた。 ちょうど6月末ごろに社内の開発合宿があったのでそこで協力者を募ったところ、2人が協力を申し出てくれ

ある程度感想が固まってきたので書いておこうかなと思いました。 特に一般化して語るつもりはなく、あくまで個人の感想です。 もともと在宅勤務の経験はほぼゼロだった(パソコンを持ち帰るのも重くて嫌いだったので基本的にオフィスに置いていた) 総合的には「めっちゃ良い」と思ってる 良い点は色々あるけど、とにかく自分の気質に合っている、と感じる 平たく言うと独りの方が気楽、無駄な体力の消耗が少ない 体調も勤怠もオフィスワークより安定している 出社することやオフィスで働くことにストレスがある自覚はあったけど、想像以上だったんだな、と分かった。今は日々が穏やか もうこれは良い悪いとかじゃなくて個人の気質としか言いようがない 業務上のコミュニケーションについても特に問題は感じていない 良くはなっていないけど、さほど悪くもなっていない、という印象 もともと多拠点開発をしていたこともあるだろう 生産性についても

同質的集団の中にいると自分が属している文化を無意識のうちに当たり前のものだと思ってしまいがちだけど、当然集団の外では通用しないということを自覚し続けないとまずい。 別の文化に属する人と関わる必要があるときにすれ違いが生じるし、すれ違いに気づくときは大体は現実の問題として顕在化したときだからだ。 その文化は「何の」文化なのか、きちんと把握することが大事なのだと思う。日本の文化なのか、エンジニアの文化なのか、ネットの文化なのか、など。把握できれば、相手がその文化に属しているのかいないのか類推し、対処することができる。 文化が違うときにどうするのかというと、基本的に相手をコントロールすることはできないのだから自分が相手の文化を尊重するか、避けるしか無いのだと思う。尊重するのと受け入れるのは違う、というのもポイントだと思う。あくまで相手の文化を知ってそれに合わせるだけで、内面化するわけではない。そ

さっきこのエントリーを書いてふと思った、いやそれは嘘でずっと前から思っていたのだけど、そもそも友達がいないという問題が自分にはある。 いや本当は友達いるんだけど、縁もゆかりもない京都に引っ越してきたから地理的に離れていたり、友達と言っても良いけど中小企業の同僚ということもあって微妙な距離感や気づかいポイントがあったり(ましてや僕は一応管理職だし……)、まあとにかくそんな感じで、簡単に言うと都合のいい友達がいないという問題というのが正直なところである。 ところでこのような話題について考えるとこの名文を僕は思い出す。 medium.com 僕はyanbeさんのことをある程度知っているのでこの文章の意図をある程度正確に汲み取れているつもりなんだけど、その上で共感する。気づいたらほぼ1年経ちつつあってびっくりした。 一方で、ブコメとかで30代の男はもうそういう年齢じゃないよみたいな指摘もあり、まあ

はてな(ウェブサービスを開発・運営している会社)で働いていて、社内でチームマネジメントについて勉強する会を立ち上げています。そこで、座学方面に興味がある人におすすめできる本を参考のためリストアップしてみます。過去の自分のあまり役に立たない感想文付き。 あまり本を読めているわけではないので、何か他に良い本があれば知りたい。 スターターキット 先ず読むと良さそうな本。 shimobayashi.hatenablog.com HRTの特にRを意識すると良いコミュニケーションが取れると思います。特におすすめの本。 shimobayashi.hatenablog.com 言葉は効果的な上に無料なので使っていこう。 shimobayashi.hatenablog.com ファシリテーションをする機会も多いはずなので、別にこの本じゃなくても良さそうだけど何か1冊くらいは読んでおくと良いのでは。 shim

ゼロ・トゥ・ワン　君はゼロから何を生み出せるか 作者: ピーター・ティール,ブレイク・マスターズ出版社/メーカー: NHK出版発売日: 2014/09/25メディア: Kindle版この商品を含むブログ (4件) を見る 知人が絶賛していたことを思い出して読んでみた。 まあ、そんな絶賛するほどじゃないでしょ、というのが正直な感想。 全体的に「ブルーオーシャンを目指そうぜ！」って感じなんだけど、目指し方については特に言及していなくて「君の思い込みはきっと正しいからこうやったらいい感じにイケルヨ！」ということが書いてある。 そしてページの下の方にチマチマと豆知識が書いてあって攻殻機動隊のコミックを読んでいるような気分になる。 帯に書いてあるPayPalとかFacebookとかLinkedInって人々に嫌われているけど使われてはいる典型的なウェブサービスだと思うんだけど、なんというか、そういう雰

ありがちな話なのでこのことについてふと考えることが多い。 最初に断っておくと特に結論はなく、ケースバイケースで考慮するべきというのが僕の考え。 それを踏まえて、先ずは良い点について考えてみる。 一番もっともらしい理由は、他のエンジニアが納得しやすいこと。一番戦闘力の高いエンジニアがエンジニア長になって皆を束ねていくという世界観。若く猛ったエンジニアも従ってくれるけど、石器時代っぽい。 次点として、システムの実装を把握しているのであまり滅茶苦茶なことにはなりづらく、安心して任せられるということ。 それ以外にありがちなものとしては、人的コストの圧縮も考えられる。人件費もそうだけど、頭数が1つ増えるだけでコミュニケーションパスは爆発的に増加していくのでコミュニケーションコストの削減にも繋がる。 次に悪い点について考えてみる。 これはまさにピーターの法則そのもので、組織の構造的な欠陥を示している。

高専ってすごい! 情報工学を体系的に学ぶために高専でやってきたことをまとめる。 - nigoblog 僕は高専卒だ。といっても、1回留年して、1回休学した。つまり、落ちこぼれだ。それでもウェブエンジニアとして一応働いている。 そして、僕は高専には行くべきではないと思っているというのが本音だ。 上記のようなエントリーをみて技術に情熱を燃やす中学生が高専を受験しようと思ってしまうと心が痛むので、行くべきではないと考える理由を書いてみようと思う。 先ず一つ目、クラスが5年間固定であること。 これがどういうことかと言うと、固定化された小さなコミュニティの中で多感な時期を過ごすということだ。 高専生は卒業までに1クラス40人の中にしか属すことがない。 一方、高校生なら毎年クラス替えをするわけだし、大学生のことはよく知らないがまたそこで新しい仲間を見つけるのだろう。 部活やバイトがあると思うかもしれな

勉強と思ってアプリをつくって提出していたがどうにもレビューを通りそうにないので、面倒になってApp Storeで公開するのを諦めた。 勉強が目的でアプリの内容は何でも良かったので、今回は手頃なFlashでつくったポケモンの努力値カウンターをiPadに移植した。 最初にリジェクトされたときはこういう画面だった。 リジェクトの理由がごちゃごちゃと書いてあるが「iOSはクールなOSだからもっとクールじゃないとダメ」という意味だと受け取った。 僕自身もFlash版から何も考えずに移植しただけだったので、別にこれで実用上全く問題ないのだけどと思いつつUIを調整した。 結果としては、またリジェクトされた。 どうやら、ボタンが沢山配置してあってレビュワーが理解できないのが問題のようだ。 しかしながら、このアプリの売りはボタンを沢山配置することによってワンフィールで操作できることなので、そこを無くしてしま

blog.nishimu.land 呼びかけられたような気がする(?)ので、思っていることを素朴に書いてみます。 まず一番大事なこととして「成果を出せているのか？」があると思っています。 「ユニコーン企業ではスクラムなんかやってない」ことが注目されるのも、ユニコーン企業だからこそです。 なので、成果を出せているのならスクラムじゃなくても何でも良いと思っています。 以前勤めていた会社はトップダウンの会社でアジャイル的な思想とは真逆だった気がしますが、天才プロダクトマネージャーの差配で回ってました。 回ってる内は、別にそれでいいと思います。 scrapbox.io これは、自然状態から成果を最大化するための課題に向き合っていくとこういう変遷を経るケースが多いんじゃ無いか、という僕の予想です。 この予想では、アジャイルソフトウェア開発に行き着くことになっています。 ただ実際は、例えば先ほど挙げた

「アジャイルの対義語はウォーターフォールではありません」というのはよく聞く話だけど、じゃあ何なのか？というと、あまり聞くことはないように感じる。 自分は、アジャイルの対義語は未来予知だと思っている。 なぜなら、もし未来予知ができるのならアジャイルである必要は全く無くなるから。 未来予知に基づいて、一切のムダがない完璧な計画を立てればいい。 そういう意味では、変更の余地が無い巨大なウォーターフォールは未来予知的で、アジャイルの対極にあると思う。 でも実際は、未来を予知することは今の僕らにはできない。台風の進路でさえ、予想することしかできていない。遠い未来ほど曖昧だ。 じゃあ、どうせ未来は分からないのだから計画を立てなくて良いのか？というと、そうではない。台風の進路を予知できなくても、予想することはできている。予想することで事前に備えることができるし、予想のモデルを修正して精度を上げていくこと

いつまでターミナル上のVimで開発してるんだ？とは思っていたので、流行に乗ってVSCodeに移行してみたものもイマイチなまま半年経ってしまった。 TypeScriptを書いてるときはVSCodeを使っていてうれしいこともたくさんあるけど、業務でPerlを書いている間はずっとVimの方が良いのではないか、いやでも、とか葛藤しながらコーディングしてる。 そりゃ10年以上Vimで開発してたら移行するのに時間かかるよね、と思って我慢していたけど、半年経ってもイライラしながらVSCodeを使っているのでこれはちょっと時間が解決してくれる感じも無さそう、という気分になってきた。 一番困っているのはこの人と同じで、VSCodeのタブ機能が貧弱すぎるというところにある(他にもこういう人はいるだろうけど、この人しか見つけられなかった)。 It creates some frustration when I

アジャイルとは、トライアンドエラーを効果的に行うための知識群、だと思う トライアンドエラーするのはどういうときかというと、やってみないと分からないとき やってみないと分からないときはどういうときかというと、その時点での能力を超えた仕事をするとき 能力を超えた仕事をするとき、成功が目的であることに変わりは無いけど、計画と実行よりも学習と軌道修正が重要になる 最初に立てた計画は間違っているため プロダクト開発の領域は大雑把には、ディスカバリーとデリバリーに分けられる ディスカバリーにおいて十分な能力を有している=つくるべき正しいものを見極められている場合、ディスカバリーにおいてアジャイルである必要は無さそう 例えば、受託開発のような場合はつくればお金がもらえるということになっているので、アジャイルになろうというモチベーションは低そう デリバリーにおいて十分な能力を有している=やるべき正しいつく

エンジニアリングマネージャーに関する以下のアウトプットを見かけて、現時点での自分の思考のスナップショットも取っておこうという気持ちになりました。 エンジニアリングマネージャーを目指す若者の戦略 - yigarashiのブログ テックリードの抱えるプレッシャとキャリアパス - 貳佰伍拾陸夜日記 ウェブ業界でしか働いたことがないので、ウェブ業界に限定したことを書きます。 状況認識 エンジニアリングマネージャーとは何なのかというと、業界としての具体的な合意はまだ形成されておらず模索中という認識です。 なので一人一派のエンジニアリングマネージャー像を持っており、個人によって理解に大きなブレがある状態と思います。 そうした前提の中での最大公約数的な理解に関してはやはり エンジニアリングマネージャ/プロダクトマネージャのための知識体系と読書ガイド - Qiita にまとめられたアンケート結果が役立ちま

SNSを見ていたり人の話を聞いたりしていると、「職場で攻撃的な物言いをしてくる人に困っている」ということがある。 攻撃的な物言いをされる側は気分が落ち込んで生産性が下がったり、最悪退職してしまう。 そして攻撃的な物言いをする側は、いくら指摘しても態度を改めない、というもの。 割と長期間に渡ってそういう話を見聞きしてきて自分なりに思うことがあったので、書いておく。 攻撃的な物言いをするメリットはほぼ無いはず 言われる側の心構え 攻撃的な物言いをするメリットはほぼ無いはず 何かを指摘する際の目的は何なのかと考えてみると、指摘をすること自体は目的ではなくて、大体は相手に素早く正しく動いてもらうことが目的だと思う。 その観点で最適な指摘の仕方を考えてみたときに、本当に攻撃的な物言いが最適だと思えるならそうしたらいい。 けど、多くの場合は相手の反発感情を煽って咀嚼に余計なエネルギーを要したり、最悪怒

引き続きリモートワークに関心があるので関連書籍を読んでみています。前作「小さなチーム、大きな仕事」は未読です。 強いチームはオフィスを捨てる 作者:ジェイソン フリード,デイヴィッド ハイネマイヤー ハンソン発売日: 2014/04/01メディア: Kindle版 どこにいても世界中の人と簡単にコミュニケーションできるのに、なぜオフィスが必要?人生の大切な時間を通勤に費やすのはナンセンス!優秀な人材と一緒に働きたければ、物理的距離なんて関係ない!前作『小さなチーム、大きな仕事』で圧倒的な支持を集めたカリスマ経営者たちが、今回取り上げたのは「リモートワーク」。世界に散らばる36人の社員を率いて、数百万人ものユーザーにふさわしい働き方を伝授する。会社や組織にまつわる固定観念が、根底からくつがえる! リモートワークを取り入れることで生産性が上がり、生活の質も上がる。リモートワークを取り入れるとき

必要にかられていて、社内でも読書会がはじまった。読書会はまだやってるけど、先行して読み終わった。愛称は「ちいとぽ」らしい。 チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計 作者:マシュー・スケルトン,マニュエル・パイス日本能率協会マネジメントセンターAmazon どういう本なのかは、訳者の方が用意してくれた以下の資料が良いのではないか。 自分が読み始めたモチベーションとしては、チームの分け方について知見を得たいというものだった。 shimobayashi.hatenablog.com 本を読んでみた感想としては、元々の自分の考え方もそんなに外してないことが分かって安心感があった。もちろん考慮の幅・深さ・質は違うので、この本を読んで良かった。 どれくらい根拠のある内容なのかはよく分からなかったけど、個人的にはこれまで勉強してきたことと整合的だった気がするので全体的にはす