島までは遠い 〜サークルアラウンド株式会社代表佐藤のブログ〜

佐藤正志@サークルアラウンド株式会社のことが少しわかる場所。プログラマーを育てるトレーナーとして、現役のソフトウェア技術者として、経営者の端くれとして、想うことをつづる。

プログラミングは難しい

uxmilk.jp

このエントリ、ズバッと言っててすごく良かったです。乗っかります。

プログラミング習得には時間が掛かる

プログラミングを学ぶのに私がかけた時間は初期の方だけ数えても

  • 中学くらいでたまに数時間ずつ使って数ヶ月で完成させた簡単なBASICのゲームらしきもの(もはやゲームじゃなかった)
  • 大学二年くらいから触り始めたVBでのプログラミング。その後VC++。 年単位で同じアプリをこねくり回していた。
  • それから大学院卒業までの4年程度は趣味として、研究データを編集する道具として、かなりの時間をプログラミング(コードを書くことももちろん、書籍を買って読んだりすることなど含めて)に費やしている。
  • 大学院出てからは一年間はWEBのシステムを開発するために、一年間活動している時間はほとんどLinuxの設定やPerlのコードと格闘した。

結構費やしていると思います。断続的ですが数年単位の時間がかかっていますね。その後お金を稼ぐプロになってから15年この仕事をしています。今も記録更新中です。

これだけ時間をかければ大抵のことはある程度上達すると思います。

プログラミングにおける成長曲線 〜 必要な忍耐

成長曲線についてですが、もともとは下記で書いていたことで、拙いながらもこの内容は今でも初心を思い出すための大事な記録です。

最初の成長は頑張っただけ伸びることができないものです。ある一定の経験を積んでからいきなり伸び始めます。私が多数の方の学習を見てきた経験上、伸びることができない長さに影響しそうなのは下記のような要素だと思っています。

  • 考える訓練ができているか
    • 物事を突き詰めて考えることや、一つ一つ丹念に確認することに慣れていない人は、集中力が続かないので成果を出しにくい
  • 調べ方の訓練ができているか
    • インターネットから必要な情報を得てそれを問題に適用することができないと成果を出しにくい
  • 大きな問題を小さく分解できるか
    • 大きな問題をいきなり解決するのはとても難しいので、今対応している問題を小さな単位に分解できることが必要です
  • 簡単な英語が読めるか
    • エラーメッセージは英語。本当に簡単でいいので英語を読めること。英語が出たらすぐ閉じる癖の無いこと。

上記は結構な忍耐が必要なタイミングがあります。脳みそがオーバーヒートしそうな程考え込むことも、エラーの原因がわからなくて頭を抱えることもしょっちゅうです。

「簡単」という嘘

「簡単に学べる」と言っているのは、全体の大きな山のうち最初の丘を越えるくらいの部分のことを指している事が多いと思います。そしてそれをあたかも大きな山を登頂するようなミスリードを生む宣伝が存在することは否めないでしょう。

逆に言うと、一ヶ月二ヶ月ちょっとやっただけでその人のセンスは判断できないとも思っています。元記事では自分の頭が悪いと諦めている例がありましたが、それはまだまだ早過ぎる判断ではないでしょうか。

簡単に始められるけれども、しっかりと身につけるには時間がかかると思って取り組んで欲しいです。

どうすればいいの?

私のところに相談に来る人には、一見「プログラミングの習得にかなりの時間がかかるだろう」と感じられる方もいます。「スクールで学んだけれどよくわからなかった」という経験を持つ方もよくいらっしゃいます。「スクールが教えてくれないのでトレーニングして欲しい*1」 という依頼まで受けました。

それでもその人に合わせたやり方を取ったり、問題の粒度を調節して一歩ずつ進んでいけばちゃんと上達していきます(かかる時間についてはマチマチになりますが、放っておくよりは諦めずに続け、成果にたどり着く確率は確実に上がっていると思います)。先述のように「急に一気に成長し出す」モデルになるので、理解を1個ずつ積み重ねるとある時いきなり繋がって回り出す気がします。

そして下記のようなことが大事ではないかと今は考えています。

  • 学習の時間を十分に確保する
    • 時間をかけないと難しいので、時間を確保しましょう。短期間に一気にやる方が良いです。最初はすぐ忘れてしまうので、定着するまでは詰めていく形です。
  • 忍耐が必要なことを理解して取り組む
    • 問題に当たるのは当然です。プロでも毎日問題を解決し続けて進んでいます。それが日常だと知ってください。
  • 問題を適切な大きさに分解して取り組む
    • 大きな問題を小さく分解できれば解決出来る可能性が上がります。そうして一つずつ解決するんですね。

