IDEに何を期待してどう使おうか

先日オンラインで行われたJJUGのJava生誕25周年 記念イベント 5/23(土) 開催で話させていただきました。

Java25周年おめでとうございますですね。もうJavaより若い開発者さんも結構おられることでしょう。これ会場で「Javaより若い人ー」とかやったら、結果がどっちでも微妙な空気になりそうですね。オフラインだとうっかりやっちゃった気がしないでもないので、オンラインでよかった！

さて、タイトルは「IDE起点で2020年代の開発環境を眺めてみる」です。

スライド

動画もあったりする。自分の動画ってあまりみたくない

話したつもりのこと

（……を書いてるつもりだけれど、話してないことも混じってるかもしれない。）

一口に「Javaを使ったアプリケーションの開発環境」と言っても、実際は様々な道具を使用します。 とは言え、我々開発者の仕事は「道具をうまく使う」ではありません。 道具なんてどうでもいいのです。「どうでもいい」と言うには、道具に意識が向いていては言えません。手足のように使えないと、どうでもよくならないのです。

自然体で使えるようにするために道具を知る必要があります。 その道具が何者で、何を期待してよくて、何を期待すべきでない、何をさせてはいけないのか……この関係性を記号化するとモデルが描けます。私の認識が資料の29,31ページ。

この関係性においてIDEに何を期待するか。開発者にべったり寄ることです。コンピュータとうまくやるところはIDEの先の道具に任せてしまって、私の開発を全力で手助けしてくれることがIDEに期待することです。 特に開発時しか要らないことはIDEが受け持つべきで、ビルドツールやバージョン管理が持つとおかしなことになります。

また、一つの役割を複数の道具で担わせるのはよくありません。原本が一つで伝播するならまだ良いですが、複数原本がある状態になると収拾がつかなくなります。

依存方向が交錯する例は37ページで挙げています。

図があまりよろしくない……シーケンシャルに見える。上と下の2パターンありますよね、と。実物の例してはMavenのEclipseプラグインと、EclipseのMavenプラグイン。他の組み合わせでも大体あります。

この連携をするとビルドツールとIDEに関連ができます。そして今時は必ず連携するでしょう。 どちらの方向にするかを考える時に、先の「開発のモデル」を参照してみてください。 ビルドツール→IDEの依存を作ると、ビルドサーバーからIDEまで依存が辿れてしまいます。 実際は設定ファイルで分離されるためそこまで強固な結合ではないのですが、依存方向として許してしまうと、あれもこれもと乗りがちです。 下手をすれば「CI環境にIDEがインストールされていないとビルドできない」なんてことになりかねません。

「開発のモデル」の要点はIDEへの依存がないことです。IDEの独立を維持できると、IDEの設定は個人に特化できます。 多人数開発において開発環境の統一はそれなりに効果はありますが、どうしても個々人の最大限のパフォーマンスからは目減りします。

私は常駐の支給端末で開発していたことも多く、プロジェクトが変わるたびに端末から入れ替えとかだったので、あまりIDEのカスタマイズはしない派でした。 キーマップも変えず何もかもデフォルトで使うのが、当時の私にとって最大のパフォーマンスが発揮できる道具の使い方だったからです。 今もあまり思い切ったことはしていませんが、ちょいちょいカスタマイズはしています。

「IDEがないと開発が一切できない」なんてことはありません。ですが、IDEを自分のためだけのものと位置付けて手に馴染ませられれば、効率は非常に上がります。 そのためにはIDEは他から依存されてはいけないですし、IDEが独立を保てるならいくらでもカスタマイズできます。

で、Javaの世界では、外から依存されるべきでないIDEがいまだに握っちゃってる問題がフォーマッタなんだよねぇ……。

フォーマッタについては過去の私（2012年）に何か思うことがあったらしいです。

irof.hateblo.jp irof.hateblo.jp

goとか見てると、フォーマッタは言語が持ってくれるのがいいなぁと思ったりしてます。 今更言語が持つのは厳しいでしょうから、とりあえずIDEから独立して使える別ツールになってくれたりしないかなぁ、とか。 コード管理システムのhookやCIで回すのもやってみたけど、今のところしっくり来てません。IntelliJのフォーマットをコマンドラインで動かせはするんだけど、動かせはする、くらいでコレジャナイだった。 コードとフォーマットについてはそのうちまた別口で書きます。覚えてたら。こう書いて覚えてたことってあるんだろうか私……。

オンラインセッションをやってみて

初のきっちりしたオンラインセッションでしたが、難しいですね。 私は話しながら聞いてくれてる人の反応を見つつ、話を足したり削ったりするのですが、そういうのができないセッションも新鮮でした。 オンラインの勉強会はきっと今後もあると思うので、何かしらオンラインならではのを仕掛けたいですね。

