ブリッジSEとPMとオフショアと

ブリッジSEをやった経験を少し記事にまとめて後悔公開してみたのですが、

racchie.hatenablog.com

その最近Twitterにこんな投稿があって盛り上がってるよ、というのがありました。

togetter.com

今さらながらこれを見てわかりみ、というか、身につまされるところが多かったので、少し散文的ではありますが実際の例を上げつつ掘り下げてみたいと思います。

外国人が「言われたことしかやらない」のは本当か

そもそものTwitterの書き込みを引用してみますが、

という話は、よく言われるし、オフショア開発の管理の経験上、総論としてはこれは事実であると言っていいと思います。

ただし、逆説的に言えば、彼らは『言った(頼んだ)ことは必ずやってくれる』ということでもあります。一部例外がありそうな気もするのですが、基本的には「頼んだら必ずコミットする」「頼んでいないことはやってくれない」という考え方で正しいと思います。

ここで注意しなくてはいけないのは、彼らは「頼んでいないことはやってくれない」という言い方。ニホンゴムズカシイネ。

『言われたことしかやらない』という言葉を文字通りに取れば、指示通りのこと以外は絶対にやっていない、と言う意味になりそうですが、おそらくこの発言をした(元ソースである)みずほ銀行の頭取だかの発言には言外に「言われなくてもわかるでしょ、ということも気付いてほしい」と言っていると思いますし、そう言う意図をもってこのような発言をしたのだろう、と思います。

言われなくても分かる、という言葉にもいろいろと意味を含んでいると思いますが、「暗黙の了解」と、「現場の共通認識」は私も躓いたところですので、経験を含めた考察をまとめてみます。

「暗黙の了解」

外国人に限らず、私たちフリーランスエンジニアが現場に入って最初にぶつかる壁ではあります。「暗黙知」と言い換えてもいいのですが、よくある「え?そんなことも知らない(でやってる)の?」というヤツです。

エンジニアが躓く一般的な「暗黙知」として挙げられるのは、例えば開発するシステムをどのような使い方をするのか、という、業務知識と呼ばれるものです。ECサイトを例にとれば、商品の購入時にどのような支払方法を選択できるのか、というのが挙げられるでしょう。

商品を購入する場合に、支払方法として代引きと口座振替、クレジットが選べると仮定します。その商品を購入するのはもちろん購入者なのですが、その購入した商品は必ずしも購入者の手元に届くわけではありません。いわゆる「ギフト(贈答品)」として商品を送ることが考えられるわけですが、もし商品を自分のところには送らずに、ギフトのみの注文とした場合に、支払方法を代引きにすることはできない(してはいけない)はずです。だって贈り物ですから。贈り物なのに送った先に「この贈り物は代引きです」っておかしい話ですよね。

しかし、システムの使い方(使われ方/ユースケース)がわからないと、商品の支払い方法が設定されていればその通りに設定してしまうわけです。贈り物なのに代引き設定をしてしまう。これは本来要求仕様や設計に明記されなければいけないはずですが、「そんなことはわかってるでしょ」という暗黙知があるからこそ起こりうる問題です。

「現場の共通認識」

業務知識と異なり、現場における共通認識はより「形式知」化させやすいはずなのですが、そうなっていないことで暗黙知化してしまうことが多いのですが、コレは基本的に「形式知化するためのリソースが足りない」といった理由で起こります。あえて暗黙知と分けている理由は、この形式知化しやすいかどうか、という点にあると考えています。

コーディング規約は現場共通認識の最たる例だと考えています。私自身は普段小さいプロジェクトで一人でコーディングすることが多いので意識することもないですが、大きなプロジェクトで複数のメンバーが並行して開発している場合は多少規約、というか簡単なルールを決めておかないと結合テストレベルでの不整合が起こったりするので軽く取り決めをすることはあります。

他にも、「ターミノロジー(専門用語)」も現場共通認識に含まれると思いますが、特に専門用語に関しては、世間一般で使われる言葉の意味と現場で使われる言葉の意味が異なるケースがあることに注意が必要でしょう。

また、元ネタであるみずほ銀行などのケースだと、現場における危機感といったものも共通認識として持っているのが一般的だとは思いますが、外部メンバー、特に外国のメンバーはそう言った現在の状況や過去の歴史などを知らないこともあるでしょうから、危機感の共有は明示的にしないといけなくなるはずです。

「言われなくても分かる」から明文化へ

ざっくりと暗黙知の話としてまとめますが、言葉も文化も違うしわからない人たちと仕事をする上で、「言われなくても分かってほしい」というのはそもそも難しいのです。もちろん、今回の元ネタの発言がどの程度の職位の人が言ったか、にもよるとは思いますが、仮に危機感を共有するレベルでこの発言に至ったのだとすれば、この発言をした人は責任感のない人、責任を他人になすりつける人、という印象を持たざるを得ないですし、オフショアという話に限定すれば、この状態でのオフショア開発はおそらく上手くいかないはず。

もちろん、他人事の逆の意味での「自分ごと」として考えて欲しい、という現場へのメッセージだとしても言葉足らずです。そうではなく、自分ごととするためにどうするのか、という具体的な方法がない。頭取レベルならそれでもいいですが、これが技術畑のトップの発言だとしたらたぶんイケてないです。

みずほ銀行をけなすための記事ではないので話を本筋に戻しますが、暗黙知が多ければ多いほど伝言ゲームが上手くいかなくなるのです。だとしたら、業務知識やターミノロジーなどをどのように明文化していくのか、また、システムの全体像などについてもどこまで詳細に明文化されているかなど、初めてジョインする人*1が資料を見て内容を理解できるように仕組みづくりをすることがオフショア開発では大切だったりします。

マネジメントスキルの違いとか

マネジメント論というかマネジメントスキルというか、そう言う違いもあるのだろう、と思うのですが、私自身実は海外の上司というものを持ったことがないので、海外のマネジメントがどのようなモノになるのかわかりません。そのうえで、経験や書籍などから得た知識をもとに「こういうモノなのではないかな」ということを探ってみます。

前項でも触れているように、そもそも暗黙知があるということを前提にすると、マネジメントの立場から言えば「これは言わなくても分かるはず」という一種の甘えみたいなものは生じるはずです。それ自体は日本固有の問題だとは思っていないですが、そう言った問題をできるだけ生じさせないようにしたいと考えるのが海外(欧米?)の考え方なのではないかな、と考えています。

ただ、そう考えると、それは「マネジメントスキル」なのか?という疑問もわいてきます。Togetterで見ると元スレに対してのレスにマネジメントスキルとしていくつかキーワードが出てきていますのでその中で出てくる「指示」「管理」「属人(化)」というキーワードを使ってもう少し深堀してみたいと思います。

適切な指示を出す?

このキーワードはかなり正論というか、コレが大切なんだな、というのがBSEとして仕事をしているうえで気を付けていることなのですが、指示があいまいになることは確実に成果物に影響を及ぼします。よくある例えとして、地図が間違っていたら違う場所に着いてしまう、というのがありますがまさにそれです。ただ、地図が間違っていたとしても、「暗黙知」の存在によって情報の補正がされることもある、ということは事実です。

先ほどの例と同じくECサイトを例にとりますが、暗黙知として「購入者の住所に送る商品が存在しない場合には代引き支払いをしてはいけない」ということが、顧客と開発者の間で共有されているのであれば、「ではどのような条件で支払方法の制御をするのか」という話題が生まれるし、それを設計なり要件定義なりで明示すればいいのですが、暗黙知が共有できていなければ贈り物を送る先で支払いをするという事態が起こってしまうわけです。

どちらがいいのか、暗黙知形式知化してあらかじめ情報共有をするのか、その都度開発要件としての指示を出すのか、これはケースバイケースだとは思いますが、いずれにしても指示を出すときに明確であることは必須です。

適切な「管理」をする?

私自身はあまり「管理」という言葉を多用するのが好きではないのですが、そもそも「管理*2」とは何をすることなのかが明確でないし、これは日本固有かな、という気もしますが、かなりあいまいな定義で使われるケースが多いと思っています。

だから、というべきなのでしょうが、いわゆる管理職の人たちがきちんとした「管理」をしない、またはできない、という問題が起こるのではないかな、と思います。海外(欧米)との差異として、マネジメントを専門的に学んでマネジメントスキルを取得する欧米的な考え方と、現場たたき上げのマネージャーが多いという日本という図式を示していた方もおられましたが、いわゆる「管理」のやり方が画一的ではなく、いかにも日本的な「背中を見て仕事を覚える」やり方が、マネジメント層のレベルの低さにつながっているのかもしれない、とは思えます*3