時間の確保以外の部分は、実は人が介在する方が良いことが多いです。つらい時に「今つらい。どう進めたらいい?」と相談できるのは大事ですし、問題を分解するのに一定の経験を必要とすることは多いでしょう。また「そこを掘り下げても今は実りがない」と伝えてくれるのも人の素晴らしいところです。 プログラミングの習得にはこういう部分で人の介在があった方が良いと感じます。より多くの人がストレスを減らしつつ学ぶにはこれらがポイントになるのではないでしょうか。

イメージとしては「うまくいかなくとも簡単に諦めてしまわない」ように組み立てる必要があります。

諦めてしまうケース

ところが元記事では下記のような最終的に受講生が自身の能力を疑って諦めている形で締めくくられているシナリオがあります。

Aさん「えっ、そうなの。一般的にはプログラミングは簡単なのでしょうね。私が馬鹿なだけで。」

Bさん「プログラミングは簡単だと持っていたけれど、どうやら僕が馬鹿だっただけみたいだ。」

これは最悪の結果です。「初期の成長が遅いんだ」という自身の特性への理解ならまだしも「簡単なこれすらも受け入れる能力がなかった」という拒絶で終わってしまうと感じるからです。

私はAさんもBさんも(実在してはいないと思いますが似たような方が世の中にたくさんいると思っています)、訓練次第でやれる人になると考えたい派です。

最初の一歩二歩がうまくいくと自立していける人は世の中に結構いるはずなのですが、その1歩目、2歩目の時点の躓きをカバーする方法があまりないのですね。

「努力していないから」「時間を確保していないから」はまだ理由として納得できる部分はあるものの「能力がないから」という理由にはあまり納得がいかないのです。

気づいている方もいらっしゃると思いますが、 事業者側の目線に立てば、短期的な利益を目指すなら最初に高い金額をまとめて納めさせて早々に諦めさせるのが一番大きな利益になります。辛くても継続してもらうには人的なコストが最も必要なところでしょう。諦めても良いのであれば、受講生に合わせることを拒絶すれば簡単だと思います。どんなに丁寧なドキュメントを用意しても初めてプログラミングをする人にとってはイメージしずらかったり、誤った理解をしてしまって袋小路にはまるものなんです。この話は機会があったら別のところでしようと思います。

難しいのはわかった。それでももっと早く成長できないか?

今は良い世の中になったので、わからないことを聞ける場所も多数できましたし、WEB上に情報もたくさん出ています。私が本格的にやり始めた20年前とは比べものにならない程良い環境になりました。

私も自分なりに色々とやっていて もくもく的にやったり、マンツーマンしたり、動画を利用したり、と試しているところです。成長したい期間や求めるゴールによって様々な手段がありそうです。

最後に

大変なことも多いかもしれませんが、難しいものを解き明かして作りたいものを実現するのは快感ですよ!是非それを感じて欲しいと思います。

f:id:ms2sato:20161016182732j:plain

*1:訳がわからないと思いますが私もわかりませんでした。念の為当該スクールに確認いただいて了承いただいた上でトレーニングはさせていただきました。デモデイ的なもので入選されていて、サービスもリリースできた様子です。

古い友人との話。振り返ってわかること。

f:id:ms2sato:20160821093835j:plain 盆休みでもあったので、旧友Sと一杯飲んできた。彼は関東にいるけれども少し遠くにいるので、最近はお互いの中間の都市で待ち合わせて飲んでいる。

私の人生の中で学生から社会に出る数年の間、一緒に最も多くの酒を飲み、最も多くの馬鹿話をした相手だ。下手すればこの時期は家族よりも過ごした時間が長いかもしれない。

最近はお互い歳をとったのか、今だから言えることのような話も出たりする。その中での話。

「でもさ、サトちゃんみたいなヤツだから今社長とかやってるんだろうね。」

「?」

「高校の頃とか、Iみたいなカリスマのある奴っていたじゃん?でも彼らって『そこに組織があるから選ばれやすい』タイプだと思うんだよ。」

「ふむ?それってどういうこと?」

