BasecampHEYがリリースされましたね。

見れば見るほどBasecamp社のWebアプリの作り方をまとめた本であるGetting Realの内容に従って作られてるアプリだなとGetting RealをバイブルにしてWebアプリ作成を仕事にしてきた我々としては嬉しくなってしまいます。(2007年の本なのに!)

ただ、業界内で「Getting Real良いですよね、私もすごく好きです。」という人は多いですが「え?あんたの作ってるアプリ全然Getting Real的じゃなくない?」ということがしばしばあります。

フィヨルドブートキャンプの最終課題の「自分で考えたWebサービスを作る」ではGetting Realを読んでからどういうサービスなのかを表現するエレベーターピッチを作ることになっています。

しかし「これってGetting Realに書いてあることと真逆じゃない?ホントに読んだ?」ということが頻繁にあります。

そこでわかりやすいようにWebアプリ作成に絞って(組織論などは除外)Getting Realの中から「Getting Real的なもの」と「Getting Real的でないもの」を僕の理解で抜き出してみました。

Getting Real的でないもの VS Getting Real的なもの

シンプルさ

  • 「競合より多い機能」VS「競合より少ない機能」
  • 「多くのコード」VS「より少ないコード」
  • 「様々なケースに対応できるように作る」VS「一般的なケースにのみ対応したものを作る」

オープンさ

  • 「失敗の許されない厳格な雰囲気」VS「失敗を認めやすいオープンな雰囲気」
  • 「クローズドなソフトウェア」VS「オープンなソフトウェア」

機能の選択

  • 「ユーザーの機能提案をなるべく採用する」VS「ユーザーの機能提案にまずNOという」
  • 「ユーザーに何が必要か尋ねる」VS「ユーザーに何が要らないか尋ねる」
  • 「ユーザーが柔軟に設定できるようにする」VS「サービス側で考えた一番良い設定を提供する」

段階的な開発

  • 「長いリリーススケジュール」VS「短いリリーススケジュール」
  • 「最初から大規模なシステムを作る」VS「システムを段階的に大きくしていく」
  • 「ユーザー拡大に備えてあらかじめ人員を揃える」VS「ユーザーが増えてから人員を増やす」
  • 「新たな機能を完璧にしてからリリースする」VS「新たな機能はベータ版として使ってもらって改良する」

ユーザーの声

  • 「自分以外が製品のターゲット・ユーザー」VS「自分自身が製品のターゲット・ユーザー」
  • 「ユーザーサポート専門のスタッフ」VS「開発者自身でやるユーザーサポート」

インターフェースデザイン

  • 「何でもできるインターフェース」VS「切り詰めたインターフェース」
  • 「システムを作ってからデザインを入れる」VS「インターフェースをデザインしてからシステムを入れる」
  • 「アウトラインができる前にディティールに固執する」VS「動くものを自分で使ってみてから必要な部分のディティールを調整する」
  • 「一貫性のあるデザイン」VS「一貫性よりもコンテクストに合わせたデザイン」
  • 「デザインにダミーテキストを使う」VS「デザインに本物の言葉を使う」
  • 「文言はインターフェースとは別」VS「文言はインターフェースの一部」
  • 「ユーザーが使う画面と管理画面を分ける」VS「ユーザーの画面に管理機能を組み込む」

その他

  • 「精巧な仕様書を書く」VS「仕様書を書かない」
  • 「初期費用・長期割引・解約料金を設定する」VS「初期費用・長期割引・解約費用を設定しない」
  • 「最初のアイデアを守り抜く」VS「最初のアイデアが悪ければ方向転換する」 

Getting Realの良さ

Getting Realが衝撃的だったのは多くの点でそれまで良いとされていたことと逆のことを言ったからです。毒にも薬にもならない耳触りの良いあるべき論ではなく「え、そんなこと言い切っちゃって良いの?」というような割り切りと実際にそれを実行してる点に当時の僕らはシビれたわけです。

と僕らが勝手に思ってるので話が食い違うことがあるんでしょうね…。