自分の例をあげるのは失敗例になってしまいそうなので少し心苦しいですが、「マネジメント」の仕事をする時には業務の隙間が相当できることが多くなることから、かなり容易に「あぁ、他の業務も兼務しますよ、できる範囲で」と請け負ってしまうことが多いのですが、それによってマネジメント業務の抜け漏れが発生することは結構あったりします。できるだけそうならないように、とは思っていても、やはり自分自身のスキルの足らなさを感じることは多いです。

「属人化」は適切ではないのか?

この手の話題の中で必ず出てくるのは、「属人化傾向が問題」という話。業務が属人化すること自体は私も好ましいと思っていないのですが、かと言って、誰でも同じレベルで仕事ができるように、というような意味あいでの「非属人化」を目指そうという方向性に向かいがちなのが日本っぽい気がしています。

マネジメント業務のところでも触れているのですが、マネジメント業務は他の業務と異なるスキルセットが必要になるという理解をするとすれば、同様にエンジニアスキルとしても全員がフルスタックエンジニアである必要はなくて、バックエンド専門、フロントエンド専門、DB専門、みたいな、特化したエンジニアスキルセットを持ったメンバーが結集したチームである方が作業効率がいいケースもあると感じています。

私自身は、自分の売り込みをするための謳い文句として「俺フルスタックエンジニアだもんね」と言うことはありますが、業務の内容によってはその一部のスキルセットだけで振る舞うことも当然あるわけです。PMという業務を例にとれば、PMとしてSQLを取り扱うスキルは、業務の一助にはなりますが基本的に使わないわけです。むしろ、どのように仕事を振り分けるか、どのように納期までのスケジュールを担保するかなどの業務を行うわけで、そのために「えっとこいつは確かバックエンドが得意だからこっちのタスク任せよか」とか考えるのがマネジメント業務なわけですからね。

あまねく教育をして、という話もあるわけですが、それをやりだしたら業務はいつになっても始まらないわけです。Laravelに慣れているからと言って、CakePHPベースの開発をするからとCakePHPを覚えさせるよりは、最初からCakePHPがわかっているメンバーを集めた方が効率がいいわけで、そんなことをするよりは暗黙知の明確化であったり、「常識」の共有のほうが先に行うべきことなのではないかと思います。

とは言え耳が痛い

では「おまいちゃんとできてんのかよ」と聞かれれば、もちろんできていないことも多かったし、結局プロジェクトの火消しをせざるを得ない状況に置かれてしまいましたし、結局、オフショアPMとしての経験が浅かったこともあり、できてないよなぁ、と思いながら元記事を眺めていました。

ただ、経験をして言えることは、

  • しつこいくらいにコミュニケーションをとること
  • 説明が足りないと後で血を見る(質問の嵐+成果物の不具合)
  • 「文化」の違いが意外に大きい

と思っていて、特に日本と海外のメンバーの中での認識の相違(フィットアンドギャップ)は早急に埋めないとかなり痛い目を見る、ということは感じました。

どうすべきか、というのはそれぞれのチーム編成にもよるでしょうし、またチーム内のメンバーによっても異なると思いますが、どれだけギャップを埋めて一丸となって事に臨めるのか、というのがカギになると思っています。

結論がすごく日本的な言い方になっていますが、欧米的な「あくまでも仕事という関係性のなかでのビジネス的な関係性」の上に成り立つ、ただ的確な指示だけ出して仕事を全うしてもらう、というやり方よりは、よりチームとしての動きを持った方が仕事もやりやすいと思うんですよね。私自身日本生まれ日本育ちの純血日本人なので。「チーム」という考え方は世界共通ですしね。

*1:もちろん外国人に限りませんよ。

*2:「マネジメント」という言葉も同様に

*3:いわゆる職人の仕事の覚え方を否定するつもりはないですが、少なくともマネジメントスキルという部分においては適さないという意図です。

ブリッジSEという仕事について

私自身は今(表向きは)やっているわけではないのですが、プロジェクトマネジメントの業務の中でいわゆる「ブリッジSE」としての業務を立ち位置として遂行することがあります。海外のプログラマなどと話をしながら製品開発を実施するのですが、コレが思っていた以上に難しい。プロジェクトマネジメントとはまた別の難しさがあるのですが、少し深掘りしてみたいと思います。

言葉の定義:ブリッジSE

ja.wikipedia.org

和製英語だったということに今さらびっくりしていますが、特に今回は第一言語(母語)の異なるエンジニア集団の取りまとめを行ってプロジェクトの遂行を行う人、という定義にしておきます。

いわゆるオフショア開発を行う際の現地メンバーとの橋渡し役です。

ブリッジSEに求められるスキル

システムエンジニア的な感覚で言えば、「SEの仕事に英語が加わればOKなんだよね?」と一瞬思ってしまいますが、実際にやってみて「SE+英語」だけではよくないのだな、とすぐに感じるようになります。よくありがちなフォーマットに則りながら細かいスキルについて説明していきます*1

「高い」語学力

母語が異なるメンバーを束ねるうえで、共通となる第2言語を駆使する必要がある、というのはなんとなくイメージが湧くとは思うのですが、ネットの記事だと、「基本的な読み書き」に加え「システム開発の専門用語」に特化した語学力、と書いていることが多いです。なのですが、特に英語が共通言語として使える現場の場合、「システム開発の専門用語」についてはあまり問題がなかったりします。例えば、「作成したコードを毎日バージョン管理システムに登録する」という日本語は英語では「merge your working code to the version control system(VCS)」と、多少単語については専門知識が必要になる可能性はあるにせよ*2、わりと適当な英語でも通じたりします。

実務をしてみると、システムの用語よりも開発をするにあたっての仕様の伝達に苦労することが多いことに気付きます。次の項目になる「コミュニケーション」の問題と言ってもいいのですが、とにかく日本の仕様を英語にして伝える、しかもそれを漏れなく伝える、というのが実は一番難しいです。そのための語学力は、「基本的な読み書き」レベルだけでは到底足りません。日常会話ができるレベルである必要は決してないとは思いますが、ある程度会話が成立する程度の語学力は持っていないとそもそも伝達できません。

「とても高い」コミュニケーションスキル

この項目も、その辺のネット記事ではサラッと流していますが、コミュニケーションスキルは相当高い必要があります。言い方が悪くて恐縮ですが、「コミュ障」気味の人は無理です。必ずしも陽キャであれ、とも言いませんが、陰キャ、コミュ障の気があるとやっぱり難しいと感じると思います*3

一口に「コミュニケーション」と言っても、どうすればいいのかわからないと思いますが、実際にやってみても、『どうすればこの言葉の意味が伝わるのだろうか?』と考えてしまうことは多いです。

そこで、伝わるようにとにかくいろんな角度から話を投げてみる、というのが私自身がやっていたことです。正しい言葉なんてわからないし、文法やらなんやらを気にすることなく、とにかくある言葉(単語・フレーズ)について知っている(数少ない)英単語を駆使して理解をしてもらう努力をする。例えば「かぼす」という果物について外国人に説明する、という行為です。でも、いくら数少ない言葉を使って拙い言葉で伝えたとしても、「かぼす」が「ドラゴンフルーツ」と理解されてしまってはおかしいわけで、なんとか正しい言葉を伝えられるようなコミュニケーションをとるわけです。

エンジニア諸兄はここで「Google翻訳やDeepL翻訳の性能が~」と考えると思います。そのとおり。確かに翻訳の性能も高くなり、言葉そのものの意味は違ってないだろうと思うのですが、その言葉の意味合いが全く異なるケースが発生しうるわけです。例えば上記の「かぼす」の例。翻訳システムに通すと柑橘類の一種、と訳されるはずですが、「かぼす」の味や香り、使われ方などは当然翻訳されないわけです。そうすると、外国人は「かぼす」のことをレモン的なものか、それともオレンジ的なものか、と考えるはずです*4。システムに置き換えれば、『ここで「かぼす」を使う』というコードを書いた時に、その「かぼす」なる柑橘系フルーツは食べるために使われるのかがわからない。そのギャップを埋めるのが『コミュニケーション』になるわけです。

前項の「語学力」のところで、

