読書感想文です。
先日参加したイベントで紹介されていた本です。 ryu-rand.hatenablog.com
自分はいま少人数チームでリードエンジニアを務めているので、実装以外にもいろいろとやります。 その中でも、自分たちの製品はどんな課題を解決するのか、自分たちはチームとしてどこを目指していくのか、などの見定めや定義づけはまだまだ試行錯誤中です。 そのあたりの参考になればと思ったのがこの本を読んだきっかけです。
プロダクトマネージャーの考え方、やるべきことがやや抽象的に書かれています。 技術的な視点では書かれていないので、非エンジニアでも問題なく読めると思います。 ポイントポイントで参考になる点がありましたが、同じ内容の繰り返しもあり、記述はやや冗長かなという印象です。 チャプター名が具体的に書かれているので、気になる箇所をピックアップして読むのがおすすめです。
こんちは、じぬ（@reximology）です。
プロダクトマネージャーカンファレンス 2019 というイベントに参加してきました。
現在は少人数チームで開発を行っているため、エンジニアでもこういったプロジェクト開発を推し進める知見を持っていた方がスムーズに進めていけるのでは、というところから参加を決めました。 余談ですが、プロダクトマネージャーは PdM と略す場合が多いようです。（PM と記載してる例もありましたが
初日の夜はネットワーキングがありました。 自分は OKR のテーブルで話をしたのと、pixiv ブースでセッションの詳細を話してきました。
共通内容として感じたこと、まず PdM のミッション。
その上で、以下の特性がある。
各社で PdM に求める役割やスキル、育成、評価、採用の方法は手探りな状態という印象だった。 それでもデータドリブンや現場の知識など、エンジニアから PdM の働きをするとっかかりが多いということを知れたのは収穫だった。
こちらのブログでまとめてくださっています。 takaking22.com
読書感想文です。
メンターから技術戦略担当まで、マネジメントに関わる仕事のノウハウが管理対象の規模に応じて段階ごとに書かれている。 著者の体験に基づいているため事例がイメージしやすく、翻訳が良いこともあってかなり読みやすかった。
こんにちは、じぬ（@reximology）です。
EOF 2019 というイベントに参加してきました。これはエンジニアリングマネジメントを主題としたカンファレンスです。 eof.connpass.com
ここでは参加したセッションと、特に印象深かった点をまとめます。
参加したセッションは次の通りです。（タイムスケジュール）
本イベントの概要説明などです。カンファレンスの価値は廊下にある（セッション後に参加者同士でコミュニケーションがとれる場があること）という話をしてました。そこに繋がる流れで隣の人となんかしゃべってくださいはびっくりしましたが、どうにか自己紹介して交流できました。
カイゼン・ジャーニーの著者である市谷 聡啓さんのセッション。
www.slideshare.net
https://www.amazon.co.jp/dp/B078HZKLMBwww.amazon.co.jp
弊社も含めてやはり課題は似たようなものが多いんだなと言う印象です。組織規模の拡大によって無視できなくなる技術負債、エンジニア採用、継続的なチャレンジ課題、文化醸成、などなど。 マネジメントやチーム作りは新卒やよほどの技術スペシャリストでなければ一度はぶつかる課題かと思うので、エンジニアならたいていの人にとって身近な話題だと思います。 それだけに講演を聴くだけでもいろいろと学んだ気になることが多いです。ですがそこでとどめず、自分の振る舞いや自分のチームにおいてどう活かすか、まで踏み込めると正しく血肉にできるのかな、と感じます（自戒）。
聞けなかった講演の資料をまとめようと思ってましたが、こちらでまとめてくださってたので貼っておきます。 medium.com
こんにちは、じぬ（@reximology）です。
これは Unity ゆるふわサマーアドベントカレンダー 2019 #ゆるふわアドカレ 24 日目の記事です。
この記事では、Unity 用 SDK 開発において遭遇したトラブルと、その解決に至るまでを紹介します。 ※ 本記事は調査手順をなぞりたいと思い時系列で記述していますが、結論だけ知りたい方は解決をご覧ください。
自分は AROW というサービスの開発を行っており、その一部として Unity 用 SDK を提供しています。 SDK は、開発者登録を行うだけでなんと無料で使うことができます（これは宣伝）。
さて、SDK は提供時に DLL 化を行っています。今回紹介するのは、DLL に関連する話です。
開発環境は次のとおりです。（両刀使いのため時々 Windows が出てきますがメインは Mac です）
GUI から作ることもできますが、自動化したかったので CLI で作成することを考えます。
ドキュメント を確認し、mcs というコマンドを使うことを確認しました。
（当時どのようにインストールしたかは不明ですが、おそらく brew install mono で環境を構築したかと思います）
実際に DLL を作成するには、以下のようなコマンドを実行しています。（一部省略）
mcs \ -r:$(UnityDirectory)/Contents/Managed/UnityEngine.dll \ -target:library \ -recurse:'Assets/Scripts/*.cs' \ -out:AROW.dll
この場合だと UnityEditor への参照は含まれていないため、Editor 用が必要な場合はもう一つ DLL を作成する必要があります。
string str = "abc.def"; string[] ary = str.Split('.'); // ここでエラー！
問題になったのは、string.Split です。これは引数の文字で文字列を区切り、配列で返すメソッドです。
開発中、つまり Unity で検証している際にエラーはありませんでした。
しかし、上記処理を含むファイルを DLL 内部に含むと、次のエラーが発生するようになりました。
MissingMethodException: Method 'string.Split' not found.
正直、このエラーだけではなにが問題なのか判断できません。 同じ処理を Unity 2018 で実行した場合、もう少し詳細なエラーが確認できます。
MissingMethodException: string[] string.Split(char,System.StringSplitOptions)
コールしたいのは char を一つ受け取るメソッドですが、エラーが出ているのは別にオーバーロードされたメソッドのようです。
まず、このメソッドについてドキュメントを確認します。
使おうとしているのはこちらです。
params char[] と宣言されているため、引数が char 一つでも該当します。
逆に、エラーが示すような引数のメソッドは定義されていません。
試しに、リフレクションでメソッドを出力してみます。
// string の関数を出力 var s = ""; foreach (var v in typeof(string).GetMethods(BindingFlags.Public | BindingFlags.Instance)) { s += v.ToString(); s += "\n"; } Console.WriteLine(s);
// Unity での実行結果 ... System.String[] Split(Char[]) System.String[] Split(Char[], Int32) System.String[] Split(Char[], System.StringSplitOptions) System.String[] Split(Char[], Int32, System.StringSplitOptions) System.String[] Split(System.String[], System.StringSplitOptions) System.String[] Split(System.String[], Int32, System.StringSplitOptions) ...
やはり、エラーとなっている char, System.StringSplitOptions を引数にとる string.Splitは見当たりません。
ところが改めてドキュメントを見直すと、.NET Core にはこのメソッドが存在しています。
しかも第二引数にデフォルト値が宣言されているため、char 一つを受け取る場合は本来呼び出したかったものと見分けがつかないはずです。
つまり、「自分たちとしては params char[] のメソッドを呼び出したかったが、コンパイルされる時点では char, System.StringSplitOptions のメソッドに対して紐付けが行われた。
ただし実行時にはそのメソッドは存在しないためエラーが発生している。」と推測できます。
開発中も DLL 利用時も、実行しているのは Unity であるため共通のはずです。
となると、DLL を作成した際に利用した mcs に原因があると考えられます。
普段の Unity が利用しているコンパイラはどこにあるのでしょうか。
Unity 内で mcs に関する検索を行うと、次の場所でそれらしきファイルが発見できます。
bin には mcs、lib には mcs.exe が存在します。
// Mac /Applications/Unity/Hub/Editor/2017.4.25f1/Unity.app/Contents/MonoBleedingEdge/bin/mcs // Windows だと少しパスが異なる /c/Program\ Files/Unity/Hub/Editor/2017.4.25f1/Editor/Data/MonoBleedingEdge/bin/mcs
おそらくこれなんだろうなと思いつつ、Unity から利用されている確証がほしいところです。 そこでこんな実験をします。
Unity が使っているとおぼしきファイルをリネームしました。 後述しますが、ファイル名を変えたのは exe ファイルです。 参照するファイルがなくなっていれば多分エラーになるでしょう。 戻せば回復するでしょう。多分きっと。 ※ 元に戻せるようきちんと確認してから行ってください
ApplicationException: Unable to find csharp compiler in /Applications/Unity/Hub/Editor/2017.4.25f1/Unity.app/Contents/MonoBleedingEdge/lib/mono/4.5 UnityEditor.Scripting.Compilers.MonoCSharpCompiler.GetCompilerPath (System.Collections.Generic.List`1[T] arguments) (at /Users/builduser/buildslave/unity/build/Editor/Mono/Scripting/Compilers/MonoCSharpCompiler.cs:88) UnityEditor.Scripting.Compilers.MonoCSharpCompiler.StartCompiler () (at /Users/builduser/buildslave/unity/build/Editor/Mono/Scripting/Compilers/MonoCSharpCompiler.cs:59) UnityEditor.Scripting.Compilers.ScriptCompilerBase.BeginCompiling () (at /Users/builduser/buildslave/unity/build/Editor/Mono/Scripting/Compilers/ScriptCompilerBase.cs:43) UnityEditor.Scripting.ScriptCompilation.CompilationTask.QueuePendingAssemblies () (at /Users/builduser/buildslave/unity/build/Editor/Mono/Scripting/ScriptCompilation/CompilationTask.cs:191) UnityEditor.Scripting.ScriptCompilation.CompilationTask.Poll () (at /Users/builduser/buildslave/unity/build/Editor/Mono/Scripting/ScriptCompilation/CompilationTask.cs:137) UnityEditor.Scripting.ScriptCompilation.EditorCompilation.CompileScripts (UnityEditor.Scripting.ScriptCompilation.ScriptAssemblySettings scriptAssemblySettings, System.String tempBuildDirectory, UnityEditor.Scripting.ScriptCompilation.EditorScriptCompilationOptions options, UnityEditor.Scripting.ScriptCompilation.EditorBuildRules+TargetAssembly[]& notCompiledTargetAssemblies) (at /Users/builduser/buildslave/unity/build/Editor/Mono/Scripting/ScriptCompilation/EditorCompilation.cs:749) UnityEditor.Scripting.ScriptCompilation.EditorCompilation.CompileScripts (UnityEditor.Scripting.ScriptCompilation.EditorScriptCompilationOptions options, UnityEditor.BuildTargetGroup platformGroup, UnityEditor.BuildTarget platform) (at /Users/builduser/buildslave/unity/build/Editor/Mono/Scripting/ScriptCompilation/EditorCompilation.cs:627) UnityEditor.Scripting.ScriptCompilation.EditorCompilation.TickCompilationPipeline (UnityEditor.Scripting.ScriptCompilation.EditorScriptCompilationOptions options, UnityEditor.BuildTargetGroup platformGroup, UnityEditor.BuildTarget platform) (at /Users/builduser/buildslave/unity/build/Editor/Mono/Scripting/ScriptCompilation/EditorCompilation.cs:896) UnityEditor.Scripting.ScriptCompilation.EditorCompilationInterface+<TickCompilationPipeline>c__AnonStorey3.<>m__0 () (at /Users/builduser/buildslave/unity/build/Editor/Mono/Scripting/ScriptCompilation/EditorCompilationInterface.cs:219) UnityEditor.Scripting.ScriptCompilation.EditorCompilationInterface.EmitExceptionAsError[T] (System.Func`1[TResult] func, T returnValue) (at /Users/builduser/buildslave/unity/build/Editor/Mono/Scripting/ScriptCompilation/EditorCompilationInterface.cs:75) UnityEditor.Scripting.ScriptCompilation.EditorCompilationInterface:TickCompilationPipeline(EditorScriptCompilationOptions, BuildTargetGroup, BuildTarget)
やはりエラーになりました。ということは、Unity が利用しているコンパイラはこの mcs で間違いないでしょう。
細かい話をすると、バイナリファイル（bin/mcs）をリネームしてもエラーにはなりません。エラーになるのは実行ファイル（lib/.../mcs.exe）を対象にしたときです。
しかし mcs.exe をリネームすると、bin/mcs を直接実行した場合にもエラーが出ます。
$ /Applications/Unity/Hub/Editor/2017.4.25f1/Unity.app/Contents/MonoBleedingEdge/bin/mcs --version Cannot open assembly '/Applications/Unity/Hub/Editor/2017.4.25f1/Unity.app/Contents/MonoBleedingEdge/bin/../lib/mono/4.5/mcs.exe': No such file or directory.
この挙動から、bin/mcs が内部で mcs.exe を利用していると判断できます。
そのため、DLL 化する際にはこの mcs を使うことで Unity 開発時と同じ環境のコンパイルができるはずです。
通常の mcs と Unity 内部の mcs を比較すると、次のような差が確認できます。
$ mcs --version Mono C# compiler version 6.0.0.0 $ /Applications/Unity/Hub/Editor/2017.4.25f1/Unity.app/Contents/MonoBleedingEdge/bin/mcs --version Mono C# compiler version 5.0.1.0
ドキュメントにあった .NET の差分から推察すると、新しい方の mcs では .NET Core の実装を参照していると考えられます。
（この点については未検証です）
Mcs := $(UnityDirectory)/Contents/MonoBleedingEdge/bin/mcs make_dll: $(Mcs) \ -r:$(UnityDirectory)/Contents/Managed/UnityEngine.dll \ -target:library \ -recurse:'Assets/Scripts/*.cs' \ -out:AROW.dll
先ほど述べたとおり、Unity 内部の mcs を利用することで今回の問題は解決できました。
開発環境の精査を怠ったことが原因となったトラブルでしたが、コンパイラについて調査するいい機会となりました。
Unity 2018.4 で試したところ、先ほどの mcs.exe をリネームしてもエラーが起きませんでした。 おそらく原因は、こちらにあるように Unity 2018.3 以降の .NET 4.x 系統では Roslyn が使われていることかと思われます。
Roslyn は csc を使っています。
そのため、次の csc(.exe) をリネームすると同様にエラーが発生します。
// Mac /Applications/Unity/Hub/Editor/2018.4.0f1/Unity.app/Contents/Tools/Roslyn/csc // Windows C:\Program Files\Unity\Hub\Editor\2018.4.2f1\Editor\Data\Tools\Roslyn\csc.exe
Exception: 'C:\Program Files\Unity\Hub\Editor\2018.4.2f1\Editor\Data\Tools\Roslyn\csc.exe' not found. Is your Unity installation corrupted? UnityEditor.Scripting.Compilers.MicrosoftCSharpCompiler.ThrowCompilerNotFoundException (System.String path) (at C:/buildslave/unity/build/Editor/Mono/Scripting/Compilers/MicrosoftCSharpCompiler.cs:65) UnityEditor.Scripting.Compilers.MicrosoftCSharpCompiler.StartCompilerImpl (System.Collections.Generic.List`1[T] arguments, System.String argsPrefix) (at C:/buildslave/unity/build/Editor/Mono/Scripting/Compilers/MicrosoftCSharpCompiler.cs:112) UnityEditor.Scripting.Compilers.MicrosoftCSharpCompiler.StartCompiler () (at C:/buildslave/unity/build/Editor/Mono/Scripting/Compilers/MicrosoftCSharpCompiler.cs:220) UnityEditor.Scripting.Compilers.ScriptCompilerBase.BeginCompiling () (at C:/buildslave/unity/build/Editor/Mono/Scripting/Compilers/ScriptCompilerBase.cs:60) UnityEditor.Scripting.ScriptCompilation.CompilationTask.QueuePendingAssemblies () (at C:/buildslave/unity/build/Editor/Mono/Scripting/ScriptCompilation/CompilationTask.cs:228) UnityEditor.Scripting.ScriptCompilation.CompilationTask.Poll () (at C:/buildslave/unity/build/Editor/Mono/Scripting/ScriptCompilation/CompilationTask.cs:135) UnityEditor.Scripting.ScriptCompilation.EditorCompilation.CompileScriptAssemblies (UnityEditor.Scripting.ScriptCompilation.ScriptAssembly[] scriptAssemblies, UnityEditor.Scripting.ScriptCompilation.ScriptAssemblySettings scriptAssemblySettings, System.String tempBuildDirectory, UnityEditor.Scripting.ScriptCompilation.EditorScriptCompilationOptions options, UnityEditor.Scripting.ScriptCompilation.CompilationTaskOptions compilationTaskOptions, UnityEditor.Scripting.ScriptCompilation.EditorCompilation+CompileScriptAssembliesOptions compileScriptAssembliesOptions) (at C:/buildslave/unity/build/Editor/Mono/Scripting/ScriptCompilation/EditorCompilation.cs:1149) UnityEditor.Scripting.ScriptCompilation.EditorCompilation.CompileScripts (UnityEditor.Scripting.ScriptCompilation.ScriptAssemblySettings scriptAssemblySettings, System.String tempBuildDirectory, UnityEditor.Scripting.ScriptCompilation.EditorScriptCompilationOptions options, UnityEditor.Scripting.ScriptCompilation.EditorBuildRules+TargetAssembly[]& notCompiledTargetAssemblies, System.String[]& notCompiledScripts) (at C:/buildslave/unity/build/Editor/Mono/Scripting/ScriptCompilation/EditorCompilation.cs:1047) UnityEditor.Scripting.ScriptCompilation.EditorCompilation.CompileScripts (UnityEditor.Scripting.ScriptCompilation.EditorScriptCompilationOptions options, UnityEditor.BuildTargetGroup platformGroup, UnityEditor.BuildTarget platform) (at C:/buildslave/unity/build/Editor/Mono/Scripting/ScriptCompilation/EditorCompilation.cs:939) UnityEditor.Scripting.ScriptCompilation.EditorCompilation.TickCompilationPipeline (UnityEditor.Scripting.ScriptCompilation.EditorScriptCompilationOptions options, UnityEditor.BuildTargetGroup platformGroup, UnityEditor.BuildTarget platform) (at C:/buildslave/unity/build/Editor/Mono/Scripting/ScriptCompilation/EditorCompilation.cs:1377) UnityEditor.Scripting.ScriptCompilation.EditorCompilationInterface+<TickCompilationPipeline>c__AnonStorey5.<>m__0 () (at C:/buildslave/unity/build/Editor/Mono/Scripting/ScriptCompilation/EditorCompilationInterface.cs:331) UnityEditor.Scripting.ScriptCompilation.EditorCompilationInterface.EmitExceptionAsError[T] (System.Func`1[TResult] func, T returnValue) (at C:/buildslave/unity/build/Editor/Mono/Scripting/ScriptCompilation/EditorCompilationInterface.cs:97) UnityEditor.Scripting.ScriptCompilation.EditorCompilationInterface:TickCompilationPipeline(EditorScriptCompilationOptions, BuildTargetGroup, BuildTarget)
Visual Studio で DLL を作成した場合は今回の問題は起きませんでした。 実際に実行されているコマンドは次のものです。
/Library/Frameworks/Mono.framework/Versions/5.18.1/lib/mono/msbuild/Current/bin/Roslyn/csc.exe /noconfig /nowarn:1701,1702,2008 /nostdlib+ /errorreport:prompt /warn:4 /define:DEBUG /errorendlocation /preferreduilang:ja-JP /highentropyva+ /reference:/Library/Frameworks/Mono.framework/Versions/5.18.1/lib/mono/4.7-api/mscorlib.dll /reference:/Library/Frameworks/Mono.framework/Versions/5.18.1/lib/mono/4.7-api/System.Core.dll /reference:/Library/Frameworks/Mono.framework/Versions/5.18.1/lib/mono/4.7-api/System.dll /debug+ /debug:portable /optimize- /out:obj/Debug/Temp.dll /subsystemversion:6.00 /target:library /utf8output MyClass.cs Properties/AssemblyInfo.cs "/var/folders/j2/xntwf0xj7311rg06_2p570d00000gp/T/.NETFramework,Version=v4.7.AssemblyAttributes.cs"
試したところ、mscorlib を指定することで本現象が解決できるようです。
ただし mcs で試した場合は System などで多重定義のエラーが起きるため、noconfig などのオプションが必要になります。
csc に乗り換えるリスクや、実行コマンドが複雑になることを避けるため、今回の問題解決としてはこれらの手段は採用しませんでした。
※ やりたいことはまだ途中なんですが、キリがよくなったのでいったんまとめています
GitHub で Wiki を書くと、サイドバーに積み上がっていきます。 これは増えすぎると隠れてしまうので、一覧で表示されればいいなと思います。
Wiki はそれ自体もリポジトリを clone することが可能です。 Wiki ページの右下で URL を確認できます。
今回の場合だとこんな感じです。
https://github.com/ryuj/Unity.wiki.git
確認したところ、生成したページが .md ファイルとして存在します。 トップページは Home.md です。 なので、以下のように対応を考えます。
上記に対応したスクリプトは以下です。 これを実行すれば、Home.md に子ページの一覧を作成できます。 （Ruby は思いつくまま書ける感じが好きですが、Ruby ぽく書けているのかは未知数）
HOME_FILE = "Home.md" def main html = "" Dir.glob("*.md").each do |file| next if file == HOME_FILE base = File.basename(file, ".md") s = "* [#{base}](./#{base})\n" html << s end File.open(HOME_FILE, "w") { |io| io.puts html } end main
現状、スクリプトを手動で実行しなければ一覧化できません。 Wiki はブラウザ等で編集することが多いと思います。 なので、ブラウザ等で編集された際に上記スクリプトを動かして Home.md を更新する、というのがベストです。
git log で確認したところ、ブラウザからの編集もコミットログで残っているため、おそらく普通に push を検知できれば行けそうです。 未確認ですが、このあたりはおそらく webhook で対応できるのでは、と予想してます。（あとでやる、つもり、、、）
本日は、こちらの勉強会に参加しました。
unity-designers-cafe.connpass.com
しばらく勉強会は行ってなかったので、よい刺激になりました。（当日朝まで補欠だったんで不参加のつもりでしたが）
本イベントはデザイナーの方が中心のイベントです。自分はエンジニアですが、以下の目的で参加しました。
一つ目はまぁ誰しも聞きたい内容だと思うのですが、今回は特に二つ目に興味がありました。自分は以前のチームでもデザイナー向けのツールを作った経験があり、以下の実感がありました。
そのため、どんな課題があるか、またそのあぶり出しにどんな取り組みが行われているのか、という点に興味がありました。
上記の目的から言うと、@LandyNagata さんの「プログラマに相談したらデザイナーの仕事が楽になった話」が一番参考になりました。（もちろん他の発表も非常に面白かったです）
ここでは、実際にエンジニアが作った事例が紹介されていました。
特に5番のビューアは、プランナーのデータ設定時やエンジニアのデバッグ時にも役立ちそうだなと感じました。また、ツールで解決すべき単調な作業を「お刺身たんぽぽ」と表していたのも印象的です。（エンジニア観点で言えば、名前をつけるのは課題解決への第一歩だと思います）
懇親会でもそのあたりのお話をさせていただき、各社似たような課題を感じているのは実感できました。改善の取り組みとしては、以下のようなものが挙がっていました。
弊社でも似たような取り組みを行っているため、少なくとも間違ってはいなそうだという実感が得られたことや、自分たちの取り組みから得られた知見もぜひ発表してみたいなと感じられたのは、非常に良い収穫だったと思います。