生放送で無料授業を受けれるschooで、『新人エンジニアが知っておきたいアジャイル開発』というお題で、授業をする機会を頂きました。
この授業では、ウェブサービスやアプリの開発に携わる新人エンジニアの方を対象に「アジャイル開発」についての概要と、実際の事例を元に学ぶことが出来るようにお話したつもりです。以下が、そのときの資料です。
この記事では、授業の後半でお話しした内容から、新人エンジニアが今後アジャイル開発の現場で求められる姿勢について、改めて書いてみました。
アジャイル開発に限らず、エンジニアとして優れた人は、エンジニアリングをマスターしていることは大前提として、その上でビジネスや世の中に対して成果を出しています。
これまで多くのエンジニアの方と知り合って一緒に仕事をしてきた経験から、そうした人たちが持っている共通の姿勢を５つ洗い出してみました。
目次
当事者意識を持つ
これはエンジニアに限らず、ビジネスパーソンにとって大事なポイントでもあります。当事者意識を持つ、というと難しく思えますが、クライアントから依頼されたことをただそのまま実現するのではなく、「そもそも」から考えることが大事だということです。
エンジニアとしては、クライアントから欲しい機能があると言われたら、それを実現してあげたくなるのはわかりますし、それが仕事であると言えばそうです。しかし、その作ろうとしているものが、なぜ必要なのか踏み込まなければ、本当の満足は得られません。
欲しい機能について相談を受けたとき、そもそもその機能は何故ほしいのか、を聞くのです。そして、そもそもの問題を確認した上で、いくつかあるアプローチの中から最適な解決方法を提示することで、本当に欲しかったものが手に入ります。
逆に考えると、依頼をする側は、エンジニアに対して解決手段で話をするのではなく、問題で相談すべき、ということです。そして、解決手段を考えるために、ビジョンやコンセプト等の共有は欠かせません。
エンジニアは作り手である前に問題の解決者であるべきです。そのため常々、そもそもから考える癖をつけることは、エンジニアにとって重要な姿勢の一つです。
保守性を重視する
作り捨てのソフトウェアでなければ、ソフトウェアの改修や修正は、動かし始めると必ず出てきます。むしろずっと直していけることがソフトウェアの良い特性なはずです。そして、作り直していくときに重要になるのが、どれだけ直しやすいかという「保守性」です。
ソースコードの保守性は、DRYを意識することで実現できます。DRYは、”Don’t Repeat Yourself”の略で、重複をしないという哲学を表しています。プログラミングをしているとコピペ（コピーアンドペースト）で作りたくなるときがあるでしょう。似たようなことを実現するために、以前にやった機能からコピーして持ってくればすぐに出来ると思ってしまいがちです。しかし、それは破滅への第一歩です。
同じソースコードがコピペであちこちに散らばっているとしたら、もし最初の箇所でバグが見つかったり、機能改修をしたいときに、コピペで作ったところを全て手直ししていかなければいけません。人間のすることなので、いつか必ず見落としが生まれます。そうするとコピペで作っていた部分がバグの温床になって、障害を引き起こすことになりかねないのです。
なので、コピペをするのではなく、共通化やメソッド化を行うことによって、DRYなソースコードにしていくのです。共通化するためにはリファクタリングが有効で、そのためにはテストコードが必要です。そうした技術的なスキルも必要となってくるのです。
単位を小さくする
ソフトウェア開発では「遅巧よりも拙速」であるべきだと考えています。これもソフトウェアならではかもしれませんが、作りながら動かしながら確認することができるのがソフトウェアです。早いフィードバックのために「作業の単位を小さくする」といいでしょう。
そのために、どんな物事もサイズを小さく細分化することで実現できます。コミュニケーションの単位が月に一度しかないとしたら、その内容は非常に重厚なものになって、準備も大変になるでしょう。しかし、毎日顔をあわすのであれば、そのための準備は気軽なものになるはずです。
たとえば、ソフトウェアのリリースも半年に１度だったりすると、そのリリース作業は非常に慎重にすることになります。過剰に慎重にしすぎることで無駄なコストが発生してしまうことは往々にしてあります。これも、毎週、毎日、いつでもリリースをすることを続けていくと、その作業が日常になります。慎重さを失ってはいけませんが、過度にコストをかけすぎることはなくなりますし、そのようにいつでも安心してリリースできるようにするために工夫をするようになるのです。ベクトルが変わるのです。
様々な作業を小さくしていくことで、それぞれにかかるコストを下げて、習慣にしていくことが大事です。良い習慣は続けていきたいものですが、習慣にするためには気軽でなければ続きません。単位を小さくし、良い習慣を続けていけるのが優れたエンジニアです。
なるべく作らない
優秀なエンジニアであれば、何か機能を作るときに、どれだけ汎用的に作るか、ということを考えてしまうものです。最初に求められた機能を設計する時に、今後もこういう追加が来るかもしれない、この先はこういう拡張を求めるに違いない、と考えて、そのための仕組みを作ってしまうのです。そして、実際に予想した通りの機能を求められたときに、待ってましたとなる訳です。エンジニアとして気持ちのいい瞬間です。
しかし、それでは駄目なのです。偶然にも、予想した通りの要求が発生して、仕組みを活かすことができたとしたらまだ良いですが、そんな風に求められなかったらどうでしょうか。その事前に予測して作った仕組みは意味がなくなるのです。むしろ、その仕組みづくりにかけたコストが無駄になるし、ソフトウェアの内部に余計な複雑さを持ち込んだことになり、後からの改修が難しくなる可能性が出てきます。
本当に必要になるまで、予想で仕組みを作ったりしないようにしましょう。これはソフトウェアの機能設計にもいえることです。ユーザがきっと要ると言うに違いない、と予想で作り込んだところで、それが外れてしまったら、無意味になるどころか、操作も複雑なものになってしまいます。必要になるまで作らないということが大事です。
その精神を「YAGNI（ヤグニ）」という言葉で表します。YAGNIは”You Aren’t Gonna to Need It. （そんなの必要ないよ）“という言葉の略です。ついつい先のことを見越して、余計な心配や沢山つくりこみそうなときは、「YAGNIでいこう」というように声をかけるのです。
守備範囲を広げる
本当に優れたエンジニアは、クライアントの問題に対して様々なアプローチで解決手段を考えることが出来ます。そのための引き出しの多さがプロフェッショナルの証で、プロフェッショナルとは、その引き出しをずっと最新に保ち続けられる人のことを言うのでしょう。
自分の出来ることや与えられた役割で、自分の仕事を限定してしまうと、それは自分の可能性を自ら狭めてしまうことになってしまいます。得意領域は持つべきです。しかし、そこだけに固執し続けると、そのエンジニアはただの手足になってしまいます。
ビジネスやビジョンに対して貢献するという姿勢を持つことが大事で、そのゴールを達成するためにはどんなことも厭わずに取り組んでもらえたら、クライアントや一緒に働く人たちは、頼りになるエンジニアとして接してくれることでしょう。
DevOpsという言葉があります。開発と運用が協力しあうというのは当たり前のことで、それぞれの守備範囲を決めつけなければ、そもそもそんなことを言い出す必要すらないのかもしれません。
たとえば、私たちの実践する「納品のない受託開発」では、お客さまとのビジネスの話から、ソフトウェアの設計とプログラミング、クラウドでのサーバ運用まで全てを一人でこなします。お客さまとの入り口から出口までを分業をせずに一気通貫で同じ担当者が実施することで伝言ゲームを無くして、無駄を最小限にすることを実現しています。
それだけの幅広いスキルをもったエンジニアなんか、なかなかいない、と思われるでしょう。たしかに誰でもかれでも出来る仕事ではないと思いますが、私はソフトウェア開発とはそもそも、誰でもかれでも出来るものではないと思っています。
プロフェッショナルとは何か、と考えたとき、たとえばドリブルだけしか出来ないプロのサッカー選手はいないのです。基本的なスキルはすべて持った上で、得意なポジションで働く訳です。とはいえ、誰しもが最初からすべて出来るかというとそうではないし、スキルの中でも得意不得意はあるはずです。そうしたところを学び合い、補い合えるのが、会社やチームという場所の価値になります。
仲間との切磋琢磨の中で、自らの守備範囲を広げていくという姿勢を持ち続けているエンジニアは、いつか優れたエンジニアと呼ばれるようになるでしょう。