ある程度会話が成立する程度の語学力

と書いているのがそれで、言葉を表面的に理解できればそれでいいのか、ということです。意味を理解させるためには会話(コミュニケーション)は必ず必要になるはず、と思います。

思っている以上にシステム開発スキルが必要

これは私の現場だけなのかもしれないのですが、海外のメンバーのスキルには偏りがあることが多く、いろいろと作業を頼める人もいれば「オレこっち専門なんであとわかんない」とか言われることもあったりします。そんな時に、業務の遂行を妨げるような彼らの専門外の要件に対してサクッと解決させるような仕事をせざるを得ないケースもあったりします。

ありがちなのは、DBが苦手なエンジニアがちょうど地球の裏側で働いている場合。DBのエラーが(現地の)朝イチで発生している、と言った時に、たまたま他のエンジニアが動けない、となった時にフォロー可能なのが自分だけ、と言ったことは起こり得ます。本当はそういった苦手分野をフォローできるようなチーム編成をすべきなのでしょうが(後述するマネジメント領域の話)、一応「SE」という肩書を持つ以上はその辺の作業もサラッとこなすことができる必要はあるはずです。

他にも、インフラ構築やコーディング規約、テスト技法などの知識も…、と言い出すと、結局のところはほぼほぼフルスタックエンジニアレベルで知識も技量も必要なんじゃないのかな、と思ったりはします。世の中のブリッジSEのみなさんは果たしてどの程度そのあたりを知ってらっしゃるのやら、気になります。

当たり前のようにマネジメントスキルが必要

ここで言う「マネジメントスキル」は、単純にプロジェクトのためのマネジメントだけではないようにも思います。自分自身のマネジメントもできる必要があります。

まずプロジェクトのマネジメントというレイヤーで考えると、上記のような私の現場であれば、海外のメンバーのスキルの偏りと作業アサインがリンクする必要があります。フロントエンド側が得意なメンバーにバックエンドプログラムを(メインで)書かせるのは効率が悪いですし、バックエンドが強いメンバーにフロントビューを書かせるのも時間ばかりかかってしまう。もちろん彼らもプロフェッショナルなので、「できない」わけではないにせよ、作業が終わるまでに時間がかかってしまう。

時間がかかる、ということがプロジェクト全体として何を意味するのかが解っていないといけない話だとは思いますが*5、それを抜きにしても作業の振り分けを見極める能力はマネジメントスキルの一つだと思います。

もちろんそれ以外にも「プロジェクトのマネジメント」で必要な事はたくさんありますし、それらを意識できていないとブリッジSEとしての仕事はできないように思えます。

そして、自分自身のマネジメントについてですが、例えば上記のような、ちょっとしたヘルプみたいなことは、それこそ上位レイヤーの職種の人たちは、本来はやるべきではない、という前提のもとに実施することが多いはずです。それは仕方ないし、それによって円滑な業務遂行ができるのだから問題もない、のですが、海外のメンバーを複数抱えることで起こるのは、「問題が発生したときの対応をいつやるのか」という話。国内であれば、業務時間内、または少し残業してでも、となりますが、海外のメンバーに関しては時差があることから、彼らにとってのコアタイムがブリッジSEにとってのコアタイムではないということが起こり得るわけです。

南アジア~アフリカ~ヨーロッパのエリアにメンバーがいる場合は、彼らのコアタイムは日本のブリッジSEにとっては夜の時間帯になります。その時間にクリティカルな対応をすべきかどうか*6。それをすればプロジェクトは円滑に進みますが自分は遅くまで働き続けることになる。

それだけではないにせよ、現場で他の業務も実施しているのだとすればもっと業務が多くなる。単純な話ではありますが、業務レイヤーとしてはかなりの作業が発生するはずで、それを逐一、しかも可及的速やかにこなす能力、というかセルフマネジメント能力はかなり必要なのではないかなと、思います。

ブリッジSEになりたいですか?

私個人的には「ブリッジSEはつらいよ」と言っておきます。

面白いとは思います。いや、面白いです。基本的にマネジメントの仕事の一環として考えていいので、マネジメント業務の側面での仕事として実施しているとより細かいマネジメントをしないといけないな*7、とは感じます。

特に、理解の違いというか、文化の違いも超えたところでの「分かり合える」感はかなり面白いです。システムの開発では当然開発するモノがあるわけですが、それが世界共通でも何でもない、とてもローカルなシステムを作る場合は、そのシステムのバックグラウンドにある「世の中の仕組み」というシステムを理解してもらわないとならない。これは実際にやってみないと分からないと思いますが、外国人メンバーにしてみたらそんな日本の細かい風習みたいなことは知らなくても生きていけるのに、私と仕事を一緒にしたことでなぜか日本(のある業界)の風習に詳しくなってしまっている、という状態。自分が逆の環境に置かれても楽しいな、と思えますが。

その楽しみが感じられるかどうか、がブリッジSEの本当に必要な資質なのかもしれないですけどね。

*1:キャリアアップ系のネット記事によくある感じを考えています。

*2:今回のケースで言えば「VCSバージョン管理システム」という単語がそれにあたります。

*3:私自身どちらかと言えば陰キャ・コミュ障属性の人間です。

*4:レモンですら、日本人と外国人の中で使われ方が違っていると思いますが。

*5:この場合はQCDすべての観点で問題があるわけですが。

*6:もちろんその対応を現地スタッフに依頼するのかどうか、という検討もできるわけですが。

*7:「マイクロマネジメント」という意味ではなく、きめ細やかなマネジメント、という意味あいが強い。

2022年の目標

あけましておめでとうございます。本年も何卒御贔屓のほど宜しくお願い申し上げます。

毎年、年末に総括をして年明けに*1目標の設定をしています。初笑いついでにお付き合いのほどを。

振り返り:2021年の目標について

目標の明確化ができていたので、それに対してきちんと評価ができるようになりました。少し成長したんですかね、ワタシ。

恥ずかしくないモノにはなっている

「コミットメントリスト」で別にいいとはずっと思っていますし、あくまでも私的な目標設定なのでコミットできたかどうかは最悪ネタになればいいや、という程度にしか思ってはいませんでした。そう言う意味ではまぁこれくらいの目標設定でも問題はないし、コミット率(意外と高いですが)もどうだっていいと言えばどうでもいい。

ただ、昨年会社を設立したことで、ある程度コミットできていないと問題があったりします。特に売上。仕事の売上については会社にいったんプールする(私は会社から給与をもらう)仕組みにしているので*2、会社がきちんと売上を出せるようにしないといけない。そう言う意味でもコミットメントリストをきちんと書いて、それを実現できるようにして行かないといけない、とは思います。

売上について

個人と法人合わせて450万円くらいの売上を見込んでいます。2021年の目標としていたのは550万円ですが、当時見込んでいた案件の失注が相次いだため(200~300万くらいは失注している)、それなりの未達率(82%)です。また、2020年の目標(400万)から見ても85%ですので、まだまだ全然、と言ったところ。

今年の目標については(例年通り)後述しますが、例年売上見込みの甘さがかなりみられるように思えます。このあたり、反省しなくては。

目標:覚えたいこと

売上があまり伸びていないと言っても、忙しさはそれなりに忙しいのでなかなか勉強をする時間が取れません。少し時間が取れれば勉強をしようと思っていて、今のところ実現はできているものの、そもそもの時間が取れてないのが現状だったりします。

覚えたいプログラム言語

GoとTypescript、そしてRust、と3つ書いておきます。ただし、「何年越しだよ」「まだ1行も書けないのか」、というツッコミは無用にてお願いいたします。今年こそは...。

覚えたいその他の技術的なモノ

2021年にとある案件の要件定義(技術選定)段階で、なぜか私がNoSQLを選択した関係で、NoSQLデータベースについて少し学習をする必要があります。特に今回はMongoDBを選択。概念はなんとなくわかっているのですが、設計に落とし込む段階でその知識がきちんと説明できないのがもどかしいです。

目標:アウトプットの増強

忙しい日々、というよりはかなりストレスフルな2021年で、そのおかげもあってあまりアウトプットができていませんでした*3。そこで、アウトプットはきちんとやりましょう、ということは目標として掲げてもいいと思っています。

でもインプットも必要

2021年の目標としてもインプットを増やすことを目標にしていたのですが、途中からはかなりインプットの量が減ったようには思っています。それがアウトプットの減った一因ではあるのですが、よく言えば「勉強をしなくても自分の『手なりで』仕事ができた」と言えますし、事実仕事の内容としては今までの経験だけで十分できた仕事だったと感じています*4