自分の会社で作ってるサービスや使ってるサービスに対して「ここがGetting Real的」「ここがGetting Real的じゃない」など考えてみるのも楽しいかもしれません。

プログラミングスクール(フィヨルドブートキャンプ)で勉強している方へよくお話している内容なのでここに書いておきます。

わからない、ツラい

プログラミング(に限らず新しいこと)を勉強してるときに、

「何がわからないのかもわからない。ツラい。」

ってときがあると思います。

わからなくて1日何も進まなかったらとてもツラいと思います。1週間何も進まなかったらもっとツラいと思います。

この「何がわからないのかもわからない」というやつ。これはすごくツラいですが、プログラマーにとっては非常によくある状態です。

全然気に病むことはないです。

「ドンマイ、ドンマイ、締まっていこうー!」

ぐらいの感じです。

日々新しい技術を覚える必要があるプログラマーには頻繁におきます。 プログラマーとして働いている人はこの状態のプロです。

むしろ「これが飯の種になる」と考えている節があります。

この状態からの抜け出し方を知っていることが新しいことを自己学習し続けていけるコツなのかもしれません。

何がわからないのかがわからなくなったら

まずは人に頼りましょう。「困っています」ということを誰かに伝えることから始めましょう。周りに誰も頼る人がいない場合は下記に進みましょう。

まず、昼間だったら温かい飲み物を淹れ、ゆっくり飲みましょう。夜だったらゆっくりお風呂に入って寝てしまいましょう。

そしてハチマキを締め直すイメージで問題に正面から立ち向かう覚悟を決めましょう。

何がわからないのかもわからないという場合、何かを見落としてるとか、大事なピースが一つ抜けてるとかそういう、あとちょっとの段階ではないということです。

自分には概要も見えないし、ピースも128ピースぐらい足りないということです。

僕はこういうとき、わかりたい対象をキーワードとしてたくさんググります。そのキーワードがちょっとでも入ってる本をたくさん買って読みます。片っ端から見てやるぞというイメージです。

とにかくそのキーワードが含まれている情報を浴びることを意識します。

そのキーワードについて様々な角度から書かれているものを見ているうちに共通点と差異からおぼろげながら輪郭が見えてくるはずです。

そうしたらもう糸口が見えているので、今まで収集した情報の中から学ぶべきものを学び、聞くべき人に聞いていけばわかってきます。自分が何をわからなかったのか、もうわかっています。

また、「理屈じゃない、触りまくって体で覚えなきゃわからない」というタイプの対象もあります。その時はひたすら触る時間を増やせば良いです。毎日習慣になるほど触っているといつの間にかわかっています。(ただそれを他の人に説明しろと言われてもできない)

一方、komagataプロは・・・

僕もプログラマーになってもう21年経ちますが、毎年一回はこれになってますね。

今年はBlender、去年はUnity、一昨年はkubernates・・・。

僕ぐらいのプロになると「はいはい、わからないわからない、ワロスワロス」ってなもんです😭

覚えるまでの苦労は何ら変わらないですが、

「今は全くわからないけど、あと1ヶ月ぐらいがむしゃらにこれをいじりまくればわかるはずだ。」

と思っているので、気持ち的には楽です。

というかホントはこんな状態になりたくないしサッとわかりたいですよ😭

半年ぐらい34歳だと思ってたので誕生日に向けて”プログラマー35歳定年説”のエントリーを暖めていたらホントは33歳で、今日34歳になったkomagataです。

おめでとう!俺。ascii codeで言えば制御コードはとうに脱し、 ” 歳になりました。

Terminal — less — 80×24

半年に1回ぐらい自己確認の為にやってることがあります。それは、Twitterに「うんこ」と書き込むことです。

何歳まで書けるかな?ってのと、書いた時自分がどう思うか。恥ずかしさはどのくらいか?などを確認しています。

ちょっと前にやりましたが、まだ余裕ですね。

というか「そういう報告要らない」と、「今、うんこしてきた」という報告と間違えられました。

2年ぐらい前につぶやいた時は姪っ子(小学生)に姉経由で見られて爆笑されました。