「俺とかお前ってあの当時基本的には二番手ポジションだったけど『俺はこうだ!』って常に出し続けてたのはサトちゃんだなって思ってさ。俺とかそうでも無いし。社会に出たら組織が無い所から始めない限りまずトップにはならないんだから、『俺はこうだ!』って出せなければ何も始まらないと思うんだよね。カリスマのあいつも組織の中で登って行くタイプなんだなって。」

「あぁ、そっか。そんな気もする。」

「だから今こうしてるのは結構当たり前な感じがするんだよ。」

こいつはいつもそうだ。こちらからは見えないどこか高い目線から俯瞰したことをサラッと言ってのける。忌々しいヤツだ。私は過去カリスマに敬服して喜んで二番手三番手を続け、社会に出てからもどこかで私を屈服させる存在に出会えることを期待した。そして出会えなかった。だから結果的に今の場所にいると思っていた。ひょっとしたらそれはちょっと違うのかもしれない。

いつも新鮮な切り口でモノを語ってくれるから、こいつとの時間は貴重なのだ。一時間やそこらの時間をかけて会いに行く価値のあるヤツだ。

「サトちゃんはこうやって時間作り続けるの偉いよな。」

「俺には家庭がないからだよ。奥さんや子供がいないからできるんだ。」

「10代や20代なら時間有り余ってるし、時間作るとかみんな言うけど、40になって仕事も忙しいのにそうそうできないって。大抵ついでがあるからやってくれたりするもんだ。」

「優先度はあるよ。Sはそれだけのモノを俺にくれているって事だ。」

「そんな感じはしないけどなぁ。」

私が受け取っているもの(と、ちょっとした嫉妬)を彼はあまり理解していないのかもしれない。だが、それは大きな問題ではない。 出会った人の印象や状態は年月と共に変わる。その中で、この人には時間をかけたいとか、それだけの価値があると思える事にはあまり妥協しない方がいいような気がする。

中には時が止まっている願望に囚われていたり、関係が変わって欲しくないと思い続けている人がいるかもしれない。でも、変化を許容し、その上で価値を見出し続けられる相手にこそ時間をかけるべきではないか。「過去の一時期、同じ場所にいた」それだけではないから長く続く関係が築けるのだと思う。

Sの奥さんも呼んでくれているそうなので、今度はやっと一歳になる彼の子供に挨拶がてら遠征するのも悪くないな。

システム開発とプログラミングの狭間

はじめに

プログラミングを知らない人がプログラミング教育をする危険性 - WirelessWire News(ワイヤレスワイヤーニュース)

こちらを拝見していたのですが、内容自体に関してはちょっと置いておいて、少し前からひっかかっている言葉のことが脳裏によぎりました。実はこの言葉の感覚について他人と話したことはないので、私だけが勝手に思っていることかもしれませんし、ひょっとしたら誰かが既にちゃんと整理してくれているのかもしれません。もしも何かシッカリした解説があったら教えて欲しいです。

私の思うこと

下の写真のイメージ感が伝わればなあと思っているのですが、プログラミングはコードを書くことを中心にした部分だと私は捉えているので、システム開発のごく一部の部分です(「プログラミング」という言葉の示す領域を一旦表現したい)。

f:id:ms2sato:20160703000123j:plain

まず最初に「プログラミングの根幹になっているアルゴリズムなどはあるものの、システムを開発するという文脈からすると普段これらはかなり抽象化されて気にしないレベルにされている」という感覚を伝えさせてください。

例えば、WEBシステムを作成している方はSQLを書いている時にorder byを使ってソートすると思いますが、これの中身がどんなソートになっていて、どういうSQLの場合にどれがふさわしいかとか理解している人はそれほど多くないと思います(私も勉強不足のため、存じ上げません)。 また、自分でソートアルゴリズムを実装する場合、ネットワークの方がメモリ上のアルゴリズムの速度よりもはるかに遅い現在の(あくまで現在の話です)WEBシステム運用環境において、ソートのアルゴリズムを何にするかは多くの場合優先度は下がっていると言えるでしょう。もしも既に何かのソートが提供されているならそれを使う(開発効率を上げる)ことを望まれることが多いと思います。 当然ですが、それはソートがどんなものか知らなくて良い理由にはなりませんけれども。