そこに甘んずることなく学びを増やしていこうと思っています。

そしてアウトプットの機会を得る

今まではこのブログやSNSが主なアウトプットの場でしたし、これからもそのレベルでアウトプットを出していこうと思っていますが、それとは別に、お客様へのアウトプットも積極的に実施していこうと思っています。これは『提案』につながっていく流れですが、お客様への提案ができることで更に仕事を増やしていく、ということも考えていく必要があります。

目標:仕事獲得について

積極的な営業活動はしていませんでしたが、それでもお客様が増えることになりました。これは目標達成です。ただし、お客様の逸失もあります。いろいろな事情はありますが、2021年の逸失は相当多かったです。

売上目標の設定

今年の目標ですが、現時点で売上が見えている(契約が突然破棄されない限りは大丈夫な)ものが300万くらいあります。その倍の600万を目標にしてみましょう。

ちなみに、会社の会計期間は8月~7月になるのですが、ここでの売上目標はあくまでも1月~12月ベースで考えています。もっとも、実際に会社に入ってくる金額として毎年600万くらいは欲しいですが、あまり欲を言わず、個人ベースで稼げるくらいの売上にとどめておきたいです。

売上以外のその他の目標

コロナ禍の終息具合にもよるのですが、一応積極的な新規道府県顧客の獲得は行わないつもりではいます。ただ、毎年1件(以上)の新規顧客獲得は必須ですし、現状顧客の逸失もあるのでその穴埋めはする必要があります。せめて2件くらいは新規顧客が獲得できると嬉しいのですがね。

若干私的な話

2020年にCybertruckを買う、とぶち上げていましたが、2021年に家を購入した際に、駐車場がかなり狭く、軽自動車しか入らないという状況でした。外に駐車場を借りるほどの余裕もまだありませんし、ということではないのですが、2021年末にいろいろとあって中古車を買うことになってしまいました。Cybertruckがパジェロミニに化けました(笑)。

これも金額的にはヨメとの折半で購入していて、2020年に飼い始めた犬とキャンプ的なことをしたいよね、ということでSUV系の中古車に落ち着いた、というのが本音ですが、これでしばらくは大きな買い物の用がなくなりました。細かいカスタマイズや改造など(家もクルマも)が主だった趣味ベースでのやりたい事だと思っています。

それから、2021年末にすごく衝動的にギターを買ってしまいました。ベースはともかく、ギターを買うつもりがあまりなかったのですが、ふと値段もそこそこ(6,500円)、なんの変哲もない白のストラト、というルックスに何故か惹かれて買ってしまいました。少しギターの練習をしたいですね。

もう一つ、目標というところで言えば、「身体を動かす」ことも私的な目標に加えておきましょう。コロナ禍と多忙でジムにも行けず、もっぱら犬の散歩でしか身体を動かしていませんが、少し公園トレーニングや自宅での自重トレも実施していかないと、と思いました。だって2021年の誕生日で50歳になったんですよ。シニアの仲間入りですよ...。

頑張らないとなぁ...。と言うことで今年もお仕事始めたいと思います。よろしくどうぞ。

*1:実際に書いているのは年末から年明けにかけてですが。

*2:まだ会社からの支払いは受けていませんが、年明け1~2月あたりから給与を出す予定。微々たるモンです。

*3:ストレスを理由にするのもどうかと思いますが、事実アウトプットをすることが余計な心配事につながるという妙な状況に置かれていたこともあり、積極的なアウトプットを控えていたという事情もあったりはします。

*4:もちろん新しく学んだことを活かすこともありましたが。

2021年の総括

2020年に引き続き、2021年もコロナ禍でいろいろな社会活動が制限されていましたが、秋口の緊急宣言解除あたりから徐々に街中に人流が増え、社会活動も活発化してきているのではないかと思います。昨年同様、季節感は希薄ではあったけれど、「地味に」季節を感じることはできていました。皆様はいかがお過ごしですか?

2021年のイベントカレンダー

毎年恒例となりました。仕事総括の前に全体イベントから振り返ってみます。

2021年に発生したライフイベント

2021年のライフイベントは珍しく多かったです。

引越し(2月)

購入の手続きは昨年中に終わっていたのですが、旧宅からの引っ越しは家族の都合もあって結局3か月くらい(12月~2月)かかってしまいました。また、2階の私・ヨメが住む居室/仕事部屋はリフォームを自分で行っていた関係もあって、それも入居が遅れた理由の一つだったりします。ちなみに仕事部屋はまだリフォーム中です。

犬を飼う(5月)

持ち家になったのでペットを飼うことは可能ではあったものの、あまり乗り気ではなかったのですが、たまたまヨメの会社関係者の犬を引き取ることになり、まんまと家族の一員が増えてしまうことになりました。生活の中心、というほどでもないですが、やはり家族。世話など意外と大変なこともあったりしますし、わからないことも多い中、楽しくやってます。

会社を設立する(8月)

作りたくなかったのですが作りました。基本的には、仕事の受注のために「法人」であることが必要になるケースでのみ法人の顔を出しますが、それ以外は個人事業主の報酬を受け取って管理するための法人組織です。

クルマを買う(12月)

またヨメにしてやられた、というか、もともと乗っていたクルマの調子が悪く、メンテナンス費用を出すくらいなら中古でもいいから気に入った車に乗りたい(運転もしたい)というヨメの欲望が突然持ち上がり、突然クルマを中古車販売店に見に行き、その日のうちに契約をするという急転直下の出来事が、つい先日(今書いているのは12/11ですが、2週間前の11/27のこと)起こりました。購入車両のメンテナンス等で納車が12月にずれ込むので購入は12月、ということにしておきます。

1~3月

2020年は半分くらい家にいなかったような記憶をしていますが(実際には2週間強しか福島に行ってないですが)、2021年の最初の3か月はコロナ禍の中ほぼ自主ロックダウン状態で自宅で作業をしていました。なかなか進まないプロジェクトも多かったのでずっと引きこもって作業をしていましたが、引っ越しも同時進行で進んでいたのでかなり忙しかったような気はしています。

そんな忙しさであまり記憶もないのですが*1、かなり仕事面でもプライベートでも地味なストレスが溜まっていたように思えます。特に仕事面で。

4~6月

2021年も前年同様にIT講師の仕事を受注していたのですが、実は前年とは違う会社さんからのオファーをずっと前から受けていて、相当なラブコールをもらってしまったこともあって鞍替え。そうしてふたを開けたら*2前年のメンター格ではなく、完全なメイン講師。しかも前年と異なり対面で教えることになる。

1-3月期は上述のようにかなり多忙であったことと、ストレスも溜まっていたこともあって満足に準備ができておらず、ギリギリ教えることができてはいたものの満足のいく結果とは言い難かったです。それでも、一緒に教室でフォローをしてくれたサブ講師や、隣の教室の講師陣と楽しくできたことは思い出ですし、自分自身のいろいろな意味での成長もできたことは経験としてもいいものでした。

実はこのタイミングでいくつか失注をしています。既存のお客様からの依頼があったにもかかわらず、そして「他のプロジェクトに従事しているから」ではなく、全く別の理由での失注でした。それが、『補助金』という話。これが法人組織の設立につながっていきます。

7~9月

昨年末くらいからの大きなプロジェクトが、3月くらいでひと段落するかと考えていたのですが終わらず、少しブランクを開けて7月からの再始動となったのですがやはり進まず、と相当ストレスがかかった状態でしたが、そんな中突然「会社作ってしまおう」と考えついて作ってしまいました。

会社自体に思い入れはないモノの、完全に個人のための(≒個人事業主である私のための)会社なので、会社名は自分の思い入れのある名前を付けています。会社設立の経緯についてはまたどこかで書こうと思っていますが、手続きをして思ったことは、「あぁやっぱりめんどくさい」でした。

そしておおよそ会社設立の手続きが終わるか終わらないかあたりの時期にまたストレスで1週間ちかくダウンしています*3

10~12月

結局昨年からの大きなプロジェクトが進むことなく次々と終了していき、とは言えお金を稼がないと、ということで始めた別の案件でなんとか糊口をしのぐ状態です。

