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

はじめに

www.recomtank.com

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

私のスタンス

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

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

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

身につけるとは何か

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

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

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

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

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

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

どうしたら良いの？

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

つまり

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

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

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

よりスムーズにするには

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

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

おしまいに

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

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

チームのことだけ、考えた。―――サイボウズはどのようにして「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のレールにちゃんと乗った形にこだわった方が結果的に良いのだなと改めて感じた次第です。

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

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

はじめに

togetter.com

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

相談される側の心構え

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

最後に

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

勉強会の内容が被るのはアリだとしても、イベント内容文章のパクリはダメじゃないでしょうか。

はじめに

偶然これを見つけてしまって「見覚えのある文章だなぁ」と。

megalodon.jp

私のところでやっている「プログラミング相談所」の文章が一部そのまま利用されているではありませんか。私が書いた文章なので当然見覚えありますよね。

circlearound.doorkeeper.jp

思うこと

勉強会の内容自体にオリジナリティがあるとかではないので、同じ趣旨の勉強会が開かれるのは仕方ないと思いますし、自分としては大歓迎な事なんです。そうやってプログラミングの初学者の人がどんどん登っていける場所が増えたら良いなと思っています（当然ですが、トレーナーとしての腕では誰にも負けたくないと思っているので、そこで差をつけたいというのが自分の負けん気とか自惚れみたいなものです。そういう本質的な競争がしたいです）。

ただ、内容とか投げかける文章に関しては自分たちで考えて書いておくべきではないでしょうか。ここまであからさまに内容を取って行かれるのはあまり面白くないですし、主催者側の倫理感が疑われると私は思います。

システムを作れるようになる為に少しずつこなそう

はじめに

新年一発目にどんな内容を書こうかと思ったのだけれど、なかなか決めることができずに時間が過ぎてしまいました。 一番伝えたいことをエントリにしたかったのですが、どうしてもまとまりません。

そんな時以前バズった記事がちょっと目に入って、メッセージよりもエピソードを伝えたいと思い直して、過去の体験を書きます。 codeio.hateblo.jp

以下の話は実際に僕の過去の現場で体験したことです。勉強して越えるべき壁について何か理解が進めば幸いです。

Aさんという人

私と彼は、ある会社の契約社員と中途入社の社員として出会いました。当時彼は26歳。私が28か9くらいの頃です。「ある学校でJavaのWEB開発を一年間学んで来た。」と言っていました。

当時の開発のリーダーが面倒をみることになって暫くしたある日、雑談していると「Aさんが活躍するのはだいぶ難しい」というような話を聞きました。どうやら本当にシロウトに毛が生えた程度の実力しかないようだと言うのです。

ヒアリング

開発についての理解度や今の実力を知るために、リーダーさんと私で業務後にいろいろと聞いてみる時間を作りました。ホワイトボードに擬似的なコードを書いてみたり、知っている言葉を確かめてみるようなことです。

わかったことは、自身で考えたコードを書くことはできませんし、Javaの参照（超基本です）への理解すらも出来ていないということでした。彼の性格から考えて手を抜くようなタイプではなく、真剣に学んでこういう結果になっているという事だろうと理解しました。

これには私とリーダーさんは頭を抱えてしまいました。そもそもの見えている世界が違うようだと認識したのを覚えています。

アプローチ

私は当時毎日出社するような事はなく自由な出社を認められていたので、暫くはそのリーダーさんについて仕事をしている姿を見かけていました。たまに昼ご飯を一緒することはありましたが、その後どうしているのかを聞く機会はなかったです。そんなある日、何かのきっかけで二人だけでランチに出る時がありました。多分下記のような趣旨の会話をした気がします。

私「最近どう？結構大変なんだろうとは思うけど。リーダーさんに面倒見てもらってる？」
A「…最近放置されています。かなりキツイです。」
私「質問したら答えてもらえるとかではないの？」
A「質問しにゆくと不機嫌になってしまうので、なかなかできません。」
私「oh...」

当時のリーダーさんはかなり職人肌の人だったので「背中で学べ」「勝手に登ってこい」「自分で調べろ」という方でした。私の伝える「育てる事が出来ない組織は沈むだけなのだから、うまく育てる事を考えないとダメだ」という事に反対はしないまでも、実践はなかなか難しい様子でした。その後様々な経験を経てだいぶ色々と考え方の変わった方なので、当時はまだまだ若かったという事でしょうか。

「このままではまずいな」と感じた私はリーダーに掛け合ってAさんを私の下に付けてもらう事にしました。 当時の会社はかなり自由度の高い扱いを認めてくれていたので、正社員でない私にもそのような形を認めていただけました。リーダーさんは既に匙を投げていたので丁度良かったのかもしれません。私と彼は考え方が違うので、私も結果を見せるしかないと考えていました。

トレーニング

基礎

まず本当に簡単なプログラミングをしながら理解度を上げて行きました。コンソールから動かせる簡単なコードを何度も書いたり、ファイルに出力するCSVの扱いなどを学んでみました。

