チームで仕事をする上で気づきの機会を提供することが大切であると考えているのですが、では新人の技術者には何を気づかせるべきなのでしょうか。基本的には以下だと考えています。
- 目的を忘れないこと
- コミュニケーションの大切さとその理由
- 作ったものがどう使われるか想像する必要性
- 日々の学習がなぜ必要なのか、危機感を持つこと
まずそれぞれについて「何に気づくべきか、なぜ気づくべきか」を述べ、次に「そのためにどのような機会を作るべきか」について述べます。
気づくべきこと
目的を忘れないこと
技術者とは技術のエキスパートであり、技術とは問題解決のための手段です。ゆえに技術者は問題解決のために自分の技術がどう活きるか、どんな技術をどう組み合わせるのかを考えなければなりません。 流行や新技術もいたずらに追うのではなく、なぜ今それが流行なのか・既存技術と比べての利点や欠点は何なのかを咀嚼し自分なりの解釈を作った上で日々の業務に適用していく必要があります。
もちろん技術は理屈抜きに面白いものですし、問題を解決するために技術を学び始めた人はむしろ少数派でしょう。
しかしプロとしてビジネスとしてお客様や課題と接する以上、なぜお客様は我々に対価を払っているのか？なぜチームは自分をここに置いているのか？を考えると、この「目的」が非情に重要であることは疑いありません。この意識こそがプロとアマの違いと言っても過言ではありません。
締切厳守、体調管理、報連相、例外系想定やBootlegging（スカンクワーク）も目的を考えることでその重要性を認識できます。
コミュニケーションの大切さとその理由
私の場合、チームの存在こそが仕事と趣味の大きな違いでした。サービス運用も障害対応も自作ライブラリの保守や要望対応も趣味でやった経験がありますが、どれも個人で完結していたものでした。仕事にはコミュニケーションが必要不可欠であり、コミュニケーションこそが成否を決める要素であるという価値観はここから来ています。
また、ビジネスが多くの場合複数名で行われることも見逃せません。規模の違いはあれど、複数名が役割を分担するからこそ可能になること、1人では調達できない資源や時間を使ってこそ実現できることがビジネスです。
お客様は自分でもうまくできることには対価を払いません。自分ではできないこと、やれるかもしれないが最善手ではないことをプロフェッショナルに委ねるために対価を払うのです。それらは1人で解決可能な課題ではないことがほとんどでしょう*1。
複数人数だからできること、それは作業の並列化・平行化そして専業化です。開発において、parallelとconcurrentが難しいことと役割の明確化が重要であることは、常識です。技術者がチームの存在意義を追求すると、必ずここに価値を見出すでしょう。そして自分がどの役割を担うべきか、他のメンバーにどう情報を渡すべきか、どう情報を取りに行くか、そして全員でビジョンと問題意識を共有するにはどうすればよいかを考えていくことになります。
作ったものがどう使われるか想像する必要性
「プロフェッショナルとアマチュアの最大の違いはねぇ、例外処理だよTODA君。」とは私の元上司の言葉です。私もこれに同意します。
学生のコードや新入社員のコードを見ていると、必ずといっていいほど、例外を握りつぶすcatchブロックに出くわします。なんでこんなことするの？と聞くと、ほとんど「IDEが補完したので」とか「えっ、どういう意味ですか？」とかそういう言葉が帰ってきます。事の深刻さがわかっていないのですね。本番環境でここに到達した場合に、どのようなトラブルになってしまうのか、という想像が働かないのです。
例外の扱いはそれだけでブログ記事が3-5本書けそうなくらい面白いのですが、ここではそれは割愛して良書にその役割を委ねることにします。例外のひき逃げ、すごい大切です。
コーディングの掟(最強作法) 現場でよく見る不可解なJavaコードを一掃せよ! (開発の現場セレクション)
- 作者: arton,宇野るいも
- 出版社/メーカー: 翔泳社
- 発売日: 2008/09/18
- メディア: 単行本（ソフトカバー）
- 購入: 29人 クリック: 348回
- この商品を含むブログ (55件) を見る
例外だけでなく、ログも想像力の欠如によって悪い使われ方をされます。System.outが散らばっていたり、ループ内部でINFOレベルのログを出力していたり、肝心のメッセージが無意味で何の追跡もできなかったり。
ログのポリシーはチーム開発ではすごく重要ですが、その徹底と浸透は非常に難しいものです。最終的には各開発者の想像力に頼らざるを得ないことが多いでしょう。
日々の学習がなぜ必要なのか、危機感を持つこと
最近の新人を見ていて思うのは、勉強は得意なのに勉強を始めるのがものすごい苦手なんだな、ということです。課題を探すのが苦手っていうんでしょうか、授業や講義みたいな機会を与えられてはじめて勉強するって感じです。自発的に技術の道を歩み始めた自分からすると、奇妙そのものです。
日々の学習が必要な理由は、技術者であれば必ず知っています。技術は日々進歩し、陳腐化します。昔の常識が今の非常識になり、今の常識が未来のブレークスルーを邪魔します。また技術は手段であり、目的である「問題解決」のための業務知識も必要です。これもまた進歩し、陳腐化します。
学びに終わりはありません。海辺で砂山を作るがごとく、繰り返してはだめになり手法を確立してもなお他の方法を試すのです。
これは一見すると儚く滑稽かもしれませんが、2つだけ陳腐化せず変化しないものがあり、技術者はそれらを知っているからこそ儚い短命な技術を学習しつづけることができています。
1つ目は変化そのものです。ものは陳腐化する、変化する、という事実を受け入れてしまうことです。この事実を受け入れるチームとそうでないチームには、製品の質に大きな違いが出てきます。変える勇気、捨てる潔さを持って初めて製品は真に永く使われ愛されることができるのです。
2つ目は学び方の個性と熟練度です。砂山とひとくちに言っても、作り手によって頑丈さ・高さ・幅・数そして作る速さは大きく違ってきます。ある人はすばやく新技術の表層を理解して物を作ることができます。ある人はひとつの概念を深く理解し、それに立脚する新技術をすぐに自分の中に取り込みます。ある人はアンテナが高く、誰よりも早くその存在と背景を知ることができます。もちろん彼らにも拙かった時期もあったでしょう。学習を続けることで知識を蓄積し手法に熟練し、新たな技術への対応力を高めていったのです。ここにも継続の重要性が現れています。
どのような機会を作るべきか
以上で、経験の少ない技術者に対して
- 目的を忘れないこと
- コミュニケーションの大切さとその理由
- 作ったものがどう使われるか想像する必要性
- 日々の学習がなぜ必要なのか、危機感を持つこと
を気づかせることの必要性を説いてきました。ではどのようにしてその機会を作るべきなのでしょうか。
コードをレビューする
どなたが仰った言葉だったか、「ソースコードは1行1行がbusiness decisionだ」という考え方があります。まさにその通りで、コードの1行1行には技術者の想定、理想、目的意識が明確に現れます。足りない部分が如実に浮き上がるため、1対1での会話のきっかけを作るのにかなりふさわしい場です。
コードレビューというとバグを見つけたり命名やインデントに口を出す場と思っている方がいらっしゃるかもしれませんが、そういうのはもっと事前に機械的に行うべきものでレビューでやるのは非効率です。レビューでは拡張性、保守性、性能、運用可能性といったコードの行間や背景、全体像から見える問題に対して建設的な議論と改善を行うべきで、そのためには技術だけでなく業務想定や運用想定、イレギュラーへの対応といった知識と意識をチームで共有されている必要があります。逆に言うと、知識と意識が不足している技術者を察知する場として使えるということです。
ただしレビューでは気付きの場を作りきれなかったり、その効率が悪かったりすることもあります。その場合は別途1on1や雑談、教育的ペアプログラミング*2を実施すると良いでしょう。技術者同士、技術屋コードについて語り合う機会というのは間違いなく面白いですし、ぜひとも作っていきたいものです。
理想や存在意義について語る場を作る
ビジネスやチームの全体像が見えるには時間が必要です。会社規模と日常業務によっては、3年経ってもまだ見えないということもザラにあるでしょう。3年間もの長い間、仕事の基礎である知識と意識が欠落してしまうのは非効率です。理想像や存在意義を理解しない状態でそれをうまく利用したり改善したりするのは不可能だからです。
営業は案件をどう探して持ってくるのか？営業は何をしたいのか？コンサルは何がやりたくて開発とコンタクトをとるのか？その現状は理想的なのか？問題の根本はどこにあるのか……。
これは営業やコンサルを紹介して交流機会を作り探らせるよりも、さくっと資料作って説明してしまうのが早いようです。紹介するとしても組織構造やその背景を理解させてからのほうが、その後の交流の効率も上がります。新人が配属された直後というよりは、日常業務に慣れた半年〜1年後に実施するのが吸収が早いです。
これをやると、単純に「報連相重要！」とか言うよりもずっと報連相してくれるようになります。やはり理由を知らないと、儀礼やテクニックとしてしか見ることができず、真の実践は難しいのでしょう。
もちろんビジネスや問題解決といった大枠だけでなく、チーム・製品・運用・技術者などの理想を語ることも大切です。理想が共有されていない状態では、各個人がそれぞれの姿とプライドを持ってしまい助け合いがうまくまわりません。優れた技術者はアクが強いことも多く、プライドのぶつかり合いは互いを傷つけることになりかねません。
私の場合「理想のチーム像」を語ったことがありましたが、それからは各個人が自分の役割だけでなく他者の役割を理解して能動的に活発に動くようになりました。また「今のやり方では彼が溢れてしまう、私の時間の一部を彼のヘルプに割いて良いか」というようにマネージャ（私）の失敗を助ける動きもありました。これもマネージャのやり方、考え方がわからない状態では原因特定まで動かなかったり「何考えてるんだかアイツは」と見放して終わったりするケースが多いのではないでしょうか。
全員が同じものを理想とすることは不可能でも、同じ理想をビジョンとして共有することは可能です。そしてビジョンを共有するからこそ、各自が自分の役割を理解しまた他者を助けることもできるのです。部下がマネージャとしての視野・視点を持ってくれないと思ったなら、まず自分の考えを伝えてみても良いかもしれません。
継続的な学習の場を作る
自発的に学習しない人に対して、学習が足りないから土日に勉強してこい、というのは無理です。就業時間中に機会を作る必要があります。
時間を作るなら、出社直後30分から1時間くらいが良いでしょう。昼食後は眠くなりますし、夕方は差し込み案件やミーティングが入るかもしれません。それ以外の時間はせっかくの集中を阻害する可能性があります。朝なら差し込みもなく、また頭も最もすっきりしていますので丁度良いです。強制はできませんが、就寝前にちょっと復習するとベストかと思います。
勉強の内容は資格勉強でも良いですし、輪講、読書、講義、LT、発表、お客様を迎えてのヒアリング、何でも良いです。様々な技術が使われるチームでは、隔月で最近の自分の業務で使った技術をプレゼンさせても良いでしょう。チームの技術知識を底上げし、技術者の流動可能性を高めることにも繋がります。
大切なのは、最適なやり方は各個人で異なるということです。まずは習慣を作るべく一斉に行える輪講や講義から初めて、徐々に各個性に合わせたやりかたに分化させると良いのではと思います。
自発的に学習する人であれば、その人のアンテナに引っかからない情報や技術、ニーズを適宜渡してあげればいいでしょう。これは日頃の雑談でカバーできます。
「今君が学んでいるこの技術はね、今海外ではこういう使われ方をしていて、既存技術の課題だったあれを解決することでビジネスの可能性を一気に高めたんだよ」というひとことだけでもテクニカルなことしか見ていない人には面白く響きます*3。逆にビジネス面しか見えていない効率の悪い実装をしてしまう人には「なるほど、確かにこのアルゴリズムでは君がやりたいことが実現可能だね。でもここでこんなにメモリ食っちゃうね……先行事例ではどう解決したか調べた？」と言うだけで良いのです。
学習というのは、極論すると、未知との接触です。相手の普段の発想を理解してそれとは違う方向にあるものを提示し、相手がそれを咀嚼する機会と手順を整えれば、それで立派な教育になります。
もちろん上記の施策は学習の必要性を認識した後でないと意味がありません。またやり方を間違えるとウザい人になります。必要性を認識させ、やり方と環境を整え、耳を傾けてもらえるような信頼を得てはじめて成功する可能性が出てきます。
教育というのはそれだけ難しく、またそのコストを払ってでも実践すべきほど大切なものなのです*4。
まとめ
以上で、経験の少ない技術者には気付きの機会として
- コードレビューと、それを起点にした1on1
- 理想や存在意義について語る場
- 継続的な学習の場
を作るべきだという持論を展開しました。実際この2年間で使ってきて、実用性はそれなりに立証されてきたものです。「入社してから初めて技術に触ります」という人には未実践ですが。
こうした機会を作っても有効活用できない人はいますし、銀の弾丸ではありません。また私とは異なる技術者像・チーム像を理想とする場合はまた異なる手法を追求すべきでしょう。