この案件は(私にしては)珍しく、常駐の案件です。たまたま「いろいろと知っているエンジニアに少しの期間でいいから常駐させてくれないか」という話があって、2~3か月くらいで終息するかと思っていたのですが、なぜか半年近く*4常駐をしなくてはならなくなりそうです。もっとも、週に何度かはリモート勤務をしてよい、という「特例*5」を得て徐々に出社ペースを減らしていこうとしています。

その他並行して継続案件を続けている状況です。

総括

TL; DR

昨年は「人生最大のモテ期」と評していましたが、お客様に恵まれていたのは引き続き変わっていないです。ただ、今年は失注も多く、中止となったプロジェクトも含めれば5~6案件くらいあるでしょうか。売上については、今年に関しては個人事業主としての売上と法人の売上を加算することになりますがそれでも昨年よりも多く、かつ補助金などもなかったので純粋な売り上げとして考えても過去最高収益にはなっています。

要約をせずにグダグダと

「失注」とコロナ禍

今年、もちろん今現状でもそうなのですが、仕事を失注することが多くなりました。

もちろん担い手が増えていること(市場のレッドオーシャン化)も大きな理由だと思っています。私自身それほど素晴らしいプログラマではないですし、よく言って「器用貧乏」なので、アレコレできるけれどそこそこしかできませんから。

ですが、コロナ禍というキーワードと絡めて「補助金」受給要件を満たさないことが失注の大きな理由(というよりその理由一択)というケースが増えてきています。特に個人事業主の場合は、補助金申請をするための開発業務を行うためには個人事業主ではダメ、というケースが多く、また個人事業主でも申請ができた補助金申請スキームに至っては詐欺の温床となったことから資格要件の見直しが入り、なぜか「有資格者」という条項が入って私が要件を満たせなくなったとか、そんなこともありました。

そう言う意味では仕事(案件)には恵まれていましたし、忙しすぎるとは思いますがそれでも仕事は4月からは特に切れることなくなにがしかの仕事をやっていたのでまぁ良かったのかな、と思ってはいます。

コロナ禍での「営業活動」

今年に関しては特に営業をかけたわけでもないですが新規顧客獲得を1件行うことができました。先方からのお声がけ、というよりは本当に「ユルく」誘われた感じだったのにそこそこの仕事を継続していただけているので*6、とても恵まれた出会いだったなぁ、と思っています。

ただ、前項でも書いている通り、フリーランスエンジニアの市場規模はおそらく、数値化された情報ではなく肌感覚ではありますが、今までよりも全然大きくなっているはずです。しかも、在宅でできる業務ということもあって、私が過去に考えていた通りの「パソコン一つあれば仕事ができる」と標榜する人たちの群雄割拠が起こっているようにも思えます。もちろん、「これで一旗揚げたるわい」と初心者がネット授業かなんかで勉強して参戦するもプロに潰される、という状況も起こっているはずですが、プロ内でも十分パイの取り合いは起こっているはず。

そうなってくると、どこに営業をかけていくか、ということを今後は戦略的に考えていかないといけないし、営業をかけていくこちらとしても「売り」を明確にしてあげないといけなくなってきます。今年1年で私の「売り」はだいぶ明確化してきていて、今後も数年くらいは受注が見込めそうな感触はあったりします。

自身の体調について

恒例の項目ではありますが、先述の通り、ストレスで寝込んでいる期間があったりして、爆弾と思われる脳梗塞とは全く異なる体調不備が発生しているのは少し気になっています*7。ストレス疲れは今年は相当ひどく、正直言えば薬(サプリ)の世話になってしまいましたし、その前から円形脱毛症が発症したり*8、相当溜め込んでいたようです。

そして、スポーツジム通いも昨年からずっとしておらず、たまに犬の散歩をするくらいなので*9、運動不足も解消できておらず、ストレス解消の手段にもならないという、あまりいい状態ではありません。

「来年2021年の展望」の回答

https://racchie.hatenablog.com/entry/2020/12/26/183000

相変わらず大した「展望」じゃないですね(笑)。

総括全体を見直してみても、当時考えていた状況や当時の進み具合とは全く異なる進み方をしていたりと、時々刻々と変化をする、まるでコロナウィルスの変異のようです。

そのコロナウィルスに関しては、2021年の1年間で、それなりに改善の兆しが見えているようではあります。まだまだいたちごっこの様相も呈してはいるものの、ワクチン接種の効果は出ているようですし、更に「ブースター接種」なる3回目の国費接種も実施される予定になっているなど、予断を許さないと言えども昨年ほどの悲観はしなくてもいいのかな、と思ってはいます。

しかし、「予断を許さない」状況であることには変わりはないですし、もっと言うと今年の失注理由の一因にもなっている「個人事業主」の限界をどう超えるのか、というところはもっと積極的に進めないといけないし、案件だけで言えば私の得意分野(=売り)は相当転がっているのではないかと考えていて、上手く拾っていかないと売上は見込めないかな、と考えています。

だからこそ今年は「現状維持」ではいけないし、もっと攻めていかないといけないように思います。

「出稼ぎ」案件ですが、今年は昨年と同様に講師の案件も受託していますが、それ以外にも客先常駐の案件が今年は入ってきています。客先常駐案件については先方に出向いて(業務詳細は言えないのですが)作業をして成果物を出して、という仕事なので、毎月ある程度定期的な売り上げが見込めます。これは昨年も指摘している通り、あくまでも売り上げの底上げというか、ベースとなる売り上げを上げるための手段として考え、基本はエンドユーザさまへのシステム納入・運用支援や企画提案をベースにして行かないといけないかな。

コンテンツ/オウンドメディアという話は、これは時間が足りない...。試してみましたが相当時間がかかります。今後もチャレンジは続行ですが、売上に貢献できるようになるまでは時間がかかりそうですね。

2021年に覚えたこと

2020年に比べるととても少ないですが、それでも今まで覚えた事をきちんと生かすことができたことは大きな収穫です。

言語編

今年も結局Goの勉強はできず、更にあちこちでおススメいただいているTypescriptやRustなども興味はあるものの全く学習フェーズに入れません...。

業務でも昨年と変わり映えがないどころか、(悪く言えば)絞り込まれてしまっています。

ちなみに業務の7割強はPHP案件でした。

その他編

これも言語同様に「昨年同様現状維持」でした。ただ、Dockerはあちこちで使いましたしPCについてもWindows(10)をずっと使い続けています。2021年にリリースされたWindows11については導入を検討していますが、そのためにはPCのリプレースが必要になるので少しだけ悩んでいるところです。

来年2022年の展望

展望なんてないですけどね(笑)。

毎年「ブルーオーシャン戦略」みたいなことを考えて書いている気がしていて、それが展望のなさにつながっているような気がして仕方ないのですが、今までの私の「ブルーオーシャン」はニッチな方向に向かうことがメインだったような気はしています。例えば、YouTuberというネタにしても、オウンドコンテンツを生産することでニッチな顧客の掘り起こしを考えているわけですが、そろそろ「ニッチ戦略」狙いも細分化(先鋭化)してきているようにも感じられます。

だとすれば、一見レッドオーシャンに見えるどこかの海も、意外と私が入っていっても勝てるのではないかな、と少し思っていたりします。特にECサイト関連、EC-CUBEのベンダーという点で言えば、もちろんここは相当真っ赤な海ではあるのですが、ちょっとくらいなら勝ち目があるかも、という勝算があったりはします。だとすれば少し攻め込んでみて、ダメなら撤退でもいいですし仕切り直してもいいのですが、そもそもすでにこの海には飛び込んでいるので(2年くらいやっていますので)それなりに攻めてみてもいい気はしています。

そして前述のように、出稼ぎ案件も定常化してくれば、それだけ底上げもできて安定した経営基盤が出来上がりますし、それが攻めにつなげられればいい、と考えています。おぉぉぉ、何年かやっていて初めて展望っぽい書き方になっているかも...*10

(最後に)ご挨拶を

他の年に比べても「ごちゃごちゃした年」だったように思えます。ごちゃごちゃに巻き込んでしまった皆様には謝罪や感謝をしなくてはなりません。ごめんなさい。お付き合いいただきありがとうございました。でも、そんな一年があったからこそ次につなげられる、と信じていますし、次につなげるために同じ過ちは繰り返すまい、と思っています。

最後になりました。

お仕事の関係者の皆様、そして、何の因果かこのブログにたどり着き、何らかの記事を読んでくださった名も知らぬ皆様、そして家族・友人の皆々様、旧年中は大変お世話になりました。皆様のおかげで今年一年なんとか生き抜くことができました。