さらにRailsのような秀逸なフレームワークのおかげで、開発において考えなければいけない設計や、よく利用する実装の部分もどんどん考える必要がなくなってきています。「Railに乗るようにする」という言葉が表すように、最近の私たちはオリジナルのクラス構造を編み出す事が少なく、型に嵌ったようにシステムを作ることが良いとされてきていると思います。昔の自分ならそれを設計することが当たり前だった部分が既に提供されているのですね。楽になったけれど一番面白かった部分は無くなってしまったとも感じています。

そうして「プログラミングの根幹」たる部分はどんどんフレームワークに隠されています。システムのコードはフレームワークに乗っかって作成されるので、フレームワークを上手に操作することが良いシステム開発だと暗黙に了解している節があります。開発の効率を目指すならばこれは正しい判断なのでしょう。

ところで改めてシステム開発全体を見ると、プログラミングが担う部分の他に、サーバの扱いやネットワークを構築すること、CIやデプロイに関すること、運用を効率化するための仕組みづくりなど、周辺の要素が多数あります。RailsのようなWEBフレームワークを初学者が学ぶ際には、フレームワークの学びからどんどんプログラミングの根幹へ向かう方向性よりも、周辺の要素の方が重要になります。まずシステムを動かす体験を得てもらうことが大切になるためでしょう。

元記事では「プログラミングを教える」と称して営業されている話が書かれていますが、某T(どこかは存知あげませんが、当たりはつきそうです)の実態としては「システム開発を教えようとしている」だろうと私は理解しています。ですからフレームワークの操り方を中心に教え、簡単なデプロイまでを行うようなカリキュラムではなかろうかと推察します。

営業としては世間によく知られている言葉を使う方が顧客にリーチできるので、「プログラミングを教える」という言葉を使うのは当然なのかもしれませんが、本来は「システム開発を教える」ではないでしょうか。自分のところでやっているトレーニングに「WEBプログラミング」と付けているのも同じような理由ですしね。

ちなみに私が今回の違和感に最初に気づいたのは、どんなものが作りたいかをトレーニングの受講生からヒアリングした時です。プログラミングがどんなものか知りたいだけであれば、私のオススメはJavaScriptです。環境構築せずにブラウザさえあればプログラミングをすることができ、HTMLがどんな風に変化するのかを見た目で確認しながら学ぶことができます。システム開発がどんなものか知りたければ、Ruby(いきなりRailsかどうかは置いておいて)やPHPを薦めるでしょう。言語をどれにすべきかはその人がゴールとしてやりたいことで決まります。脱線するのでこの話はここで止めます。

おしまいに

自分の考えている言葉のニュアンスの違いを示そうと努力してみました。

でも実際「プログラミング」という言葉の領域って私が思っているよりもズッと広いのかな。それとも分けようとし過ぎ?世間でも「プログラミング教育」なんていう時に、それがどこまでを示そうとしているのかなと思ったり。もやっとしたまんまで終わりますが、誰に伝えるでもないブログなので答えがなくても勘弁してくだされ。

私について

言葉の話は持っている背景や文化によって違うと思います。 一応私の技術のバックグラウンドと考え方をだらだら書いておくと、中学生の頃にMSXでBASICをいじったのが最初で、大学の一般教養でC言語やったけどつまらなくてVisualBasicでWindowsアプリ作ったりしてるうちにVC++など弄り始めて、学校出てからPerlでCGI書いたらWEBは結構楽しくて、仕事始めたらWEBのJavaが中心で業務の為のフレームワークのコードばっかり書いて、phpのWEB開発の手伝いしつつガラケーのアプリのプロトをC++で書いてみたり、リッチクライアント的な流れでFlexやら.NETやらやってJSでSPA的なの書いてるうちにnode.jsとかも手を出してめっちゃカオスだけど、二年くらい前にJS中心はちょっと置いといて最終的にはチーム開発をRails使ってやっていたりする、そんな奴です。

言語はあんまり選り好みしません。「ロジックちゃんと書けるなら別になんでもいいんじゃない?」くらいに思っています。チームメンバーが使いやすいのに合わせます。チームの成果の最大化が自分のミッションになることが多いので、自分の開発効率だけで物事判断しません。ちなみに自由気ままにやれるなら、まずフレームワークを作らせて欲しいと駄々こねるでしょう。

人を育てることが会社の方向でもあって自分もやりたいことなので、最近は「お客様に提供するでもなく、趣味でもない」という領域でプログラミングすることも増えてきました。レビューばかりする事も増えたので、たまにガッツリ好きな趣味のコードを書きたくなります。