その一環としてCommentScreenを使って字幕を流していました。今でも動画でみれるかと思います。 Twitter連携してハッシュタグが流せます。Twitterなくても専用のフォームがありますが、今回はTwitter連携だけで。 YouTube Liveだったので数十秒の遅延があって、リアルタイムに反応を拾う目的でやったのですがこれは外しました。最初から分かってはいましたが、数秒ならともかく数十秒はキツイ。 でもなんの反応もないよりはやりやすかったです。

経験年数で何がわかるか

経験年数が問われることはしばしばあります。 私も聞かれたり聞いたりしたことはあるけれど、それで何かがわかったことはありません。他の話のきっかけに使うのがせいぜいです。

たとえばJava経験15年とか言われれば「Java5が出た前後か、この時期をどう過ごしたか聞いてみようかな」なんて思ったりします。 Java5はジェネリクスやenumなど、Javaにとっての一大転換期です。とはいえこの時期に新人だったとすると、社会人として精一杯で言語のバージョンに意識が向いていなかったかもしれません。 とはいえ次の転換期であるJava8の話は間違いなくできます。転換期の振る舞いは何を期待していいかを知る重要な手がかりになると思っています。 対して経験年数が5年未満であれば、Javaの転換期の話をしても仕方ありません。それよりも言語の選択肢が増えている昨今ですから、他の言語など横に広げて聞いた方が実りのある話ができる気はします。 いずれにしても経験年数はあくまできっかけであって、それで何かの成果を期待するものではありません。

経験年数でスキルを測るのは、よくある誤ったメトリクスと同じ構図です。 コード行数とかバグ密度とかが適切な条件を揃えないと意味がないのと同じ。（適切な条件を揃えると意味はあります。「古臭くて何の役にも立たない」って切り捨てちゃってる人はちょっと見直してあげて欲しい。） 選択肢が狭くコンテキストのズレが少ないのであれば、経験年数で何かを測れた頃もあったんだとは思います。 しかしながら、現在は既にそのような時代ではありません。 開発に携わる皆さんは、時代遅れのメトリクスにとらわれる不幸は多くみてきたはず。不適切なものは排除するのが健全だと思います。経験年数の誤った適用は辞めましょう。

経験年数の他に年齢も似たように扱われ、結構な頻度で聞かれます。経験年数よりも聞かれる頻度は多いのではないでしょうか。 そして年齢、もっと扱いづらい……どころかほぼ役に立つシチュエーションは無いと思っていて、私は意識的に捨てることにしました。8年前に某セッションで「年齢を気にしない」と話していたり。

何かができるできないの理由に年齢を持ってきたくなかったんですよね。「若いのに」とか「結構なご年齢なのに」みたいな言葉がすごく嫌。 たとえ10代だろうと当人を見ればいいだけの話です。プロとして関わっているのだし、少なくとも「いい大人」です。変に気を使うのは当人にも失礼だと思っています。 それで期待と合わなくても、それは「若いから」とか「学生気分」とかではありません。単にその人に対する期待が違っていただけで、差分を見極めてギャップ制御すればいいだけの話。 こんなところに年齢を持ち込んでも何も問題に制御不能なパラメータを突っ込むだけなので、何も解決しないのです。

年齢を含む最古のツイート……当時の私に何があったんだろうね。もう覚えてないや。

当時……と言うかそれよりも前からですが、私は基本的に年齢不詳でやっていて、直接聞かれても濁したりしています。うっかり言ったこともあるので知っている人は知っていますが。 実際のところ別段隠すつもりはなくて、単に覚えてないのをごまかしている＆引っ込みがつかなくなってるだけですが、まあそれはどうでも良くて。 自分のできるできないの理由を年齢に持って行きたくなくて。これは年齢の割にできないとか、この歳で何かを始めるなんてとか言いたくない、みたいなやつです。

槇原敬之の東京DAYSに「24歳の年に初めて照れもなくスケボー抱えて」というフレーズがありますが、私スケボー今年始めました。10年前からこんなこと言ってる私の現在年齢なので、たぶん24は超えてると思います。

経験年数で何がわかるか

さてタイトルに戻って、経験年数で何がわかるか。

経験年数だろうとなんだろうと「情報を仕入れる＝何かを判断する材料にする」です。そして経験年数で何かを判断できるか。私はせいぜい冒頭に書いた「期待値設定するのに役立つ可能性のある話題の予想が立てられる」くらいです。これも予想に過ぎなくて、外すことも多々あります。外れた事実や反応を次の手の判断材料にするだけですが、よほど相手に対する事前知識がない時くらいしかこんな周りくどいことはしませんね。

年齢でわかること？せいぜい雑談ネタじゃないかな。とはいえぼっち属性だったので、同年代だったとしても別に同じ話題なんて……うん。ドンマイ。

経験年数が増えて私がどうなったか

新しい技術を習得する速度が上がりました。

未経験からの「経験n年」での到達点（それが測れると仮定して）に、かなり短時間で到達できると思っています。 コンテキストが違うので、このことを他の人には適用する気はありません。同じような人は多いだろうけれど、前提にはしない感じ。