来年2020年も変わらずお付き合いのほどよろしくお願いいたします。

末筆となりましたが、読んでいただいている皆々様のご健勝をお祈りいたして筆を起きます。

来年絶対1か月休み取って寝て過ごす...。

*1:年末の総括のためにメモを残しておく必要があるのかもしれない、と思う50歳...。

*2:もっともふたを開けたのは年末から年初にかけてだったのだけれど。

*3:毎年どこかで倒れてる気がします。やっぱり1か月くらいどこかで休暇取らないとダメかもな...。

*4:つまり来年の1~2月くらいまで続く可能性が出てきています。

*5:常駐をしているのだから出社が義務、くらいに言われていましたが「そんな仕事ならリモートでもできる」と先方を説得して何とかリモートにこぎつけました。

*6:10月からやっている常駐の仕事もそうですが、案件ベースでも複数の仕事が走っていたりします。

*7:ちなみに脳梗塞は先日定期健診で異常なしという結果になっています。

*8:しかも円形脱毛症って、ヒゲでもなるんですね。アタマ1か所、ヒゲ2か所の円形脱毛症でした(笑)。

*9:犬の散歩程度では運動にならないですが、気分転換にはなります。

*10:ま、来年も同じように昨年の展望の自己批判から始まるわけですが。

アジャイル開発を実践してみて思うこと

久し振りに書いた記事です。Qiitaのアジャイル開発アドベントカレンダーに参加して書いてみました。 こういう理由でもないと記事ずっと書かないまま過ぎていく気がしてしまい、アドベントカレンダーに乗っかってみました。

普段一人で開発をしていて、あまり意識はしていないのですがアジャイル型の開発をやっています。なにをもって「アジャイル開発」なのか、という定義の問題については後述しますが、まずはWikipediaにある

ja.wikipedia.org

人間・迅速さ・顧客・適応性に価値を置くソフトウェア開発

を定義として、特に顧客の求めに応じて迅速に開発対応をし、更に適応性の高い対応を行うことと位置付けて話を進めます。

ひとりアジャイル

フリーランスエンジニアという立場で開発の仕事を受注する場合、一般的に大規模開発などで使われる「ウォーターフォール型」の開発方式をとることはできません。できないわけではないでしょうが、ひとりで全工程を実施するという前提であれば、そもそも各フェーズ(企画・設計・製造・テスト)がクリティカルパスになっているし、それぞれの工程内でもクリティカルパスがあればもちろん、なくても並行してコーディングはできないので積み上げた工数はイコール開発にかかる時間になってしまいます。30人日の開発工数が見積もられる場合、その開発期間は必ず30日かかるわけです。短縮するためには要員追加をしなくてはならないわけです。

アジャイル」の場合、特にひとりでやる場合は、もちろん全体像の把握をしなくてはならない企画フェーズや基本設計フェーズレベルであれば最初にまとめて実施して顧客とのコンセンサスをとる必要がある可能性もあるはずですが、そのあとの詳細設計以降はもちろんそうですし、基本設計フェーズにおいても小刻みに設計を作りながらレビューして、徐々に基本設計を進めながら並行して設計→製造→試験のイテレーションを回す、という方法が取れるわけです。

似非アジャイル

個人的には私がひとりでやるアジャイル開発は「似非アジャイル」と呼んでいます。今でも自分のやり方は、我流と言えば我流ですしそう思っています。アジャイル関係の書籍で読んだのはこの本一冊だけだし、そもそもXPって二人でやるモノなのでそれを一人でやれるように翻案してみたりしましたが、結局は自己流に落ち着いています。

自己流とは言え、ある程度はXPに沿った内容で実行しています。例えば、XPにおいては「コーディング、テスト、傾聴、設計」を書き出すことになっていますが、私は開発する単位においてはまず(詳細)設計から作ります。手書きのメモで、大体フローチャート・アクティビティダイアグラムだったりしますが、何をすればいいのかをざっと書き出してしまいます。

そしてコーディング。設計ができていればコードは設計通りに書けばいい、という持論があるので、設計通りに書いてみる。そして、最近取り入れたのがTDD(テスト駆動開発)の手法。MVCモデルみたいなフロントエンドとバックエンドがわかれている仕組みの場合は、とりあえずフローに基づいてフロントエンドを先に組んでしまう。そしてフロントエンド実行で発生したエラーがバックエンドのモデル(ビジネスロジック)部分になるのでコードを書いていく。

テストをパスすればお客様に「できたから見てちょうだい」と依頼する。それでヒアリング/レビューに代えられる。これまた最近のやり方は、レビューをオンラインで実施、その場で動かしながらその場で直せるものは直しちゃう。もちろんすぐに直らないモノもあるので裏でコードにコメントで打ち合わせのメモを残しておいて、「やっときますぅ~」と言って翌日あたりから開発にいそしむ、という。

あまり体系化されていないし、本当に自己流・我流なので、このあたりの説明はこれくらいでご勘弁願いたいのですが、実際問題、これでなんとかお客様に、多少ご迷惑はかけつつもなんとか何年間しのいでおります。

チーム開発とアジャイル

アジャイル開発が生きてくるのはやっぱり少数のメンバーでゴリゴリと開発していくシーンかな、と思っていたのですが、先日たまたまそんなゴリゴリのアジャイル開発現場に管理者として入り込むことができて、チームメンバーの「総意」としてアジャイル開発方式で行きましょう、というコンセンサスが取れていたので、ではアジャイルで、とやってみたのですが、これがまた、絵にかいたような大失敗。実は現在も失敗の火消し中ではあるのですが、その失敗を踏まえて、アジャイルってたぶんこんなのがいい、あくまでもこんな感じにすれば上手くいったはずでは?という意味を込めて*1ベストプラクティスを探ってみたいと思います。

失敗例

まず今回のプロジェクトは(詳細は守秘義務もあるので書けませんが)既存プログラム機能を使った新しいプログラムの開発。ほぼ既存プログラムのままで、少しデータの読み込み方を変えて、集計用の計算ロジックを考え直すくらいですむはず、というのがお客様の考えなので、工数も大してかからないだろう、ということだったのですが、私と私が率いるチームは今回この現場に入るのが初めて。既存プログラムについても見たこともなければ触ったこともない。似たようなシステムがあるわけでもないので(特定用途のためのシステムのため)、当然誰も何もわかっていない。

仕方がないので私だけ先行して現場に入り、まずは現行のシステムの理解をすることになるわけですが、そのために作ったのが実は「設計書」でした。と言っても、現在のプログラムを解析して設計書という誰が見ても分かる内容に落とし込むことで、この後に入ってくるエンジニアたちは設計書を見ればなんとなくシステムのやりたいことややるべきことがわかるはず、と書いてみました。

ある程度書き終わり、クライアントからの了承も得て、更にそのあと実際に作る設計書を基本設計レベルで書いてみたのですが、それをエンジニアに渡して、「ではここからは皆さんの出番ですのでアジャイル方式で開発進めましょうね」、とお願いしたところ、数日くらいしてから「何をしていいのかわからない」という質問が上がるようになってきました。

私としては、設計書は渡しているし、データベース構造の情報も渡しているし、そこから探って作り込んでいくしかないよね、と思っていたのですが、どうやらそうではなかった。よくあった例は、「この画面要素にどのデータベース項目を適用すればいいのか?」という質問*2

その機能/表示項目は何をするものなのか、ということが設計書に書かれていた「はず」だと設計担当をしていた私はもちろん思っていましたが、設計書を読んだ人たちにはそれが伝わっていなかった。まず、設計書を読んでいるかどうかすらわからない。

とにかくそんな状況でずっとメンバーからの質問に答え続けて毎日が過ぎていき、次のプロジェクトにアサインされて次の作業を始めてもいい時期なのに何もできない、という毎日が実は今も続いていたりします。

失敗例に見る課題とその解決策

ここまで読んで、『そりゃそうだ』と思うでしょう。自分もまとめていて思います。こりゃ失敗するよね、と。

キックオフが実施されていない

私自身キックオフミーティングなどの実施は必須ではないとも思いますが、それでもメンバー全員が同じ方向を向くために、設計書の読み合わせや意識統一はされるべきでしょう。今回のプロジェクトではそれが一切行われていませんでしたし、途中参加のメンバーについてもドキュメントを読んで理解することは一切指示をしていませんでした。