企業の透明性、情報共有度などを測るのに有用なメソッドではないでしょうか?

「うんこ」と呟きたい為にどんだけ必死なんだって話ですが…。

“プログラマー35歳定年説”の話は来年書きます。

受託開発から離れた理由というエントリーを書きましたが、

「新卒の時からウォーターフォール開発じゃあ既になかった。」

というアジャイルネイティブ(コンチクショウ!)な方には少し分かり辛いかなと思い少し補足を。

受託開発から離れた理由 - komagata

(僕ら受託開発会社とクライアントの利害は必ずしも一致していない。エンドユーザーに至っては受託開発会社の利益と相反してるとさえ言えるじゃないか。)

「開発会社とクライアント(開発を依頼した会社)の利害が必ずしも一致してない」というのは極端に言えば下記のようなことがあるということです。

下記は全てフィクションです

開発会社が論文検索システムを4人月(1人月=100万円)と見積り受注した。全文検索にはクライアントも知っている名のある商用パッケージを使う前提で見積もったが、土日で試してみたApache Solrを使えば半分の工数(というか土日で仕様の70%を満たしたプロトタイプが出来てしまった。)で出来そうだということが判明した。

当初の予定であった商用パッケージはより機能が豊富だが、今回の案件の規模にはオーバースペック気味で、検索UIには少し制限があり微妙に使い辛く、デザインがダサくなる。対応表明しているハードウェアやOSのバージョンが若干古く、運用も少し面倒そうだ。

要するに、「半分の値段・期間でより良いものが出来そうだ」ということが契約後に判明した。

見積りと契約にはクライアントも納得していたし、採用実績の多い商用パッケージに比べて初採用するならSolrを使うことには多少のリスクを伴う。

ちなみに現在期末であり、当案件の受注を獲得した営業担当にとっては受注金額の半減が決定した時点で今期目標の未達が確定する(笑)

さてここでこの開発会社が取るべき選択肢はどれ?

  1. クライアントにも理解できる言葉で全てを説明した上で再度決定を促す。
  2. わざわざ損を取る馬鹿がいるか。当初の契約通り行く。契約書の内容と照らし合わせても合法行為である。
  3. ウヒョー!クライアントには「商用パッケージと同機能のオープンソースパッケージがありました。ライセンス料を考えたら後者をお勧めします。」と言ってライセンス料だけ引いた金額で再契約すれば、更に2人月別の案件に投入出来て売上アップだぜ!
  4. この案件は既存の論文検索システムが使い辛いとのエンドユーザー(学会会員)からの多数のクレームから始まったシステムリニューアルの案件だ。エンドユーザーにとって一番使い易いシステムと柔軟なUIが構築できる可能性が高いSolrを採用した再提案をすべき。
  5. 仕様も期間もそのまま、人月50万で下請けに流す。

ではどうすべきか

前述のエントリーは本文を読んでいただければわかりますが、「受託が嫌だから離れたよ」という話だけではなくて、「過去離れたけど今戻ってきて勉強中だよ」というお話です。

どの選択をすべきかという点については僕にはまだわかりません。

ただ、「開発者にとっては受け入れがたいが、ビジネス上反論できない選択肢が存在する」というジレンマがあるため、多くの開発者が悩み、それを解消すべくアジャイル開発などの方法論の開発や経営を含めた契約形態の模索が行われている。アジャイル開発には商売上、受託開発最大のメリットである「商品を作る前から買い手と値段が決まっている」という点と真正面から対立するというこれまたジレンマが存在する。という認識です。

既に、「昨今ではそういう問題は解決してて、普通はこうやってるよ。例えばこの本読めば分かるよ。」みたいなのがあれば教えていただけると非常にありがたいです。また、そういった勉強会を行われている方や実際に答えを持っている方が居らっしゃれば是非、お話を伺いに参りたいです!

数年前、受託開発の会社を辞めてこれから自社・製品サービスを作ってる会社で働こうと思い、会社を転々としつつ今(FJORD, LLC)に至ります。

上記のような事を思った切欠は下記の様なことがあったからです。