見て覚えるでもなくマニュアル渡すだけでもなく、本質や概念を適切に掴んでもらうことが大事。

f:id:ms2sato:20160312231733j:plain

はじめに

www.recomtank.com

こちらを拝見していて考えたことを綴ってみます。 とても勿体無いと感じてしまったので、私なりに整理したいと思いました。

私のスタンス

  • 後輩は私よりも早く成長して欲しいです。私が20年かけて体得したことを若い彼らがより短期間で体得することが、人の進歩を生むと思っています。40歳近い私と同じことが30歳より前にできたらそれは10年以上の飛躍です。物凄い価値創出だと思います。
  • 願わくば早く私よりも「現在望まれていること」に関してはできる人になって欲しいです。そして私にも最新のことを教えて欲しいです。
  • 過去の経緯はロートルの私の方が知っています。それは私が彼らを補ってやれば良いことです。
  • これを繰り返せば、人の成長はもっと加速します。加速した成長の結果「今の私には解決できないような問題を解決する人を輩出するのだ」と信じています。例えばAIやロボットが当たり前になった世の中で新しい価値を創造するのは、私のようなオッサンではなくて若い後輩達に間違いありません。

マニュアルがあれば良いのか

まず、単なるルーチンについて、マニュアルはあって良いと思っています。 操作そのものは文書化されていればミスも減りますし、人に伝える際に情報へのポインタを示すだけで委譲できるからです。端的に言えば「全部あれこれ説明するなんて時間がかかる」「見真似で勝手に想像でやれば抜け漏れが出る」と考えています。

身につけるとは何か

私は「本質・概念を獲得する」だと考えています。細かい操作を暗記することは身につけているとは言えません。それは単純に記憶しているだけだからです。その結果不測の事態に対応できないことになります。逆に本質を獲得している人は、今まで起こったことのなかった事態にも、新たに編み出した適切な対策を行うことができます。

手取り足取り教えること or 放置して勝手に身につけさせる「だけじゃない!」

さて、この話題で見落とされていると私が感じるのはこの点です。元記事でも言及されているのですがこの部分の強調が弱く、感情論が先に立っているように見えて、とても勿体ないのです。

  • 教えると、考えない。
  • 教えない為に何も示さず、見て覚えろ。

この二つには大きな飛躍があります。私も手取り足取り教えることには反対です。ただし「見て覚える」という不確実な方法で果たして本質が掴めるのでしょうか。掴めるとしても多大な時間をかけて会得するのではないでしょうか(「私のスタンス」にも書きましたが、私はこの時間をかけることをすっ飛ばしたいのです)。

大事なことは本質や概念をいちはやく獲得することであって、細かい操作を暗記することではありません。

どうしたら良いの?

本質や概念を獲得するには「自分の頭で考えて、明瞭な形で落とし込むこと」が必要だと考えています。 これはとても大事なことです。そしてそれが短時間で行われるように促すことは先輩がやって良いし、やるべきだと私は思います。「何について沢山考えるべきか」知っているのは同じように悩み苦しんだ先輩だと思うのです。

つまり

  • 先輩は全てを手取り足取り全てを教える必要はありませんし、それはやってはいけません。
  • 先輩のやるべきことは「本質や概念を獲得する為の大事なポイントについて考えてもらうこと」です。
  • 本質や概念に到達するまでの思考の道のりが長い場合には適切な単位で到達ポイントを区切ってやること。

さて、二番目の話は少し抽象度が高いですね。もう少し具体化します。考えてもらう為に下記のようなアクションがふさわしいと私は考えています。

  • 考える材料になる適切な体験をしてもらうこと。
  • 適切な質問を投げかけること。それに対して十分な理解が感じられるまでは問答を続けてやること。
  • ルーチンではない本質の理解が必要な課題を与えること。

よりスムーズにするには

上記の内容は、実は学ぶ側からするとストレスの高い行為です。それは考えることを強いる為です。考え続けることに慣れていない人はその疲れを解消することができず、モチベーションが酷く下がってしまいます。考えることを放棄したり、わかったようなフリをしてしまうのです。

その為モチベーションの維持が大切になります。これはいろいろなシーンで言えることなので、また別の機会に。 ちなみに私は先輩や指導者のやることの殆どはモチベーションを上げることだと思っています。理不尽にやる気を削ぐ先輩は碌な先輩でないとすら思っています(もちろん「相手のモチベーションをあえて下げてでも伝えなければいけない大切なことはある」と認めた上での話ですよ。誤解なきよう)。