で、何歳？

少なくとも昭和生まれらしい。前々時代ですね。年齢書く欄があるたびに指折りしてたりするし、結構な頻度で計算間違えて書いてます。

やるまえに確認せよと言う呪い

呪いにかかると鈍くなる。 仕事には数多くの呪いがある。

前置き

本稿での「確認」は「やるかどうかや進めるかどうかのお伺いを立てること」を指します。 完了の定義や制約条件等、内容の確認は違う軸の話。 確認を依頼する側（実行者、メンバー）と確認する側（仕事を依頼する者、リーダーやマネージャー等）が登場人物で、確認を依頼する側の視点ではなく、確認する側の自戒として書いています。

やる前に確認せよと言う呪い

確認は美徳のように扱われることも多く、何か問題が起こったら「なぜ確認しなかったんだ！」と言ったり、チェックシートを作ってみたり、頻繁にするように指示したり。そんなマイクロマネジメント万歳な事をのたまいつつ、「自分で考えて行動しない」とか愚痴ったりする。何かがおかしい。何がおかしいのかを考えてみる。

「やる前の確認」は待機を伴う同期処理になる。 確認がされるまでその作業を進めることはできない。 その間に他のことをすれば無駄にならないと言うかもしれないが、待たなくていいのとは比べるべくもなく、スイッチングにかかるコストは非常に軽視されている。スイッチングのコストを過小に見積もって、うまく行くはずがない。マルチタスクが効率的だと言うのが幻想なことくらい、そろそろ当たり前の話になってほしい。

また、確認を依頼する際に期限を指定することはあまりない。 往往にして確認を依頼する側の方が立場が弱く、依頼された側は多忙なもの。依頼する側が期限を切るのは難しいだろう。仕事は立場の上下関係ではなく協力関係であるべきなので、これが難しい時点で何かがおかしいのだけれど、現実は現実として受け入れなければ話が進まない。 このため、確認を依頼した側はいつ返ってくるかわからない確認結果に心をさきながら待つことになる。 確認しなかった場合に冒頭で挙げたような「なぜ確認しなかったんだ！」と言うような関係では当然そうなる。

「やった後に確認」だと何が問題なのか。 手戻りが大きい、無駄なコストをかけることになる、、、などが挙げられるだろうが、手戻り（これも嫌いなのだけど）の大小やコストの有効無効を判断することは、確認を依頼する側にはできない。その判断ができるほどの情報を持っているのであれば、おそらく確認は不要になる。ここにジレンマがあり、判断できない方に確認のトリガーを任せているところに無理がある。

このように情報弱者に確認トリガーを押し付けると、あらゆることを「やる前に確認する」しかなくなる。 確認が必要かどうかの判断がつかないのに、確認をしなかったら「なぜ確認しなかったんだ！」と責められるわけだから。 当然確認するためのコミュニケーションにコストがかかるし、いちいち立ち止まるから遅くなる。確認待ちの間は他のタスクを行っていても返答の待ち受けるスレッドは常駐せざるを得ないので余計だ。 そのうち確認していいかの確認をすることになっても不思議ではないし、実際そうなっているのを見ることもある。

「やる前に確認する」はおかしい。 おかしいにも関わらず、誰にも指示されていないのに「やる前に確認しなければならない」と思い込んでいたりする。これまでの経験から思い込まされていたりするんだろう。 このようなおかしいことをやってしまうのは、正しく 呪い なんだろう。

やる前に確認が必要なものは、確認の必要性を判断できる側がするべき指示。 これに対して「やる前に確認せずに進めたこと」を責めるのはお門違い。 確認を指示されていたのにそれを無視したとしたら問題ではあるが、責められることは確認しなかったことではなく、指示に従わなかったことになる。 と言うことで、確認タイミングも指示するのが正しい。ようこそマイクロマネジメントへ……あれ、おかしいな。

マイクロマネジメントの何が悪いって話もあるが、それはさておき。 これを避けるため、つまり「やる前の確認」を実行者が自発的に行うためには、情報を持つ必要がある。判断しきる情報があればそもそも不要だが、そこまでいくと最初の「やれ」と言う指示から不要になるので堪えておこう。少なくとも「確認が必要かどうか」を判断するための情報はあって、最低限この情報を与えなければならない。もしくはその情報を当然知り得る環境を整えなければならない。ここで誤ってはいけないのは、後者の場合に「なぜその情報を知らなかったんだ」と責めること。情報を当然知り得る環境とは、例えばWikiやチャットなどに書く、ミーティングで言及する、などになる。環境を準備してそれで情報を得られていないとしたら、それは情報を知らなかったことを責めても意味はない。対象個人と環境とのミスマッチに過ぎない。個人よりは仕組みに帰属させたい。

仕事には数多くの呪いがある。 呪いにかかると鈍くなる。 呪いが解けたらどうなるか。鈍の対になるものは何か。鈍いには鋭い。鈍感には敏感。後者で居たい気はする。