中規模の案件

その時、僕はコンシューマ向けのWebシステムの案件を5〜6人ぐらいのチームで取り組んでいました。データベースに保存されたデータをPHPでXMLを返すAPIを作り、Flashで表示するサイトで、時代が時代だったので「このトラフィックをPHPで構築するなんて。Javaでやるべきだ。」なんて言われてましたが今考えるとおかしいですね。

サーバーとFlashクライアントが連携するのでAPI(XMLのSchema)に関してはデザイナーとも結構密にやり取りしていたように思います。僕はガントチャートとにらめっこしながらも案件の後半になってもそれ程デスマという感じも無く、定時で帰れるメンバーも普通にいて、

「余裕という程では無いにしてもどうやら無事リリースできそうだな」

なんて考えていました。

そんな時、Flashクライントも担当していたデザイナーの@946さんから、

「この部分のUIはこう変更した方が使い易いのではないか?」

という提案がありました。それに対して僕は、

「確かに改善案はもっともですね。僕も使い易くなると思います。しかし、今までのやり取りの感じだとクライアントはその分の工数追加を認めないでしょう。」

と答えました。

そしてその後凄く落ち込みました。

(僕ら受託開発会社とクライアントの利害は必ずしも一致していない。エンドユーザーに至っては受託開発会社の利益と相反してるとさえ言えるじゃないか。)

受託開発という商売

商売の仕組みとして受託開発はとても凄い。ソフトウェアを開発する前から買い手と値段が決まっているんだから。皆がこぞってやるのも当たり前だ。世の中に需要が一定数あるかぎり、ローリスク・ミドルリターン?のとても手堅い商売だ。

僕もその時まではデマルコやワインバーグに始まってAgile関係の書籍を読んだり実践したりして、受託開発がより良く進化していくことに期待していた。しかし「はじめの契約形態、要は契約書になんて書くの?」が解決しない限り本質的に問題は解決しない。(何度か受託でAgile開発系のイベントに行って質問したが、決まって「業務請負契約にしてもらっています」という答えだった。これは僕には妥協に感じられた。)

実際に昨今では永和システムマネジメントの価値創造契約など、その問題に正面から取り組んだ企業出てきた。(これは僕のように逃げずに真正面から受託開発に取り組む本当に素晴らしい姿勢だと思う。)

しかし、そういった問題は経営から考え方を刷新しないと無理だ。その時点で平凡なプログラマーである僕には「まず確実に5年はこの状況がかわることは無いだろう」と考え(実際に5年たったが変わってない)、「ならばエンドユーザーと直接金銭をやり取りする自社製品・サービスを作る仕事をしよう」と考えて転職した。(要は逃げた)

そして現在

現在のFJORD, LLCでも自社サービス(怖話)で利益を上げようと頑張っているが、それだけで食べていける状態に達していないので受託開発も承っているが、僕は上記の様に受託開発を良くしようとする方法論の進化から遠ざかっていた。しかし、下記の2点からまた勉強を始めました。

  • 5年ぐらいたっているので僕の知らないだけで上記の問題が解決しているのではないか?
  • メンバー2人でもAgile開発の恩恵が無視できない。

「ニワカほどよく語る」と申しますが、恥をかくのは得意なので、Agile開発について勉強したこと、疑問なども書いていこうと思います。

追記

新卒時を除いて、僕の経験した受託開発とはほとんどがコンシューマー向けWebシステムなので、エンタープライズシステムのゼネコン体質などといった、更に難しい問題が無かったのは幸運でした。

僕の仕事はWeb開発者ですが、時々、

「何が仕事で何が仕事でないんだろう?」

と思うことがあります。

  • Webと全く関係無い趣味のコードを書いてる時、それは仕事なのか。 
  • FacebookのEmpires & Alliesをやってる時、それは仕事なのか。
  • レストランで食事をする時、それは仕事なのか。 
  • くだらないジョークをTweetする時、それは仕事なのか。

仕事と遊びを区別することなどナンセンスだという考えもありますが、ある時、仕事の条件についてのアイデアを思いつき、以来気に入って使っています。