おしまいに

物事を二元論で表現している時は、別の切り口を考えると本質に近いことがよくあると私は思っています。

チームのことだけ、考えた

チームのことだけ、考えた。―――サイボウズはどのようにして「100人100通り」の働き方ができる会社になったか

チームのことだけ、考えた。―――サイボウズはどのようにして「100人100通り」の働き方ができる会社になったか

かんそう

年末に買って1日で読み終えました。とても良い本です。 組織をどのようにしたらうまく進めることができるのか著者が考えたこと、試したことが細かに記されています。本当に様々なことを試しながら進めてこられたことがわかります。事業におけるPDCAサイクルを繰り返して最適化していく過程に似ていると感じました。

そしてそれぞれについて論理的な説明がなされていることも価値の高い部分であると受け止めました。直感的には理解していても、他人に確からしい説明を試みることが難しい場合がある為です。

現在は「多様性を高めること」が大切であるという軸で進められており、現在の情勢に適用する内容であると思います。賛否のある部分もあるかとは思いますが、大きな方向性として納得のいく方針ではないでしょうか。

薦めたい人

  • どのように自社を進めていこうか迷っている経営者
  • 会社の結束がなかなか高められないと感じている経営者
  • これから会社を立ち上げようという人

年末年始で「JSON一発」というシャレみたいなサービスを作った話

はじめに

弊社で一緒にお仕事していたり、バックオフィスを手伝ってくださる方とでささやかな忘年会を開いたのですが、その二次会で「年末年始でなんか作りましょうよ」的な話が上がり、その場の勢いで「やろうやろう」という感じになりました。その顛末となんか出来上がったものの紹介です。

作戦会議

弊社の入ってるシェアオフィスCASE Shinjukuの会議室に、当時同じプロジェクトで働いていたalgolaboの川人さん、1年ほど前のプロジェクトで右腕として働いてくれたアイデア家業の池田さんをはじめ、弊社周辺で働いてくれている技術者数名で集まりました。

作るもの

「ものすごく簡単に公開JSONを作れるサービス」です。JSONは生のJSONだけではなくて、マクロ機能が自動的にダミーの人名を作ったりしてくれます。 利用イメージとしては例えばajaxでデータを持ってくるサービスのプロトを作る際、サーバーサイドを用意することのコストをかけたくない時にサクッと通信先を用意するというシーンです。テストでも使えるんじゃないかと言われてもいます。

作り方

基本的にみんな慣れている形がだいたい同じだったので下記のやり方で。

  • Rails
  • GitHub-Flow
  • CircleCIでHerokuデプロイ

GitHub-Flow周辺の流れは以下です。

  1. タスクを切る
  2. 勝手に自己アサインしてPR
  3. レビュー権限のある三人のうち誰かがOK出したらマージ
  4. CircleCIでテストしてHerokuへデプロイ

期間

12/20 - 1/3(のつもりが1/10まで延期)

一応年末年始でなるべく収めないとモチベーションが維持できないと思ったので超短期でした。 そうしといて良かったです。実際10日以降はほとんど稼働していません。

デザイン

「ファイ◯ー!!イッパーーーーツ!!」 のイメージから考えてくれたキャッチーなデザインです。 弊社トレーニングでJSを学んだ岡田さんに頼みました。

経過

  • 12/31 までに大枠が共有できて、マクロはRubyの関数を作ればいいよという感じで担当者が並行して実装。全てオンライン進行。
  • 1/3 には私の自宅に何人かで集まって最低限の切り口で実装完了。
  • 1/10 までにデザイン調整や仕上げなど。

結果

JSON一発

こんな感じです。下記のようなJSONを返すURLをサクッと作れます。

https://jsonone.herokuapp.com/a690ac6431ce45f4b2c949718d9cad05

ご注意

アカウント管理とかしていないので、プロジェクトのURLがばれると誰でも編集できます(URLが認証キーみたいな扱いをされている感じ)。まぁその辺は許してください。あくまでそのURLがバレない程度(もしくはバレても問題ない程度)の使い方を今はしていただければ幸いです。興味ある人いたら声かけてくれたら色々考えるかもしれません。

お礼

今回開発に関わってくれたメンバーは記事に入っていない方も何人か居ます。名前が出しにくかったり出せなかったりしますが、忙しい時期に色々とアクションしてくれて楽しい開発になりました。ありがとうございました!

