システムを作れるようになる為に少しずつこなそう - 島までは遠い〜サークルアラウンド株式会社代表佐藤のブログ〜

f:id:ms2sato:20160108223033j:plain

はじめに

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

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

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

Aさんという人

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

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

ヒアリング

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

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

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

アプローチ

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

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

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

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

トレーニング

基礎

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

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

題材

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

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

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

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

実装

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

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

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

結果

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

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

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