そうする中で効果的な関数の使い方、コレクションクラスの理解などを勉強しています。勤勉な彼だったので、私からの提案に応えようとよく努力してくれました。「ここで結果を出さなければ会社を出て行くしかない」と本人も感じていたのでしょう。確かお盆休みの間も「宿題としてxxxを勉強してきます」という意欲的な生徒でした。

題材

少し学んだところで社内で利用するツールを作成する提案を会社にしました。当時社長が欲しがっていた「製品が売れたことがパッとWEBで見てわかる」というものでした。仕組みは忘れてしまいましたが、CSVのファイルでinputを行って、グラフにアウトプットするものでした。ポイントとしては下記を意識しました。

• なるべく仕様が小さいこと
• 皆の目に触れるもの（改善要求が出やすい）
• 利用シーンの明瞭なもの

私の意図としては下記です。

• これまでの練習が活かしやすい要素技術でできていること
• 成果を会社のメンバーに見せることができること（成長を感じ取ってもらえなければ次の仕事は貰えないと考えた為）
• 設計が分けやすく、彼の仕事の単位を小さくできること

実装

流れとしては、下記のような形でした。

1. なるべく小さな単位で関数を私が切り出す（全てユーティリティクラスの関数です。オブジェクトをマスターさせるのは早いと思っていました）
2. 仕様を彼に伝えて実装してもらう
3. テストはコンソールへの出力で行う

結合はバラバラに作られた関数を繋げるロジックを書いてもらうことでした。「ちゃんと繋がって、魔法みたいだ」と言われたのを覚えています。関数へ切り出された部分を実装している間は彼には全体が見えていなかったので当然かもしれませんが、慣れた私たちにとっては当たり前のことですよね（＾-＾）。

結果

そうしてこのプロジェクトは成功して、確か一ヶ月程度で望むものが完成し、リーダーなど周囲からフィードバックを得て改善してゆくような形も取れるようになりました。プロジェクトの担当者としてのポジショニングと、少しは書ける人となったことが自信に繋がり、リーダーの元へ戻って行きました。

「あの時声かけてもらえなかったら辞めてました」

と、何かのタイミングで聞いて、うまいタイミングで行動できて良かったなと思いました。このことを通してリーダーの考え方にも変化が見られ、成長を促す方法について色々と考えてくれるようになった事も成果になったと思います。その後リーダーさん自身も人を育てる分野の会社に一時期身を置くことになるのですから、世の中わからないですね。

その後

その後は私の直属ではないものの、朝飯を食べながらAさんの作業を見つつ、抱えている問題のヒアリングと解決への糸口を伝えることはしていました。暫くして私は現場を離れることになったのですが「もう大丈夫だろうな」と感じていたのを覚えています。

一年もするとリーダーの右腕として信頼されるようになったと聞き、本当に嬉しかったです。

おしまいに

最初に学んだことだけで自分の実になって活躍できることは少ないと思います。ですが、諦めずに積み重ねてゆくことで成長できるのではないでしょうか。一度は現場で匙を投げられてしまうようなAさんでも、信頼を勝ち取る技術者になれる道筋があるということです。

私はそれまでにもOJTで何人か面倒を見ていましたが、Aさんとの体験は今のマインドや方法に強く残っている出来事です。私はただそれを何度も繰り返したくて今の仕事を続けているのかもしれません。

Aさんのその後はわかりませんが、良い体験や出会いをして現場で活躍されていることを祈っています。

世代の断絶を防ぐことが知識の継承に繋がるのかもしれない

blog.tinect.jp

ここで言っているのが経営者の様子なのでしっかり主題を捉えられているかちょっと難しいですが、ここ最近私に相談してくれた方の内容に似たようなケースが複数ありました。プログラマとしてキャリアをスタートして、その後マネージャとしてある程度のキャリアを積んだ方の中に、下記のような状況の方がいらっしゃる様子です。

• 最近の開発のトレンドはキーワードレベルや概念レベルでは理解している
• 実際に実践するレベルでは理解できていない
• 現場の人達を自ら育てることがちょっと難しい

私と同じくらいの年齢かそれ以上くらいの方なので、業務系の開発が多かった時期にキャリアをスタートして、その後WEB系の流れが目立ってきた頃には現場を離れてマネージをしており、最近WEB系の現場を見るような立場になった、というような足跡である様子を伺っています。

• GitHubや外部のCIを活用するような開発
• クラウドを利用するインフラ
• アジャイルな開発

というようなところがネックになる様子です。本来は世代の隔絶が無ければ少し上の先輩が間を埋めてくれると思うのですが、これが問題になるような場ではその間の世代が何らかの理由で抜けてしまっているのでしょう。

組織で物事を進める際のアドバンテージの一つは「集団でいることによる過去の知的資産の継承」だと思うのですが、それが難しくなっているということかと思います。工夫すれば現場の若い人たちが自ら学んでいく形を推進して物事を進めることができそうですが、これでは求められているスピード感に追いつけない、という事も多いのでしょう。

ノウハウの陳腐化が加速した結果だと思うのですが、ある程度世代の断絶を防ぐことがこういった問題を防ぐことに繋がりそうに思いました。組織は少人数で組み立てたいですが、このような視点も大事かもしれないと感じました。