私の反省

なんか途中でroutesの設計に苦しんだりして無駄にコストをかけてしまいました。Railsのレールにちゃんと乗った形にこだわった方が結果的に良いのだなと改めて感じた次第です。

ただ、こういうところは本当は若手に任せて成長を促したかったなと思う次第。もうあんまり自分がコーディングのところでリードしないで、レビュアーとかで活躍する方へシフトする方が皆にとって得になると思っています。次回はそういうスタンスもできればなぁ。

メンバーの仕事の遅延後の私のコミュニケーション

f:id:ms2sato:20160123143132j:plain

はじめに

togetter.com

これを読んで「先輩側が悪いんだ」「バッファが甘いからだ」などと意見が出ていますが、元々は「質問はありか?」ということなので、YES派の私なりの考えをまとめてみようと思いました。実際に私の現場では新入社員に対してこういうことを聞きました。ヒアリングの場に使いやすいように投げかけ質問調でまとめます。

ただ、思い起こすと結構経験を積んでからも見積もり失敗とか間に合わないとか恥ずかしい状況も引き起こしている自分なので、ホント「恥を忍んで」という感が否めません。そんな私も小規模ながらチームを率いて何人もの後進の面倒を見なければならない状況下で、こんな風に悩みながら色々とやっているよってことで。

私ならこんなヒアリングします例

「いつ、『間に合わなさそう』と思った?」

どこかの時点で気づいているはずです。なので、まずそこを確かめた上で「その時にどうすると良いと思う?」と続けて聞いてみます。たいていは「相談するべきだった」のような回答をくれるのではないかな〜と思っています。そういう回答でなかったとしても、一緒に考えてみる時間にします。

そして私としては「何の相談もなく締め切りに遅れる」よりも「事前に相談される」方が何倍も良いし「間に合わないと思ったけど、間に合います」という再修正がある方が良いということを強調します。相談しにくい状態は避けたいのです。

それは「遅れることが事前に分かってさえいれば、自分なら手を打てることが沢山ある」ケースが多いからです。助けてあげることはもっと上位の人ならできる場合が多いですし、仕事の信頼感がこういう連携から生まれたりもすると思います。

「何に思ったより時間かかった?」

何がしか予想外のことが起こっていて、時間がかかっているはずなんですよね。その時のことを確認します。

  • 技術的な問題でいわゆる「ハマってしまった」(実力不足も含む)
  • 割り込みの出来事

大抵こんな感じのことが確認できるのではないかなぁと。想定よりどれくらいのダメージがあったのかも聞いてみたりします。

「相談して良いタイミングはあった?」

上記が整理された状態でこの投げかけがあると、おそらく時間がかかったところの話が出てきたりするのではないかなと。その時にどんな相談があったほうがいいかはこちらから提示してもいいかと思っています。例えば以下のようなことでしょうか。

  • 「この問題に1時間以上ハマってるので助けてください」
    • そのために「1時間悩んだら聞いていい」とか言っておきます。どれくらい難しいかを判断できる経験値が無いことが多いからです。
  • 「この問題に結構時間がかかりそうですが、かけてもいいですか?」
    • 時間を無言で浪費されるより許可を求めてもらう方がいいです。そのために遅れる可能性があることをこちらは了承しないといけませんが。
  • 「思ったより1日くらい長くかかってて、終わりが来週前半までかかりそうです」
    • いわゆるリスケの希望を出してもらいます(できれば最後の手段にしてほしい。それまでに相談されたい)。

相手に伝えておきたい心構え

  • 予想外になってしまって遅れることは必ずある
  • 大事なことは「遅れる事実」「どれくらい遅れそうか」を事前に伝えること
  • 事前にそれを伝えることがシッカリできれば信頼が維持される場合は多い(むしろ高まったりする)ので、恐れず相談して良い

相談される側の心構え

  • 自分に余裕がないと色々と失敗することが多いので、できれば余裕を持った状態を維持する(難しいよね)。
  • 相談がしやすい雰囲気作り(相談された時「あぁん?」とか言わない)
  • 大事な内容は「大事なことだから厳しく何度も言う」と前置きしたり、その背景を話してあげる。

最後に

だめだ。書けば書くほど以前の失敗を思い起こして胸が痛くなる...。自分も努力します。 できれば具体的な「自分はこうしているよ」が皆で共有されてより素晴らしい対応ができると良いなと思い、書いてみました。