いまどきExcelでしか管理していないチームはないと思う。Webアプリと違って頻繁なリリースのできないパッケージタイプではバグを先に直すべき。バス修正にかかる時間は読みにくいけれど、新規機能開発は読みやすいはず。「プログラマがスケジュールを立てたがらないのはよく知られている。彼らはビジネスの連中に向かって、「いつ出来上がるかって?そりゃ、出来上がったときさ!」と怒鳴る」。ビジネスや他チーム連携のために重要です。フローやゾーンと呼ばれる集中した状態は簡単に消されてしまうのでそれを減らすためにも必要。日本の小さな組織だとどうするべきなんだろう?常にいるというより、週何日かだけでも小部屋にいるとかいいのかも。ビルド時間を短縮するマシンだったり、ディスプレイだったり。10.テスタはいる?→プログラマ2-3人につき最低でも1人の割合で専任のテスタがいないとバグだらけの製品をリリースするか、時給30ドルのテスタにできることを時給100ドルのプログラマにさせて金を無駄にする、とのこと。最近は当たり前のようになってきていますが、どうでしょうか。廊下で5人くらい捕まえて試してもらうとユーザビリティ上の問題の95%を明らかにできる、とのこと・・・このテストは、チームの状態をマネージャが把握したり、会社に応募するときや投資するときに目安になったりする、とのこと。仕様書について仕様書はデンタルフロスのようなもので、みんな書かなきゃいけないとは思っているけれど、誰も書かない。アジャイルソフトウェア開発宣言*1では「包括的なドキュメントよりも動くソフトウェアを」と書かれていることもあって、仕様書を軽視するプログラマは多いと思うけれどビジネスサイドと話を積めて安全効率的に開発するにはやっぱり必要。どのレベルのものか、が難しい。Inspiredなどプロダクトマネジメントあたりでは、紙芝居のように動作する「ハイファイ・プロトタイプ」が仕様書としてよいのでは、とも言われているけれど、Joelの意見はちょっと違う。あまりにもデザインができすぎたものは、ビジネスサイドがほぼできていると勘違いしてしまうからよくないと、、これは、ハイファイ・プロトタイプが効くのはユーザの、利用者の、言葉にしにくいフィードバックが重要な、どちらかというとB2C向けなのかもしれないし、ちゃんと運用できるのはリテラシーの高いプロダクトマネジメントチームがいるときだけなのかもしれない。必要な理由としては事前にビジネスや他チームと共有するためなのが大きいけれど、ほか気になったところをピックアップする。プログラマは、時間をかけて書いたコードが、仕様上どんなにまずいコードであっても、それに執着するようになるのでこれを避けるため。はい、心当たりがありますね。次に、プログラマというのは「正しい答え」ではなくかれらがコードとして書いたことに即して質問に答える傾向があるから。これは自分もやりがちです。仕様書の中身について、ユーザ観点でどう動くかを記述する「機能仕様書」と内部の実装についての「技術仕様書」があって、Joelのいう仕様書は前者、内容は具体例がおもしろいので読んでほしいけれど、ユースケースのシナリオや対象、簡単なフローチャート、画面が紹介されていて、「カタログ」のようなものだと感じました。あいだに未解決の問題やテクニカルノートが挟まっている。テンプレートは使うべきではない。証書は1人の人間によって書かれ、所有されるべき。重要なのは仕様書がアップデートされてその差分がわかるようになっていること。そんな仕様書を書いて価値あるソフトウェアをつくっていきたいです。この、バージョン差分を分かりやすくてだれでも使いやすいドキュメント管理システムはないだろうか・・・プログラムマネージャについてプログラムマネージャという、いまプロダクトマネージャーとして知見が積み重ねられているものの前身と思われる役割にも紙幅が割かれている。マーケットに対する意識、ユーザ理解、良いUIデザインをつくる。コーディングへの理解も欠かせない。重要なのは・コーダーをプログラムマネージャに昇進させないこと。・マーケティングの人間をプログラムマネージャにしないこと。・コーダをプログラムマネージャの監督下におかないこと。難しいですね・・・正しい資質のある人を採用するなり抜擢する必要がある。このあたりは、最近2版が出たInspiredを読むのがよいと思う。単行本5つの世界いろんなひとがさまざまな文脈でソフトウェア開発についての知見を語るけれど、たいていの人はその人の知っているソフトウェア開発を念頭においているので、話を聞くときは、どの世界のことを話しているのか気にしましょう、というはなし。・パッケージ・インターナル・・・特定の組織内で使われるもの・組み込み・ゲーム・使い捨てそれぞれ求められる品質や基準が違う。いまネットで多数の記事があって人々が働いているwebアプリケーションは、多数のブラウザで使われるという点でパッケージの変異として分類されているけれど、今なら独立させてもよさそう。B2CかB2Bかで分けてもいいかもしれない。Joelはユーザが1000万人いるかどうかで区別はしていたので、特に自分のような凡百の開発者とは桁が違うことだけご留意を・・・。使い捨てプログラムはすぐにインターナルソフトウェアへと変化し、さらにMBAがそれを見つけて「これを使って新しいビジネスをスピンオフできるぞ」と言うと、ジャジャーン!ひ弱な「エンタープライズソリューション」を提供するコンサルティングウェア会社が生まれる。目指すのかBen&Jerrysは東京とかデパ地下とかで売ってる高いアイスクリーム屋。2000年にユニリーバに買収された会社。スタートアップは急成長を目指すという点でスモールビジネスと違う、と思っていたけれど、その中でもAmazonスタイルともうちょっとゆっくりなBen&Jerry'sモデルがあるのうまく区別できていなかった。競合がいるかどうかや資本が必要かどうか、ネットワーク効果の有無、損益分岐点の近さ、リスクなどが違うなどなど(それぞれどちらのモデルかはわかるよね)。ひとつ自分が意識できていなかったのは、Amazonモデルでは企業文化(を維持していくのは)不可能だということ。最悪なのはAmazon型の会社にならなければと思いつつお、Ben&Jerry's型のように行動すること。どちらか決め切れているでしょうか。Joelによれば、MicrosoftはBen&Jerry's型のもっともよいモデルとのことで、Ben&Jerry's型が巨大化しないわけではないけれど、もう時代は違うかもしれない。その他アーキテクチャ宇宙飛行士を雇わないことアーキテクチャ宇宙飛行士とは、アーキテクチャや抽象的なことがらについて議論するばかりでなにも生み出さない人間のこと、らしい。類似性を見つけて抽象化をすすめていくの、楽しいけれど、解くのが楽しい問題ではなく、解く価値がある問題を解決したいものです。デザインというのは、コストを増やすよりも早く価値を追加することができる、漠然とした領域のことをさす。たしかに漠然とした領域・・・。言いようがないのかも。プログラマの評価について逆効果になることが多く、するべきではないと書かれている。評価が高くても、それが生産性につながらず、評価が低い人のモチベーションを下げるだけ、華々しい成果を出していなくとも目立たぬところで重要な役割を担っている人を評価するのが難しい、ということもある。それは、わかるんだけれど、適切にストレッチさせるためにどうなのかは気になる。なんらかの目標管理的なものは必要なのかどうか、ちょっと悩ましい。Joelのブログはまだまだ続いているので2020年は英語をがんばって読めるようにしていこうと思う。三行まとめ・ブログ名を「うんこめも」から「ぜぜ日記」に変えます・理由)食べ物についても触れることが多くなってきたのでちょっときれいな名前にしたかった・意味)ぜぜは住んでいる滋賀県大津市の地域名である膳所(ぜぜ)と是々非々をかけています経緯あまり更新されていないブログの名前なんて誰も気にしていないのでしれっと変えてもよいとは思うのだけれど、なにかを変更する際には、意図を書いておくことは、プログラミングにおけるコミットメッセージのように職業倫理的に必要なので書いておきます。この旧名の「うんこメモ」というのは冷静に考えると汚い名前ですが、自分がうんこを好きということでも、うんこのような文章をかくと卑下しているわけでもありません。「自律分散うんこ製造システムについてのメモ」という名前のブログを書いていたんですが、長くてよくわからないと略してうんこメモになって、なぜか自分ではあまり汚さを意識できていなく、たまにコメントやはてなブックマークで、ブログ名ワロスみたいに言われてハッとするのが積み重なってようやく変更に至ったのでした。「自律分散うんこ製造システム」とは、勝手に自由意思をもって動いていて、なにかを消費してうんこを生産するだけのエージェント、端的にいうと人類のことを社に構えた学生が皮肉った言い方です。Intelligenceの頭文字のDAIが自分の名前っぽいと思ったというのが安直な理由。いうと膳所高校という滋賀県有数の進学校で知っている人も多いかもしれません。自分は福井という田舎出身なので関係ないです。2000年代後半のブログブームのときにニュースサイトやGoogleリーダーで読んでいたさまざまなブログたちは、どんな名前だっただろうか、と調べようと思いましたが、Chrome以前の時代のブックマークやGoogleリーダーの登録リストが不明で調べられない。はてなブックマークなんかで流れてくると、まだ続けてたのか、と嬉しくはなることもありますが、ほかはいまどうなっているのか分からず思いをはせています・・・。好き勝手書いていこうと思います。今年もよろしくお願いいたします。10thにコーチ参加したこと。Railsでプログラミングを学ぶイベントにコーチ役として参加してきました。楽しく、得るものがあったので感想を書いてみます。Girlsについてこのイベントはフィンランド*1のリンダさんが2011年にはじめたものです。目的は「女性に技術の理解とアイデアを実現するためのツールとコミュニティを提供する」こと。ideas.コミュニティベースの動きといろんな企業のスポンサーシップとで世界中で何百回も開催されていて、男女で数の差があるプログラマーで女性に機会をつくる機会になっています。背景については、英語ですがYuryuさんのこの資料が現状(2014年)の数字と取り組みについて説明していてわかりやすいです(5年で改善されているでしょうか)。Iwao日本では東京でやるといつも満員で京都でももう10回開催されているくらいそうです。自分の勤め先でアルバイトとしてエンジニアをして重要な戦力になっている女子学生がRailsGirlsに参加していたことがプログラミングを学びはじめたきっかけ(の一つ)だったり、知り合いや友人がコーチとしてコミュニティに貢献していたことから自分も参加してみました。教えることでなにか発見があるかもという期待と、社会のエンジニア層を厚くしたいという気持ち。パソコンとインターネットがあれば学べるプログラミングは、表面的なスキルの陳腐化は早いけれど、Webアプリケーションの開発の考え方の根底はしばらく変わらず、需要はまだまだ大きいと思っています。向き不向きはあって万人におすすめできませんが、向いているかどうか知る機会のひとつとしては、いきなり、お金と時間をかけてスクールに行ったり、自学だけよりRailsGirlsは気軽で便利でおすすめです。自学は、どの段階のひとにとっても重要だけれど、最初は知らない概念が多すぎたり、玉石混交の記事を見分けられらなかったり、どこから手を付けるかで挫折しやすい。自学だけだと、自分がなにをわかっていないかもわからず、ネットのQAサイトやGoogle検索で困っていることを言語化するのも難しい。いえ、自学で一度挫折した人が、経験者に気軽に聞ける時間としてもRailsGirlsはよい場所です。connpassもおすすめです。あとあと、プログラミングを仕事にしなくても、プログラミングやWebアプリケーション開発のことを知っているというのは、多くの仕事や人生で役立つとも思っています。10th今回は、半年ほど前に大阪でRailsGirlsに参加したという大学2回生の人がオーガナイザーでした。教授1人に6-70人の授業でプログラミングを教わったけれどわかるわけもなかったのが、RailsGirlsで理解が進み、これを同じ大学の人にも伝えたいということでの開催でした。参加者9人にコーチが1人ずつという贅沢な体制。コーチやスタッフは4割ぐらい女性です。自分は、大学の授業でRubyによるプログラミングに触れたけれど、よくわからないままなのをなんとかしたいという学生さんにコーチとして付きました。RailsGirlsでは、このチュートリアルの1つ目から4つ目までを10:30-12:30、14:30-16:30の4時間で取り組みます。Japaneseこのチュートリアルを読むだけでは背景や意図は理解できないので、参加者の理解度や、興味にあわせて調整します。とこれでできたファイルの役割の説明で午前中ほぼすべて使いました。ユーザがアクセスしてからroutes.rbでどのコントローラが呼ばれるか決まって、コントローラがモデルを読んで、対応するビューをユーザに返す。ルーティングをみたりなどなど。納得するまで粘り強く質問してもらえて理解が深まったのではないかと思います。午後は、gemをつかって画像登録を簡単にできるようにしたり、パーシャルをつかってhtmlを便利に管理できるようにしたり、githubに登録して、herokuにデプロイして世界中に見えるように公開するところまで。そのあとは時間の都合で、1対多関係のモデルをつくるところを手は動かさずに概念だけいろいろと説明しました。4時間ですが、これまで知らなかった複雑な概念を理解するというのはとても消耗するし、それを理解度を追ってフォローするのもなかなかたいへん。参加者の集中力や、理解してやろうという気迫、疑問と理解のサイクルはめちゃめちゃ学びがありました。自分も、知らない概念をがんばって会得しようという気持ちになります。アフターパーティではほかのコーチの方々、さまざまな現場で活躍している人たちともエンジニアリングやマネジメントについておしゃべりできて楽しい時間を過ごせました。(弊社、株式会社坂ノ途中もコーヒーを提供するスポンサーをしていました)最後に今回コーチをする中で考えていたこと3つを書いておきます。コーチとしての狙い1.なんでも質問できる関係をつくる。なにかを聞いても一度で理解できるわけはないので、同じ質問を何度してもよいし歓迎、ということを繰り返し伝えました。今回はわからなかったらいつでも、と話をしています。職場だと15分考えたり調べて進まなければ聞いてね、と言っています。2.自分のペースでやるほかのひとも同じことやる環境は刺激的ですが、焦ったりしないように自分のペースでやれるようにしました。ほかの参加者も含めてみな自分の理解にフォーカスできていたようだったので杞憂だったかな。3.自学できる準備をするエラーは怖くないということと検索のやりかたについて話しました。プログラミングをしているとエラーは日常茶飯事です。環境構築などでは、真っ黒い画面によくわからない英語の文字列がたくさんでてきて特にはじめのころは拒否反応とストレスを持ちがち。それでも、エラー文を読めばヒントが書いてあるし、検索できるということを伝えています。今回だと、コマンドを打ったり、コードを書く場面でタイプミスを見つけても、あえて指摘せず、実際に画面表示時にエラーを起こしてから、その読み方と原因を説明しました。エラーが出ることは完成を高めていくのに必要なこと。意味を調べるために、公式サイトを検索したり、日本語でも解説記事があること、なかには間違った情報を書いているものもあって鵜呑みにできないことなど。upイベントも開催することやコミュニティを活用することを話しました。ここらへん、意外と初学者向けの教材やカリキュラムにはない気がしています。学習の高速道路*2、みんなでつくっていきましょう。10thにコーチ参加したこと。Tumblr広告を非表示にするもっと読むコメントを書く2019-10-28舞鶴(西)に行ってきた。小学生のころ米原と舞鶴を混同していた時期があったけれど、どちらもいいところです。先日は舞鶴Rubyという勉強会に参加するために朝一で西舞鶴駅まで出かけてきました。ruby-maizuru.connpass.com京都縦貫道が全線開通してから車で1時間2150円くらいで行けるようになってめちゃめちゃ便利になってはいますが今回は電車。京都駅から西舞鶴駅までは特急を使うと2680円、100分で行けます。今回は、特急きのさきで途中綾部で乗り継ぎしましたが直通も特急まいづるが1日8本あってたいへん便利。土曜の7時半の電車で自由席は全部埋まっていて城崎温泉人気です。いに山あいの農村を通る単線の山陰本線は車窓も楽しい。ちなみに帰りは特急を使わず2回乗り換えで140分1660円でした。座れて苦にはなりません。かまぼこの街らしいです。新世界です9時ごろの商店街、かしわ屋さんや肉屋さんくらいしかあいていません。いろんなお店がありそう。勉強会はFLAT+という場所でした。日替わりのお店があったり地域の野菜が売っていたりハブになっています。デザインの仕事も請け負っていておもしろい。多彩で勉強熱心な人たちで議論も盛り上がって、自学タイム(もくもく会)も集中できました。おやつタイムでは居酒屋のスイーツを食べました。カラメルなクリームとナッツがうまい。水路が多くて街を歩くのも楽しい道の駅の舞鶴港とれとれセンターは繁盛している。魚もいいのたくさん売っていて楽しい。車できてクーラーボックス積んでいたら楽しそう。お昼は大六丸という魚屋のやっている定食屋で刺身定食。これにアラ汁がついて1500円。右下のオレンジ色のは黒ミル貝。向こうにも山が見えます。