そのアイデアとは「URLを持ったら仕事だ」というものです。

  • 趣味のプログラムをネットにアップロードし、URLを持ったらそれは仕事です。
  • Empires & Alliesをプレイして感じたことをブログに書いたら、URLを持つのでそれは仕事です。 
  • レストランで食事をしてその写真をInstagramにアップロードしたら、URLを持つのでそれは仕事です。 
  • ジョークTweetもURLを持つのでそれは仕事です。(自分のサービスのマーケティングになっているかもしれません)

逆に、どんなに充実して深い考察を得たとしても、URLを持たず、ネットからアクセス可能な形を持たないとしたらそれは遊びです。

極端なアイデアなので全くの的外れかもしれません。しかし僕は直感的に気に入って使っています。

フォーマットはhtml。epubもpdfもメンドイ。というか単なるWebサイトであって欲しい。ユーザー登録が必要なWebサイトで、サインインしていれば買った本のページが見れる。

僕にとってテキストを一番読み易いのはスマホ + 横書き + 無限縦スクロール(要はWebでよくある奴)なのでスマホでいい塩梅のレイアウトにして欲しい。(はてなダイアリーのスマホ版Webぐらいで十分読み易い)

著作権やライセンス表示はしっかりいれるが、システムで縛らず、無茶した奴をタイーホするぐらいにして欲しい。

縦書きやレイアウトにこだわりたい本は印刷物を同じページから買えるようにする。

懸念点

  1. 無法者やそもそも著作権に頓着しない外人への対応。
  2. 所有感がないこと。(僕は気にならないが)

先日の飲み会で話した自分のフィードやTwitterなどの情報収集スタイルについて。

ストック(貯めこむ)情報とフロー(流れる)情報の2種類に分ける。

ストック情報

僕にとってのストック情報とは未読既読を管理し、全て読むタイプの情報です。Googleリーダー(フィードリーダー)とEchofon(Twitterクライアント)で管理します。

フロー情報

僕にとってのフロー情報とは、はてブとHacker Newsです。時間が開いたとき適当に読みます。息抜きと自分のフィルターをなるべく通してない情報を得るためです。

フィードリーダーの使い方

Twitterなどの手軽な発信手段が増えたので色んな人の書くブログエントリーは全体的に量は減っていますが質は上がってると思います。

月に1エントリーの頻度で書く人を100人購読しても大した負担にならないのでなるべく沢山の人を見つけたいと思っています。読みきれないフィードは購読しません。

Twitterの使い方

fav(favorite)リストを作ってそれを全て読みます。Echofonは起動してない時間の投稿を省略するといった取りこぼしが無いので全部読めます。mentions, DM, fav以外は読みません。

仙人について

時々、自分でもどうやってたどり着いたのかわからないような、マイナーなブログで恐ろしく質が高く貴重なエントリーを書いている人がいます(僕個人に物凄くフィットした情報を書いている)。

エントリー頻度はそれ程高くないけど、時々、お金を払っても得られないような情報や専門分野の秘密の奥義をタダで公開してくれる。そんな人が気まぐれに書くエントリーは絶対に見逃してはいけない(フロー情報として扱ってはいけない)。

そういうフィードはお宝です。そういう人は中国の秦の時代、漢の成立に尽力した張良に六韜を授けたとされる黄石公のような仙人です。

「5日後の朝ここに来い」

と言われたら夜明け前からスタンバってないといけません。そんなことはなかなかできませんし、仙人と会えることもまれです。

しかしGoogleリーダーやEchofonを使えば中国全ての山の麓でスタンバってることもできるのです。100人の仙人から学ぶことができます。これを100人仙人状態といいます。

自分だけのポートフォリオを組む

取得すべき情報は個人によってまったく違います。自分にとっての仙人をみつけたら大切に自分の情報源ポートフォリオに組み込みましょう。読みきれるフィード量には限界があります。日々良いフィードを探し、悪いフィードを外しましょう。磨き上げられたフィード集は将来にわたってあなたのとても心強い見方になるでしょう。