「(プロジェクト)スコープ」の共有ができていない

ゴールがどこなのか、ということもチーム間で共有できていませんでした。ゴール、という言い方よりも、プロジェクトを管理する立場で言えば『スコープ』という言葉を使いたいのですが、プロジェクトそのもののスコープ(What to make)もわかっていないし、いつ納品するか、という情報すら伝わっていなかったメンバーもいたりしました。そのため、どれくらい工数がかかるのか、という質問に対して「わからない」という回答をしれっと投げてくるメンバーもいました。

アジャイル方式」の定義が明確でない

これはかなり後のほうになって気が付いたことだったのですが、「アジャイル方式」と言ってもそれぞれが同じやり方をするわけではないわけです。自分の例が一番わかりやすいですが、いわゆる我流でやっているアジャイル方式は、もちろんほかの人が実施している「アジャイル方式」とは違うわけです。だとしたら、「アジャイルで」と言った場合に全員が同じやり方を指すとは限らないのだから、きちんとやり方を示すべきであっただろう、と思います。

[解決策]コミュニケーションを頻繁に取る

結局はコミュニケーションなんだな、と感じています。情報の共有、という言葉を使ってもいいのですが、ただ共有する=シェアする、のではなくて、意識が統一されていることが重要になってきます。

実は今回の反省点をメンバー内でも報告しており、課題としてもコミュニケーションが大切だ、という話をしているのですが、どうしてもメンバー間ではそれが「ではコミュニケーションツールを導入することで云々」という言葉に翻訳されてしまい、ツールの選定を急ぐように指示をされているのですが、私はそうじゃないよ、と何度となく言っています*3

コミュニケーションをとり、情報が一方通行ではなく相互に共有されるようになり、更にその情報が整理されたうえでメンバー全員の共通認識となる、という状態が正しいコミュニケーションの取り方、だと思っています。

ウォーターフォールアジャイルの共存

実は今回の開発メンバーの中にもいたのですが、「ウォーターフォール方式とアジャイル方式は相容れない」という主張をする人は多いです。確かに全く考え方が違う、といえばその通りで、プロセス・計画重視であるウォーターフォール型に比べて、コード(納品物)重視のアジャイル、というのはその通りではあるのですが、「相容れない」とまでは言い過ぎでしょう。

今回の開発受託において、私自身が考えていたのは、基本設計フェーズまでは「ある程度」ウォーターフォール型で進め、途中から、または基本設計フェーズが終わり次第「アジャイル型(イテレーション型)」で進めるというやり方でした。そのやり方を伝えておらず、結局メンバーは開発ドキュメントを開発が始まる当日まで見ていなかった(提供していたのはもっと前であったにもかかわらず)、という状況であり、更には開発中にもドキュメントの一部しか見ていないメンバーが多数いた、という状況で、ドキュメントを作った立場の人間としてはここまでの努力を見事に水泡に帰してくれたものだ、と思うほどです*4

アジャイル型開発においてドキュメントは不要である、という主張はよく聞かれるのですが、私自身はドキュメントがないことには何をすべきかがわからなくなる、と思っています。プログラムを書く立場の人間が必ず何かを残すべきか、という議論に関しては、それは人それぞれ、と思うのですが*5、全体の設計ドキュメントはもちろん必要になるし、それを疎かにすることは許されないはず、と思っています。

ウォーターフォール型の開発にアジャイル型の開発を組み込むとしたら...、と言う日本語自体がおかしい気もしますが、設計の一部→開発→試験の一部、または大部分をまるまるアジャイル型に置き換える、というやり方は可能なはず、と私は考えています。

ベストプラクティスを探すために書籍を紐解くことも必要だと思いますし、新しい方法論を採用したり、トライアンドエラーで改良を加えていくことでよりよい開発ができるようになる、と思っていますが、一朝一夕に上手くいくこともないでしょう。やってみるしかないのですよね。上手くやるためには。

*1:実際に次のプロジェクトが並行して始まるのでその時の運用テンプレートの作成を兼ねて...

*2:実は今回のプロジェクトメンバーはほとんど外国人だったという別の問題も抱えていて、日本語で書いた仕様書が外国人が理解するには少し難しすぎた、という問題も実はありますが、それを除いてもこの質問は多かった

*3:それでもツールを導入したいと急かしてくるのは、ゼロだったところから少しだけでもいいから進めなければ、というメンバーの焦りがあるのだろうと推測します

*4:もちろん、ドキュメントに目を通させることをしていなかったのが問題なのですが

*5:先述の通り私は詳細設計をメモレベルではあるけれど必ず作るので

しばらくお休みをいただきます

取り急ぎのご連絡。

表題の通り、ブログ更新をしばらくお休みします。

ネタ切れが大きな理由ではあるのですが、そのネタを仕込むヒマもございませんです、ハイ。

7月~8月くらいにまたお目にかかります。

「アジャイル」とはなにか

フリーランス在宅ワークをやっていて、いわゆる「アジャイル型」の開発をすることが多いです。大きなプロジェクトへの参画ではなく、中小規模プロジェクトで、開発自体も基本一人で賄えるレベルのプロジェクトなので、進め方もこちらでコントロールしやすいのがアジャイル方式だったりします。ただ、自分では自分のやり方を「アジャイルっぽい開発スタイル」と言っていて、本来の、と言うか提唱されている各種のアジャイル方式とは違ってはいますが、できるだけアジャイル型開発の良いとこどりをしている、と自分では思っています。

そもそも、「アジャイル」とは何か、ということについてまとめてみたいのですが、自分のスタイルについても本当に今のままでいいのか、という検証を含めて、定義や方法論についてきちんとまとめてみたいと思います。

アジャイル開発とは

そもそもの定義は何か、と言うと、

ja.wikipedia.org

迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群

なのですが、では、どのような手法なのか、というと、いろいろと種類(流儀)があるようです。実際の開発フェーズにおいては、短期間のイテレーション開発の繰り返しで機能の実装をし、機能レビューをしている段階で他のイテレーション開発サイクルを回すことができる、というのがキモだと私は理解をしていて、だからこそ私自身が開発の仕事を請け負う際はそのスタイルを踏襲しているつもりです。

特に、私はXP(エクストリームプログラミング)の手法を参考にしているので*1、チーム開発を前提としているスクラム開発手法とは相いれない部分すらあると思ってはいますが、根底には、「アジャイルソフトウェア開発宣言」に基づく開発スタイルがあります。

agilemanifesto.org

アジャイル開発は「銀の弾丸」ではない

ソフトウェア開発の業界で「銀の弾丸」、いわゆる特効薬的なモノは存在しない、と言われています。

ja.wikipedia.org

アジャイル開発もその例には漏れず、「アジャイル開発を採用すればすべてうまくいく」ということではないし、あとで述べますが「アジャイル」を曲解してしまっている人たちがとても多いため、むしろ「アジャイル」を採用したことで開発プロセスが滅茶苦茶になってしまうケースも散見されます*2

ウォーターフォール開発の反意ではない

simplearchitect.hatenablog.com

この方の投稿がとにかく的を射ています。

と言うか、ウォーターフォールという「大きな流れ」に対する真逆の方法論として、ウォーターフォールで行われている製造までにとてつもなく時間がかかるやり方ではなく、とにかく動くコードを、みたいな意味でアジャイルをとらえている人は多いんだろうな、と思います。

マーケティングの世界でよく言われる、「ドリルを買いたい人が欲しいのはドリルではなく『穴』」の格言に似ていて、お客様が欲しいのは動くソフトウェアであって、開発手法がどうであっても構わないのですが、それを「ソフトウェアがすぐに動く」という言葉に引っ張られて、すぐにソフトウェア開発をするならアジャイルで、みたいなことを考えてしまっているようには思います。

アジャイルにおける「勘違い」

既にいくつか紹介をしている勘違いですが、結局、言葉を表面的になぞっていて、都合のいい言葉ばかりを引用してしまっていることが原因です。

先に挙げた「アジャイルソフトウェア開発宣言」ひとつをとっても、都合のいい耳障りの良い言葉が並んでいますが、あくまでも今までやっていた他の開発手法でうまくいかない理由を考えたうえで、「こっちも重要でしょ?」という言い方をしているのがアジャイル開発宣言なんだと思うんです。

私たちは、ソフトウェア開発の実践

あるいは実践を手助けをする活動を通じて、

よりよい開発方法を見つけだそうとしている。

この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、

包括的なドキュメントよりも動くソフトウェアを、

契約交渉よりも顧客との協調を、

計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを

認めながらも、私たちは右記のことがらにより価値をおく。

全文引用をしましたが、中段の、「〇〇より××を」、のくだりは、その下の2行にもある通り、〇〇に価値がなく、××に価値がある、ということではなく、どちらにも価値があるし、今までの開発手法ではより「左記(〇〇)」に価値を置きがちではなかったか、というアンチテーゼととらえることができるわけです。

ウォーターフォール型開発を例にアジャイル開発宣言を検証

一般的には大規模開発に向いていると言われているウォーターフォール型の開発手法の場合、

要件定義→設計(基本→詳細)→コーディング→テスト

というそれぞれのフェーズがあって、前のフェーズが完了しないと次のフェーズに動けない、という問題をはらんでいる、と言われます。プロジェクトマネジメントで言えば、要件定義がきちんと終わっているかどうかは、以降のフェーズでの出戻りの発生に関わることなので、ここで要件ができっているのかどうかをきちんと確認する必要があります。各フェーズで抜け漏れがないことがプロジェクトを成功に導く鍵、とも言えます。そのためのプロセスであり、ツールがあるわけです。

しかし、多少の出戻りが発生してもよい環境であれば、既定のプロセスを飛ばしてでもコミュニケーションを密に取っていれば「もしかするとこの辺りは要件が変わるかもしれない」と開発を柔軟に行うことも可能だったりします。オブジェクト指向的に言えば、わかっている要件だけで抽象クラスやインターフェースを実装しておいて、実際の動きは子クラスを作ればいいや、というような手法で、手戻りを最低限にとどめることも可能なはずです。

そうやってプログラムが先にできることを「ドキュメントよりソフトウェア」と言っているのであって、すべてを仕様書に落とし込まなければソフトウェアの開発に入れないウォーターフォール型のデメリットに対してのアンチテーゼと考えられるわけです。

左辺は疎んじて右辺のみに価値を見出すか

では、ドキュメントとソフトウェア、どちらが大事なのでしょう。同じように、4つの「比較された価値」はどちらかが本当に大切だと言えるのでしょうか。

プロセス・ツール vs 個人との対話

開発で陥りやすい罠で、コミュニケーションの欠如が挙げられます。特にプロジェクトが大きければ大きいほど、お客様と開発者の間に大きな溝ができていきます。コミュニケーションという観点で言いかえれば、お客様と開発者の間に、いろいろな人たちが介在し、意思疎通が難しくなっていくことになります。いわゆる伝言ゲームが始まるわけです。

そのために、ウォーターフォール型ではドキュメントを多用し、意思疎通の簡便化を図っているわけですが、そうは言ってもドキュメントは作成するのにも時間がかかるし、それを読まないで仕事をすることも当然できるわけです。だったらコミュニケーションを密に取ろうよ、というのが「個人との対話」です。

しかし、これは私のコロナ禍での経験の一つではあるのですが、密にコミュニケーションをとりたくても、遠隔地での会議や作業を強いられる中でFace to Faceのコミュニケーションはとても難しくなりました。気軽な話もしにくくなったりしましたし、本当にコミュニケーションをとり続けることが難しい、と感じています。

だから、目的がコミュニケーションなんだよ、という理解で、ツールを使ったりする必要があるのではないのかな、と思うのです。ドキュメントを作ることで意思疎通ができるのであればドキュメントを作って共有すればいいし、ちょっとした会話程度ならチャット等のツールでいいし、最終的にそれでコミュニケーションが取れて、意識の共有ができていればそれでいいわけです。

ドキュメント vs ソフトウェア

上記で一部答えを書いているようにも思いますが、成果物として最初に必要なのはドキュメントではなく、お客様に納品し、使ってもらうためのソフトウェアなはずです。ソフトウェアを完成させるためにドキュメントは必須ではない、というのはその通りなのですが、だからと言って、ソフトウェアを作るためにコミュニケーションをとらないで勝手に作るのも問題です。そのためのドキュメントは必要でしょう。

特に、要件定義の「ドキュメント」に関しては、アジャイルだろうがウォーターフォールだろうが、絶対に必要なモノです。一番最初に要件定義ができていなければ開発なんて入ることができないんです。もちろん、ウォーターフォール型のように、抜け漏れを防ぐためにドキュメントをきちんとそろえる、という方法もありますが、アジャイルの場合は一部の要件が決まっていればそこだけ作ってみようぜ、というやり方が取れなくはないので、要件をまとめつつソフトウェアも動かしつつ、みたいなことはできますが、だからといってドキュメントもなく、要件もあいまいなままで開発に入るのは無理です。

契約交渉 vs 協調

対お客様、という視点で見ると、開発のコストがかかればそれだけお客様に対して交渉をしなくてはなりません。制限事項も設けなければ開発そのもののコストは青天井になります。ウォーターフォール型でなくとも、アジャイル型開発で、ずっとお客様が要件を出し続けていれば、確かに動くものはできていてもお客様が満足するものはいつまでたってもできない、ということになるわけです。

がんじがらめにお客様を縛り付けて、開発側がコントロールしやすいのは確かにウォーターフォール型だったかもしれません。こういうやり方でやるからね、と流れを説明しやすいです。が、それではお客様にとっては流れの最初と最後しか見えない、ブラックボックス化された状態なので、より、お客様とのコミュニケーションをとりやすいやり方がいいよね、という意味ではあると思います。

ただ、「がんじがらめ」に対する「協調」は、ともすれば『お客様にコントロール権を渡してしまい開発側ではコントロールしない』というとらえ方にもつながりかねません。あくまでも「お客様との協調」であって、お互いに主張するところはして、お互いにより良いものを作っていこう、という態度が必要なんだ、とここでは言っているのだと理解をしています。

計画 vs 変化への対応

「計画」を「プロセス」と読み替えてもいいのですが、今までのプロセス内でやってきたことは絶対だ、という考え方はとても危険です。プログラムに関係がないですが、これはコロナ禍で人類が直面したことの一つだと思っています。計画が絶対、という考え方をすることで、最悪命の危険が迫ってくることになってしまう、という事例は2020年に起こった出来事だけでも枚挙にいとまがないでしょう。

計画を変更するには大変な労力が必要です。だからこそ、計画を変更するための労力を惜しまないようにしよう、というのがこの言葉の意味だと思っていますが、だからといって、計画をしなくていい、ということでは決してないわけです。

よくある「どうなるかわからないから後回し」なのは結構なのですが、「どうなるかわからないからとりあえずコレでやってみて、あとでいろいろと変更してみようぜ」という、どちらかといえば行き当たりばったり的な、そしてこれを「臨機応変」という言葉に置き換えてしまうようなやり方はどのような開発手法をとったところで好ましくはありません。

臨機応変に対応するコトは大切ですが、それは無秩序とは違います。

(で、結局)アジャイルとは何か

ウォーターフォール型開発がプロセスであり、ツール群であり、開発の方法論・思想であるのと同じく、アジャイル型開発もプロセスであり、ツール群であり、思想である、と言えるのでしょう。

私が感じている限りでは、「アジャイル」という言葉は若干独り歩きをしすぎていて、本来意味しているところから乖離してしまっている気はしています。アジャイルの専門家でも何でもないのでこういう言い方はすごくおかしいのかもしれないですが、ウォーターフォール型開発の不都合な部分を解消してくれる、と言えば聞こえはいいですが、不都合な事をしなくてもいい、と言う免罪符として「アジャイル」という言葉を使って開発を進めようとしているだけなのではないかな、と思うのです。

先に挙げた「メソッド屋」さんの記事にもあったのですが、アジャイル「型」がウォーターフォール型に取って代わられているわけではなく、方法論以前、「型」以前にある、目の前の『課題』を解決するための一つのやり方(方法論)でしかない、ということなんだろうな、と思うのです。

もちろん、「このやり方はウォーターフォール型は向いてないよね」とか、「アジャイル向きかなぁ」という議論はなされていいのですが、ウォーターフォール型が向いていないのでアジャイルで、という二極化ではないし、少なくとも向き不向きがある開発手法の一つでしかないということを理解すべきなんだろうな、と思います。

*1:だから開発サイクルのことを「イテレーション」と呼ぶんですね。スクラム開発なら「スプリント」なんだそうで。

*2:私もそういう現場によく投下されていました。